Ten engineers, thirteen weeks. The plan assumes 130 engineer-weeks. The quarter ends with about half the roadmap shipped, and the retrospective blames estimation.
Estimation was not the problem. The plan was built on time the team never had.
Where a quarter goes
Take the same ten engineers and subtract what is already committed before any roadmap work starts.
| Where the time goes | Share |
|---|---|
| Leave, holidays, and sickness | 12% |
| Meetings and ceremonies | 15% |
| Maintenance and upgrades | 20% |
| On-call, incidents, and support | 10% |
| Hiring and onboarding | 5% |
| Left for the roadmap | 38% |
Those shares are illustrative, and yours will differ. With these, ten engineers behave like 3.8, and the quarter holds 49 engineer-weeks instead of 130.
No one on that team is underperforming. The work in the table is real work. It is simply not roadmap work, and the plan did not count it.
The Engineering Capacity Calculator does this subtraction with your own percentages. Measure them for two or three sprints before trusting the result.
The cheapest engineer is the one you already have
When capacity is short, the reflex is to hire. Hiring is slow: a new engineer takes months to find and months more to become productive, and takes time from the existing team while that happens.
Reducing a drain pays back at once. With the numbers above, cutting maintenance from 20% to 15% returns 6.5 engineer-weeks in a quarter. That is half an engineer, starting now, with no recruiting.
So before asking for headcount, find the largest drain and ask what it would take to shrink it.
- Maintenance is the largest. Old systems need investment or retirement. Upgrades that are done by hand each time should be automated.
- On-call and support is the largest. The same incidents are recurring. Fixing their causes buys more roadmap than a new hire.
- Meetings are the largest. This is the only one a leader can change in a week.
When a platform team makes sense
Some of the drain is shared across every team: waiting for builds, requesting environments, chasing access, filing a ticket to change a DNS record. No single team can fix it, because no single team owns it.
That is the case for a platform team, and it is a question of scale. Suppose each developer loses six hours a week to this kind of friction and a platform team could remove 40% of it. For 120 developers that is worth about $1.15 million a year in recovered time, against roughly $1 million for five platform engineers and their tooling. It pays, narrowly.
Run the same numbers for 40 developers and it does not come close. A platform team is a fixed cost, and its return grows with the number of people it serves. Below the break-even point, the better move is a managed platform, or part of a senior engineer's time on the worst two sources of friction.
The Platform Team ROI Calculator shows the break-even size for your own figures.
Build less
The last lever is the amount of software the team has to keep alive. Every internal tool that gets built joins the maintenance line in the table above, permanently.
Build-versus-buy estimates usually compare a project with a subscription: three engineers for six months against a $90,000 licence. The comparison leaves out the overrun, and it leaves out the engineer who maintains the tool for as long as it exists. With those included, the build in that example costs about a million dollars over three years and the purchase under half that.
That does not mean always buy. It means count the maintenance before deciding, and build only what customers choose you for. The Build vs Buy Calculator puts both sides on the same footing.
Plan the next quarter differently
- Measure the split. Track where time goes for two or three sprints. Rough categories are enough.
- Plan against roadmap capacity. Multiply headcount by weeks by the share that is left. Commit to that.
- Pick one drain to reduce. Put the work to reduce it on the roadmap, as a project, with an owner.
- Show the table to your stakeholders. A plan that states its own capacity is easier to defend than one that quietly assumes 100%.
A roadmap that fits the team's real capacity ships. One planned against headcount is late on the first day.
Work out your team's real capacity. It runs in your browser, with no sign-up.