Capacity planning

You have 10 engineers. Your VP of Product has scoped work that requires 10 engineers for the quarter. Perfect fit, right? So you commit. Then three months later you’ve delivered 60% of what you promised, everyone’s frustrated, and someone in leadership is muttering about “engineering velocity.”

You didn’t have a performance problem. You had an arithmetic problem. 10 engineers has never meant 10 units of output. Not once, in the history of building software.

The job

Capacity planning is the discipline of understanding what your team can actually deliver and making commitments you can keep. It bridges the gap between headcount — the number of people you’re paying — and throughput — the amount of work that actually gets done.

Most engineering leaders over-commit because they confuse these two things. They look at their team size, mentally multiply by some vague notion of productivity, and commit to a number that assumes every person is writing code eight hours a day, five days a week.

The tax on capacity is 30-40% in most organisations, and nobody accounts for it.

Context switching. Meetings. On-call rotations. Tech debt. Onboarding new hires. Supporting other teams. Code reviews. Incident response. All of it real work, none of it “delivery” in the way your product team counts it.

Until you measure and communicate this gap, you will always over-promise and under-deliver. And that erodes trust faster than almost anything else.

Why it matters

Over-commitment is the single most corrosive dynamic in engineering leadership. Here’s what happens:

You commit to more than you can deliver. You miss. Leadership loses confidence. Next quarter, they ask for more visibility, more reporting, more checkpoints. That reporting overhead further reduces your actual capacity. You miss again. The cycle tightens.

I’ve watched this death spiral kill engineering credibility at three different companies. At one — a mid-stage B2B SaaS company with about 80 engineers — the CTO committed to a roadmap that assumed 100% utilisation. By Q2, they’d delivered 55% of commitments. By Q3, the CEO had hired a “VP of Engineering Execution” to sit between the CTO and the teams. By Q4, the CTO was gone.

The tragedy is that the engineering team was actually performing well. They just couldn’t show it because the commitments were built on fantasy numbers.

The flip side is powerful. Engineering leaders who consistently deliver what they promise become the most trusted people in the building. Not because they’re doing more work — often they’re committing to less — but because reliability compounds. After three quarters of hitting your commitments, leadership stops questioning your estimates and starts asking for your opinion on strategy.

What good looks like

Struggling: Capacity is assumed from headcount. Every sprint or quarter starts with optimistic commitments. Delivery consistently falls short. The team feels stretched and demoralised. Leadership adds process and oversight, which makes things worse.

Mature: Capacity is measured empirically. Commitments are made against actual available capacity, with explicit buffers for unplanned work. Delivery is consistent and predictable. The team has breathing room to do quality work. Leadership trusts the numbers because they keep proving accurate.

Markers of excellence:

• You can state your team’s actual capacity as a percentage of theoretical capacity, and you can explain where the rest goes
• Your delivery rate against commitments is above 85% quarter-on-quarter
• You maintain an explicit allocation for unplanned work (typically 15-20%) and it’s understood and accepted by stakeholders
• New hire productivity ramps are factored into capacity, not treated as instant additions
• You review and recalibrate your capacity model quarterly based on actual data

The approach

1. Measure actual capacity, not theoretical

Start with a brutally honest audit of where your engineers’ time actually goes. Not where you think it goes. Where it actually goes.

For a typical team of 10 engineers over a quarter (roughly 520 person-days), here’s what I’ve seen consistently:

Activity	Days	% of Total
Feature development	296	57%
Meetings & ceremonies	52	10%
On-call & incident response	26	5%
Code review & pairing	42	8%
Tech debt & maintenance	36	7%
Onboarding & mentoring	16	3%
Cross-team support	26	5%
PTO & sick leave	26	5%
Total	520	100%

That 57% number will sting. It might be lower for your team. At one organisation I worked with, it was 43% — they’d accumulated so much meeting overhead and cross-team dependency that less than half their engineering time went to building things.

