Capacity Allocation
Definition
Breakdown of engineering capacity across new features, maintenance, and tech debt — typically reported as a three-way split summing to 100%. The execution-level view of where engineering hours are actually going (vs. `innovation_capacity_pct` which is a single percentage for new-capabilities work, and vs. `offensive_roadmap_pct` which is a roadmap-classification percentage). Common pitfall: capacity allocation reported in plan rather than actuals. The plan can say 60% new features but the actuals can be 30% new features and 50% support work — the gap is the operating signal. Boards should require both planned and actual splits, at least quarterly.
Why it matters
Names where engineering hours actually go. The plan-versus-actual gap is one of the highest-signal operational metrics for the board — a persistent 20+ point gap between planned and actual new-feature allocation is the loudest possible flag that the company is under-investing in platform health (the missing hours are going to firefighting).
How it's calculated
Three-way breakdown: new_features_pct + maintenance_pct + tech_debt_pct = 100%. Measured in the same unit as capacity (eng-weeks, story points, or sprint capacity). Report planned vs actual split — the gap is the operational signal. How to interpret it
Industry folk-wisdom, not citation-grade: a healthy steady-state split at growth-stage SaaS is roughly 50–70% new features, 15–30% maintenance, 10–20% tech debt. Companies in platform-investment cycles will skew toward maintenance and tech debt. Pair with `innovation_capacity_pct` and `delivery_predictability` — capacity allocation tells you where time goes, predictability tells you whether commitments hold, innovation capacity tells you the available headroom for offense.
Source
imboard Editorial
Stage relevance
Typically owned by
Related KPIs
Percentage of R&D capacity (typically measured in engineering-weeks or story points over a quarter) allocated to net-new capabilities, as opposed to maintenance, bug fixes, internal tooling, or customer-support engineering. The "available bandwidth for offense" view. Common pitfall: confusing innovation capacity (input — how much team-time is available for new work) with `offensive_roadmap_pct` (output — what proportion of the planned roadmap is growth-oriented). A team can have 60% innovation capacity allocated entirely to defensive work if the roadmap demands it. Boards should look at both together.
Percentage of the planned roadmap (typically next 1–2 quarters) allocated to offensive bets — net-new capabilities, market expansion, differentiation moats, new monetization. The "what proportion of the plan is about winning" view. Common pitfall: counting "improvements to existing features" as offensive when the change is really table-stakes parity work. Boards should expect a McKinsey-style horizon framing (Horizon 1 = core, Horizon 2 = adjacent, Horizon 3 = transformational) or an equivalent classification, and apply it consistently. Per the original McKinsey "Three Horizons" framing (Baghai/Coley/White, "The Alchemy of Growth", 1999), a healthy portfolio funds all three — over-indexing on any one is a strategic risk.
Percentage of the planned roadmap allocated to defensive work — platform reliability, security/compliance, scalability rearchitecture, table-stakes parity with competitors, customer-retention features. The complement of `offensive_roadmap_pct`. Common pitfall: defensive work is chronically under-funded (less visible to customers, harder to demo) until a quality-churn or scalability event forces a reactive surge. Boards should treat sustained zero or near-zero defensive allocation in a maturing product as a leading indicator of future quality issues — per the standard product-management argument (Marty Cagan and similar product-leadership writing), a healthy roadmap pays both growth and platform-health rent.
Percentage of committed deliverables shipped on or before the originally-promised date within a measurement window (typically a quarter). Surfaces whether the engineering organization can be trusted to hit commitments the company makes externally — to customers in contracts, to the board in quarterly plans, to GTM teams sequencing launches. Common pitfall: gaming. Teams over-deliver by under-promising (predictability climbs while velocity drops) or move the goalposts (re-baseline mid-quarter so "on-time" stays high). Boards should ask for "predictability against original commitment", not "against current plan", and pair with throughput trends.
Headcount of engineers (software, infrastructure, security, data, ML) in the R&D organization, typically including full-time employees plus contractors at a defined FTE-equivalence factor. The "capacity input" side of all R&D ratios. Common pitfall: definition drift. Some companies include only software engineers, others include product managers and designers, others include all of R&D plus QA, plus support engineers. Boards should anchor the definition once and hold it stable — otherwise quarter-over-quarter comparisons are noise. Pair with `rd_monthly_spend` to derive fully-loaded cost-per-engineer.
Track these KPIs with your board
I'mBoard helps startup CEOs report the metrics that matter, track resolutions, and run better board meetings.