I became an Engineering Manager at the start of covid. The company was not hiring, the role genuinely needed filling, and I went into it with no real idea what the job involved or whether I would be any good at it. Nobody sat me down and told me how much of my week should still be spent writing code. I am not sure anyone in the building could have told me. So I kept picking up tickets, because that was the part of the job I already knew how to do.
Almost every new manager I speak to arrives at this question within a few weeks, and they all want the same thing from me. A percentage. Twenty per cent, thirty, half a day on a Friday. Something they can put in their calendar and defend when someone asks why they are in the code.
The percentage is the wrong question
The honest answer is that it depends on how many people report to you, whether you have a tech lead, whether you are hiring, whether you are one of three engineers in a startup or one of forty in a scaleup, and what state the team is in this quarter. Any number I give you will be wrong by the time your team next changes shape.
That is not me dodging it. What determines whether your coding helps or hurts is which code you pick up, and almost nobody asks about that part. I did not get this split right in my first year and I would not expect you to either.
Keep the code nobody is waiting on
There is code on your team that somebody’s sprint depends on, and code that nobody has capacity to touch. Your name belongs on the second kind.
The flaky test that everyone reruns twice and nobody owns. The build step that takes eleven minutes because of something one person did in 2023. The internal tool three people use daily and nobody has ever improved. The spike into whether that new library is worth it, which has been sat in the backlog since spring because it is nobody’s priority and everybody’s problem. The bug that only fires for one customer and has been carried in triage for months.
Take a story on the critical path and your calendar becomes everybody’s problem. It is the first thing to go in any given week, and it goes without warning. An incident, a 1-1 that needs to run long, a resignation, a conversation with your own manager that was supposed to take fifteen minutes. Your branch sits there while someone else’s work hangs off it, and the person waiting is too polite to chase their own manager. You are the blocker on your own team.
If you report to me, you will never be waiting on my branch. That is the rule, and it is not because my time matters more than yours. It is because my time is less predictable than yours.
Your hour is not worth what their hour is worth
Lazear, Shaw and Stanton studied this properly in The Value of Bosses, published in the Journal of Labor Economics (working paper here). Swapping a bottom-decile boss for a top-decile boss raises a team’s total output by more than adding an entire extra worker to a team of nine does. That surprised me when I first read it.
Spend the hour in front of you on a ticket and you produce, at best, one engineer’s worth of output, and you are slower at it than you used to be because you have not been in that part of the codebase for a month. Spend it unblocking a decision that four people are stuck behind, or clarifying what the roadmap actually means for the next two sprints, or finally having the conversation you have been putting off, and the return lands across the whole team.
I am not telling you to fill that hour with meetings. Most managers already have too many. I am telling you that when you choose the ticket over the harder, vaguer, less satisfying work, you are usually choosing the thing you can finish over the thing that matters. Closing a ticket feels like progress in a way that a good 1-1 never does.
Taking the keyboard is not helping
Lazy mentors want to take your keyboard. The help that stops someone struggling is the help that stops them learning, and it is the most tempting thing in the world when you can see the fix and they cannot.
The version I catch myself in:
“Send me the branch, I’ll take a look tonight.”
And the version that takes longer today:
“Where have you looked so far? Okay, what made you rule that out? Right, I’d start with the request logs. Come back to me tomorrow either way, even if it’s still broken.”
I think about it like taking a team bowling. They bowl their own game, and the bumpers go up at the points where you and the team have agreed they should. People are allowed to fail inside boundaries the team has set. If someone is only ever succeeding because the bumpers are up, that is a coaching conversation, not a reason to bowl the ball for them.
Fix it yourself and you save time today and they learn nothing. Do that often enough and the team cannot operate without you.
Technical credibility is not a commit count
I am certainly not the best Software Engineer on my team, or on any team I have managed. I am proud of that.
New managers hear that and assume it is false modesty, or that it only applies once you are senior enough not to care. It is neither. Your credibility with engineers does not come from out-shipping them. It comes from asking the question in the design review that changes the design. From remembering why the last attempt at this failed and saying so before anyone repeats it. From reading a pull request and being able to tell whether an estimate is honest or hopeful. From knowing enough to spot when the answer you are being given is not quite the answer to the question you asked.
If you report to me I do not need you to be the strongest engineer on your team. I need you to know enough to tell when the answer you are being given is not the truth. None of that requires you to out-code anyone, and if you are still trying to, that is a separate problem worth reading about on its own (managing engineers more experienced than you covers where that fear actually comes from).
What you lose if you stop completely
I would be selling you something if I told you the answer was zero.
Teams do not really end, they get reinvented in waves. Engineers leave, new ones arrive, the work continues, and the reasoning behind old decisions quietly disappears with the people who made them. The tell is the day you hear someone say “Ah, the previous team did that” about a system your own team owns. If you have been fully out of the code for a year, you are one of the people who cannot answer that question either.
So keep a foot in. Read code every week even when you are not reviewing it. Run the thing locally often enough that you would notice if setup got worse, because a slow local setup is a tax your team pays every day and never mentions. Sit in design reviews and follow the argument rather than the conclusion. Review pull requests where you are not the blocking approver. None of that is on the critical path, and all of it keeps you able to tell whether what you are being told is true.
The answer moves as the team grows
If you are one of three engineers at a startup and you also happen to manage, you are going to be shipping features, and no article is going to change that. What matters is that you and your team are honest that you are doing two jobs, and that the management one is the one that silently gets dropped when the sprint gets tight.
Once you are at six or seven reports, plus hiring, plus a performance conversation or two, the coding time stops existing whether or not you have booked it. Managers who insist otherwise at that size are usually doing both jobs badly, and the management one is the half nobody can see slipping.
Some of this is about the size of your team, and some of it is about the kind of manager you are, which is a genuinely different thing. Being hands-on is an identity for a lot of engineering managers, not a scheduling choice, and it shapes everything from how you run 1-1s to what you find hard about delegation. If you have not worked out which sort you are yet, the engineering manager type quiz takes a few minutes and will tell you more about your instincts than a percentage ever will. The five types of engineering manager piece goes into what each of them tends to get wrong.
Final Thoughts
I know managers who write a lot of code and lead well. It is usually a small team, or a strong tech lead absorbing the parts of the job they are neglecting, and it usually stops working when the team grows and nobody adjusts. The failure is not the coding. It is coding that somebody is waiting on, coding that replaces a conversation you owe someone, or coding you are doing because it is the only part of the week where you can point at something finished.
I still cannot give you the percentage, and I am suspicious of anyone who can give you theirs without asking about your team first. What I can tell you is that the question changes as you get further in. It stops being how much am I allowed to code and starts being what am I not doing while I am in here.
If you have found a split that works, or a rule you use to decide which tickets you will and will not touch, send it to me. I collect these, and the best ones have all come from people two years into the job rather than ten.
