2026-10-01
October 1, 2026 · Issue 111
The manager role is splitting into a hands-on pole and a span-of-control pole, and neither one is the answer. Treat it as a tension to manage, not a problem to solve.
LeadDev's Stephane Moreau argued in June that the engineering manager role is bifurcating. One branch is the Tech Lead Manager: a senior engineer with three or four reports who still writes code and sets technical direction. The other is the multi-team EM: a people manager over many small teams, with little technical depth. Moreau points to Meta's reported 50-to-1 employee-to-manager ratio as the shape of what's coming, and notes that most companies haven't chosen between the two models. Flattening is happening to them through cost-cutting reorgs.
LeadDev's Chantal Kapani then reported in August that EMs are back in the codebase, with hands-on coding rising from 20% to 35% in twelve months and 37% of engineering leaders doing more technical work than in 2025. Will Larson, meanwhile, wrote that middle-management roles are a trap: you balance pressure from above, beside and below, and the reward is more middle management.
Read together, these describe a squeeze on everyone who sits between strategy and execution. That includes TPMs. If you are a senior TPM or a director, the useful question is not "which pole wins?" It is how to run a role that has to hold both.
Start with what the sources agree on. Layers are being removed, spans are widening, and AI is lowering the cost of the technical work that managers once delegated away. Kapani's piece quotes Bloomberg's Paul Williams saying the core EM job (empowering teams, leading the organization) "remains unchanged." That is the tension in one sentence. The job didn't shrink. The capacity to do it did.
Now look at how organizations respond. Most pick a pole and declare victory. One camp says managers must be technical again, so everyone codes. The other says span is the efficiency lever, so every manager gets ten teams. Both fixes feel decisive and both fail on a predictable schedule. Hands-on managers drift into the keyboard, because shipping gives feedback in an afternoon and developing people gives it in a year. The people work is the first casualty. Wide-span managers lose the technical context to challenge estimates, so they become relays, and the technical decisions drift to whoever is loudest. Moreau's quote about the missing path is the quiet cost: if you only ever manage five teams, where does the next generation learn to manage one?
That pattern is the signature of a polarity in Barry Johnson's sense: an ongoing tension with two legitimate poles, where each pole has upsides and each, pursued alone, produces the downsides the other pole exists to fix. Technical depth and organizational breadth are interdependent. You need both and you can't pick one. Johnson's test is simple: if the problem will still exist after you "solve" it, and the opposite choice has a real upside you'd miss, you have a polarity. A problem you can solve has an end state. Hiring a missing engineer is a problem. "How hands-on should a manager be?" isn't.
This matters for senior TPMs for a specific reason. Our role has always lived in the middle, and the middle is exactly where Larson says the career risk concentrates: conflicting feedback, where driving execution reads as micromanaging and going deep reads as neglecting stakeholders. Larson's observation is that this perverse feedback loop filters people out. The polarity framing gives you a way out of the blame game. The feedback isn't evidence you're doing it wrong. It is the two poles talking to each other, and the right response is a pre-agreed rhythm of oscillation, not a one-time answer.
What does an oscillation rhythm look like at program scope? Larson's August post on roadmapping decisions rather than dates offers a concrete anchor. His claim is that the constraint on software is no longer implementation time but decision speed and quality, and that teams should work down a decision list instead of chasing internal dates. For a manager or TPM squeezed between depth and breadth, the decision list is the shared object: depth means you personally prototype or review the hardest two decisions each cycle; breadth means you keep the other twenty moving through an owner, a deadline, and a visible status. You are not choosing between technical and managerial work. You are deciding, explicitly, which decisions get your depth.
Name early warnings too, because polarities fail slowly. Over-indexed on depth: your reports bring you problems they used to solve, your one-on-ones get shorter, and a dependency slips that you'd have caught if you'd read the status. Over-indexed on breadth: you approve estimates you can't evaluate, a design review passes and nobody can say why, and you notice you've stopped asking "show me." Write these down now, while you are still in the middle. Under pressure, people only notice the pole they are already leaning toward.
One more honest caveat. A polarity map organizes judgment. It does not supply it, and it won't tell you your current ratio is wrong. It makes the tradeoff discussable, which is most of what a flattened org lacks.
Try this week. Pick one tension in your role that keeps resurfacing (hands-on vs. delegated, speed vs. rigor, your team vs. the portfolio). Spend 20 minutes drawing the four quadrants and writing down two early-warning signs for each pole. Then share the draft with your manager or one peer and ask only: "which warning sign do you see in me right now?"
What it is. A four-quadrant tool for tensions that have two legitimate poles and no permanent winner. It maps the upsides and downsides of each pole so you can manage the movement between them instead of picking a side.
When to use it. The same debate keeps returning after each "decision": centralize vs. decentralize, move fast vs. be safe, manager as coder vs. manager as coordinator. Use it when both sides of the argument contain true statements.
How to run it:
When NOT to use it. On a genuine problem with a solvable end state, or on a question where one pole is simply unacceptable (safety, legal, ethics); mapping those as "tensions" just legitimizes the wrong answer.
Example: "Technical depth" vs. "organizational breadth" for a director over six teams, with the warning signs above attached to each.
Trying the Software Factory pattern — Will Larson describes Imprint looping agents on broad project goals, with Linear as the single source of state plus Datadog and Snowflake access; the lesson for TPMs is that program hygiene (clear goals, RFCs, measurable metrics) is what makes agentic delivery work at all.
Roadmap decisions rather than dates — Larson's case that decision quality, not calendar time, now constrains delivery; a good prompt for rethinking what your status review actually tracks.
Who wants to be an engineering manager anyway? — Chantal Kapani reports 65% of engineering leaders with expanded responsibilities and 40% managing more reports; useful data when you push back on scope creep in your own org.
"Prototyping can turn most complex problems into a series of simple problems."
— Will Larson, "Roadmap decisions rather than dates," August 2026
Don't miss what's next. Subscribe to Critical Path: