How Much Should an Engineering Manager Still Code? A Practical Answer

Last updated: August 31, 2026

By Kris Drouet, Engineering Executive, in partnership with KORE1

Yes, engineering managers should still code, but keep it under 40% of your week and off the critical path. Your team size sets the number, not a rule you read somewhere.

He told me he was still shipping.

That was the word he used, and he said it like a defense. Six weeks into his first management job, eleven people reporting to him, and he had assigned himself a story in the current sprint. Payment reconciliation edge case. Gnarly one. He took it because he was genuinely the fastest person in the building at that particular corner of the system, and because the sprint was tight, and because saying yes to it felt like the opposite of becoming the kind of manager he had always resented.

The ticket sat open for nine days. Two people were blocked behind it. He was not being lazy. He was in one-on-ones.

Every engineering search KORE1 runs for a first-line manager role has this argument buried in it somewhere, usually as a job description that promises both “lead a team of eight” and “stay hands-on” without saying which one loses when the week gets short. I have written both halves of that job description myself. Nobody writes the tiebreaker. So the new manager invents one in month two, under pressure, badly, and by month five it has hardened into how they run. I work on this with the engineering staffing agency side of KORE1 because the tiebreaker is usually the whole job.

This piece is the tiebreaker.

“Thirty Percent” Was Never an Answer

The number that has floated around this argument for over a decade is 30%. It traces back to a widely circulated 2014 argument that no engineering manager at a tech company should fall below 30% coding time, because below that line their effectiveness comes apart. I understand the appeal. It is concrete, it sounds researched, and it gives you something to say when your director asks.

It is also unusable, for a reason nobody says out loud.

You cannot schedule a percentage. Nobody has ever opened a calendar on Monday morning and allocated 30% of it to anything. You take a piece of work. Then the work charges you whatever it feels like charging you, and you find out the number on Friday, or the following Friday, or nine days later while two people wait behind a payment reconciliation ticket. The percentage is an output. People keep using it as an input.

There is a second problem and it is bigger. Thirty percent of a five-person team and thirty percent of a 45-person org are different jobs carrying different risk, and when they fail they do not even fail in the same direction. One is a player-coach with three reports and a real backlog, which is a perfectly good way to run a small team, and I have run one that way happily for years. The other is a director whose team has quietly stopped bringing them problems.

The 40% Line, and Where It Actually Comes From

There is real data on this now, and it is more useful than the folklore.

Gallup published a span-of-control study in January 2026 with a finding I have not been able to stop thinking about. Managers spend a median of 40% of their time on individual contributor work. Not engineering managers. Managers, across the economy. So the manager who quietly assumes they are the only leader still writing code is describing the median.

The useful part is the next finding. Gallup found that managers who keep non-managerial work below 40% of their time sustain higher team engagement than average, regardless of how many people report to them. Regardless. Team size did not rescue the ones above the line, and it did not punish the ones below it.

Read that as a ceiling. Not a target. The difference matters more than it sounds, because a target is something you protect and a ceiling is something you watch.

Now the other direction. LeadDev’s Engineering Leadership Report 2026 found that 37% of engineering leaders are doing more hands-on technical work than they were in 2025, and among engineering managers specifically that share went from 20% to 35% in twelve months. Tech leads came in at 41%. CTOs, of all people, at 44%.

Those two findings pull against each other and I am not going to pretend they resolve neatly. The trend is toward more hands-on work. The evidence says the ceiling is real. Both are true, which means the ceiling is getting harder to hold at exactly the moment it started to matter, and if you are feeling that squeeze personally, you are not imagining it and it is not a discipline problem.

That table is mine, not Gallup’s, built from watching this go wrong for twenty-five years across fintech and mortgage tech. Treat the ranges as starting points you argue with.

One number does make the table less theoretical than it looks. Gallup put the average manager at 12.1 direct reports in 2025, up from 10.9 the year before, though the median team is still five or six people. Half of you are in row two. A meaningful slice of you are in row four and have not adjusted.

Team Size Picks Your Number. Your Calendar Enforces It.

Here is the mechanism underneath the table, and it has nothing to do with willpower.

A manager’s week is not a shorter version of an engineer’s week. It is a differently shaped one. An engineer gets blocks. A manager gets fragments between meetings, and the fragments are unpredictable in a way that a sprint commitment cannot absorb.

Researchers at UC Irvine and Humboldt University ran a controlled study on this in 2008 and found something people usually get backwards. Interrupted work got completed in less time, with no difference in quality. People compensate for interruption by working faster. The catch sits in the same sentence: they paid for it with more stress, higher frustration, time pressure, and effort.

