Comment by cryptica | Hacker News Reader

Comment by cryptica | Hacker News Reader

I disagree about 'Still doing much technical work' being a problem. The author incorrectly infers that a manager writing code is going to take away developers' freedom. It's the opposite.

The way I manage developers is I design the system into small projects with separate concerns and which can be easily integrated together. With the participation of the team, we discuss and iterate over the design of interfaces between those components/projects.

Then when it comes time to implement, I assign 'ownership' of each project to a developer (with consultation with them). Then with the exception of a few basic guidelines, they can implement it however they want. We just do regular peer reviews of each other's work. We tolerate code style variations between different projects but each project must be internally consistent.

So far all our projects never needed more than 2 people to implement (each one having 1 developer as the project owner). At the end, we integrate maybe 10 different projects into the final working product (which gets its own repo).

This approach to development is extremely fast and robust (very few bugs which are easily caught and fixed). We don't even need special tools or programming languages. We just use plain JavaScript; never had the need to use TypeScript, the code is very easy to follow so it's not a problem.

All you need is to have small projects with clear separation of concerns. The trick is to not invent new abstractions; all technical abstractions should come from the specification and be understood by non-technical people. Also all components/projects should have simple interfaces between each other (only basic types that can easily be serialized into a JSON string). Different projects/components should never pass 'live instances' to each other; that would indicate poor separation of concerns.

Thanks for this.

I always held the opinion the "perfect" leader would be a hybrid of leading + devving, flexible enough to switch to 100% leading if need be, yet perfectly capable of picking up any technical work required, therefore never landing in the above situation out of inability.

I've never seen the problem "we don't have enough management capacity". On the other hand, I've seen plenty of non-/low-technical people become engineer managers, flailing their arms when there is too much work and not enough time. Only making the situation worse by stressing everyone out and taking up additional time in communication.

Those are the same problems. Managers flailing when there is too much work and not enough time means that there is not enough management capacity.

Not often called out because the short term effects of managers not existing are minimal, where as without engineers work stops. Long term without managers work continues but the value tends toward zero.

Frankly, personal anecdotes disagree. I don't need managers breathing down my neck because they aren't capable of resolving the issue, and end up overcommunicating with the customers, reinforcing behavior in customers to continuously ask for information instead of realizing the harm they are doing. "Two days" means "two days", no matter how many times you ask for a progress update or try to push it to one day.

Quality managers doing more than shoving boxes, that's a different story. We are definitely lacking high quality management capacity actually capable of preventing these situations from happening in the first place. I'd argue an overcapacity of managers actually actively prevents healthy relationships and usage of developers. People who aren't capable of doing anything useful in the moment, get antsy. It is a lot easier to get antsy as a manager than it is as a developer with an endless backlog.

That's also one of my arguments against full time managers. Management work is actually pretty rare, and full time managers tend to inflate it as to not twiddle their thumbs. As we move towards more "self-managing" practices (actual self-managing), total FTE of managers required drops significantly. It makes more sense to hybridize the role, so they keep an affinity with technology, than to put them on the "people manager" path which makes them rapidly lose their connection with technology and will quickly makes them stub their toe against Dunbar's Number. That's before considering tech will rapidly take away most of management's routine work. Their most important responsibilities don't take the majority of their time.

This is, in my opinion and experience, the main gist of the problem. Management work doesn't take full time and people get bored or scared they can lose their jobs if someone finds they didn't do much. So you end up with a lot of synch meetings, one-on-one's, backlog refinement meetings, weekly reviews etc.

