Should managers still code?

When I've worked as an engineering manager I've found the advice to "stay out of the critical path of getting features into production" to be very helpful. It's difficult to commit to coding timelines as a manager, and it harms your team if you are the bottleneck to shipping something.

But... keeping your hands in the mix elsewhere helps you stay informed and make better decisions. I found writing things like internal debugging tools, documentation, helping out on code review and architectural discussions, building example features against APIs etc were all good uses of my time.

An interesting trend I've observed over the past couple of years is that a lot of my friends who had moved into engineering management and stopped coding completely are picking up more coding tasks now thanks to LLMs - previously spending ~4 hours getting a development environment working and getting back up to speed wasn't justifiable, but LLM assistance means they can now get something small and useful done in just an hour which is much easier to carve out time for.

I've bounced back and forth between IC and EM (intentionally) and I've seen some that get very very close then completely blow it with one of these. One in particular would put people through management training for a full day each week for months, give them a very senior director, all the "right things" but then cut their IC duties by maybe 10-15% at most and give them a team of 12 people to manage. And they wondered why fully half of new managers wanted to go back to IC work after a year or two.

The best realistic thing I've seen, and my current workplace, is pretty good with small teams and training and all that, but basically doesn't offer any pay increase from upper level IC to first-level management and so you have to be okay with basically 20% more work for the same money. It's not perfect but one benefit is you don't get any managers who are only in it for the money.

At the same time, they also tend to start interfering in the solutions proposed by their team. It hard to stave off that temptation.

it depends. Last ~3 years i was CTO of small company - with a software team of 7-10. With the idea of - no-more-coding (TM). Just the other 90% - from cleanup repos and jira etc project things - to organise proper reviews and workflows - process things, etc, to.. pushing infrastructure, hiring and pitching to investors/clients. But the codebase was.. not ideal. It was hard and tempting but i managed not to touch it directly, only did rise architectural-and-similar-level issues, and did (somewhat nitpicky) code reviews - like, date-arithmetic IS very important, pretty-please. Still, had to build a crawler over the production-codebase to visualise the event-flows and map consequences - a reverse-engineering live-Documentation, kind-a. Scratching my own itch? pfft. (hint: There was no other docs..)

But then there were some small non-essential projects that would have been complete distraction for the team.. so i took one, then another. In nodejs which isn't my cup of tea - so even better, learned some things the hard way. Though.. lucky they were rarely needing support, or it would have become a chore.

Then, one day, the company was acquired, and.. i am not a CTO anymore, but a (tech and also non-tech) Lead of some future greenfield project, ~re-factor with diff.goals. So here we go - research, architect, code, hire, discuss, demo, eh.. usual tiny-startup thing - except that the politiking and the now-everyday-a-new-policy chase me away.

So.. IMO one has to keep some of the programming skills sharp. In order to stay relevant. But this applies when you are 1 level away from actual coding. If farther.. probably no time, and no point. Although.. too long staying hands-off, and there may be no coming back - and losing grasp of how-it-feels-like to be in the trenches.

> They don’t know how to play politics and compete for resources against other managers and make sure their team gets raises and promotions.

Clearly those are not the skills Steve Jobs valued.