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

61–70 of 224 posts

Re: Common Mistakes of New Engineering Managers

#61

Post by alistairSH »

iandanforth wrote: post #53

I will disagree with one point. Neither eng managers nor tech leads should be doing project management. It is a unique skill and worth having someone explicitly in charge. They should own the structure of requirements docs, story breaktown, ticketing, jira processes, etc. While they may be somewhat technical they are more ensuring consistency and quality of process without burdening devs. The best team composition I…

I just left a team that was structured similarly. It was a pleasure managing them.

Team members were: - Manager (me), BA - managed backlog and some project management (actual title was principal dev, but she wanted a role change), 2x senior developers (both capable of architectural work), 2x developers, 2x test engineers, 0.5 Product manager (they report through their own branch of the org chart and cover several related products).

Additionally, I had 2.5 developers working on a different project, run as a separate agile team.

New team is 1 architect, 1 senior dev, 1 dev, 1 test engineer. BA and PM support comes from elsewhere, which is a big change fo me. Also in a new technical area (SRE vs 20 years of product/app dev). Fun, but stressful. I'll reserve judgement on the lack of BA/PM until I'm a few months into the role.

Re: Common Mistakes of New Engineering Managers

#62

Post by rathboma »

tacticalDonut wrote: post #38

I've come to realize that the promise of a 50/50 split between technical work and management after getting promoted to a data science technical lead manager is not something that is feasible within my org. Unfortunately, I'm at an organization in which the only way up is for ICs to move to management. So I'm leaving to another company that has much more runway for IC career progression. I've got a great relationship…

Lack of IC progression is a real problem.

I used to manage teams and missed engineering too much, so I quit to be a freelance engineering consultant. It felt like the best way to progress as an IC for me.

Bigger tech companies do a better job of IC career paths than others, but it still feels like your influence is muted compared to managers.

Re: Common Mistakes of New Engineering Managers

#63

Post by alistairSH »

daenney wrote: post #21

In about 90% of companies I’ve seen they expect you to do all the manager things and be an engineer too. It’s not so much a mistake individuals make as that it’s an explicit expectation that you’ll be wearing multiple hats. Folks generally get bombarded to manager because there’s no career ladder and this is what people think they have to do next to be able to continue to grow. And once you become a manager it doesn’…

Folks generally get bombarded to manager because there’s no career ladder

That's a pretty serious organizational flaw. At my employer, we have a well-define architect path that ends with "Technical Fellow" which on the job matrix is parallel with director-level management.

As a developer, I see 4 basic career tracks. Developer-track - caps out at principal developer, thought most people in this role are capable of architectural work within their product/tech-stack. Architect-track - high-level strategic technical decision making, caps out at Technical Fellow. Business-track - eventual move into a BA or Product Management role. Management-track - typically moves in scrum master or project management role, then into full-time personal management.

I started down the architect track, then hopped over to management because I wanted to challenge myself (at the time, leading people was WAY WAY WAY outside my comfort zone), not because I was forced into it due to lack of career growth.

Re: Common Mistakes of New Engineering Managers

#64

Post by cryptica »

dontreact wrote: post #57
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…

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 + 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.

Re: Common Mistakes of New Engineering Managers

#65

Post by gfodor »

1. Become an engineering manager

2. Stop coding

3. Do well for a few years until you become out of touch

4. Watch your team stop respecting you on technical subjects because you’re behind the times and too rusty but don’t know it so look foolish and are ignored when you give suggestions, which radically undermines your relationships with them as well as your ability to lead

5. Watch as your role morphs from a manager with chops and respect into a PHB, unless you happen to have been born with natural leadership skills (you probably haven’t)

6. Realize you are now just a mediocre manager who can no longer return to the engineering track since you cannot compete with other candidates

7. Drag yourself to retirement by slogging through life as a relatively poor middle manager

Re: Common Mistakes of New Engineering Managers

#66

Post by halfmatthalfcat »

iandanforth wrote: post #53

I will disagree with one point. Neither eng managers nor tech leads should be doing project management. It is a unique skill and worth having someone explicitly in charge. They should own the structure of requirements docs, story breaktown, ticketing, jira processes, etc. While they may be somewhat technical they are more ensuring consistency and quality of process without burdening devs. The best team composition I…

Can I just throw in a wrinkle, I'm what could be described (from this list) as an Engineering Manager and Tech Lead. I architect and implement solutions while also doing all the traditional managerial duties. I feel like I've been eaten alive lately on HN that this arrangement isn't possible and you cannot do both well, but I beg to differ.

Re: Common Mistakes of New Engineering Managers

#67

Post by halfmatthalfcat »

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…

I'm also in the same boat but my split is 80/20 engineering/managing. It may be the product of whose on my team (many independent and senior level devs) but there are those who need more help/mentoring/etc.

Contrary to a lot of the other commenters, I feel like this team works but it may be a product of it being made up of these people rather than a broader generalization.

Re: Common Mistakes of New Engineering Managers

#68

Post by halfmatthalfcat »

daenney wrote: post #21

In about 90% of companies I’ve seen they expect you to do all the manager things and be an engineer too. It’s not so much a mistake individuals make as that it’s an explicit expectation that you’ll be wearing multiple hats. Folks generally get bombarded to manager because there’s no career ladder and this is what people think they have to do next to be able to continue to grow. And once you become a manager it doesn’…

Is it pressure if that's what you want? I explicitly took my managing role because I was going to still be able to code, not in spite of it.

Re: Common Mistakes of New Engineering Managers

#69

Post by halfmatthalfcat »

gfodor wrote: post #65

1. Become an engineering manager 2. Stop coding 3. Do well for a few years until you become out of touch 4. Watch your team stop respecting you on technical subjects because you’re behind the times and too rusty but don’t know it so look foolish and are ignored when you give suggestions, which radically undermines your relationships with them as well as your ability to lead 5. Watch as your role morphs from a manager…

That's exactly why I was adamant (on condition of taking my current manager role) that I was always going to be coding. But I agree with most of these steps and when I was solely an engineer, I resented managers in 4 - 7. It was my goal to never be like that.

Re: Common Mistakes of New Engineering Managers

#70

Post by sanderjd »

iandanforth wrote: post #53

I will disagree with one point. Neither eng managers nor tech leads should be doing project management. It is a unique skill and worth having someone explicitly in charge. They should own the structure of requirements docs, story breaktown, ticketing, jira processes, etc. While they may be somewhat technical they are more ensuring consistency and quality of process without burdening devs. The best team composition I…

I think this is about right, but one sticking point I've found is: what kind of employee is the project manager? Who do you hire, what is the career trajectory? There is a temptation to have them be a manager, because hey, manager is in the name! But having gotten over that, there is a version of the job that is essentially entry level work; what you describe of managing the tickets and all the stuff is just not very high level work relative to what the rest of the team is doing. But then what is the progression? What are they trying to do after they've put in their years wrangling tickets? I think this can actually lead to a lot of unnecessary complexity. If you have a smart and ambitious person doing this job, they're going to naturally look for ways to make it more meaty. But it doesn't really need to be, so you're in a bit of a bind.

I think this is where the impulse to let the managers handle this as a small part of their job comes from. It's already clear who the managers are and what their career progression is, and handling stuff the team needs to unblock, which doesn't fit well into any particular box is already part of their job.

Post reply on HN