Why I Still Write Code as an Engineering Manager

I still code on my team. Not every day, and almost never on critical path work, but regularly enough that I know what our codebase actually looks like. The parts that are a joy to work in and the parts that aren’t.

Why not critical path? Because that’s not my job anymore. Taking the interesting, high-visibility work from your team is a fast way to breed resentment and stunt their growth. But there’s plenty of other work: small bugs, minor improvements, tooling fixes, documentation that requires code understanding. The stuff that matters but isn’t going to make or break the quarter.

So why bother? A few reasons.

First, it’s fun. Becoming a manager doesn’t mean I have to stop doing the thing I love. Second, it keeps me sharp. Skills atrophy when you don’t use them, and I don’t want to become the kind of manager who says “it’s just a button” when something takes a full day.

But the most important reason is this: I get to show my team what good work looks like.

Andy Grove, in High Output Management, talks about how a manager’s job is to increase the output of their team. One of the most effective ways to do this is through training. Training isn’t slides, though, but showing your people what good work is in practice.

When I write code, I’m setting a standard. How do I structure a PR? How do I write commit messages? How thorough are my tests? How do I handle code review feedback? How do I communicate when I’m uncertain about something? My team sees all of this.

Showing beats telling. When you’re doing the work alongside your team, not dictating from above, it lands differently. They see you’re not asking them to do anything you wouldn’t do yourself. And because they can observe how you work directly, they can adopt what works and adapt it to their own style.

This connects to something Nassim Taleb (one of my heroes) calls skin in the game: you make better decisions when you personally bear the consequences of those decisions. When I commit code that goes to production, I feel what my team feels. I deal with the same flaky tests, the same deployment process, the same frustrating parts of our developer experience. I can’t wave my hand and say “just fix it” because I know exactly how hard that fix actually is. I’ve tried it myself.

When I’m pushing back on a deadline, I know the trade-offs because I’ve lived them. When I’m advocating for time to pay down tech debt, I can point to specific pain I’ve personally experienced. My team knows I’m not asking them to do things I don’t understand.

Look, I’m not going to pretend I know your situation. Maybe you’re managing fifteen people and there’s genuinely no time. Maybe your company has a strict policy against it. Maybe you’ve moved so far into strategy that coding would actually be a distraction from higher-leverage work. Context matters.

But if you’ve stopped coding entirely, ask yourself why. Is it because you genuinely can’t, or because you’ve convinced yourself you shouldn’t? “I’m a manager now so I don’t do that anymore” isn’t an answer.

Staying technical doesn’t mean being the top contributor, but maintaining enough connection to the work that you can make informed decisions, earn your team’s respect, and remember what it actually feels like to ship software. The frustration and the satisfaction, the parts that look easy but aren’t, the parts that look hard but turn out to be trivial.

That feeling is what your team experiences every day. And if you’ve completely forgotten what that’s like, it gets harder to truly connect with the people doing that work.