What the board is asking underneath
The question sounds like curiosity. It usually carries one of three concerns, and naming which one you are answering helps.
The first is cost: can engineering absorb more work, or grow more slowly? The second is position: are competitors moving faster, and are we behind? The third is exposure: has this created security, data or legal risk the board should know about? A listed company's board, a private-equity owner and a start-up's investors weight these differently, and you can ask the chair which matters most before the meeting rather than guessing in it.
Whichever it is, the board is also testing you. A leader who reports a confident number that later dissolves has damaged every future report. Board reporting on a new technology is where calibration is most visible.
Board reporting in three strengths of evidence
| Strength | What counts | How you present it |
|---|
| Measured | Change against a baseline captured before rollout, ideally compared with teams not yet switched on | Figures with the comparison and the period stated |
| Observed | Specific work that now happens and did not before, such as a deferred test backfill or migration finished | Named artefacts the board could check, with no number attached |
| Believed | Your judgement about direction, such as onboarding feeling faster | Stated once, labelled as belief, with how you would test it |
The measured row depends on preparation. If the rollout was staggered, as described in rolling out AI coding assistants to two hundred engineers, you can compare teams over the same weeks. If everyone got access at once, you only have before and after. Say so plainly.
The observed row is often the most persuasive, because it is AI impact you can attribute directly. A legacy module that nobody would touch now has characterisation tests and is being changed. A dependency upgrade deferred for a year was done in a sprint. Those are facts, not estimates.
A one-page board note
A worked shape, with bracketed values you fill from your own data. Nothing here is a benchmark.
AI impact in engineering: position at [quarter]
1. Spend
[n] seats at [cost] a year; [n] engineer-weeks on rollout and training.
2. Measured (teams switched on vs teams still waiting, [period])
Median cycle time: [moved / did not move].
Change failure rate: [held / rose].
Review wait: [rose]. Review is now our constraint; we are acting on it.
3. Observed, not measured
Test backfill on [legacy module], deferred for [n] quarters, is done.
[Migration] finished by [team]; previously estimated at [n] months.
4. Not claimed
A productivity percentage or headcount equivalent. We have no
counterfactual, and team, product and reorganisation changes overlap.
5. Risk
[n] credential exposures via prompts, all rotated; [n] licence findings;
[n] policy breaches, with actions.
6. Next
By [date]: two more quarters of comparison data.
Decision we will bring: renew, expand or reduce, with criteria.
Section 4 does real work. Telling the board what you are not claiming, and why, makes sections 2 and 3 more credible. Section 5 matters for the same reason: a board that hears only good news discounts the next report.
Hours saved times salary is not a saving
The adequate answer avoids a percentage. The strong answer also spots the most common error in board reporting on this topic: survey respondents report time saved, someone multiplies by a loaded salary, and the slide shows a cash figure. That figure is wrong in three ways. Perceived time saved and elapsed time often diverge, because people estimate their own effort poorly. Saved minutes scattered across a week do not turn into shipped work unless authoring was the constraint. And no cash leaves the budget unless you cut spend or hire less, which is a separate decision with its own risks.
If the board wants the cost effect, offer the honest version: the decision a saving would require, and the evidence you would need before making it. The AI in the delivery lifecycle guide sets out why percentage productivity claims collapse under follow-up questions. At board level the cost of collapse is higher, because the figure ends up in a plan.
What you refuse to claim
Some claims you decline even if asked directly:
- A productivity percentage for engineering as a whole.
- A number of "engineers' worth" of capacity gained.
- The share of code written by AI, presented as an achievement rather than a usage fact.
- A vendor's published figure presented as your own result.
- Summed survey hours, in hours or in money.
Declining works only if you offer something in its place. "I cannot give you a percentage I would defend. Here is what moved against our baseline, here is what we have done that we could not do before, and by [date] I will have enough comparison data to recommend renewing, expanding or cutting back." That sentence is not evasive. It gives the board a date, a method and a decision.
Being honest about uncertainty without sounding behind
Some board members will hear caution as falling behind. Answer the position concern directly: the organisation is using the tools at scale, under a policy, and measuring them carefully enough to make the next decision on evidence. Uncertainty about the size of the effect is not doubt about adoption. Saying "we would rather lead on evidence than on claims" reframes caution as an advantage, and it holds up when a sceptical director asks the second question.
Bring AI impact evidence in labelled strengths, put spend and risk beside it, and replace the percentage you will not give with a date and a decision.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).