And now most of the managers have a calendar full of meetings to coordinate projects with other managers that after that they meet with their teams to get feedback/answers they need to go back to the project meeting and tell other managers that tell their teams... If they were not managers but developers or engineers with technical knowledge, they would save a ton of time (and team's time) and solve most of the issues in a couple of sessions.

But most managers will disagree because they cannot see how the "difficult technical problems they helped solving" were not so complex in the first place... when you put together the people who knows about the code/projects/systems.

This is the winner right here, this is the manager who will get the most things done and deliver the most business value. This team would run in circles around a whole department of snowflakes. Focusing on being efficient at getting the actual job done, not wasting time on bullshit like figuring out how to have the perfect "one-on-one" to "make people happy". People on a team like this will be happy because they have a high level of purpose, craftmanship and impact.

I wouldn’t want to work for you, since it sounds like I would be put into a small box where I would have limited value and potential for growth. The only way to produce more value is to finish my projects faster. No thanks.

Well it's likely I wouldn't want to hire or sponsor you either because you seem to jump to conclusions and make incorrect assumptions.

The projects I manage are open source, I pay in crypto (which has been going up in price so my team is earning more over time) and I pay based on value added (small base sponsorship amount <essentially a monthly retainer> + generous bonuses at the end of each month based on delivered value) not lines of code or hours worked. I don't expect people to be fast, I never rush anyone. People can come and go whenever they want, all remote. They can change projects after they finished their current project (a clean working state). If they want to work multiple projects in parallel they can do this too if they have the capacity. As I said, projects are limited in scope so they get finished quickly, usually a few weeks to a month or so so people can still move around and tackle progressively more difficult projects.

I suspect that devs complete projects quickly because we have good separation of concerns and developers have a sense of ownership and independence. To top if off, we let developers work for other companies if they want to - At least one of them does and he creates more value for us than in his other company, in less time. We probably pay him more too thanks to increase in crypto prices... In fact he says he wants to quit the other company. He just liked to have it as a backup because we don't pay predictable income but it's getting high enough that he feels that he can take a chance.

I wasn't convinced of the gp commenter's sentiment about you being a less-than-ideal boss to work with but it seems you proved his/her point.

Not sure whether you actually understand the issue raised by him/her -- the process of defining, designing and architecting a solution is very much something that an junior engineer would aspire to be able to take responsibility for one day. But under your working model, only one person (you) would be mainly responsible for doing that, and other people could only prove their worth by doing their piecemeal work (the small and isolated "projects") faster.

Not saying that this is actually true, and from your original comment it seems that it might not be completely true, but that's what the the gp commenter wanted to say. And you seem to confirm it in this comment -- you praise people who work fast but haven't seen you mention about their code quality or "taste" in architecture or design.

... and I haven't mentioned the retaliatory vitriol. Seriously, talk about jumping to conclusions...

Personally, I would wonder how you assess "delivered value", given that this is basically one of the hardest problems to solve involving questions about asthetics, ethics, business management, leadership, capitalism and even the worth of a person's time... but I'd jump to my own conclusions and will assume you think you have figured it all out :)

When you code all the time for over a decade, you know what good code looks like. When you care about the product, you know what a well implemented feature looks like from the user's perspective. So it's easy to approximate value from these two aspects.

The people who work with me learn a lot about architecture because I explain everything. I only had 1 manager who had a similar style as me in my own career as a developer (out of over a dozen) and I wish I would have had more of them or that I could have worked for them longer.

You're assuming things because you've probably never seen a good manager in your life. It's difficult to imagine something better than the best you've known.

To put it more concretely, how many people have you been able to promote into a role like yours where they are defining the architecture, in the last 5 years?

For simpler projects (like simple front end applications), I usually let developers decide the architecture themselves (I mostly just offer advice). Since in those cases, architecture is not as critical.

I was myself overlooked for promotions for over 5 years (in spite of constantly asking for one). I was better qualified than my managers to be making architectural decisions but they only realized this after I left (since I started a competing project). So I know how it feels to not be given the chance. I even know what it feels like to have an incompetent person promoted as my boss.

That said, it doesn't make sense to put someone 100% in charge of architecture if they don't yet have the necessary skills. Some systems are extremely complex and easy to mess up architecturally so I wouldn't hand off this responsibility unless I knew that the next person would do it properly.

Reply on news.ycombinator.com