Reporting Engineering to the Board Without Vanity Metrics

“When a measure becomes a target, it ceases to be a good measure.”
— Marilyn Strathern, restating Goodhart’s law, “Improving Ratings” (1997)

Report five things to the board: whether engineering delivers what the company promised, whether the product is reliable enough for the customers you are selling to, what engineering costs relative to the business, which risks directors don't yet know about, and whether the team can deliver the plan they just approved. Drop everything else from the deck. The test for any number is what the CEO or the board could decide differently because of it.

That needs saying because the engineering slide in most board decks is a velocity chart, a count of story points or pull requests, and a headcount figure. Directors look at it for about ten seconds and move on to revenue. Nobody can act on it.

Why the usual metrics survive

The standard defence of activity metrics is reasonable on its face. Boards want evidence that a large and expensive function is working, and activity is cheap to count and visibly moves. A chart that goes up and to the right reassures. Some leaders also argue that any consistent metric is better than none, because trends show change even when the absolute numbers mean little.

That argument holds inside an engineering team, where the people reading the chart know what produced it. It breaks in a boardroom for two reasons. The first is that activity measures are local to a team's habits. A story point at one company is not a story point at another, and a team can double its pull request count by splitting work more finely without shipping anything new. The second is that once a number is shown to the board, people start managing to it. Picture a Series B company whose board deck has tracked velocity for six quarters. Velocity drops 20% in one quarter, and the meeting spends fifteen minutes on estimation practice. The real answer, which nobody reached, was that the team spent the month closing a security finding that a large customer had made a condition of renewal. The metric pulled the meeting away from the decision that mattered.

These are measures of motion, and activity theater is no more useful in a boardroom than on a team. The same caution about numbers that mislead applies to engineering data as to any other: the question is what the number can and cannot support.

What a board can act on

A board can fund more hiring or slow it, move a launch date it has promised to customers or investors, accept or reject a risk, or ask management for a cost plan. Five measures map onto those decisions. You won't need all five at every stage, but between them they answer the questions directors are actually asking.

Delivery predictability

The question behind it: will the things we told customers, sales and investors would ship this quarter actually ship? Report the handful of committed bets for the period, whether each landed, and for any that slipped, why and what was traded to protect the rest. Measure at the level of outcomes a director recognizes ("enterprise SSO is live for the three pilot customers"), never at the level of tickets.

The useful number is the hit rate over several quarters. A team that lands four of five commitments every quarter is easier to plan a company around than one that lands everything once and nothing the next. When the hit rate drops, say so first, before anyone has to find it.

Reliability

The question: is the product dependable enough for the customers we now sell to? Show availability against the target you have committed to, the incidents customers felt, and how long they lasted. A board doesn't need your alert volume. It needs to know whether reliability is a sales asset or a churn risk, and what the last serious incident taught you, which is where a blameless postmortem practice earns its keep.

This is where the DORA software delivery metrics belong. Of the five, change fail rate and failed deployment recovery time translate most directly into customer risk, and a four-quarter trend of each says more than any single month. Deployment frequency and change lead time are worth a line too, framed as how quickly the company can respond to a customer request or a security problem. Keep the full set for engineering's own reviews. The board needs the trend and what you are doing about it, not the method.

Cost

The question: is engineering spend growing in line with the business? Show total engineering cost (people, cloud, tools and now model inference) against revenue, and one unit cost that matches how you sell: cloud cost per customer, per thousand transactions or per active seat. A rising unit cost is often the earliest signal of an architecture that won't scale economically, and it reaches gross margin a year or two later. Directors would rather hear it from you while the fix is still cheap.

Risk

The question: what could hurt the company that the board doesn't already know about? Keep a short register, three to five items, each with an owner, a trend and the next action. Typical entries are a security gap, a key-person dependency on a system only one engineer understands, a vendor you can't easily leave (the exit cost that build-or-buy decisions tend to ignore), a compliance deadline a large deal depends on, or debt that blocks a roadmap item.

Treat debt as a financed decision, as the guide to living with tech debt argues. The register is where that financing becomes visible to the people who approve the budget. Frame each item the way directors already think about risk elsewhere: what is the downside, how likely is it, and what would it cost to reduce? A cheap action against a severe downside is the kind of asymmetric bet a board will approve in one meeting.

