From ‘Trust Us’ to ‘Look at This’: Building Engineering Dashboards That Boards Actually Understand

ℹ️ Rewritten 18 September 2026

I first published this post on 21 November 2025, and I have since rewritten it. It now uses the DevOps Research and Assessment (DORA) programme’s current metric names, and hands the explanation of those metrics to a companion post. The client examples that remain carry only the figures I can stand behind.

“How do I show that to the board?”

I was asked some version of that question again a few days ago, and it arrives more often than any other question I get from tech leads and engineering managers. Their teams are shipping. Sprint reviews go well. They can feel the work getting better month on month. What they cannot do is put anything in front of a board that makes that obvious to people who do not write software.

Most of them already have a dashboard, which is the part of this problem that gets missed. The board has charts. What nobody in the room can say with any confidence is whether the numbers on those charts are good. The working assumption is that a line heading up and to the right means things are going well, and that only holds if everyone in the room agrees on what the line is counting.

So before anyone opens a charting tool, I ask a question that sounds almost rude: does a commit mean we have delivered something? Does a merged pull request? The answers are never as obvious as people expect, and the gap between them is usually the real problem.

What "Delivered" Actually Means

I was once asked to review a client’s board dashboard. It reported story points completed, number of commits, lines of code changed, and a ranking of individual developers. The board’s question, when it came, was whether the company was delivering value faster than its competitors. Nobody could answer that from the dashboard, because nothing on it had been connected to delivery in the first place. Every number on that screen described how busy the team looked.

This comes up on discovery calls often enough that I now treat it as the first piece of work rather than a preliminary. Rather than propose metrics, I ask the people in the room to talk me through what delivery means on their project, and I keep asking until the answers stop contradicting each other. Sometimes delivery means merged into the main branch behind a feature flag. Sometimes it means running in production. Occasionally it means nothing counts until the customer who asked for the work has used it and said something about it.

Each of those is defensible on its own. The trouble starts when the engineering team is working to one definition, the product owner to another, and the board to a third that nobody has ever said out loud. You can build a beautiful dashboard on top of that disagreement, and all it will do is give three groups of people a shared surface on which to misunderstand each other.

Agree the definition first. Once you have, the dashboard becomes a question of presentation: how do we show a thing we have already agreed on, in a form the board can read.

The Vanity Metrics Trap

Lines of code, commit counts and story points measure activity, not value. They are popular because they are easy to collect: every one of them falls out of tooling the team already runs, with no argument about definitions and no work to set up. That is the whole of their appeal, and it is not a good enough reason to put them in front of a board.

Any metric can be gamed, including the good ones. If deployment frequency is what gets you praised, you can ship empty changes all afternoon. If a low bug count is the target, you can stop writing the tests that find bugs. None of that requires anyone to act in bad faith, either; people respond to what is being counted, and they do it without needing to be asked.

The defence is a small set of measures that pull against each other, so that gaming one of them shows up in another: something about speed alongside something about stability, all of it reported at team level. When one improves sharply and the others do not move at all, that is a question to ask before anyone celebrates.

Measure Teams, Not Individuals

A client of mine built the other kind of dashboard, the one that reports on people. It tracked pull requests merged, bugs fixed and lines of code written, per developer, and it was visible to everyone.

What happened next was entirely rational. Individual contributors started picking the small tickets, the single bug fix and the change to a UI layout, because those are the items that move a per-developer count. The large features customers were asking for sat in the backlog, because taking one of those on meant weeks of work with nothing to show on the board each week. Nobody was cheating. They were reading the scoreboard and playing the game it described.

The cost of that arrived as a resignation. Their strongest developer left, and the reason, as it was put to me afterwards, came down to not having joined to be counted like a factory worker. The tickets they wanted to work on were the ones the dashboard punished them for taking.

So the rule I now give clients is a blunt one: measure teams, never individuals. A team’s deployment frequency tells you something about how the work flows. An individual’s pull request count tells you who has been assigned small tickets. There is a wider point here about what happens when you make it harder for developers to do good work, and about the learning culture that keeps people around long enough to build anything substantial.

Three Numbers a Board Can Read

When a client wants somewhere to start, I suggest three delivery numbers, because three is about as much as a board will hold in its head between meetings.

