The Best Engineering Managers Write No Code

An EM who ships features is serving their own identity, not their team.

The hook

Eight months ago I promoted the strongest debugger on the team to EM. She could read a Datadog trace and find the bottleneck in under a minute. For her first three months as manager, she took on a Redis caching layer migration that required deep concentration over several weeks. During those weeks, two of her reports had PRs sitting unreviewed for four days. A third engineer was stuck on an IAM permissions issue and did not want to "bother" their new manager, who was clearly heads-down. The team's cycle time went from 2.1 days to 4.8 days in one quarter. I should have caught it sooner. I did not.

मज दास करी त्यांचा · Make Me the Servant of Your Servants

मज दास करी त्यांचा । संतदासांच्या दासांचा ॥
नीच वृत्ती काम । परी मुखी तुझे नाम ॥
तुका म्हणे सेवे । माझे संकल्प वेचावे ॥
The highest aspiration is to serve those who serve. Greatness is measured not by the rank you hold but by how far down the chain your service reaches.

What I keep seeing

Charity Majors has written about this repeatedly, and she is right: the transition from IC to manager is not a promotion. It is a career change. The skills that made you an excellent engineer (deep focus, code ownership, technical problem-solving) are not just irrelevant in management. They are actively harmful if you keep exercising them. Every hour you spend coding is an hour you are not spending on the work that only you can do.

A staff engineer can review a PR. A staff engineer cannot run interference with the product VP who wants to add three features mid-sprint. A staff engineer cannot notice that a quiet junior engineer has not spoken in three consecutive standups and pull them aside. A staff engineer cannot renegotiate a deadline with the CTO because the team discovered a data migration that was not in the original estimate. These are not lesser tasks. They are the job.

The mechanics

Engineering management is, mechanically, a scheduling and shielding function. The EM's job is to maximize the uninterrupted hours their reports spend on the highest-priority work. Triage incoming requests before they reach the team. Run 1:1s that surface blockers before they become emergencies. Handle cross-team coordination so engineers do not spend afternoons in alignment meetings.

Google's Project Oxygen found that the top behavior of effective managers was not technical expertise. It was "is a good coach." Technical skills ranked eighth out of ten. The math is straightforward: an EM who writes code adds their own output. An EM who removes blockers for six engineers multiplies six people's output. The leverage of management comes from multiplication, not addition. The trade only works if you let go of the direct output.

Camille Fournier makes the same point in "The Manager's Path": each rung of the ladder trades direct output for organizational leverage. An EM who holds onto code is operating at the wrong level of abstraction. It is like a function reaching into its caller's stack frame. Technically possible. Architecturally wrong.

Where Tuka comes in

Tukaram does not ask to be a leader. He asks to be "दासांचा दास": the servant of the servants. This is not humility performed for an audience. It is a positional claim about where the real work happens. The devotees (the ICs, in our frame) are the ones doing the core work. The highest aspiration is not to do that work yourself. It is to serve the people who do.

The second line matters: "नीच वृत्ती काम, परी मुखी तुझे नाम" (the work is lowly in nature, but on my lips is your name). The EM's work is not glamorous. Updating Jira tickets, writing status emails, sitting in cross-functional meetings about a roadmap change. It feels like a demotion to someone who used to ship code. Tukaram says: the status of the work is irrelevant. What matters is whether the work serves the people closer to the core.

What I would actually do

Institute a hard rule: EMs do not have assigned tickets on the sprint board. If an EM writes code, it must be a tooling improvement or a spike explicitly not on the critical path. Measure EMs on team throughput (cycle time in LinearB or Jellyfish), retention, and unblocked hours per week. Run a quarterly survey with three questions: does your manager remove blockers, shield you from unnecessary meetings, and give you feedback that helps you grow. If an EM scores low on all three but ships a lot of personal code, that is not an underperforming manager who "stays technical." That is an IC wearing a manager's title, collecting a manager's salary, and doing neither job. Name it. Fix it.

Chetan Dhandal