They should be coding because they're "engineering" managers. What's the point of having engineering in your title if you're not actually practicing the craft?

They should be coding because they'll be able to relate to their supports in a deeper and more fulfilling way. They'll be able to mentor and provide guidance on technology best practices and patterns.

They should be coding because they'll be able to more accurately plan and execute projects. Understanding and applying the technology is understanding it's pitfalls and anticipating potential upcoming challenges.

The role where you're still hands-on on a team is sometimes called a Tech Lead Manager, and there is a ceiling to this role. The next step up is true Engineering Manager where you have to be able to talk to engineers on other teams and gather information without being familiar with their code. If you rely on direct knowledge of code in all circumstances you won't be able to effectively operate in an organization with thousands of engineers and millions of lines of code. This is super hard, and relies on deep experience in the trenches (preferably 10 years+), but it is the only way to solve broader organizational problems that cause projects to fail, and many eng months or years to be shitcanned.

>They should be coding because they'll be able to relate to their supports in a deeper and more fulfilling way.

That's a valid point although I've seen it go badly when a mostly out of touch manager (time is finite, even the most technical manager will be out of touch) thinks they're still at the top of their technical game. They then force out of date engineering decisions on the team.

>They'll be able to mentor and provide guidance on technology best practices and patterns.

That should be done by the senior engineers and tech leads with support from the manager. These are the people who spend 100% of their time thinking technology while even a technical manager will do it 25% of the time. The manager should be the one to structure these conversations, formalize mentorship processes and so on.

> That's a valid point although I've seen it go badly when a mostly out of touch manager (time is finite, even the most technical manager will be out of touch) thinks they're still at the top of their technical game. They then force out of date engineering decisions on the team.

Yes, or even worse they don't respect it when their team tells them something is hard to build and will take more time. You get a very "back in my day I'd put this together in a weekend what's the big deal" attitude from people like this.

"Engineering" is more than coding and engineering managers can provide insights and value by demolishing higher-level roadblocks for their IC colleagues.

> need managers to be coding.

> understand what tech is relevant to them

can they really understand tech by merely reading whitepapers and youtube videos?