Which is the honest description of a new manager coding between one-on-ones. The work does get done. You get it done. And you are paying for it in a currency your calendar does not track and your team cannot see, right up until the week you have nothing left for the person who came to tell you they are thinking about leaving.

So the constraint is not moral. It is structural. Fragmented time can absorb some kinds of engineering work and cannot absorb others, and knowing which is which is most of the practical answer.

The Only Code Worth Taking

My rule has one clause. Take work that can be dropped for two weeks without anybody noticing.

That is it. Everything else follows from it.

The spike nobody is waiting on qualifies. Somebody is going to have to find out whether the vendor’s API can actually do the thing the deck claims, and that investigation has no downstream dependency, and it happens to be the exact work that keeps a manager’s build vs buy judgment sharp. I take those every quarter.

Internal tooling qualifies. The deploy script your team complains about in every retro and nobody has budget to fix. Fix it. It is real code, it is genuinely useful, it makes you popular in a way that costs the roadmap nothing, and if you vanish for a fortnight it just stays broken the way it already was.

Test coverage on the module everyone is afraid of. Flaky CI. Observability nobody funded.

Reading code qualifies, and I will die on this hill. You do not have to write a line to stay technical. Pull up the last two weeks of merged diffs on your team’s hairiest service and follow them. Thirty minutes. If you cannot follow them, you have your answer about where you have drifted, and it is a more honest signal than any percentage you could calculate. I go deeper on that distinction in the case for why engineering leaders should stay technical, which is the argument sitting underneath this whole piece.

Now the other list, which is shorter and firmer.

Never take anything on the sprint’s critical path. Never take anything with a customer-facing date attached. Never take work where you are the only person who understands it, because you have just built a bus factor of one and handed it a calendar it cannot survive. And never, under any circumstances, take a ticket because you are faster at it. That instinct is correct about the ticket and wrong about the job, and it is the single most common way a competent engineer becomes a bottleneck inside one quarter.

The manager with the payment reconciliation ticket broke three of those four in a single sprint, and I have never been certain about the fourth. He was also, by any reasonable standard, doing his best.

Have the Conversation With Your Own Boss, Before You Need It

Most new managers negotiate their coding time with themselves, silently, at 9pm, and lose. Every time.

The conversation you actually need takes fifteen minutes with your director, and there is exactly one question in it. When my hands-on work and my team’s need collide in the same week, which one gives?

Ask it before it happens. Ask it when nothing is on fire and nobody is defensive. Then write the answer down somewhere you will both see it again, because the version of this agreement that lives only in memory gets relitigated every time a release slips, and it gets relitigated by whichever of you is more stressed that day.

Three things worth asking for in that same fifteen minutes:

A named ceiling. Say a number out loud, get a yes or a no, and let your director own it with you. If they will not name one, that is information about the role you are in.

An explicit answer on whether your delivery is still counted. Some orgs quietly measure a manager’s individual output long after the org chart says they stopped, usually because a director three levels up wrote the review template back when everybody on it was an engineer and nobody has touched it since. Most claim not to. Ask directly, and watch the pause more than the answer.

A recovery plan for the weeks it breaks. It will break. Q4 will break it. What matters is whether the org treats that as a temporary exception with an end date, or as a new baseline nobody announced.

If this conversation is going sideways, the underlying problem is usually not the coding time at all. It is that nobody defined the job when they handed it over, which is the failure mode behind promoting your best IC into engineering management. The coding argument is a symptom that shows up first because it is the one you can see on a calendar.

The Drift Test, Every 90 Days

You can fail this in two directions and they look nothing alike, so run both tests.

Drifted too far into the code. Open your last ten sprint items and count how many you assigned to yourself. More than two and you are competing with your own team for work. Then count how many one-on-ones you moved or shortened last month. If the answer is most of them, the ticket is winning and you already know it. You knew before you counted.

Drifted too far out. Pick the service your team was paged for most recently. Explain the incident. Out loud, to yourself, in your own words, with the actual mechanism and not the summary from the retro doc. Show me the data behind that outage and see whether you can still read it. Most managers who have drifted find out here, and they find out uncomfortably fast.

Run both quarterly. Not monthly, that is noise, and not annually, because a year is long enough for either drift to become who you are. Ninety days is roughly how long it takes for a pattern to be visible and still be reversible, which is the same window that governs the IC to manager transition timeline more broadly.

One more thing on the second test. If you fail it, the fix is not a heroic weekend. Pick a single service, read its merged code for an hour a week, and let it take a quarter. Boring, and it works, and I have never seen the panicked version work even once.

When the Number Is Really a Headcount Problem

