What "Hands-On Engineering Manager" Actually Means

"Hands-on engineering manager" is one of the most over-used phrases in tech-hiring listings. Half the time it means "we don't have headcount to hire a tech lead and an EM, so we want one person." The other half it means something real and important — but most candidates and most managers struggle to articulate which version they're living in.

Here's what I've learned over five years of running engineering teams while still writing code.

1. The math: why 30%?

The number I aim for is 30% of my week in code. Not 50%. Not 10%. Thirty.

The math behind that number is roughly:

• ~25% of the week on 1:1s with reports, peers, and leadership.
• ~15% on broader org work — calibration, hiring, performance reviews, planning cycles.
• ~10% on the team's roadmap and dependencies — partners in Product, DevOps, Compliance, Security.
• ~10% on async written work — status updates, RFCs, internal docs, code review comments.
• ~10% on unblocking — the surprise meetings, the urgent escalations.
• ~30% for IC work — coding, debugging, architecture.

The 30% is the residual. It's what's left after the management work that only the manager can do. If management eats more than 70% of your week, you have no time for code. If management eats less than 50%, you're probably under-managing and the team is paying for it.

2. Where hands-on pays compound interest

There are five places where IC time as an EM is worth disproportionately more than the same hours as a pure IC:

2.1 Code review on cross-cutting concerns

Reviewing PRs that span multiple sub-teams or that touch shared infrastructure. As EM you have the cross-team context an IC reviewer often doesn't. Your review is uniquely valuable because it catches the "this conflicts with what Team B is about to ship" issues.

2.2 The hardest 5% of the hardest project

Every project has a 5% that's genuinely difficult — the bit that the team is collectively nervous about. Pairing on that 5%, or owning it outright, frees the team to ship the other 95% confidently. Don't take the easy 5%. Take the hard one.

2.3 Bootstrap work for new patterns

When the team is adopting a new pattern — first microservice extraction, first use of a new database, first event-driven flow — writing the reference implementation yourself sets the bar. Then code-review enforces it. Much higher leverage than authoring a "best practices" wiki page that nobody reads.

2.4 The week before an audit

PCI DSS prep, security review, compliance audit — these need someone who can read code and talk to auditors. Often that someone has to be you. The 30% of code time is the reason you still can.

2.5 Production incidents

I don't take primary on-call. But I'm in every Sev-1, and I'm the person who can read the trace, the code, and the deploy history simultaneously without 30 minutes of context-rebuilding. That speed during incidents is worth weeks of management overhead.

3. Where hands-on backfires

Three traps. I've fallen into each at least once.

3.1 Taking the critical path

You write the code on the dependency that the team's release depends on. You also have a 1:1 cycle, an interview loop, and a leadership update. Predictable: the code slips. The release slips with it. Six engineers idle. The lesson: never own the critical path unless you are willing to drop the management work to ship it. And dropping management work is usually wrong.

3.2 The PR you never finish

You open a draft. You don't touch it for three weeks. You eventually close it. Worse: someone re-does the work and now your draft is the false-positive in their grep when they're looking for prior art. Either ship the PR within a sprint or close it and hand it off cleanly.

3.3 The architecture you authored

You design the system. You wrote the original code. Now nobody on the team is willing to push back on your assumptions because they assume you've thought of it. The team's collective judgment gets quietly worse over months. The signal: when was the last time someone on the team disagreed with you in writing? If you can't remember, the team has stopped pushing back.

4. The question I ask before every IC task

Before I take an IC task, I ask one question:

If the answer is "no one would drop anything important; this would just be slower without me" — take it.

If the answer is "I'd drop performance prep" or "I'd skip my 1:1s this week" — almost always wrong. The team will accept slower IC work. The team will not accept skipped 1:1s.

If the answer is "someone junior on the team would have to drop a big project to take this on" — sometimes right. Junior engineers learn most from the work just past their comfort zone, not the work miles past it. As EM you can sometimes shield them from work too big and free them to do the work that grows them.

5. Five things from my week

Concrete examples from the last seven days at Kort:

1. Code review on the idempotency-key refactor — cross-cutting concern, exactly the kind of review that pays disproportionately at EM level (caught a race condition the IC reviewers missed).
2. Pairing for 90 minutes on a circuit-breaker integration — engineer had been stuck for two days; the unblock was a piece of shared context I happened to have from a previous team's mistake.
3. Wrote the first draft of a design doc for the next-quarter platform investment — bootstrap work; set the template, the team will own the actual content.
4. Joined a Sev-2 incident as second on-call. Stayed quiet for the first 20 minutes, then pointed out a metric the team hadn't checked.
5. Reviewed 14 PRs across 5 engineers. Approved 11. Asked for changes on 3. Mentored on 2 of those.

Total IC hours: about 12. Total management hours: about 28. That's the 30/70 split in practice. Not a target; an outcome of the week's demands.

6. Anti-patterns to watch for

• The "EM who's really a Staff Engineer with a team." They write 60% of the code, never run a real 1:1, and the team is functionally manager-less. Often happens at startups under headcount pressure.
• The "EM who never codes." Loses technical credibility within six months. Stops being able to call out bad design in reviews. Team starts working around them.
• The "EM who codes on weekends." The math doesn't work — they're paying with their off-hours for IC work they should have delegated. Burns out. Team learns helplessness.
• The "EM who codes only on greenfield." Always the new shiny thing; never the unglamorous maintenance. The team notices.

7. What to ask in an interview

If you're a candidate evaluating an EM role advertised as "hands-on":

• "What percentage of a typical week does the current EM spend in code?" If the answer is >50% or <10%, ask what gives.
• "Has the current EM authored a production-merged PR in the last month? Last quarter?" Concrete signal.
• "How does the team handle code review when the EM is the author? Who can block?" Tells you whether they have a healthy culture around manager-authored code.
• "What's the IC work the EM owns vs. delegates? Who decided that split?" Tells you whether the role is intentionally hands-on or just under-staffed.