An engineering update to the board should fit on one page, open with the decision you need from them, and carry six or seven items: where capacity went, what shipped against what you promised, reliability, AI spend, people, and risks. Everything past the first three items goes below the line, in an appendix the board can open if it wants. The vendor templates we read assume you already run a metrics platform. This one doesn't, and it's written for a team of 10-40 engineers between seed and Series B. For the rest of the VP's toolkit, see Engineering management guides for CTOs and VPs of Engineering.
What does a board want from an engineering update?
A decision, not a status report. KORE1's advice is to translate engineering work into four units a board can act on: revenue, cost, risk and time. "Test coverage went from 41 to 73 percent" is an engineering fact. "Releases we had to roll back fell from one in six to one in twenty" is a risk fact, and the board can weigh it against a hiring request.
Our rule of thumb: if a line in your update can't be filed under one of those four, it belongs in the appendix or nowhere. A board has less context than you do about your migration, but it can weigh what the migration frees up for the roadmap.
What goes in a one-page engineering update?
Seven items, in this order.
- The decision or ask, in the first line. "Approve two senior hires and a capped AI seat budget" beats a paragraph of context.
- Where capacity went. Split the quarter into new work, improvements to existing systems, and keeping the lights on, as a percentage of engineering time with the change since last report. Swarmia's seven-part board update structure uses the same categories, plus a productivity bucket you can fold into improvements.
- What shipped against what you promised, with dates, and the one thing that slipped. Say why it slipped and what changed.
- Reliability and delivery. Two or three numbers, not eight. If you track DORA, pick the ones the board will recognise from an incident, usually change failure rate and failed deployment recovery time. What each DORA metric measures is covered in its own guide, so there's no redefinition here.
- AI spend and what it bought. The next two sections cover this.
- People. Headcount against plan, attrition, open roles and time-to-fill. Cummulative's guide to what a VPE shares with the board lists hiring against plan, attrition, pipeline conversion, time-to-hire and offer close rate as the scaling-the-team block. At 20 engineers, you can drop most of the funnel numbers and keep headcount, attrition and open roles.
- Top risks and your mitigation. Two or three. Name the owner.
KORE1 says one page and three items, never five. Swarmia lists seven components. They aren't in conflict if you read them as a layout rule: the page leads with the ask and the top three items, and everything else goes below the line. Our advice is to keep the whole body to one page, and treat the appendix as the place for anything a director might ask about but wouldn't miss.
A placeholder layout, to adapt rather than copy:
Ask: <the decision, one sentence>
Capacity this quarter: new <n>% | improvements <n>% | keep-the-lights-on <n>% (change vs last quarter: <+/-n> points)
Shipped vs promised: <item, date> done | <item, date> done | <item> slipped to <date> because <reason>
Reliability: change failure rate <n>% | failed deployment recovery time <n> hours | incidents above severity 2: <n>
AI: spend <amount> | seats <n> | delivery vs baseline <direction>, evidence <measured or survey>
People: headcount <n> of <n> planned | attrition <n> | open roles <n> | median time-to-fill <n> days
Risks: <risk> / <mitigation> / <owner>Every placeholder is yours to fill from your own data. Nothing here is a benchmark.
What should you cut at seed, Series A and Series B?
No page we found answers this. ICONIQ, the growth investor, states the principle: reporting should emphasise different questions at different stages of growth. The stage split itself sits behind a template download, and it's not on the page. What follows is judgment, built from what the vendor templates assume you have.
At seed, the board is asking whether the product ships and whether the founder-CTO can hire. Report what shipped, what slipped, runway-relevant cost, and open roles. Skip DORA benchmarks entirely. You won't have a baseline, and a number with nothing to compare it to invites the wrong conversation.
At Series A, add the capacity split and two reliability numbers, once you have about three months of data to show a direction. Add attrition. This is also when the AI line appears, because someone on the board will ask.
At Series B, finance starts asking for more. Software capitalisation is on Swarmia's list, and it matters if your CFO needs CapEx figures for the accounts. Ask finance before you build it. Flow efficiency and a full DORA panel can come later still.
We think the common failure is borrowing a vendor template built for a larger company. You end up reporting numbers you computed by hand, once, for the slide.
How do you report AI spend without overclaiming?
Report the cost per seat and what changed in delivery against a baseline you took before rollout. If your only evidence is a developer survey, call it sentiment and say so on the slide.
The method for getting to defensible numbers is in a five-step plan for measuring AI coding tools ROI. Its three outputs, delivery and stability against baseline, review load, and cost per seat, are the inputs to this line of the update. Don't restate the plan to the board. Show the three outputs and one sentence on how you measured.
In our view, boards hear the same AI story you do. Jellyfish's 2026 State of Engineering Management report says 75% of its 636 respondents, surveyed in March 2026, see engineering productivity as a strategic concern for the business. That shows leaders are under pressure to show results. It isn't evidence that your tools work.
What do you tell the board when AI didn't shrink the team?
Expect the question: if the engineers have copilots, why isn't the team smaller? Don't answer defensively, and don't promise a headcount reduction you can't deliver.
CTO Craft's survey with Damilah, reported in Engineering 2028: leading human-AI teams responsibly, found 92% of respondents already deploying AI in delivery, 68% expecting productivity gains of 11-50% by 2028, and 51% naming governance as the biggest barrier. The landing page doesn't state the sample size or date, so read these as that report's figures, not an industry measure. What they do show is that 68% of that report's respondents expected gains in a range, not a halving.
CTO Craft's separate piece, no, AI won't be shrinking your engineering team, says of the 11-50% expectation: "This would be very meaningful progress, but a long way from the dominant 10x narrative." It makes a Jevons-paradox argument: when producing software gets cheaper, demand for it grows, so organisations build more rather than staffing less. That's their argument, not a settled fact. They quote Lee Provoost, CTO at Flagstone: "We're not interested in doing the work of 400 people with 200 and reduce heads. We're interested in doing the work of 800 people with 400."
Here's how we'd use this with a board. Frame AI as capacity that expands what the roadmap can hold. Show the work added, not the heads saved: features that were in the "someday" column and are now scheduled, with dates. If you can't point to added work, the honest answer is that the gains haven't reached delivery yet, and you should say that. Pair it with the baseline data from the AI line so the claim is checkable.
How should you present it?
Send the page days ahead as a pre-read. KORE1 recommends two minutes presenting and nine for questions, which only works if people have read it. KORE1 suggests calling the director who will ask the hardest question three or four days before the meeting; let them see the hard number first.
Lead with the bad news. Pillar's guide to founder updates puts it plainly: "Get the bad news out of the way right up front. Take it head on." It's written for whole-company updates, but it holds for engineering. In our view, a board that finds the slipped milestone on its own has a reason to doubt the green ones.
Keep the format identical every quarter. Swarmia's guidance is the same baseline structure each time so directors don't have to reorient themselves. We'd add that it also makes a change in a number visible without explanation.
What this means for your next board meeting
You're deciding what to ask for and how to tie it to numbers the board has already seen. Pick the ask first, whether it's headcount, an AI seat budget or both, and put it in the first line. Then make sure the page contains the evidence for it: capacity split for headcount, baseline-compared delivery for AI spend.
Size the ask as a range, not a point. How a Series A engineering budget splits in Europe covers the cost side, and this article covers reporting against it. As judgment, don't ask for AI seats on the strength of a survey alone. Ask for a capped budget with a review date and show what you'll measure.
If the board's next question is what the team should look like, the answer depends on the mix of seniority. How many juniors and seniors to hire in the AI era is the next read.
FAQ
How long should an engineering update to the board be?
One page, plus an appendix. KORE1 advises one page with three items; Swarmia lists seven components. The two fit together if the page carries the ask and the top three items, and the rest sits below the line for anyone who wants it.
Which engineering metrics should you show the board?
Show the capacity split between new work, improvements and keeping the lights on, two or three DORA figures, and AI spend with its evidence. Add headcount, attrition and open roles. Skip any metric you can't compare against your own baseline.
Should the update include AI productivity numbers?
Only with a baseline. Without one, report spend per seat and label any survey results as sentiment. Measure delivery against a baseline taken before rollout, and report cost per seat.
How do you explain to the board why AI didn't reduce the team?
Frame it as capacity: the same team is covering more of the roadmap. Show the work that was added and the dates it's now scheduled for.
What do you do if the board asks for more headcount justification?
Tie each requested role to a line in the update: a roadmap item that's blocked, a capacity share that keeping-the-lights-on is eating, or attrition you need to backfill. Then show the cost as a range.