How do you calculate team capacity?

Start from available hours, subtract leave and holidays, then subtract the standing overhead the team actually carries — meetings, support rota, code review, interviews. What remains is deliverable capacity, and for most knowledge teams it is between 45% and 60% of nominal hours rather than the 80% most plans assume.

Why do capacity plans always turn out wrong?

Because they count hours rather than usable blocks, and they ignore standing overhead. A team of six is not six people of capacity; after meetings, support and review it is often closer to three. Plans built on the first number miss consistently and in the same direction.

What percentage of capacity should you plan to?

Plan project work to roughly half of nominal hours for a team carrying normal overhead, and measure your own ratio rather than trusting that figure. Teams that plan to 80% or more are not being ambitious; they are building a plan with no room for the work that already exists.

How do you plan capacity for a team with support duties?

Take the support load out of capacity entirely rather than averaging it across everyone. Concentrating interrupts on one rotating person protects everyone else's focus and makes the remaining capacity predictable, which is worth more than the small amount of throughput you lose.

Capacity Planning That Survives Real Teams

Most capacity plans treat people as interchangeable hours. Here's a method that holds up in practice, worked through a single example end to end.

Take a team of six engineers. Standard week, nothing unusual.

Most capacity plans start here and reach for a number like 6 × 40 = 240 hours, discount it a bit for optimism, and commit to something in the region of 200. Then the quarter goes badly and nobody can say precisely why.

Let's do the same team properly, and watch where the hours actually go. I'll carry this one example the whole way through.

Start from the calendar, not the headcount

Six people, 40 hours nominal. 240.

Take out leave and public holidays. Over a quarter, with normal leave patterns, that is comfortably 10% before anything else happens. Down to about 216.

Now the standing overhead — the work that exists whether or not you plan for it.

Standups, a sprint ceremony, a team meeting, one-to-ones. Call it 5 hours a person a week. Down to 186.

Code review. Real teams spend meaningfully more on this than they admit; 3 hours a person a week is not a stretch on an active codebase. Down to 168.

Support and escalations. This one varies enormously. On this team, say two interrupts a day landing across whoever is nearest — 4 hours a person a week. Down to 144.

Interviews, onboarding, an incident, someone's laptop dying. 2 hours a person. Down to 132.

So the six-person team that looked like 240 hours is carrying about 132 hours of deliverable capacity. Fifty-five percent.

That is before we ask whether those hours are any good.

The hours are not equal

Here is where most plans stop, and where they go wrong for the second time.

Those 132 hours are not 132 hours of engineering. They are spread across days that also contain the meetings and interrupts we just subtracted, which means they arrive in fragments.

If the support interrupts land randomly across the team, every person's day is broken into 60- and 90-minute pieces. For anything requiring sustained reasoning, those pieces are worth considerably less than their clock value — the context switching cost is exactly this. Our six-person team might have 132 nominal hours and something closer to 80 hours of genuinely useful engineering time.

Two teams with identical capacity on paper can differ by 40% in what they actually ship, purely on the shape of the day.

The fix that costs almost nothing

Take the support load off the team and give it to one person on rotation.

Same total interrupt hours. Completely different distribution. One person's week is shredded; five people's weeks are clean. The team loses one person's focus and recovers five people's, which is the best trade available to most engineering managers and is roughly free to implement.

Do the same with meetings — cluster them rather than spreading them, because a meeting at 11:00 costs the morning and a meeting at 09:00 costs an hour. That argument is in the real cost of meetings.

Our team's usable time goes from around 80 hours to something like 110, without hiring anyone or asking anyone to work harder.

Now you can plan

Plan project work against 110 hours, not 240.

That will feel wrong. It will feel like you are planning to less than half capacity, and someone senior will say so. The honest answer is that you are planning against the capacity that exists, and the 240 was never real — it was nominal hours with the actual work of running a team subtracted from nobody's total.

Teams that plan to 132 and hit 110 look like they are underperforming by 17%. Teams that plan to 110 and hit 110 look reliable. Same team, same output. The only difference is whether the plan was honest.

Measure your own ratio

Do not take 55%, or 45%, or any number from an article. The ratio is specific to your team and it moves.

Take four weeks. Track two things: total available hours, and hours in sustained blocks. The ratio between them is your real capacity multiplier, and it is the single most useful number a manager of knowledge workers can have. Re-measure quarterly, because it drifts — usually downward, as the team accumulates standing commitments nobody ever removes.

Then use it. When someone asks whether you can take the extra project, you have an answer with arithmetic behind it rather than a feeling.

When the answer is "hire"

The interesting thing about doing this properly is how often the answer stops being "hire".

Our six-person team was at 80 usable hours and got to 110 by changing an interrupt rota and moving some meetings. Thirty hours a week is most of another engineer, recovered for the cost of a calendar change. If the plan had gone straight to headcount, you would have spent six figures to buy back capacity that was already there, and the new hire would have inherited the same fragmented week.

Hire when the structural fixes are exhausted and the ratio is still short. Not before. The ROI calculator does this arithmetic if you want it laid out.

ProdView gives you the two numbers this method needs — available hours and sustained focus blocks, per team, over time — from activity metadata rather than timesheets. Free for three seats, which is enough to measure your own ratio before deciding anything.