What to show an executive who does not read pull requests

If you do not supply a picture of what engineering is doing, one gets assembled anyway, out of whatever was most recently late.

There is an information gap in most companies above a certain size. Engineering knows what it is doing. The executive team does not, and has no practical route to finding out: reading pull requests is not a reasonable ask of a CFO, and a sprint board is written in a dialect that assumes six months of context.

The gap gets filled regardless. It fills with whatever reached the executive team most recently and most loudly: the outage, the missed date, the thing a customer complained about in a meeting. That picture is not false, but it is drawn entirely from exceptions, and a picture drawn entirely from exceptions is a bad basis for deciding where money goes.

The engineering leader’s actual job here is not defending the team. It is supplying a boring, regular signal so that the exception has something to be an exception to.

What executives are actually asking

“What is engineering doing?” is rarely the literal question. Underneath it, in almost every case, is one of four:

  • Are we getting faster or slower? A direction, not an absolute. Nobody outside engineering has an intuition for whether forty deploys a month is good, and everybody has an intuition for whether it is up or down.
  • Where is the effort going? The split between new work, maintenance and unplanned interruption. This is the one that most often produces a genuine surprise, and it is usually the argument that wins headcount.
  • Is anything about to go wrong? Rising failure rates, lengthening reviews, a team that has stopped shipping.
  • Are the people alright? Asked less often than it should be, and the one where a metric is most likely to mislead.

None of those require anybody to look at an individual engineer, and answering them with individual data is the mistake that gets the whole reporting effort withdrawn a year later.

The monthly slide

One slide, four numbers, per team, with last month next to it. That is genuinely enough, and the discipline of fitting it on one slide is what keeps it honest.

Throughput, and its direction. Whatever unit of delivered work makes sense in your context, such as merges, releases, completed items. The absolute number is nearly meaningless across teams and highly meaningful against the same team last quarter.

Lead time. How long a change takes from written to live. This is the number executives understand fastest, because it maps onto a question they already have: if we decided something today, when would customers see it?

Failure rate, and recovery time. Together, and never separately. Alone, failure rate rewards caution and caution is expensive. Paired with recovery time it describes something an executive recognises: how well the team absorbs being wrong.

Unplanned work as a share of the total. The most commercially useful number on the slide and the one most often missing. “Forty per cent of last quarter went on interruptions” is an argument. “The team is stretched” is not.

Three things to keep off it

Anything per person. The moment a name appears on an executive slide, the number stops describing reality. People find out, and they optimise. You also lose the ability to be candid about a team having a bad quarter, because it now reads as a list of who to blame.

Story points. They are a planning tool for a team estimating its own work, they are not comparable between teams, and they inflate over time in a way that makes a chart of them worse than useless. An executive presented with points will compare two teams within about nine seconds.

Anything you cannot explain in one sentence. A composite health score computed from six weighted inputs will be questioned once, and the answer will take four minutes, and the number will never be trusted again. Prefer four simple numbers to one clever one.

Give the same picture to the people in it

The part most reporting efforts skip. If a team’s numbers are being shown to executives, that team should see the same numbers, at the same time, in the same form. Not as a courtesy, but because it is the only thing that keeps the metric honest.

A team that can see its own reported numbers will tell you when they are wrong, and they will be wrong at first. Attribution is imperfect, a service moved between teams, someone’s contributions are landing under two different accounts. All of that gets corrected quickly when the people who know are looking, and never gets corrected when the data only flows upward.

It also removes the thing that makes measurement feel hostile. A number about you that you cannot see is surveillance. The same number, visible to you first, is just information.

What this looks like in practice

A team-level view showing movement between two periods, with no route from it to ranking individuals. A per-person view that belongs to that person. Both reading from the same events, so there is only one version of what happened.

A detail that matters more than it sounds: a team with no prior activity should show no trend rather than a triumphant hundred per cent. Inventing a direction from a single data point is how a dashboard starts lying, and it usually starts lying in the flattering direction, which is the one nobody checks.

More on the mechanics: the full guide to the four DORA keys, how the team view is computed, what the four DORA keys do and do not tell you, and how to keep this from becoming surveillance.

See what your team already shipped.

Free for your first 50 people. No card, no sales call.