The deadline I missed because nobody checked capacity

In Q1 2024, I committed to shipping a hardware certification update by end of February. The initiative was on the roadmap. Engineering had estimated effort. The CEO had told the board.

What I didn't do — and didn't have a tool to make easy — was check whether the certification engineer was actually available.

He was already at 110% utilization on a different project. The certification work needed his deep involvement for two weeks. There was no way to fit it.

We slipped. The CEO was unhappy. The engineer was burned out. The board was confused.

That deadline was the trigger for me building a real capacity feature into my workflow. This guide is what I've learned since.

Screenshot: assets/screenshots/blog/capacity-overcommit-warning.png — A team utilization dashboard showing two members at 110%+, flagged in red.

What capacity planning actually means for product teams

Most software engineering teams that "do capacity planning" do it badly:

They count headcount. ("We have 5 engineers.")
They estimate story points per sprint. ("Velocity is 40 points.")
They commit work up to the velocity number.
They miss deadlines anyway.

The reason is that headcount and velocity are aggregate fictions. Real capacity is about specific people, working on specific things, with specific dependencies and PTO and meetings and context-switches.

Capacity planning, done right, answers four questions before you commit to a new initiative:

Who is available to work on this?
When are they actually free of other commitments?
For how long can they sustain this without burning out?
What are the dependencies that could block them?

If your tooling can't answer these in under 60 seconds at the moment of commitment, you don't have capacity planning. You have headcount math.

The five time horizons of capacity (and what each tells you)

Different decisions need different time horizons. Most tools show only one (usually weekly), and PMs who want more end up in spreadsheets.

Daily capacity (next 1-7 days)

Use it for: firefighting decisions. "Can engineer X take on this urgent bug?" What to show: booked hours per person per day. Highlight anyone above 8 hours.

Weekly capacity (next 1-4 weeks)

Use it for: sprint planning, near-term commitments. What to show: utilization % per person per week. Flag anyone above 100%.

Monthly capacity (next 1-3 months)

Use it for: committing to new initiatives that span multiple sprints. What to show: rolled-up utilization with PTO factored in. This is where over-commitment usually hides.

Quarterly capacity (current + next quarter)

Use it for: strategic roadmap decisions. "Can we add this big bet to next quarter?" What to show: team capacity vs planned initiatives. Visualize the buffer or shortfall.

Yearly capacity (current FY)

Use it for: hiring decisions, strategic prioritization, OKR setting. What to show: total capacity vs total commitment. The annual view often reveals chronic over-commitment that weekly views miss.

Screenshot: assets/screenshots/blog/capacity-five-horizons.png — Five-tab view showing the same team across daily, weekly, monthly, quarterly, yearly views.

The reason CapacityIQ in Roadmap OS supports all five horizons is that I wanted to stop guessing across them. Different stakeholders care about different horizons. The CEO wants the quarterly view. The engineering manager wants the weekly. The PM needs both.

The "capacity check before commitment" rule

The single highest-leverage rule I've adopted is this: no initiative gets added to the roadmap until I've checked capacity in the same view.

Not after. Not "I'll check later." Not "we'll figure it out in sprint planning."

At the moment of commitment.

This rule sounds obvious. In practice, the friction of switching tools (roadmap → spreadsheet → mental math → back to roadmap) is enough that most PMs skip it. So they over-commit. So they slip. So trust degrades.

The fix is twofold:

Make capacity visible inside your roadmap tool (not in a separate spreadsheet).
Make it a hard rule. No commitment without a capacity glance.

I went from 60% on-time delivery to 89% in the first quarter of running this rule consistently. That's not because the team got faster. It's because I stopped committing to work I couldn't deliver.

Screenshot: assets/screenshots/blog/capacity-inline-roadmap.png — Adding a new roadmap initiative with a capacity sidebar showing team availability for the date range.

The 80% rule (and why 100% utilization is a lie)

The most damaging metric in capacity planning is the one that says "we're at 100% utilization."

What that actually means is:

100% of planned hours are scheduled
0% buffer for the inevitable urgent work
0% buffer for sick days
0% buffer for context switches
0% buffer for PR reviews and meetings
0% buffer for actually thinking

Anyone who has shipped product knows that 100% utilization = 70% actual delivery. The remaining 30% gets eaten by the things that aren't on the schedule.

Plan for 80%. That gives you:

1 day a week for unplanned urgent work
Margin for sick days and PTO
Margin for code review, meetings, async communication
Margin to think strategically (not just execute)

If your team is at 80% utilization on the schedule, they'll feel like they're at 95-100% in reality. That's the right calibration.

If your team is at 100% utilization on the schedule, they're already burning out. The next surprise will tip them over.

Individual vs team capacity (and why both matter)

Aggregate team capacity is necessary but not sufficient. Two teams at "85% utilization" can be in completely different shapes:

Team A: Every member at 85%. Healthy. Sustainable. Team B: Three members at 110%, two at 60%. Same average, but the heavy hitters are about to burn out and the others are under-utilized.

If your tool only shows team-level utilization, you'll miss this. You need individual rollups, sortable, with the outliers flagged.

CapacityIQ surfaces this with a per-person view alongside the team view. The two tell different stories, and you need both.

Screenshot: assets/screenshots/blog/capacity-individual-vs-team.png — Two views side by side: team average 85% (all green), individual rollup showing 3 members at 110% (red) and 2 at 60% (amber).

Capacity for cross-functional teams (where it gets hard)

A pure-engineering team is the easy case. Capacity gets messy when an initiative needs:

Engineering (estimated in hours / story points)
Design (estimated in days)
PM specs (estimated in hours, but compressed)
QA (variable, dependent on engineering)
Marketing prep (sequential, dependent on engineering completion)

The rule for cross-functional capacity:

Don't try to roll everything into one number. Instead, show capacity per role per initiative. Engineering can be at 80%, design at 110%, marketing at 60% — all on the same initiative — and the bottleneck is design, even if the team average looks fine.

The honest version: most tools (including the one I built) handle this imperfectly. Cross-functional capacity is hard. The best you can do is make it visible and let humans triage. There's no autopilot.

Capacity warning signs to watch for

Even with great tooling, capacity problems hide. The warning signs:

1. The "we're fine" stand-up.

Engineering says "we're on track" three weeks in a row, then suddenly "actually it's slipping." This is usually a capacity problem that compounded silently.

Fix: Daily capacity check, not just status check. "How many hours did you spend on this initiative yesterday?" reveals what status hides. 2. Heroes and martyrs.

One engineer is consistently shipping. Two are slipping. The hero is at 110% utilization permanently.

Fix: Look at individual capacity, not team. Re-distribute work. Don't reward heroism with more work. 3. The "small ask" parade.

The roadmap looks reasonable, but everyone is being asked for "small things" outside the roadmap that eat 30% of their week.

Fix: Track unplanned work. If unplanned work consistently eats >20% of capacity, the roadmap is fiction. 4. The post-launch hangover.

After every major launch, the next sprint shows zero progress.

Fix: Plan for it. Bake a "recovery week" into the schedule after every major launch. It's not lost time — it's predictable.

Screenshot: assets/screenshots/blog/capacity-warning-flags.png — Dashboard with four warning indicators highlighted: hero pattern, unplanned-work %, post-launch dip, weekly drift.

A working capacity workflow

Here's the cadence I run weekly:

Monday (15 min): Look at next-week capacity per person. Flag anyone at >100%. Re-allocate or push out work.
Wednesday (10 min): Mid-week check. Anything that's slipping? Capacity issue or scope issue?
Friday (15 min): Look at next-month capacity. Anyone consistently overloaded? Is the next-month roadmap commitment realistic?
End of month (30 min): Look at quarterly capacity vs roadmap. Are the bets still feasible? Is anyone burning out?

That's 70 minutes a month. The trade is that I haven't missed a deadline-from-overcommitment in a year.

When capacity tools become micromanagement

Capacity planning has a dark side: time-tracking-as-surveillance.

The version that works: showing the team capacity overall, flagging overload, helping the team push back on commitment.

The version that kills culture: tracking individual hours, comparing engineers' velocity, using "low utilization" as a performance metric.

The team uses CapacityIQ for the first version. We've never used it for performance reviews, and we never will. If you're choosing a capacity tool, choose one your team trusts. The capacity data is only useful if engineers report it honestly.

The bottom line

Capacity planning is the half of roadmapping that most teams skip. The result: missed deadlines, overcommitted teams, burnout, and broken trust.

Make capacity visible inside your roadmap tool. Adopt the "capacity check before commitment" rule. Plan for 80%, not 100%. Look at individuals, not just teams. Watch for the warning signs.

If you're using a roadmap tool that doesn't make capacity visible, you're flying blind on the most expensive question you can ask: "Can my team actually deliver what I'm about to commit to?"

CapacityIQ in Roadmap OS is built for this. Daily, weekly, monthly, quarterly, and yearly views. Per-person and team-level. Right next to the roadmap. Free tier available.

Capacity Planning for Product Teams: A Practical Guide