Seniority mix and the cost of imbalance

Every engineering team has a seniority mix: the split between engineers who can own a problem end to end and engineers who are still learning the craft. When you are putting a team together and ask how many of each you need, the standard advice is a ratio: keep three seniors for every junior, so the people who need teaching never outnumber the people who can teach. There is a real constraint behind it: a senior can grow only so many people at once, and a team that overruns that mentorship bandwidth stops growing anyone.

But a ratio is a starting point that gets treated as a target, and two teams with identical ratios can behave completely differently. The seniority mix is a bet on what the team will be able to do a year from now, and since coding agents became a normal part of engineering work, both ways of getting it wrong, too senior-heavy and too junior-heavy, have become more expensive.

Read the mix as coverage

When I look at a team's composition, I set the titles aside first and ask who on this team can take an ambiguous problem and own it end to end, and who does excellent work once someone else has specified it. The distribution across that line is the real mix, but titles blur it: ladders promote for tenure and reliable delivery as well as for comfort with ambiguity, so a team can be senior on paper and thin on owners in practice.

Picture two teams of six, each with two seniors and four mid-level engineers, identical on any headcount sheet. On the first team, both seniors can take a vague problem and turn it into a plan, so that work flows to whichever of them is free. On the second, one of the seniors was promoted for years of reliable delivery and still works best from a spec, so every vague problem waits on the same one person. The two teams share a ratio but not coverage, and only one of them is capped.

The ratio never tells me how much of next quarter's ambiguity the team can absorb, or through whom. I start from the standard numbers and check them by counting owners.

Diagnose senior-heavy gridlock

A senior-heavy team fails through gridlock rather than arrogance or cost, and you spot it when the same decision comes back a second time. Designs get relitigated after they were settled, and debates outlast the work they were supposed to unblock. Every boundary between two scopes stays contested, because the senior on either side of it could plausibly own the whole thing.

A platform team of five seniors takes up a storage migration. The design debate runs two weeks, ends in a decision, and then reopens when a new constraint surfaces, because the engineer who lost the first round never stopped believing in their approach. By the time the approach is finally settled, the migration deadline has moved, which reopens the debate under new constraints. The debate has now outlived the thing it was about.

The mechanism is contested ownership: five people who can each own the whole problem, on work that needs one owner, will spend their spare attention on each other. Shrink the overlapping scopes until each senior owns an area that is distinctly theirs, and if the scopes cannot be made distinct, move a senior to a team that is starving for one. Moving a strong engineer off a strong team feels like a loss, and it is also the transfer that pays back most: the sending team regains room to converge, and the receiving team gains an owner it could not hire.

One caution before you act on this diagnosis: vigorous review is not gridlock. A team that argues hard and then stays converged is healthy; gridlock is when convergence does not hold. Mistake healthy arguing for gridlock and you will break up a team that was working.

Diagnose junior-heavy low ceiling

A junior-heavy team fails more quietly, because the well-trodden work keeps shipping, which hides the problem from above. The symptoms show up in how work moves through the team: anything ambiguous queues on one person while reviews take longer, and the roadmap quietly narrows toward what the team already knows how to do. That last symptom is the dangerous one, because from the outside it looks like focus.

A product team of six carries one senior. Every ticket that says "investigate" or "design" rather than "implement" waits for that senior's attention, and the queue is visible in the review dashboard as one long column under a single name. The other five engineers are not coasting: one of them picks the well-specified ticket over the interesting vague one, not from laziness but because the vague one means waiting a week for the senior to have time to shape it with them.

This team is short a skill rather than discipline, and process will not close that gap. Everyone is trying hard and the team is still capped, so adding standups or tightening ticket templates treats a missing-senior problem as a discipline problem; standups are cheaper than a senior hire, which is why they get tried first. Add or borrow a second senior before you add anyone else, and then raise the ceiling deliberately, through teaching rituals like design review run as a classroom, rather than through more headcount. And the one person everything waits on is also a single point of failure, which is its own problem to fix.

Set the mix from next year's work

The ratio was only a starting point; the target comes from the work the team plans to do next year. Uncertain bets need seniors, and more of them than the work appears to need, because the expensive part of a bet is turning a vague problem into a plan, which is the skill you counted when you counted owners. Well-understood systems are where juniors grow fastest, because feedback arrives quickly and mistakes stay cheap.

So write down the year's portfolio, split it into bets and well-understood delivery, and staff the levels to match. Teams get this wrong in both directions: they staff an exploratory bet with juniors because the work looked simple from a distance, and the bet dies quietly because nobody on it could turn the problem into a plan. Or they keep seniors on a stable system because those seniors built it, while the bets go understaffed.

Redesign the junior seat

Everything to this point is the established advice, and it still holds, but coding agents have changed the junior seat itself. The old deal was that a junior paid their way from early on with boilerplate and routine fixes, the well-specified small work that every codebase generates. That work is where juniors learned the craft, and it is what agents have absorbed. Junior hiring fell by half or more within a year of agents becoming standard tooling.

It is easy to read that number as proof that juniors no longer work. Hire a junior on the old assumption and you will watch them flounder, because the ladder of small tasks they were supposed to climb no longer exists, and then you will conclude that juniors were the problem, when what failed was a seat you never redesigned. The seat has to be rebuilt as a designed apprenticeship:

• a small part of the product owned end to end, with agents doing the routine work
• agent output reviewed with a senior sitting alongside
• a planned path from supervised to independent ownership

A junior seat is now a training investment with a payoff schedule, and pretending it is still cheap capacity from day one sets the junior up to fail.

Keep funding the pipeline

From there it is tempting to stop hiring juniors at all. A team that once bought throughput with mid-level headcount can now buy the same throughput with fewer seniors working through agents, and the spreadsheet makes that trade look free. Seniors are made from juniors plus years, though, and the years do not happen unless someone pays for them. A team that stops funding those years is betting that someone else will fund them, at the exact moment other teams are placing the same bet.

The industry has run a version of this experiment: after 2008, companies froze early-career hiring for several years, and when hiring came back the market was short of the engineers those frozen years should have produced, the ones with three to five years of experience. The freeze saved money for exactly as long as it took the gap to reach mid-level, and then every company paid at once, in senior salaries bid upward by scarcity.

An all-senior team carries its own costs, and none of them show up in a headcount plan. There is nobody to promote, so your strongest people grow by leaving, and there is nobody to hand the well-understood systems to, so your seniors hold work that stopped stretching them years ago. Keep a thin junior layer and grow it deliberately, because it is the only reliable source of next year's mid-level engineers, and of the seniors after that. How thin can the layer get before it stops being a pipeline? I do not have a defensible number; thinner than the old ratios suggest and thicker than zero is as far as I can argue it.

Rebalance one seat at a time

When you conclude the mix is wrong, your first instinct will be to fix it in one planning cycle, but resist it and spread the change over quarters instead:

• Change one seat per quarter, and let the team resettle before you touch the next one.
• Add juniors one at a time so mentorship bandwidth keeps pace; a team that adds three juniors at once after a budget win collapses every senior's bandwidth at the same time, and then the juniors look like the problem they never were.
• Move a senior out only after what they own has a named successor, because a transfer that leaves an area without an owner converts a gridlock problem into a coverage problem.

The mix will drift again, because people grow and people leave, and the drift is fine. You will be back at this in a year, counting again who can own ambiguity and who needs the work specified, and if a junior you seated this spring has moved to the owner side of the line, the team made a senior instead of buying one.