Operations

intermediate📖 7 min read

Capacity Planning

Also known as: Resource PlanningWorkforce PlanningHeadcount PlanningTeam CapacityResource Allocation

Effective Capacity = Team Size × Hours × Productivity Factor × (1 − Meeting %)

💡The Concept

Capacity planning is the process of determining how much work your team can handle and aligning resources to demand. The core calculation is: Available Capacity = Team Size × Working Hours × Productivity Factor (typically 0.6-0.8 after meetings, admin, and context-switching). A team of 5 engineers working 40h/week at 70% productivity has 140 productive hours/week, not 200. Companies that do capacity planning well ship 35% more features per engineering dollar by eliminating both overwork (burnout → turnover) and underutilization (idle teams → wasted salary).

⚠️The Trap

The capacity trap is planning at 100% utilization. Organizations that load teams to 95-100% see throughput DECREASE by 20-30% because there's no buffer for bugs, urgent requests, sick days, or creative thinking. McKinsey's research shows optimal knowledge work utilization is 70-85% — above that, quality drops, bugs increase, and burnout skyrockets. Another trap: headcount-based planning. Adding 1 engineer doesn't add 1 engineer's worth of output — it adds 0.5-0.7 due to onboarding, mentoring overhead, and increased communication costs (Brooks's Law).

🎯The Action

Calculate your team's true capacity: (Number of ICs × Weekly Hours × Productivity Factor) - Planned meetings - On-call hours = Actual Weekly Capacity. Track velocity (story points or tickets completed) over 4-week rolling average. If actual output is consistently below 70% of theoretical capacity, audit where time goes — most teams lose 30-40% to meetings, Slack, and context-switching. Set a 'capacity budget': 70% planned work, 15% unplanned/bugs, 15% tech debt and improvements.

⚡Pro Tips

The best capacity metric is 'cycle time' (time from work-started to work-done), not velocity. Cycle time tells you how fast your SYSTEM works; velocity tells you how much you did. A team with decreasing velocity but stable cycle time is doing fewer, higher-impact projects — that's often good.

Never plan capacity in 'developer-months' — it's a fiction. 3 developers working 4 months ≠ 12 developer-months of output. Communication overhead grows quadratically: a team of 3 has 3 communication channels, a team of 6 has 15, a team of 10 has 45.

Keep a 20% 'slack' budget explicitly. Google, 3M, and Atlassian all have variants of '20% time' — and it's not just for innovation. The slack absorbs unexpected work without derailing the mainline roadmap.

🚫Common Myths

✗Myth: “Adding more people makes projects go faster”

✓Reality: Brooks's Law (from 'The Mythical Man-Month'): adding people to a late project makes it later. A new hire on a 5-person team reduces team productivity by 15-20% for 2-3 months due to onboarding, mentoring, and communication complexity. Nine women can't make a baby in one month.

✗Myth: “Higher utilization means better efficiency”

✓Reality: A highway at 90% capacity is a parking lot. Similarly, teams at 90%+ utilization have no room for unexpected work, quality drops, and one sick day cascades into missed deadlines. The most efficient teams operate at 70-80% planned utilization with explicit buffers.

📈Industry Benchmarks

Engineering Utilization Rate

Software Engineering Teams (Startups & Scale-ups)

Elite

70-80%

Good

60-70%

Average

50-60%

Needs Work

40-50%

Critical

< 40% or > 90%

Source: State of Engineering Productivity Report, Jellyfish 2024

Time in Meetings

Individual Contributors (not managers)

Elite

< 15%

Good

15-20%

Average

20-30%

Needs Work

30-40%

Critical

> 40%

Source: Microsoft Work Trends Report, 2024

🎮Decision Scenario: The Scaling Challenge

You're VP of Engineering at a Series B startup. Revenue is growing 15% month-over-month, but your 12-person engineering team is struggling to keep up with demand. The CEO has approved budget for up to 8 new hires.

Team Size

12 engineers

Current Utilization

93%

Bug Rate

2.5x above target

Sprint Completion Rate

65%

Hiring Budget

8 headcount approved

Decision 1

You need to decide how to use the hiring budget. Your team is burned out at 93% utilization, bugs are piling up, and only 65% of sprint goals are achieved. The CMO needs 3 new integrations built this quarter. The CTO wants to migrate from a monolith to microservices.

Hire all 8 engineers immediately and assign them to the integrations and microservices migrationClick to reveal →

Hiring 8 people for a 12-person team is a 67% team increase. Communication channels jump from 66 to 190. Onboarding 8 people simultaneously overwhelms your senior engineers — each new hire needs 5-10 hours/week of mentoring. Team velocity drops 30% for 3 months. The integrations stall because new hires don't understand the codebase.

Team Size: 12 → 20Velocity (Q1): -30% (onboarding drag)Communication Channels: 66 → 190 (3x overhead)

Hire 3 senior engineers now, reduce utilization target to 75%, and delay the remaining 5 hires until infrastructure stabilizesClick to reveal →

Smart. Adding 3 seniors to a 12-person team is manageable (15 → 105 channels, reasonable). Dropping utilization from 93% to 75% immediately improves quality — bug rate halves within 4 weeks. Sprint completion jumps to 85%. After 2 months, infrastructure is stable enough to absorb the next batch of hires effectively.

Team Size: 12 → 15 (then 20 in Q2)Utilization: 93% → 75% (healthy)Bug Rate: 2.5x → 1.2x targetSprint Completion: 65% → 85%

Decision 2

Two months later, your 15-person team is humming at 78% utilization. Bug rate is down. But the CEO is pushing hard for the microservices migration because 'everyone at the conference was doing it.' Your tech lead estimates 6 months of dedicated work for 4 engineers.

Start the microservices migration — allocate 4 engineers full-timeClick to reveal →

You reduce product delivery capacity by 27% (4/15 engineers) for 6 months while the migration produces zero user-facing value. Revenue features slow down, competitors close the gap. Halfway through, you realize the migration is actually 10 months, not 6 (infrastructure projects ALWAYS take longer). You've committed to a project that starves the business.

Feature Delivery Capacity: -27% for 6-10 monthsUser-Facing Value: $0 from migration

Hire the remaining 5 engineers, then extract services incrementally — one at a time, alongside product workClick to reveal →

Correct. The 'strangler fig' pattern lets you extract microservices one at a time while continuing product delivery. With 20 engineers at 75% utilization, you can dedicate 2-3 engineers to gradual migration while maintaining full product velocity. Each extracted service is deployed and validated independently. It takes 9 months total but ZERO months of product work stoppage.

Team Size: 15 → 20Product Velocity: Maintained (no stoppage)Migration Approach: Incremental — zero risk

🧪