How much should a manager code?
Turns out that's the wrong question.
I’m Roman, CTO at a startup, and I write High-Impact Engineering — a weekly newsletter for engineering managers, directors, and CTOs.
I have two GitHub contribution graphs that tell opposite stories about coding as a manager. I’ll show you both.
Here is this year.
544 contributions so far, while leading four teams. Not a green carpet, but not a few scattered dots either. By one popular rule, that is already too much.
Karol Wójciszko recently wrote a good piece arguing that managers should spend up to 10% of their time on code, and he treats that as a ceiling (please, after reading this issue, go and check Karol’s newsletter for engineering managers — it is great). I agree with almost all of it, especially the why: firsthand experience with flaky tests, slow pipelines, and nasty legacy code gives you an understanding you can never get secondhand. You stop nodding along to complaints in standup and start feeling them.
But I do not think the percentage is the point. The real question is not “how much is too much.” It is “how much does your team still need you?” Get that right, and the time to code appears on its own.
The time comes from autonomy, not discipline
My calendar is often open. Not because I defend a coding slot with willpower, but because I do not sit in the critical path of most decisions.
I lead four teams: software engineering, data science, QA, and product. I run the product team directly. The other three have leads who own the day-to-day. Small decisions sit with individual contributors, bigger ones with a lead, and only the biggest reach me. The right people are in the right seats, and they are enabled to decide without walking every question up the chain.
That is what creates the room for me to proactively decide how to spend my time. Quite often, it is coding.
Why spend your time on code
A manager’s time can go to dozens of things. Why code?
Because a technical leader needs a live connection to the ground, and the bigger the org, the easier that connection is to lose. A few years ago, I heard Stripe’s then-CTO David Singleton describe what he called an “engineerication,” an engineering vacation: he would clear three or four days, sit with a team, pick a small task, and ship it end-to-end, just to feel how people and systems actually work there.
My most useful version of this was not planned. A team was racing a deadline, so I volunteered to cover “primary,” our support rotation for client issues, and hoped not to have too many requests. I had plenty. But many of them were similar. We had scripts and docs for them, but I had a better idea: let non-technical support resolve them without us. Between tickets, I built a self-serve fix for the most annoying one, automated another the next week, and over the following months, the team turned the rest into self-serve tools. The load on the rotation dropped sharply.
I could see that only because I had both views at once: the code in front of me and the system around it, the business, the roadmap, where the team’s time actually went.
People who are in the code every day often accept the pain as just how things are. A manager brings a fresh perspective, broader context, and the power to change it, and that combination can produce outsized wins for the team.
When this goes wrong
Now the other graph. This is the year I became a manager.
I stepped into the role in August. You can see what happened next: I did not code less, I coded more. I felt personally responsible for delivering everything while trying to pull the team up to speed at the same time. I also had a few-month-old son at home and a wife who, bless her, had bottomless patience for all of it.
Plenty of those squares are weekend commits. I thought I was helping the team.
Looking back, I would have been far better off spending that energy differently: learning the product properly, and defining with the team what we were building and how the pieces fit together. The team would have reached cohesion sooner, the architecture would have been better, and nobody would have needed to work weekends, least of all me.
That is the first failure mode: coding to carry the delivery yourself, instead of building the team that carries it.
The second is standing on the critical path. You take a task with a deadline and dependencies, and then you cannot ship it for weeks. A manager’s day is nothing like a senior developer’s: the meetings, the interruptions, the ad hoc Slack fires shred the long focus blocks that real feature work needs. But new managers keep estimating their own work as if they still had a developer’s calendar. They do not, and the estimates stop meaning anything.
So if you go hands-on, pick work that cannot hurt anyone: no deadline, no dependencies, and on the periphery of the product rather than in its core.
So, how much?
I don’t have a number for you. Sorry.
I want to emphasize, though, that coding as a manager is just a tool. A tool to get deeper insight into how technical systems and the team as a system work.
There are several others we should use:
One-on-ones
Skip-level meetings
Retrospectives
Post-mortems
Surveys
Development process metrics (for example, DORA)
Coding as a manager is one of the ways to get feedback.
As you get feedback and improve how your team works one small step at a time, you get more freedom to decide how to spend your time. The more autonomously your team can run, the fewer distractions you have and the more power you get over your own calendar.
If you’re considering starting to code as a manager, good news: the barrier has never been lower. With today’s AI tools, a manager can learn an unfamiliar stack and ship a small change in a few hours. If you want a great system for that part, Karol’s article lays out the steps.
Just remember, a green contribution graph is not the goal. A team that barely needs you is.
If this was useful, subscribe for one practical lesson on engineering leadership every week. You’ll also get The Manager’s Scoreboard, my free guide to scoring yourself as a leader, the moment you sign up.
P.S. I also coach a handful of engineering managers and leaders 1:1. If you need help, book an intro call.