§ CAPABILITY

Engineering Reporting for Boards

A monthly engineering report a board can act on. What shipped, what it cost, what is at risk, and what decision is being asked for — in the language the rest of the pack is written in.

Who
Led by the founder, hands-on for the duration.
Request a call How the work runs

What you're seeing

A board asks how engineering is going and receives a roadmap.
Usually means A roadmap answers what is planned. The board is deciding whether to keep funding it, which needs delivery against previous commitments, cost, and what would change the plan.
The engineering section of the pack is assembled the night before.
Usually means There is no standing measurement, so each meeting costs a scramble and produces numbers nobody can reproduce next quarter. Comparability across meetings is where the value would have been.
Delivery slipped and the board found out at the meeting.
Usually means There is no mechanism for surfacing a risk between meetings. By the time it appears in a pack it is a fact rather than a decision, and the board's remaining options are worse.
Engineering spend rose and the pack cannot connect it to anything.
Usually means Cost and output are reported separately, so the only available question is why the number went up. Joining them is what converts an interrogation into a decision.

What a board is actually deciding

Not what engineering is working on. Whether to keep funding it at this rate, and whether this team’s forecasts can be relied upon.

Those two questions determine what belongs in the pack. Delivery against what was committed at the last meeting, so there is a record of forecast accuracy. Run cost joined to output, so spend has a denominator. Risk with owners and dates, so the board is being asked for decisions rather than informed of outcomes. And an explicit statement of what decision is wanted this month.

A burndown chart answers none of those and is frequently what gets sent.

Against commitments, not against a plan

Reporting a fresh plan every month is unfalsifiable, and a board notices that within about three cycles.

Reporting against what was said last time is uncomfortable — it creates a permanent record of forecast accuracy — and it is the only thing that makes a good month credible. A team whose commitments have held for four quarters has bought something with that record that no amount of narrative achieves.

It also changes internal behaviour, usually for the better: commitments get made more carefully when they are going to be reported against by name.

Bad news, early and in the same place

A pack that only reports good news stops being read the first time reality contradicts it.

After that, everything in it is discounted, including the parts that were accurate. That is a high price for the deferral it bought, and it is paid at the moment credibility matters most — usually during a raise or an acquisition, when engineering is being diligenced by somebody with no history with the team.

Early bad news also arrives while the board still has options. A risk surfaced two months out is a decision; the same risk surfaced at the meeting where it lands is an announcement.

Where it sits

This capability sits under Engineering Velocity, where the measurement exists and needs translating, and inside both Fractional CTO and Delivery Implementation, where board-facing reporting is part of holding the seat.

It is downstream of DORA Metrics — the pack is that data rewritten for people who do not read a backlog — and it is the artefact that pays off during Technical Due Diligence, when a buyer’s diligence team asks whether this team ships what it says it will and there is a two-year record to hand them.

How the work runs

  1. Establish what the board actually needs

    Usually three things: whether the plan is on track, what it is costing, and what decision is wanted this month. Rarely a burndown chart.

  2. Pick the measures that carry those

    Delivery metrics against commitments, run cost against headcount and infrastructure, and a risk register with owners and dates.

  3. Build the pack

    A repeatable format short enough to be read, with the engineering detail in an appendix for whoever wants it.

  4. Run it and hand it over

    Two cycles produced together, then it becomes yours.

What arrives

  • A monthly reporting template with a fixed structure
  • A risk register with named owners and review dates
  • A run-cost view joining infrastructure and headcount to output
  • Two cycles produced alongside your team before handover

What it costs your team

Around three hours a month once the format is set, most of it review rather than assembly.

Next step

Tell us where this is breaking and we'll say what it takes to fix.

Request a call

How we decide

  • The pack reports against previous commitments, not against a plan

    Costs It creates a permanent, visible record of what was said and what happened.

    A board's real question is whether this team's forecasts can be relied upon, and that is only answerable by comparison over time. Reporting a fresh plan each month is unfalsifiable and, after two or three cycles, it is read that way. The record is uncomfortable and it is what makes the good months credible.

  • Bad news goes in early and in the same format

    Costs It surfaces problems to investors sooner than management would choose.

    A pack that only reports good news stops being read the first time reality contradicts it, and everything in it afterwards is discounted. Early bad news also arrives while the board still has useful options, which is the difference between being asked for a decision and being informed of an outcome.

  • It is handed over after two cycles

    Costs It ends a recurring piece of work that could reasonably continue.

    A board report that depends on an outside party is a dependency the board should not have, and it is one they will discover at the worst moment. Two cycles produced together is enough to transfer the format and the judgement about what belongs in it.

Frequently Asked Questions

A recurring engineering report written for the people funding the work rather than for the people doing it. It answers whether the plan is on track against what was previously committed, what it is costing, and what decision is being asked for — in the format and the language the rest of the board pack uses.
Three things, usually. Whether the plan is on track, measured against what was committed previously. What it is costing, joining infrastructure and headcount to what shipped. And what decision is being asked for this month. Detail belongs in an appendix for whoever wants it.
A roadmap answers what is planned. The board is deciding whether to fund it, which requires delivery against previous commitments, the run cost, and the risks that would change the plan. The roadmap is one slide inside that, not the report.
It replaces unstructured scrutiny with structured. Boards ask harder and more speculative questions when the answers are absent, and a regular pack in a consistent format reliably reduces interrogation rather than inviting it.
Then the report says so, early, with what changed and what is being asked for. A pack that only carries good news is discounted the first time it is contradicted, and everything in it afterwards is read sceptically — including the parts that were true.
Whoever will own it, and they are identified at the start. We produce two cycles alongside them and then it is theirs. A board report that requires an outside party to assemble is a dependency the board should not be carrying.

Sources

Page reviewed