Stop asking for status, start asking for evidence

Status reports optimise for the wrong thing. They reward whoever writes the most reassuring narrative, which rewards performative polish over honest signal. Most engineering status reports I read as a VP were trying to tell me the team was doing well, which isn't what I needed. What I needed was a fast read on reality, and the report was aggressively filtering it.

What the evidence page contains

The version that has worked, for me and for the teams I've advised, is a single page with five entries. Lead time for changes, trending. Release frequency, trending. Change failure rate, trending. Top three delivery risks with a one-line current status. What shipped this period that moved a customer-visible metric, with the metric named and the delta quantified.

Five items is the hard constraint. The temptation to add a sixth is strong, and every quarter someone in leadership will propose one. Usually the sixth is a metric that serves their seat specifically. If you let it in, within two quarters the page is back to being a twenty-metric status report with 'evidence' written on the top. The discipline of keeping the page at five is a governance problem, not a reporting problem, and it has to be defended by whoever runs engineering personally.

Why the first three are those three

Lead time, release frequency, and change failure rate are the three DORA metrics that aren't recovery time. Recovery time is fine to measure but harder to improve in the first year, so I leave it off the evidence page until the other three are stable. These three are diagnostic of engineering health in a way that project-delivery metrics are not. A team that claims to be healthy while their lead time is rising is not being honest, and a team that is genuinely healthy will show improving trends on these three almost regardless of what they're building.

The trend line matters more than the number. A team with a long lead time that is steadily improving is in better shape than a team with a short lead time that is getting worse. Evidence pages should show trends, not snapshots. This is not a technical distinction. It is cultural. Snapshots let you game the current quarter. Trends make you defend a direction.

The risks column

The risks column is the one that changes the meeting dynamic. Asking a team to name their top three delivery risks forces them to state what might fail, in writing, before it fails. This is culturally hard the first time. Teams are trained to surface risks privately and mitigate them quietly. Asking for them in a standing artefact feels, at first, like asking for ammunition to be used against the team later.

The trick is that leadership has to actually treat the risks column as information, not as blame material. If a named risk materialises and the team gets punished for having predicted it, the next version of the page will only contain risks that have already been mitigated. The page becomes ceremony. Keeping the risks column honest is a leadership behaviour, not a team behaviour, and it's the bit that usually breaks first.

Trends make you defend a direction. Snapshots let you game the quarter.

The customer-metric column

The final column - what shipped this period that changed a customer metric - is the hardest to populate honestly, and the most valuable. Most engineering teams don't have the telemetry to attribute cleanly. They shipped something. Some metric moved. Whether the two were causally related is usually unknown. Naming this column forces the investment in attribution, which most organisations have been putting off for years.

The first three quarters of running this column, most teams will produce thin, apologetic entries that say things like 'shipped X, suspect it contributed to Y'. That's fine. The column is doing its job when it exposes the attribution gap. Within a year, most teams will have pushed for better telemetry because they're tired of writing apologetic entries, and the telemetry is where the real value lives. The evidence page is, in this way, a slow forcing function for product-engineering integration that would never have happened from a direct ask.

What you lose

You lose the coasting middle tier. Status reports hide managers who are managing narrative rather than outcomes. Evidence pages do not. Within two quarters you will know, with more clarity than any performance review offers, which of your managers are actually running teams and which are running reports. Some of those people will leave. Some will improve. Losing a few is part of the cost of the change, and the honest framing up front makes it survivable.

You also lose the polished narrative in leadership meetings, which some senior executives rely on more than they admit. If the CFO is used to a soothing three-page monthly that tells a clean story, replacing it with five trend lines and a risks column will be uncomfortable. The uncomfortable version is accurate. The soothing version was not. This is a hard conversation to have with executives who prefer the soothing version. Have it anyway.

The smallest version

If you want to pilot this without committing the whole organisation: pick one area under your direct report, replace its status report with a five-row evidence page for a quarter, use it as the only artefact you read at the weekly. Watch what changes. The behaviour shifts within about three meetings. By month two the other areas will be asking why they have to keep producing the old reports. That's when you make the change permanent.

The reason this works is unexciting. People optimise for what's measured. When you measure narrative, you get narrative. When you measure evidence, you get evidence. Most organisations have been measuring narrative for decades by accident, and wondering why execution is slow. Change what's measured. Everything else follows.