Before deciding you have no capacity, measure it. Most teams have never looked at where the engineering week actually goes, and the split between maintenance, interruption and new work is usually different from what everyone assumes. Sometimes there is more room than expected. More often the problem turns out to be interruption rather than volume, which has a completely different fix.
Four numbers, all available from tools you already run, none requiring anyone to fill in a timesheet.
Key takeaways
- Do not estimate this, measure it: Perception and reality diverge widely here.
- Four numbers from existing tools: Unplanned work, incident hours, context switching, and untouched roadmap.
- Interruption and volume look the same and need different fixes: One is structural, the other is capacity.
- Measure for four weeks before acting: One sprint is noise.
Number 1: unplanned work as a share of the total
From your issue tracker: of everything worked on in the last four weeks, how much was not planned at the start of the period? Urgent bugs, support escalations, requests from elsewhere in the business.
This is the single most useful figure. A team running at a fifth unplanned is normal for a product with real users. A team at half is not short of capacity, it is short of protection, and hiring will not fix it because new people get interrupted too.
Number 2: hours spent on incidents and support
Also from the tracker, or from whatever handles support. Count both the time on the incident and the time lost afterwards, since a developer pulled out of deep work does not resume instantly.
Track which parts of the system generate this. It is usually concentrated: a small number of components produce most of the interruptions. That concentration is useful, because fixing two or three specific things often returns more capacity than adding a person.
Number 3: how fragmented the week is
How many distinct pieces of work does one engineer touch in a week? You can see this in the tracker or in the repository history.
An engineer moving between six or seven items a week is not doing six items of work; they are doing perhaps three, plus the cost of switching between them. Fragmentation is the most invisible capacity loss, because everyone is busy and every item shows activity. It is also the reason a team can feel fully occupied while the roadmap does not move.
Number 4: how much roadmap work actually happened
Of the work completed in the last four weeks, how much was on the roadmap you set at the start of the quarter?
This is the number that tells you whether you have a capacity problem at all. If a quarter of completed work is roadmap work, your team has capacity and it is being spent elsewhere. If it is almost none, and numbers 1 and 2 are low, then the volume genuinely exceeds the team.
Reading them together
| Pattern | Diagnosis | What helps |
|---|---|---|
| High unplanned, low roadmap | Interruption | Protect time, fix the noisy components |
| Low unplanned, low roadmap, high fragmentation | Too many parallel threads | Fewer things at once |
| Low unplanned, low fragmentation, low roadmap | Genuine capacity shortfall | More capacity |
| Moderate everything, roadmap moving | It is working | Leave it alone |
Only the third row is solved by adding people or an external team. The first two get worse when you add capacity, because more people means more coordination and more things in flight.
If you land on the third row, the options are set out in what to do when your engineering team has no capacity.
How to measure without adding overhead
Do not introduce timesheets. They cost more than they reveal and the data is unreliable because people reconstruct it on Friday.
Everything above can be derived from what is already recorded: tickets with labels, repository history, incident records. One person can pull the four numbers in an afternoon. Run it for four weeks before acting, because a single sprint is noise and the pattern is what matters.
Share the numbers with the team. They usually recognise the picture immediately and can tell you which two components are causing most of number 2, which is the fastest capacity gain available to most companies.
Ali Boran Gazel