How to present ADLC metrics to a board

An engineering leader I know opened a board update with a slide showing deployment frequency up several times over the previous year. It was a real number, honestly produced, and it represented genuine work by a lot of people. The first question from the table was: “Is that good?”

He had an answer. It was a good answer, about batch size and risk and the research behind the four keys. It took ninety seconds. By the end of it the room had moved on, and the rest of the deck landed in the space that opens up after a leader has visibly had to defend a slide.

The problem was not the metric and it was not the answer. The problem was that he had presented an engineering metric to an audience that does not hold engineering metrics, and then had to translate live, under mild pressure, in front of people whose attention is the scarcest thing in the building.

This is the last piece in this series, and it is the one about the room rather than the repository. Everything earlier assumed a technical reader. Boards are not that, and the translation is not a matter of simplifying. It is a matter of answering different questions.

What a board is actually asking

Directors are not curious about your life cycle. They are discharging a duty, and the duty has a shape. Stripped of ceremony, almost every board question about engineering is one of three questions wearing a costume.

Is the money doing what we said it would do? You asked for headcount, or tooling budget, or an AI spend line. Something was supposed to happen. Did it.

What is our exposure? Not “are there bugs.” Exposure means the things that would become the board’s problem: a customer-visible failure, a regulatory finding, a security incident, a dependency on one person, a number in a report that turns out to be wrong.

How quickly would we know if this stopped working? This is the question boards ask least directly and value most. A management team that can say precisely how a problem would surface, and how long it would take, is a management team that gets given more room.

Notice that none of these is answered by a throughput metric. Deployment frequency is an input to all three and an answer to none.

The translation job is to take the left column and use it as evidence for claims in the right column. Never present the left column as the claim itself.

Three slides, in this order

If you get one page, use one page. If you get three, this is the order that survives contact.

One: output against the thing you promised. Not raw activity. Output tied to whatever the investment was justified on. If the case was “we can carry more roadmap with the same team,” then the slide is roadmap items delivered, and the throughput metrics live underneath as supporting evidence for anyone who wants them. If the case was “we can hold headcount flat through growth,” the slide is headcount and delivered scope on the same axis.

Two: control. This is the slide most teams skip and it is the one that buys credibility. It says: here is what is automated, here is what still requires a human, here is the rate at which the automated part gets it wrong, here is how we know, here is how we undo it. A board that hears a specific error rate and a specific reversal mechanism relaxes. A board that hears “it has been fine so far” does not.

Three: cost per unit of output. Agentic development moves a chunk of engineering cost from salaries, which are predictable and annual, to inference, which is variable and monthly. Boards notice new variable lines. Get in front of it by presenting spend next to what it produced rather than as its own line item in the finance pack, where it will show up as an unexplained increase and generate a question you answer three weeks later by email.

Anything after those three is for the appendix. The appendix is where DORA belongs, along with your drift measurements, your definition-of-done adherence, and every chart you are personally proud of.

State the basis on the face of the number

The single most damaging thing that can happen in a board meeting is not a bad number. It is a number that turns out, on questioning, to mean something other than what the slide implied. That event costs more than the underlying problem ever would, because it converts every future number you present into something that has to be checked.

The defence is boring and total: every metric carries its basis. What it counts, over what window, from what source, and what it excludes.

Delivered scope, last quarter
47 roadmap items closed
basis: items linked to a merged pull request
source: repository history, not the tracker
excludes: 6 items closed as “won’t do”
window: 1 Apr to 30 Jun, merge date
Not shown: 12 items with no linked change
these may be delivered; we cannot prove it

The instinct is to hide the twelve unprovable items because they make the chart look weaker. Do the opposite. Naming them does three things at once: it inoculates you against the discovery, it demonstrates that you know the limits of your own instrumentation, and it quietly makes the case for the work that would close the gap.

If the basis of a metric will not fit in four lines under the number, the metric is too complicated for this room.

Present the error rate before anyone asks for it

Once automation is touching your record of work, you have introduced a new category of risk that a board has no prior model for. Software is updating the artefacts that your reporting is built on. The obvious question, and it is a good one, is what happens when the software is wrong.

You want to have answered this before it is asked, and you want the answer to have numbers in it that came from your own environment rather than from a vendor.

Three facts, plainly:

• How often the automated layer acts, and at what confidence.
• How often it was wrong, measured against a sample somebody actually checked.
• What happened to the ones it got wrong, specifically.

