Skip to content
← All writing

Reporting delivery to leadership: promises, not activity

· 5 min read · by Tan Gravam

The short answer

Report delivery to leadership as promises against outcomes, not as activity. The useful report has a small fixed shape: what was committed and when; what closed honestly — delivered, delivered with exclusions, or not delivered, with the difference recorded; what is at risk, with the reason the accountable person gave; and which commitments were made early on a recorded exception. A status colour belongs in it only with its reasoning attached, because a green with no reason is a feeling, not a claim. And a quarter closes by counting honest closes, slips and exceptions — not by the volume of things that moved.

The monthly delivery report, as usually written, is a list of things that happened. Features shipped, tickets closed, releases cut, a paragraph per team. It takes hours to assemble, it reads as momentum, and it answers no question leadership actually has.

Leadership's questions are about promises. What did we say we would do? Did we do it? What is in danger, and does anyone need to act? An activity list cannot answer any of these, because activity has no relationship to a promise — a team can be visibly busy for a quarter against commitments it is quietly missing.

The unit of the report is the commitment

A commitment has a shape an activity item lacks: what was promised, to whom, at what size, by when. That shape is what makes a report checkable. "Shipped the new exporter" is information only if somewhere there is a record saying the exporter was promised, for this quarter, at two FTE-months — and the comparison of the two is the report.

This is why the closes have to be honest. A commitment ends in one of three ways: delivered, delivered with exclusions, or not delivered — and for anything but a clean delivery, the difference from what was promised gets written down. Collapse those three into a checkbox and the ledger degrades into the activity list it was supposed to replace, because "done" now spans everything from a clean delivery to a quiet abandonment.

A colour needs a reason

In-flight work reports by status, and status decays into decoration unless the reasoning travels with it. A RAG status is a judgement by the accountable person — and the judgement is only readable when the check-in says what changed and what decision or help is needed. A wall of bare greens tells leadership nothing; worse, it teaches them that the report is written to be filed rather than read. One amber with "vendor contract unsigned, need legal by the 20th" attached is worth the whole board, because it is the only line someone can act on.

Count the exceptions

Some commitments are made before the work is ready, because real deadlines exist. The governance move is not to forbid them but to record them — why early, what is missing, who accepts the risk, what would change the decision — and then to count them at the close. Early commitments are the report's leading indicator: if this quarter's misses cluster on them, the organisation is promising ahead of its evidence and the fix is at commitment time, not in delivery.

What to leave out is the other half of the discipline. Release notes, ticket counts, burndowns — anything nobody promised and nobody can act on. Dropping them is not hiding information; it is refusing to bury the four lines that matter under forty that do not. If you want this as a copyable artifact, the four-part status report template is exactly this argument in table form.

A worked example

An engineering director with six teams closes the quarter for the leadership meeting. The ledger shows fourteen commitments: nine delivered clean, three delivered with exclusions — each naming what was cut and why — one not delivered, one slipped to next quarter with the re-baseline recorded. Three of the fourteen were early commitments on a recorded exception, and two of those are the miss and the slip. The risk register holds two open high-severity items, both with owners.

That is the whole report, and it fits on one screen. It took no assembly, because every line is a record that already existed. And it changes the conversation: instead of "what did the teams do?", the meeting asks why early commitments keep missing — which is a question about how the quarter gets planned , and exactly the conversation a delivery report exists to cause.

How DeliverySheet does it

The reports hub is built from these records and only these: a commitment ledger of promises against outcomes, a risk register, committed effort per team in FTE-months, the early commitments with their exceptions, and the completed-and-learned list — closed outcomes with the lesson each one produced. Check-ins ask for the reason alongside the rating. Nothing in it is assembled by hand at month end, because everything in it was written down at the moment it was decided. What happens after the commitment — tracking, closing, learning — is its own overview .

I'm Tan Gravam. I build DeliverySheet — it takes a vague work request to a clear delivery decision, so the shape, owner, capacity, dependencies and open questions are on the table before anyone commits people or a date.

$189/month per workspace, unlimited members, 7-day free trial. I answer the support email myself.

More on after the commitment

Read the overview: After the commitment: tracking, closing and learning →