Annual Planning & Capacity Aligner
Align your annual Objectives and Key Results (OKRs) with realistic engineering team capacity.
Formula
Effective Capacity = (Engineers × Weeks) × (1 - (Maintenance% + Meetings% + PTO%))
We calculate Total Person-Weeks (Engineers × 13 weeks), then deduct the 'Tax' of doing business: Maintenance (KTLO), Meetings/Overhead, and PTO/Holidays. The result is the actual time available for strategic OKR work.
Worked Examples
Example 1: Small Team
Problem:5 Engineers, 20% KTLO, 10% Meetings, 10% PTO
Solution:5 × 13 = 65 weeks. Tax = 40%. Effective = 65 × 0.6 = 39 weeks.
Result:39 Weeks Available
Example 2: Large Org
Problem:50 Engineers, 30% KTLO, 15% Meetings, 10% PTO
Solution:50 × 13 = 650 weeks. Tax = 55%. Effective = 650 × 0.45 = 292.5 weeks.
Result:292.5 Weeks Available
Frequently Asked Questions
What is KTLO?
KTLO stands for 'Keeping The Lights On'. It refers to maintenance, bug fixes, on-call duties, and tech debt reduction required just to maintain current operations.
Why plan quarterly (13 weeks)?
Most tech companies work in quarters. 52 weeks / 4 = 13 weeks. It's a standard cadence for OKR cycles.
Does this apply to non-engineering teams?
Yes! Marketing, HR, and Sales teams also have 'maintenance' (admin) and 'projects' (campaigns). The percentages might differ, but the logic holds.
How do I account for new hires?
New hires have negative capacity initially (onboarding). Count them as 0 or 0.5 FTE for their first quarter.
Why is capacity always lower than expected?
We tend to be optimistic. We forget about holidays, company offsites, mandatory training, and context switching. Real productive capacity is rarely above 60-70%.
Should I track actuals?
Yes. At the end of the quarter, review how many 'effective weeks' were actually spent on OKRs versus KTLO. Adjust your percentages for the next quarter.
How do dependencies affect this?
Dependencies reduce effective capacity because of 'wait time'. If Team A needs Team B, and Team B is busy, Team A sits idle or switches context.
Background & Theory
The Capacity Math
Annual and quarterly planning is often a negotiation between "What we want" (Strategy) and "What we can do" (Capacity). This calculator provides the "What we can do" number.
The "Tax" Breakdown
- Maintenance (KTLO): Keeping systems running. 15-30% is healthy. <10% usually means you are accumulating debt. >50% means your platform is unstable.
- Meetings/Overhead: Scrum ceremonies, 1:1s, All-hands. 10-20% is standard.
- PTO/Buffer: People get sick, take vacation, or get stuck on hard problems. 10-15% buffer is essential.
Interpretation Guide
- Effective Capacity: This is your "Budget" to spend on OKRs. If you have 40 effective weeks, and your projects cost 50, you must cut scope.
- Utilization: Aim for ~70-80% planned utilization of effective capacity. Leave room for "Unknown Unknowns."
Practical Tips
- Big Rocks First: Slot in the large, non-negotiable projects (e.g., Compliance) first.
- Theme Allocations: Allocate % of capacity to themes (e.g., 50% Innovation, 30% Scale, 20% Debt) rather than specific tickets.
- Visualize: Show stakeholders the "Pie Chart" of capacity. If they want more features, ask "Which slice of the pie should shrink? Maintenance? (Risk) or Buffer? (Burnout)."
History
Management by Objectives (MBO)
In 1954, Peter Drucker introduced **MBO** in "The Practice of Management." It aligned goals across the organization but often failed due to rigid annual cycles and lack of measurement.
Intel and OKRs
Andy Grove at Intel evolved MBOs into **OKRs (Objectives and Key Results)** in the 1970s. The key difference was the "Key Result"—a measurable, quantitative outcome. OKRs were aggressive, quarterly, and decoupled from compensation to encourage risk-taking.
Google and the Tech Boom
John Doerr brought OKRs to Google in 1999. Google's success popularized the framework. However, a common failure mode emerged: **The Capacity Gap**. Leadership would set ambitious OKRs ("Moonshots"), but Product would road map features without checking if Engineering had the hours to build them.
Modern Capacity Planning
Today, agile organizations treat "Capacity Planning" as the prerequisite to OKR setting. You cannot set a Key Result of "Launch 5 Features" if you only have capacity for 2. This alignment—matching ambition to arithmetic—is the hallmark of mature product organizations.
Common Misconceptions
- Myth: We can work 100% on features. Reality: KTLO and meetings eat 30-50% of time. Ignoring this leads to failure.
- Myth: Hiring solves capacity instantly. Reality: Brooks' Law: Adding manpower to a late software project makes it later (due to onboarding/coordination).