You don’t need timesheets to measure this. Nobody wants timesheets, and they produce garbage data anyway. Use proxies: look at your issue tracker for delivery throughput, your calendar system for meeting load, your on-call schedules, your PTO records. You can get to 80% accuracy without asking anyone to track their time.

2. Calculate your capacity factor

Your capacity factor is the ratio of actual productive capacity to theoretical capacity. From the example above: 57%.

This number is your planning currency. When someone asks “can 10 engineers deliver this in a quarter?” the answer is “10 engineers have 296 productive days this quarter. Does this work fit in 296 days?”

Not 520 days. Not even close to 520 days.

Some leaders resist this because it feels like admitting inefficiency. It’s not. That 43% of non-delivery time isn’t waste — it’s the operational overhead of running a software team. Code reviews make the code better. On-call keeps the system running. Meetings (some of them, anyway) coordinate work that would otherwise collide. The waste isn’t in doing those things. The waste is in pretending they don’t exist when you make commitments.

3. Build in a buffer for unplanned work

Even after accounting for known overhead, shit happens. Production incidents that consume a week. A critical security vulnerability. An urgent request from your biggest customer. The CEO’s pet project that materialises from nowhere.

Reserve 15-20% of your productive capacity for unplanned work. Yes, this means your “committable” capacity for a 10-person team is roughly 240 days per quarter, not 520.

That feels aggressive. But track your unplanned work for two quarters and tell me it’s not accurate.

If the unplanned work doesn’t materialise, great — you’ve got capacity to pull forward next quarter’s priorities, tackle tech debt, or invest in developer experience. Your team gets the rare gift of breathing room. That’s not wasted capacity. That’s how you keep good engineers.

4. Account for ramp time

A new hire on day one has approximately zero productive capacity. An experienced engineer in a new domain takes 3-6 months to reach full productivity. Yet most capacity plans treat new hires as fully productive from their start date.

Use a ramp curve:

• Month 1: 15% productivity (learning codebase, tooling, processes)
• Month 2: 40% productivity (contributing with significant support)
• Month 3: 65% productivity (contributing independently on smaller tasks)
• Month 4-6: 80-90% productivity (fully independent, still learning domain nuances)

If you’re hiring four engineers who start in January, don’t count them as four full engineers in Q1. You’ve got roughly 1.2 FTE of productive capacity from them that quarter. Plan accordingly.

And remember: the engineers mentoring those new hires are spending some of their capacity on onboarding, which further reduces available throughput. It’s turtles all the way down.

5. Communicate capacity, not just commitments

Most engineering leaders present their quarterly plan as a list of things they’ll deliver. That’s necessary, but insufficient. Also present the capacity model behind it.

Show leadership:

• Total headcount and theoretical capacity
• Capacity factor and what drives it
• Available capacity after buffer
• How that capacity maps to commitments
• What didn’t make the cut and why

This transparency is uncomfortable the first time. Some leaders worry it invites micro-management. In practice, the opposite happens. When leadership understands the math behind your commitments, they stop second-guessing them. They might still push back — “can we reduce meeting overhead?” or “do we really need that much buffer?” — but those are productive conversations, not trust-eroding ones.

6. Recalibrate quarterly

Your capacity factor isn’t static. It changes as your team grows, as processes evolve, as the codebase matures. Measure actual delivery against planned capacity every quarter and adjust.

If you planned for 57% utilisation and actual delivery used 52%, figure out where the extra 5% went. Was it more incidents than expected? A spike in cross-team support requests? An underestimation of onboarding load?

This data is gold. After four quarters of measurement, you’ll have a capacity model that’s accurate to within a few percentage points. That predictability is worth its weight in headcount.

The conversations

With your team

Trust-building: “I’ve committed us to 80% of what Product asked for this quarter. The other 20% is important, but we don’t have capacity for it without cutting quality or burning people out. Here’s what we’re doing and what we’re not.”

Trust-eroding: “We’ve committed to the full roadmap. It’ll be tight but I think we can make it work.”

Your team knows when commitments are unrealistic. When you over-commit on their behalf, they lose faith in your judgement. When you protect their capacity, they’ll run through walls for you.

