Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Common Mistakes of New Engineering Managers

ochronus.online

Post reply on HN
Print view View original

41–50 of 224 posts

Re: Common Mistakes of New Engineering Managers

#41

Post by mtberatwork »

ochronus wrote: post #15
goatinaboat wrote: post #14

Earlier quoted context omitted.

It's been over a decade since I've worked at a company with managers. However, it was common for the top programmers to make more money than their managers there. Programming and managing are completely different jobs that accomplish different things for the organisation, but they are typically arranged in a top-down fashion, the manager has power over the programmer. A manager's job is to do the function of interact…

There are companies where managers are truly in a supporting function. I'm not here to advertise but my last two jobs were like that.

I am doubtful. If the managers are writing the performance reviews, they are not in a supporting function at all. They are the arbiters of the subordinate's success in the company and that is a vertical relationship.

Re: Common Mistakes of New Engineering Managers

#42

Post by cryptica »

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.

Re: Common Mistakes of New Engineering Managers

#43

Post by alexpetralia »

lentil wrote: post #32

I've been an engineering manager for a couple of years. I'm still expected to do 50% engineering and 50% people management. As the article describes, it is a struggle to do both well. I don't see this responsibility split changing in my current role. I do often wonder what it would be like to be 100% people focused, and whether or not I would miss engineering too much. When my role first changed, I was very intimidat…

Great writeup, thank you.

Re: Common Mistakes of New Engineering Managers

#44

Post by varjag »

mtberatwork wrote: post #39
varjag wrote: post #25

Earlier quoted context omitted.

Depends on the org structure. In the one I was, architects were siloed off from the projects in a parallel sub-unit in the department, making it a bit of an ivory tower. They would issue design and scope decrees without facing any schedule pressures themselves. It took me a while to realize that most of my managing peers were quietly* ignoring them, delegating the actual decisions to the team. (*) As in, amend them t…

A situation like this can backfire quickly though. If the project fails or a setback occurs, the architects can quickly say that the engineers weren't following the original design and specifications.

Sure, but here lies the importance of my point: you get to be responsible either way, but at least you get to make your own call. If you turn that around and fail to deliver "because architects overdesigned it" everyone is going to give 0 f*cks - it's still your fault.

Re: Common Mistakes of New Engineering Managers

#45

Post by cryptica »

Under "Still doing much technical work":

> Focusing on your team’s health and growth will pay much higher dividends than still being half an engineer.

This logic is completely flawed as it assumes that the manager has reached a point in their career when they have nothing else to teach and nothing else to learn about coding. I'm an excellent coder and manager but I'm still learning all the time, even after 15 years. My team greatly benefits from me still being in touch with the code. Also, it helps me to make stronger arguments about why we should avoid using certain tools or blindly following hype.

The best engineering managers I've ever had were coding alongside the developers. The worst ones were not. This point about "Still doing much technical work" being a problem could not be further from the truth.

Re: Common Mistakes of New Engineering Managers

#46

Post by tenaciousDaniel »

As a new eng manager with about a year under my belt, #1 really hits the nail on the head. I couldn’t step away from the code because I was so used to IC.

Now as a result, I’m having very difficult discussions about promotions (or lack thereof), because I didn’t give my team the chance to grow.

Re: Common Mistakes of New Engineering Managers

#47

Post by BlargMcLarg »

cryptica wrote: post #42

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 betw…

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.

Re: Common Mistakes of New Engineering Managers

#48

Post by cryptica »

lentil wrote: post #32

I've been an engineering manager for a couple of years. I'm still expected to do 50% engineering and 50% people management. As the article describes, it is a struggle to do both well. I don't see this responsibility split changing in my current role. I do often wonder what it would be like to be 100% people focused, and whether or not I would miss engineering too much. When my role first changed, I was very intimidat…

It's kind of ridiculous for a company to 'expect' 50% engineering and 50% people management. It should be fluid and vary depending on the skill level of the team and the complexity and criticality of various projects over time. It shouldn't be fixed at 50% like some magic number.

Re: Common Mistakes of New Engineering Managers

#49

Post by jessermeyer »

cryptica wrote: post #48
lentil wrote: post #32

I've been an engineering manager for a couple of years. I'm still expected to do 50% engineering and 50% people management. As the article describes, it is a struggle to do both well. I don't see this responsibility split changing in my current role. I do often wonder what it would be like to be 100% people focused, and whether or not I would miss engineering too much. When my role first changed, I was very intimidat…

It's kind of ridiculous for a company to 'expect' 50% engineering and 50% people management. It should be fluid and vary depending on the skill level of the team and the complexity and criticality of various projects over time. It shouldn't be fixed at 50% like some magic number.

My hope is that those illustrate the 'spirit of the law' of taking both responsibilities equally serious. An issue is when middle management, so often comprised of literally minded number crunchers, interferes.

Re: Common Mistakes of New Engineering Managers

#50

Post by mtberatwork »

varjag wrote: post #44
mtberatwork wrote: post #39

Earlier quoted context omitted.

A situation like this can backfire quickly though. If the project fails or a setback occurs, the architects can quickly say that the engineers weren't following the original design and specifications.

Sure, but here lies the importance of my point: you get to be responsible either way, but at least you get to make your own call. If you turn that around and fail to deliver "because architects overdesigned it" everyone is going to give 0 f*cks - it's still your fault.

Yup, a tough call to make for sure and certainly grey areas with no clear path. When things fail, folks are quick to pass the buck and it's best to have as much recourse in your back pocket as possible. Don't give yourself a bigger mountain to climb so to speak.
Post reply on HN