Capacity Planning
Also known as: Resource PlanningWorkforce PlanningHeadcount PlanningTeam CapacityResource Allocation
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).
Real-World Example
Valve Software (creators of Steam) operates without traditional managers or capacity planning quotas. However, they strictly enforce that desks have wheels so employees can physically roll to whichever project needs their capacity most. They plan capacity purely on peer-perceived value: if a project cannot attract engineers to roll their desks over to it, the project doesn't get built, ensuring capacity is only spent on the highest-impact work.
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
✗“Adding more people makes projects go faster”
✓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.
✗“Higher utilization means better efficiency”
✓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.
Real-World Case Studies
Basecamp
Continuous
Basecamp enforces a strict 6-week development cycle ('Shape Up'). But critically, every 6-week cycle is followed by a 2-week 'Cooldown' period. During Cooldown, engineers have zero planned capacity. They use this time to fix bugs they care about, explore new ideas, or just recharge. This explicit slack ensures the 6-week cycles run at maximum efficiency without burning out the team.
Planned Capacity Cycle
6 Weeks
Unplanned 'Cooldown' Buffer
2 Weeks
💡 Lesson: Operating at 100% planned utilization leads to burnout and fragility. Explicitly scheduling 'slack' (Cooldowns) creates a more resilient and consistently productive engineering culture.
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
Recommended Tools
Go Deeper: Certifications
The most recognized project management credential worldwide — proves you can lead and direct projects.
$555–$1,500 (exam + prep course)
via Coursera
Beginner-friendly 6-month program covering Agile, Scrum, and traditional project management.
$49/month (Coursera subscription)
via Coursera
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 →
Hire 3 senior engineers now, reduce utilization target to 75%, and delay the remaining 5 hires until infrastructure stabilizesClick →
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 →
Hire the remaining 5 engineers, then extract services incrementally — one at a time, alongside product workClick →
Knowledge Check
Challenge coming soon for this concept.
Related Concepts
Turn knowledge into action
Try our free calculators to apply these concepts with your own numbers.
Try the Calculators →