Of course they should still code, otherwise they're not engineering managers, they're project/product managers, and good engineers will not follow those people.
Whenever we talk about EM duties, it's always a list of fuzzy, empty words:
> Owning the team's strategy and roadmap, and ensuring efficient execution.
This is project management.
> Making decisions to ensure that the team is working on the right things and saying no to the things that don't matter.
This is product management.
> Dealing with fires, escalations, and other crises that pop up all of the time.
How can an EM that doesn't code deal with fires? The only thing they can do is pull the sleeve of someone else who does code, and then, what, hang behind their shoulder until the fire is put out?
> Building a strong culture within the team so that people are engaged, challenged, and motivated.
This is meaningless. We're not children.
> Mentoring and coaching your reports so they get better and can have more work delegated to them, thus increasing output further.
Mentoring them at what? If an EM doesn't code, how can they mentor in an area that's relevant to the mentee (i.e. a coding engineer)? They can coach them on moving Jira tickets more effectively, or playing office politics better?
> Managing the team's stakeholders so they can offer their steer to the team early and often.
Again, product management.
> Actively performance managing the team so that superstars can continue to shine and underperformers can be coached or exited.
Combination of meaningless and project management. In order to be able to evaluate someone's performance, you need to know their work. If you don't, the only metric you have is number of tickets, or "velocity" or whichever other bullshit metric you use because you're not in the trenches.
> Building close working relationships with other teams so that smooth collaboration happens across the organization, leading to a better and more cohesive product.
Office politics.
The only one that make sense is hiring and retaining great people, but you can't do either without being a technical person.
EMs that don't code making technical decisions is a showcase for divorcing decision making from suffering the consequences of those decisions. And having teams with EMs + tech leads + team leads etc. is just making things worse by diluting the responsibility.
Whenever we talk about EM duties, it's always a list of fuzzy, empty words:
> Owning the team's strategy and roadmap, and ensuring efficient execution.
This is project management.
> Making decisions to ensure that the team is working on the right things and saying no to the things that don't matter.
This is product management.
> Dealing with fires, escalations, and other crises that pop up all of the time.
How can an EM that doesn't code deal with fires? The only thing they can do is pull the sleeve of someone else who does code, and then, what, hang behind their shoulder until the fire is put out?
> Building a strong culture within the team so that people are engaged, challenged, and motivated.
This is meaningless. We're not children.
> Mentoring and coaching your reports so they get better and can have more work delegated to them, thus increasing output further.
Mentoring them at what? If an EM doesn't code, how can they mentor in an area that's relevant to the mentee (i.e. a coding engineer)? They can coach them on moving Jira tickets more effectively, or playing office politics better?
> Managing the team's stakeholders so they can offer their steer to the team early and often.
Again, product management.
> Actively performance managing the team so that superstars can continue to shine and underperformers can be coached or exited.
Combination of meaningless and project management. In order to be able to evaluate someone's performance, you need to know their work. If you don't, the only metric you have is number of tickets, or "velocity" or whichever other bullshit metric you use because you're not in the trenches.
> Building close working relationships with other teams so that smooth collaboration happens across the organization, leading to a better and more cohesive product.
Office politics.
The only one that make sense is hiring and retaining great people, but you can't do either without being a technical person.
EMs that don't code making technical decisions is a showcase for divorcing decision making from suffering the consequences of those decisions. And having teams with EMs + tech leads + team leads etc. is just making things worse by diluting the responsibility.
https://world.hey.com/dhh/we-once-more-have-no-full-time-man...