To report engineering ROI and capacity allocation to the board, put what shipped and why it mattered at the center of the page, and frame it with how engineering effort split across categories against the target the board agreed. Name the three to five most significant things the team shipped, the company priority each served and what changed because of it. Show the allocation split (features, bugs and quality, maintenance and KTLO, platform) so the board can see what that work displaced. Give cost as context: fully loaded engineering cost, with AI tooling as its own line. End with risks and the decisions you need. Leave velocity charts, PR counts as a measure of output, and individual rankings out of the deck.
As of November 2026. The company in the example is fictional. The accounting and tax notes are dated and linked; check them with your controller.
Engineering is a large share of operating expense, and the board wants to know whether the money is going to the right things and whether it's working. A board can't act on a cycle time. It can act on a missed priority, a quarter eaten by bugs, or a platform bet that ended a run of incidents.
Start with what shipped
The center of the page is a short list: three to five items, a sentence or two each. Each one names the company priority it served and what changed because of it. "Shipped SSO" is a release note. "Shipped SSO, which unblocked the two enterprise deals the Q4 sales plan depends on" is a board update. A rewrite that ended a run of incidents counts too. If something important slipped, say so here, and say where its capacity went.
Picking the items is the hard part. The temptation is to pick by volume: most merged pull requests, biggest diff. That was always a weak signal, and coding agents made it worse. A pull request now takes much less effort to produce, so more of them is not more value, as the output was never the work argues. What the board cares about is significance: how much a change did, not how many changes there were.
Without a tool, the workable method is a fixed rubric. Have each tech lead tag their team's merged changes for the quarter, or a random sample of them, as small, medium or large, with weights of 1, 3 and 8. Tag each one by kind of work too: feature, bug, maintenance or platform. Keep the rubric the same every quarter, or the trend means nothing. Then, for the handful of large changes, write down in one sentence what each did for the business. Those sentences are the draft of your "what shipped" list.
This is where doing it by hand stops scaling. A 50-person team merges thousands of changes a quarter, tagging even a sample costs each lead an afternoon, and it's the first thing dropped in a busy quarter. Maestro does that reading for you: it scores every merged PR for scope, complexity and effect and writes up what each team accomplished.
Frame it with capacity allocation
Allocation explains the shipped list. If the board agreed to 50% on roadmap features and the actual was 42%, the list is shorter than planned, and the table says why. Against an agreed target, it reads as budget versus actual, a format every director knows.
Pick four categories and keep them stable:
| Category | What goes in it |
|---|---|
| New features and roadmap bets | Capability customers or the business asked for, including experiments |
| Bugs and quality | Fixing defects in shipped software, tests for known weak spots |
| Maintenance and KTLO | On-call, incidents, dependency and security upgrades, support escalations |
| Platform | Planned investment that makes future work cheaper: build systems, data infrastructure, a service rewrite |
Derive the split from the work, not from timesheets, which people fill in from memory and round toward whatever looks normal. Start from the engineer-weeks available: headcount times weeks in the quarter, minus leave. Then split each team's weeks across the changes the team finished, weighted by the significance tag from the rubric above. A week in which a team merged one large feature change (8) and two small bug fixes (1 each) counts 8 ÷ 10, or 80%, as feature work. It's an estimate of where effort went, not a time record. Don't weight by lines changed or files touched. Agents inflate both, and a large diff is often a small idea.
Classify by why the work was done, not what it touched: a refactor done to unblock a roadmap item is feature work, and an upgrade forced by a security advisory is KTLO. On-call often leaves no PR, so count the rotation itself as KTLO. Each quarter, pull 20 classified changes at random and ask leads whether the label and size are right. If fewer than about 17 hold up, fix the rules before trusting the trend.
Cost is context
Use finance's fully loaded engineering figure (salaries, benefits, payroll taxes, contractors, other tools) so the board sees one number everywhere in the deck, and use it to put dollars on the allocation table.
Give AI tooling its own line: seats plus usage-based charges for coding agents, taken from your invoices. Next to payroll it's small. Jellyfish's AI Engineering Trends report (October 2026) puts "AI's direct slice of the cost" at "about $18 of the $799 average" cost per PR. It still deserves a line, because usage-based charges can swing month to month and directors keep reading about it.
If you want one unit cost, total engineering cost divided by merged pull requests works as a crude spend trend, and finance can check it against GitHub. Show it over four quarters and label it for what it is: what you paid per unit of shipped change. It isn't a return measure, for the same reason PR counts aren't. Cost per merged PR covers where it misleads.
A short note on capitalization. Finance may want the same allocation data. Under US GAAP, ASC 350-40 governs when internal-use software costs are capitalized. ASU 2025-06, issued in September 2025, "eliminates references to project stages," as RSM summarizes it, and the amendments "are effective for annual periods beginning after December 15, 2027." On the tax side, the new Section 174A "permits taxpayers to immediately deduct R&E expenditures" for domestic research, per Cooley. Written classification rules that separate new functionality from maintenance give your controller a starting point. The judgment stays with them.
Close with risks and asks
List two or three risks, each with what you're doing about it, then the asks: a decision, a hire, a change to next quarter's target. A director who first hears about a problem once it's a crisis stops trusting the engineering section.
Example: Brindle Dispatch, Q3
Brindle Dispatch is a fictional software company serving regional trucking carriers. It has 50 engineers at a fully loaded cost of $240,000 each per year: $60,000 each per quarter, $3,000,000 for the quarter. Q3 had 13 weeks, so 50 × 13 = 650 engineer-weeks, minus 50 for leave, leaves 600. Each engineer-week cost $3,000,000 ÷ 600 = $5,000.
What shipped
- EDI integration with the two largest transportation management systems (large). It was first on the enterprise plan, and two signed carriers had made it a condition of rollout.
- Offline mode in the driver app (large). Rural accounts named connectivity as their top reason for leaving in last year's churn interviews.
- A rewrite of the rate-card logic (platform, large), which ended a run of invoicing defects.
- Slipped to Q4: the carrier analytics dashboard. Its capacity went to those defects.
Allocation
| Category | Target | Engineer-weeks | Actual | Cost |
|---|---|---|---|---|
| New features and roadmap bets | 50% | 252 | 42% | $1,260,000 |
| Bugs and quality | 15% | 126 | 21% | $630,000 |
| Maintenance and KTLO | 20% | 132 | 22% | $660,000 |
| Platform | 15% | 90 | 15% | $450,000 |
| Total | 100% | 600 | 100% | $3,000,000 |
Features came in 48 engineer-weeks under a target of 300. Bugs ran 36 over a target of 90, and KTLO 12 over a target of 120. That's $240,000 of planned feature capacity (48 × $5,000), $180,000 of it spent on bugs (36 × $5,000). The cause was a July billing launch that broke invoicing for carriers on custom rate cards; fixing it took most of August.
Cost. AI coding tools cost $90,000 in Q3, or $600 per engineer per month ($90,000 ÷ 50 ÷ 3). Total engineering cost was $3,090,000, so AI tooling was 2.9% of it, shown beside the previous three quarters.
Risks and asks. AI usage charges grew faster than headcount, so Brindle reviews them monthly by team and re-forecasts after two straight months over plan. The Q4 plan assumes 50% feature capacity, which Brindle hasn't reached in two quarters. The ask: approve two platform hires for Q1, or agree to a 45% feature target for Q4. The VP of Engineering recommends the second.
What to leave out
Individual rankings tell your team to chase the number. Lines of code and PR counts mostly track agent usage now. Story points don't convert across teams. AI adoption rates say nothing about what the tools bought. If the board asks about AI, answer with the cost line and what it bought, using how to measure the ROI of AI coding tools. If you recently rolled out a tool to control that spend, see measuring ROI after deploying an AI coding cost tool; what software measures AI coding ROI compares the options.
Where Maestro fits
Maestro builds the center of this page. It reads every ticket, review and line of code, scores each merged PR 0 to 5 for scope, complexity and effect, and sorts the work into categories such as features, bugs and maintenance, so your split by kind of work comes from the changes themselves, not timesheets. It writes up what each team accomplished and why it mattered, and every report links to the work behind it. Its scores describe how significant the work was, not its business value. Book a walkthrough.
For the AI line, VibeCheck estimates what each Claude Code, Codex and Cursor session cost and splits spend by team and model; use your invoices for the total. Get started for free.