With Product

Trust-building: “Here’s our capacity model for Q2. We’ve got 240 productive days across the team. Your top three priorities fit in 210 days, which leaves a buffer for unplanned work. Priority four would need either more people or a trade-off against priorities one through three.”

Trust-eroding: “We can probably do all four. Let me check with the team.”

Product partners respect engineering leaders who can articulate constraints clearly and offer trade-offs. “We can do A, B, and C, or we can do A, B, and D — but not all four” is a thousand times more useful than a vague yes followed by a painful no three months later.

With leadership

Trust-building: “Last quarter we committed to 14 initiatives and delivered 13. Our capacity factor held at 55%, consistent with the previous two quarters. For Q3, I’m planning against the same factor, which gives us room for these commitments.”

Trust-eroding: “We had a tough quarter. A few things slipped. We’ll try to catch up next quarter.”

Numbers beat narratives. When you can show a consistent track record of accurate capacity planning and reliable delivery, you don’t need to sell leadership on anything. The data speaks.

Common failure modes

Planning for 100% utilisation. This is the original sin. No team operates at 100% utilisation, and planning as if they do guarantees failure. Even factories don’t run at 100% utilisation — they build in maintenance windows and changeover time. Software teams have far more variability than factories.

Treating all engineers as interchangeable. A senior engineer with five years of domain knowledge is not fungible with a new hire. Capacity planning needs to account for skill distribution and knowledge concentration. If your only database expert is on paternity leave for a month, your database-related capacity is zero, regardless of team size.

Ignoring the capacity cost of growth. Hiring three people doesn’t add three units of capacity in the short term. It might add one unit while consuming one unit from existing team members who are mentoring and onboarding. In the short term, growing the team actually reduces capacity. Plan for this.

Letting buffer become slop. Your unplanned work buffer exists for genuine unplanned work, not for commitments that didn’t fit in the plan. If you routinely fill your buffer with planned work, you’ve just returned to over-commitment with extra steps.

Optimising for utilisation instead of outcomes. High utilisation looks productive but often indicates a team with no slack to respond to opportunities. The goal isn’t to keep every engineer busy every minute. It’s to deliver the right things reliably. The best teams operate at 70-80% planned utilisation and use the rest for quality, learning, and responding to the unexpected.

Getting started

If you’re not doing capacity planning today, start here.

This week: Run a quick audit. Look at your last quarter. How many things did you commit to? How many did you deliver? That ratio is your current effective capacity factor, whether you planned for it or not.

Next two weeks: Build a simple capacity model. Take your team size, multiply by working days, subtract known overhead (PTO, meetings, on-call), and apply a 15% buffer. Compare the result to what you committed to last quarter. I’d bet good money the commitments exceeded the capacity.

This quarter: Use your new capacity model to plan the current quarter. Commit to less than you think you can do. Aim for 85% of calculated capacity. Track delivery weekly. At the end of the quarter, compare planned vs. actual and recalibrate.

Next quarter: Share the capacity model with your Product counterpart and your leadership chain. Show them the math. Have the conversation.

The first time you under-commit and over-deliver, something shifts. People start trusting your estimates. Product starts prioritising more ruthlessly because they know the capacity constraint is real, not negotiable. Leadership starts treating engineering like a strategic function instead of a feature factory.

That’s worth more than any number of heroic sprints.

Downloads

The Capacity Planning Template includes a team capacity calculator, an overhead audit worksheet, and a quarterly commitment tracker. Enter your team composition and known overhead categories, and it will calculate your available capacity and capacity factor automatically. Use the commitment tracker each quarter to measure delivery against plan and recalibrate your model over time.

Related plays

• Scenario Planning — Use your capacity numbers to build realistic scenarios. Without accurate capacity, your scenarios are fiction.
• Investment Framing — Capacity tells you what you can do. Investment framing tells you what you should do with that capacity.
• Building Long-term Credibility — The quarterly recalibration loop that makes your capacity model better every cycle.