Capacity against the roadmap

The question: can the team we have deliver the plan we just approved? Show how engineering time actually split last quarter between new product work, keeping the lights on, debt and unplanned work, and set that against what the roadmap assumes. If the plan needs 70% of capacity on new features and the team has spent 45% there for three quarters, that gap is the most important engineering fact in the room. It leads directly to a hiring, scope or timing decision, which is exactly what a board is for.

This view also replaces raw headcount, which answers "how big is engineering?" when the real question is "is engineering the right size for the plan?" Built from actual time allocation rather than estimates, it turns a request for more engineers into the kind of data-driven case for growing the team a finance-minded director can test.

What to stop showing

Lines of code, commit counts, pull request counts, story points and raw velocity should come out of the deck. Each one is easy to inflate and invites the wrong question.

Add a newer one to the list: the share of code written by AI agents. It says nothing about whether the company ships faster, more reliably or more cheaply, and there is good reason to distrust intuition on the subject. In a randomized controlled trial by METR, experienced open-source developers expected AI tools to make them 24% faster, and still believed afterwards that the tools had saved them about 20%. Measured completion time went up by 19%. One study of sixteen developers doesn't settle the question, and the tools have moved since. It does show that users are poor judges of the tools' effect. If agents are helping, it will show up in predictability, lead time and cost. If you want to report the investment, report what it cost and which of the five measures it moved.

How it changes by stage

Seed. The board is a few investors who want to know whether the product is finding its market. Engineering reporting is a paragraph, not a dashboard: what shipped, what you learned from customers, burn, and the one risk that would change the plan. Instrumenting DORA metrics for a team of four is effort better spent on the product. Do start writing down what you committed to each quarter, so the hit rate exists when it matters.

Series A to B. Sales now makes commitments on engineering's behalf, so predictability and reliability start to affect revenue. This is the stage to introduce all five measures on a single page, with definitions held steady quarter to quarter so the trends mean something. Capacity against roadmap does the most good here, because hiring plans are the largest lever the board controls and the most expensive one to get wrong. Agree the format with your CEO before the first meeting, so engineering reads as part of the company's story, in the spirit of shared product and engineering KPIs, and not as a separate report bolted on at the end.

Later stage and pre-IPO. An audit committee appears, and security, compliance and cost efficiency get their own agenda time. The risk register becomes formal, reliability ties to contractual SLAs, and unit costs feed gross margin discussions. The DORA trends can move to an appendix, still available when a director asks. A page that has been kept honestly for several years also becomes evidence in its own right: it is much of what an acquirer or late-stage investor will ask for in technical due diligence, and a consistent history is far more persuasive than a dashboard assembled for the data room.

What to ask for, and what to resist

The opposite failure deserves a mention. Some boards, burned by vague engineering updates, overcorrect and ask for everything: per-team dashboards, individual productivity data, monthly DORA breakdowns. Resist that politely. A board that receives thirty engineering metrics will pick the two that look worst and spend the meeting on them, and individual productivity data in a board pack does lasting damage to trust inside the team. Offer the five measures, their definitions, and the underlying data on request. That satisfies a skeptical director without turning the board into a second management layer.

From the board, ask for one thing in return: a decision whenever the page shows a gap. If capacity doesn't match the plan, the board should leave having chosen between more people, less scope or a later date. If it leaves having merely noted the gap, the report has done half its job.

What good and bad look like

A good engineering update is one page, opens with what changed since last time (bad news first), and uses the same measures every quarter. Each number comes with the decision it supports, or a plain statement that no decision is needed. Directors leave knowing whether the plan is on track and what you need from them.

A bad one is a dashboard screenshot with a dozen activity charts, metrics redefined each quarter, and problems discovered by a director reading page eleven. To the board it reads as a function that is either hiding something or doesn't know what matters.

Before the next board meeting, take the current engineering slide and write next to each number the decision it informs. Then ask your CEO the harder question: which decision is the board going to face in the next two quarters that the current slide gives them no way to see coming?