I'mBoard API Docs

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. — Product KPI, I'mBoard-authored (editorial tier).

I'mBoard-authored (editorial tier)

No public third-party standard anchors this KPI yet, so I'mBoard authors and maintains the definition — transparently labeled as editorial tier. See the ontology methodology for the published vs editorial tier system and the back-attribution workstream.

Rogue ID: product.total_engineers Type: Number Domain: Product

Definition

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.

Formula

Count of engineering headcount (FTE + contractor FTE-equivalence). Define inclusion explicitly: SWE-only vs SWE+PM+Design vs all-of-R&D-including-QA. Hold the definition stable across quarters; surface the definition in a footnote.

Why it matters

Capacity denominator for every R&D ratio — rd_efficiency, ARR-per-engineer, cost-per-engineer, throughput-per-engineer. The board reads this to gauge whether team growth is keeping pace with revenue and product-surface-area growth.

How to interpret

No single benchmark; the right number depends on product complexity, business model, and platform vs. point-solution architecture. The SaaS Capital Annual Survey reports revenue-per-employee for its private SaaS panel (see revenue-per-employee section of the latest edition) — pair total_engineers with company-wide headcount and ARR to derive both engineer-density (engineers ÷ total headcount) and ARR-per-engineer. Industry folk-wisdom, not citation-grade: engineer density of 25–40% is typical at product-led growth-stage SaaS; lower at sales-led, higher at infrastructure / platform companies.

Calculation policy

How an AI agent should compute this KPI from messy company data. Free-text rules consumed at reasoning time — not a deterministic DSL. The most common ways to get this wrong are listed under Common miscomputations.

Inclusion rules

Count of engineering headcount (software, infrastructure, security, data, ML) in the R&D org AS OF the period-end snapshot date — a point-in-time read.
Include contractors at a defined FTE-equivalence factor when the board definition includes them; state the factor explicitly.
Pin the inclusion boundary once (SWE-only vs SWE + PM + Design vs all-of-R&D-including-QA) and hold it stable across quarters; surface the definition in a footnote.

Exclusion rules

Non-engineering R&D staff (PMs, designers, QA) when the adopted boundary is SWE-only — exclude per the chosen definition, consistently.
Open (unfilled) engineering requisitions — those are product.* hiring plan / hr.open_positions, not current capacity.
Accepted-but-not-started offers — they join the count on their actual start date.
Engineers whose last day fell on or before the snapshot date.

Required inputs

Engineering roster as of the snapshot date with employment type (FTE vs contractor) and FTE fraction per person.
The board-adopted inclusion boundary and the contractor FTE-equivalence factor.
Department / function attribution if the board reads engineer density by team.

Data-source priority

HRIS active-employee report at period close, filtered to the R&D org.
Engineering-leadership org chart as a cross-check on the inclusion boundary.
Payroll / contractor ledger to confirm contractor FTE-equivalents are counted consistently.

Edge cases

Part-time / job-share engineers: convert to FTE fraction — two 0.5 FTEs are 1.0, not 2.0.
A definition change (e.g. starting to include QA): re-baseline the whole series rather than creating a phantom step.
Contractor-to-employee conversion mid-period: count the person once, on the basis in effect at the snapshot date.

Validation checks

Should move in step with the R&D share of hr.total_headcount; an engineer count exceeding total R&D headcount means contractors or a wider boundary crept in.
Pair with product.rd_monthly_spend to derive fully-loaded cost-per-engineer — an out-of-band cost-per-engineer flags a counting or spend-classification error.
Engineer density (engineers ÷ total company headcount) far outside ~25–40% for a product-led SaaS is a context flag, not necessarily an error.

Common miscomputations

Definition drift quarter-over-quarter (SWE-only one period, all-of-R&D the next) — turns the comparison into noise.
Counting contractors as whole heads instead of FTE-equivalents — overstates capacity.
Counting open reqs or accepted-but-not-started offers as current engineers.

product.rd_monthly_spend
product.rd_efficiency
product.capacity_allocation_pct
product.innovation_capacity_pct
hr.arr_per_fte

Source

I'mBoard editorial — authored and maintained by I'mBoard, first published 2026-04-01. No third-party standard is cited for this KPI; when one emerges, the definition is back-attributed and promoted to the published tier (a minor version bump). Read the ontology methodology for the published vs editorial tier system, attribution rules, and dispute process.