Total Engineers

Total monthly cash outflow on research and development — fully-loaded engineering, product, and design payroll plus tooling, infrastructure dedicated to product development, contractors, and direct R&D vendor spend. The "input" side of R&D efficiency. Common pitfall: companies report base-payroll R&D and exclude the loaded cost (benefits, stock comp at cash-cost basis, allocated rent, dev tooling), under-reporting true R&D burn by 25–40%. Boards should always ask whether the number is base-payroll, fully-loaded, or GAAP R&D expense — they tell different stories. The KBCM/Sapphire SaaS Survey reports R&D as a percentage of revenue for its company panel — use that as the benchmarking lens.

Ratio of net-new ARR generated in a period to R&D spend in the same period — answers "how much revenue does each R&D dollar produce?" Distinct from sales-efficiency metrics (Magic Number, CAC payback) which measure sales/marketing productivity. Common pitfall: R&D-driven ARR (new capabilities, expansion features) shows up on a 2–4 quarter lag after the spend — single-period ratios mis-state the relationship. Boards should look at trailing-twelve-month R&D efficiency, not month-over-month, and pair with `innovation_capacity_pct` to understand whether the spend is on growth bets or maintenance.

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.

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.

Annual Recurring Revenue divided by total FTE-equivalent workforce — the canonical SaaS workforce-productivity ratio anchored to the SaaS Capital Annual Survey methodology (revenue per employee benchmarks). A high-signal denominator for "are we over- or under-staffed for our revenue scale?" Common pitfall: choosing different ARR conventions (ending vs average, GAAP-reconciled vs raw) without locking in a board-level standard. Best practice is to pair this with `sales.arr` so the numerator is unambiguous and to disclose whether contractors are included in the FTE denominator.