There is a version of this question that is not about time management, and I want to name it, because a lot of managers spend a year optimizing a calendar that was never the constraint.

If the sprint only closes when you code, you do not have an allocation problem. You are short a person, and your hands-on time is the load-bearing wall holding up a plan that got built wrong.

The tell is simple. Take your hands off for two sprints and watch. If throughput drops a little, fine, you were contributing at the margin. If a whole workstream stops, you were never a manager who codes. You were an engineer with a management title bolted on top, and your org has been quietly getting two jobs for one salary, which is flattering for about eight months and then it is not.

That is a conversation about headcount, and it is worth having with real numbers attached. KORE1 averages 17 days to fill an IT role and holds 92% twelve-month retention on placements, and the retention half is the part people forget to ask about. A fast fill that turns over in seven months costs you two more quarters of exactly the situation you were trying to escape. Whether the answer is a direct hire or a contractor covering the gap, the useful move is to stop funding the shortfall out of your own evenings. If you want a second opinion on how the role should be scoped before you post it, KORE1 does engineering manager coaching and advisory work for exactly this, and it is a cheaper conversation than a bad hire.

What New Managers Ask Me About Their Own Calendar

My skip-level wants me coding more and my team wants me coding less. Who is right?

Your team. They are describing what it is like to be blocked behind you, which is data your skip-level does not have. Bring it up as a delivery observation, not as a complaint about your own workload.

The skip-level is usually not wrong about the intent. They want a technical manager. They are just reaching for the only proxy they know, which is output, because output is the thing that used to be legible about you.

Give them a better proxy. Tell them which architecture reviews you are in and what you caught. That lands, and it does not cost your team a sprint.

Does code review count?

It counts toward staying technical. It does not count toward delivery, and confusing the two is how managers convince themselves they are contributing while their team waits on an approval queue.

Review returns more per hour than any other technical work available to you. It is also the easiest to turn into a bottleneck, because everything routes through you and nothing routes around you.

My bar is that I am never the required approver on anything. I review because I want to see the work. If my absence blocks a merge, I have built the wrong thing.

How do I get coding time onto a calendar that is already full?

Stop trying to protect a block and start picking droppable work instead. A two-hour Thursday block survives about three weeks in a real management calendar. Work with no dependency on it survives indefinitely.

Everyone gives the block advice. I gave it for years. Then I watched what happened to those blocks in any week with a production incident, a resignation, or a board deck, and the honest answer is that they are the first thing to go and they should be.

Choose work that tolerates that. The calendar is not the variable you control. The dependency is.

I took a ticket and blocked the sprint. How bad is it?

Recoverable, if you name it in standup tomorrow. Hand it off, say plainly that you took work you should not have, and let the team watch you do it. That is worth more than never having made the mistake.

What makes it bad is the second time. And the quiet version, where you keep it and grind it out over a weekend so nobody has to know, which teaches the team that the rule applies to them and not to you.

I have done the weekend version. It bought me nothing except a team that stopped telling me when they were stuck, because clearly the standard was heroics.

Six months in and I miss building. Did I choose wrong?

Missing it is normal and it does not fade, which is not evidence that you chose wrong. Any manager who tells you it fades has either forgotten or is performing. The real question is whether you miss building or you miss being good at something.

Those feel identical for about a year. They are not the same problem. Missing the craft is manageable with a spike, a prototype, and a weekend project nobody is depending on.

Missing competence is harder, and it is the actual reason most people go back. You were excellent, and now you are mediocre at something new, and nobody warned you the ramp is measured in quarters. If that is where you are, read what the timeline actually looks like before you make a decision about it. It runs longer than anyone tells you, and being nine months in and shaky is not evidence of anything.

The Practical Answer, Stated Plainly

Under 40%, and lower than that as your team grows. Nothing on the critical path. Nothing anyone is waiting for.

The manager with the payment reconciliation ticket runs a platform group now. He handed that ticket off on day ten, told the team exactly why, and it was awkward for one standup and forgotten by the next. What changed was not his discipline. He stopped asking how much he should code and started asking which code he could afford to drop, and that is a question with an actual answer.

Ask yourself the same one on Monday. Look at what you are holding. Then find out how much of it your team would even notice if you put it down.

If you are somewhere in the middle of this and want to think it through with someone who has been on both sides of it, connect with me on LinkedIn. If the honest answer turns out to be that your team is a person short, talk to a recruiter at KORE1 about what that role needs to cover.

Related reading: Why the Best Engineering Leaders Stay Technical, Promoting Your Best IC to Engineering Manager Without Ruining Two Careers, and How Long It Actually Takes a Promoted IC to Find Their Footing.