The third is the one that lands. “Every automated change captures the value it replaced and can be reverted individually” is a sentence a board understands immediately, because it is the same shape as controls they already know from finance. “We would look into it” is not a control, and a director who has sat on an audit committee will hear the difference instantly.

Put spend next to output or someone else will put it alone

Inference cost has a habit of arriving in the finance pack as a line that grew, with no denominator attached. Once that happens the conversation is about reducing a cost rather than about the return on it, and you will spend two meetings recovering ground you never needed to lose.

The fix is to own the number and always show it with what it bought. Spend per delivered item. Spend per team. Spend by model, if you route across models, because the moment you can show that the expensive model is used for the twenty percent of work that warrants it, you have demonstrated management of the line rather than exposure to it.

A word of caution. Do not present cost per line of code, cost per pull request, or anything else that rewards volume. You will get exactly what you measure, and what you will get is more, smaller, worse changes, generated to make a ratio look good. Denominators should be things you actually want more of.

When a number gets worse

It will. Change failure rate will spike after a threshold change. Lead time will look strange for a quarter after you start measuring it differently. Some quarter your delivered scope will drop because you spent six weeks on a migration that produced nothing visible.

The rule that has never failed me: bring the bad number yourself, in the same meeting you noticed it, with a cause and a decision attached.

A metric that regresses and is presented by you, with an explanation and an action, is evidence that your instrumentation works. The same metric discovered by a director two quarters later is evidence that it does not, and no amount of subsequent good news fully repairs that.

There is a variant of this worth naming, because agentic teams hit it specifically. Sometimes a metric gets worse because you started measuring honestly. A board sees change failure rate double and hears “quality collapsed.” What actually happened is that you began counting reverts you previously never attributed. You must say this in the same breath as the number, and you must have said in advance that it was coming, or it sounds like an excuse constructed after the fact.

Say what would change your mind

The strongest single sentence you can put in front of a board is a pre-commitment. “If drift between the record and the repository is not below this level by the end of Q3, we stop the rollout and go back to the manual process.”

This does three things. It converts an open-ended programme into something with a decision point, which is the shape governance likes. It makes you the person who set the bar rather than the person being measured against someone else’s. And when you hit the bar, the credit is unambiguous, because you defined it before you knew the answer.

The failure mode to avoid is a pre-commitment nobody could fail. If your stated bar is one you would clear by doing nothing, the board will not say so, but it will note it.

Where this breaks down

I have been writing as if boards are uniform and rational, and they are neither.

The most common failure of everything above is that some boards do not want this level of detail and will read it as an engineering leader who cannot summarise. If your board’s culture is three bullets and a forecast, presenting a control slide with a disagreement rate on it will not read as rigour. It will read as noise, and you will get less time next quarter, not more. Read the room you have rather than the room this article assumes. The underlying discipline still matters, but it may belong in the operating review rather than the board pack.

The second limit is that metrics chosen for a board have a way of becoming the metrics the organisation optimises for, whatever you intended. Once “delivered items linked to a merged change” is on a board slide, someone three levels down will start linking things. This is not hypothetical, it is the oldest dynamic in management, and putting a number in front of directors is the single most effective way to make it the number people game. Choose metrics you would be comfortable having people maximise.

Third, and most awkward: almost everything above assumes your instrumentation is honest and complete enough to base claims on. If a meaningful part of your work happens outside source control, your basis lines will be full of exclusions, and a slide that is mostly caveats is worse than no slide. In that situation the right board message is not a metrics page at all. It is a short statement that you are building the measurement capability, with a date.

And finally, none of this makes a bad quarter good. Presentation discipline buys you the benefit of the doubt exactly once, and only if the underlying story is real. If the investment is not producing, the correct move is to say so early and propose the change, not to find the framing that makes it survive one more meeting.

The takeaway

Boards ask three questions: is the money working, what is our exposure, and how fast would we know. Engineering metrics are evidence for those questions, never answers to them.

So: one slide on output against the promise, one on control, one on cost against output. Every number carries its basis, including what it excludes. Bring the error rate before it is requested and the bad number before it is discovered. Pre-commit to a bar you could actually miss.

That closes this series on measurement. The place it points next is the failure mode that the control slide exists to prevent: what happens when someone external asks you to prove, for a specific change made months ago, who authorised it and on what evidence, and the honest answer is that you would have to reconstruct it.