I've seen plenty of managers who increased team output 10% for a few months by coding and completely lost the thread in the meantime. That's how your entire team gets laid off. Leadership doesn't care how much code your team writes, they care that you're working on the right stuff.
An engineering manager's job is: take long-term ownership for the performance of the team. That might include aligning with leadership, marketing your team's work internally, hiring, performance management, team bonding, planning, retros, oncall coverage etc. etc, although sometimes you'll have a PM/tech lead/HR contact who handle some of these.
Every now and then, your bottleneck really is just writing more code (more common in smaller companies). In that case, jump in.
> your bottleneck really is just writing more code
You're characterising it as pure "code volume" question but it's completely not the point. Absolutely if they are coding just to directly increase the output of the team they are much better devoting that time to getting more output from the IC's they are managing.
But even better is coding in a way that helps the team overall work better. This can be because they do architectural work, they gain insight into the actual team challenges, it improves how they can estimate the time needed for different tasks, etc.
Yep, there's definitely a way to write code intentionally, for the reasons you listed, and I approve of that! But you'll see a lot of engineering managers coding because they are trying to help the team reach its next deliverable. This is usually short-sighted.
I think of it as the management control loop: "I have some spare cycles -> what is the most important work I can do for the team right now?" Coding can be the answer. But some people's control loop seems to be more like: "I have some spare cycles -> what is the most interesting/rewarding task I can do next?" The latter might lead to a lot more coding, but it's not good for the team.
No idea where these guys work where they can just roll up their sleeves and start coding. I would love to help out but there is zero time for me to code.
One of the reasons I keep doing it is because I know if I fall off the wagon it will very quickly translate into that situation. As long as I have everything set up like the actual devs do and know all the processes, it isn't a lot of time for me to jump in and do bits and pieces. And even though its a very slippery slope, there are absolutely cases where it takes longer to explain what I want than just to do it. Sometimes I will start it off to get the architecture right and then leave a trail of points to complete it with someone on the team. So there are times when it's a "time saver" and it's a win all round.
As an aside: If you're a line manager of a small coding pod, and your manager is very engaged in company planning and generally competent, then you can probably do a lot more coding. Someone has to do the organizational engineering work, and it's your manager, in this case. Now, if this individual ALSO wants to spend their time coding, then things can go very wrong indeed.
The worst possible scenario is that a manager doesn't know how to prioritize amongst their existing team, and/or doesn't want to say a difficult 'no' and tries to make up for it by coding in the evenings. That's someone who hasn't learned how to really fly the airplane yet.
> An engineering manager's job is: take long-term ownership for the performance of the team
This is a rather naive, mid-level management-style take.
The real EM job is to represent the team to the company, to be aligned with company priorities, and to be a backstop for the team. In other words, being the leader - the face, the prioritize, and the helper of the team.
Performance-style nonsense is what is used in warehouses and factories where the manager is responsible for number of units produced.
But in software, the goal is NOT to produce more but to produce correct/investigate correct/and maintain correct.
As such, EM is very different from warehouse-style management.
I'm not quite sure where you're getting "performance = maximizing units of output" from my post, as the whole point was the difference between squeezing out a little more code vs. keeping the team on track doing actually valuable stuff. Either way, I think we mostly agree here: the EM is the face of the team who makes sure the team, as a unit, is doing valuable work as a sustainable pace that's understood as such internally.
However, to be clear, software teams, engineers, and engineering managers are absolutely evaluated on their performance, which is a complex and subjective metric, and the manager is generally the one held responsible for it at the team level.
> However, to be clear, software teams, engineers, and engineering managers are absolutely evaluated on their performance,
Yes, and no one said that this kind of evaluation has produced long term success. It has widely been recognized that when upper management is more involved in evaluation rather than leading teams of managers themselves, they address issues and market conditions too late. Thus, affecting businesses negatively over and over.
In other words, managers are being asked to NOT perform to certain metrics/evals but to make choices that benefit the company - even if it falls outside any evaluation rubric.
Pardon my cynicism, but this doesn't really change anything. These companies are still evaluating their employees, just informally. They are still promoting and firing people. There are still teams who are doing well and teams that are not. There are teams that picked the right goals and met them, and teams that failed to deliver on their promises for yet another quarter. There are still teams with happy stakeholders and teams that infuriate everyone whom they interact with.
It doesn't matter how you measure it or try to ignore it, the buck still stops with the manager of each team.
There is plenty of words written on what the difference is between leading and managing.
True leaders are role models, not higher-ups, the ones where authority comes from competence, not position, showing the way, not just telling what to do, facilitating self-organization, giving direction, prioritizing, giving vision and perspective, not orders, fostering intrinsic motivation.
An engineering manager's job is: take long-term ownership for the performance of the team. That might include aligning with leadership, marketing your team's work internally, hiring, performance management, team bonding, planning, retros, oncall coverage etc. etc, although sometimes you'll have a PM/tech lead/HR contact who handle some of these.
Every now and then, your bottleneck really is just writing more code (more common in smaller companies). In that case, jump in.