The first is how often you deploy. Said plainly, it answers the question of how frequently the business puts something new in front of customers, and a board can understand that without any translation from engineering.

The second is how long it takes for a change to get from a developer’s machine into production. This is the one that tends to surprise people, because the coding is rarely the slow part. When that number is measured in weeks, the reason is almost always a queue: a waiting review, a batched release window, a change advisory board that meets on Thursdays.

The third is how often things break in production. How many bugs exist in a codebase is unknowable, so this measures something narrower: how often a change causes something customers rely on to stop working. A board understands that one immediately, because it is the number that turns into phone calls.

Those three are only a starting point. The DORA programme, which has been researching this for over a decade, now publishes five measures: deployment frequency, change lead time, failed deployment recovery time, change fail rate, and deployment rework rate. I have written a companion piece on what those five actually measure and what they reveal about a delivery process, including the one that was renamed and the fifth that was added after most of us learned the original four. Start with three numbers your board can read, and grow into the rest once the first conversation has stopped being confusing.

Getting to the Why Takes Longer Than the Build

The dashboard work I am proudest of took about a week before anyone designed anything. That week was calls, meetings and a good deal of disagreement, all of it aimed at working out why this client wanted a dashboard at all, and what they would do differently once they had one. Building it afterwards took a few days: designing the thing, pulling the numbers from application programming interface (API) endpoints the team already had, and publishing it inside the client’s own technology estate so that anyone in the business could look at it.

Nothing happened on the day it went live. That is worth saying, because the imagined version of this work ends with a room full of impressed executives. The real version is quieter. What changed came at the next sprint review, when the team could point at the screen and say: this is where we are, this is what the board is seeing, everyone is comfortable with it, so what would stop us from keeping it there.

That last question is where a dashboard starts earning its keep, because it gives the team something to defend together. Add to it slowly, and only once the numbers already on it have stopped needing explanation. A board that has understood three measures for two quarters will take a fourth in its stride. A board handed nine at once will go back to asking whether everything is on track.

What a Dashboard Cannot Fix

One client I worked with had a mean time of over one hundred days between a customer asking for something, or reporting a problem, and that change being live. Not the worst I have seen, but slow enough that customers had stopped expecting anything to happen when they got in touch.

The dashboard was one of several changes we made. There were process problems underneath the number, and a lot of firefighting that kept pulling people off planned work and onto whatever was loudest that morning. It would be dishonest to claim the dashboard fixed any of that. What it did was make the problems impossible to overlook: once decision makers could see where the time went, they could audit their own processes, and they had the evidence to challenge the parts they had previously only suspected were slowing things down.

That is the honest version of what this work does. Visibility locates the problem and settles the arguments that would otherwise run on opinion; the fixing is still done by people, and it is usually less interesting than the dashboard that revealed it.

The clearest example I have of measurement done properly came from an engagement that was still running when I first published this post. Over twelve months with Ligentia, a globally distributed logistics business, the engineering team’s feature delivery improved by 75%. What makes that number defensible is how it was measured: Ligentia already ran DORA measurements on their own dashboards, feeding their own reporting calls, so there was a baseline from before the work started and the same methodology running throughout.

The engagement was about adopting AI tooling, which is rather the point, because nobody had introduced a new measure to make the programme look good. When delivery sped up, the bottleneck simply moved somewhere else: the team started producing pull requests faster than their reviewers could clear them. Their existing dashboards showed them that, too.

If your organisation already measures something it trusts, measure the next piece of work with that, resisting the temptation to introduce a metric that exists to make a project look successful.

From Trust Us to Look at This

Boards do not need to understand Agile, and they will not be persuaded by a burndown chart. They need to see that the company delivers consistently, that quality is holding, and that the people doing the work are still there in six months.

Most of that work happens in conversation, long before anyone opens a charting tool. Settle what delivered means, so that everyone is counting the same thing. Report on teams, so that the dashboard does not reshape how people choose their work. Then show few enough numbers that a board can remember them between meetings, and let those numbers do what “trust us” never could.

If you would like help working out what your delivery numbers are telling you, or how to present them to a board without either overselling or drowning them, let’s talk.