Reporting engineering progress to the fund

Reporting engineering progress to the fund is a format problem before it is anything else. A board receives an engineering update as a paragraph and a colour, and the colour is chosen by the person whose work it describes. The fix is a report built on measures that are captured the same way every quarter, that describe delivery rather than effort, and that a director can read in a minute without knowing how the software is built.

Four such measures exist and have been studied for more than a decade. This page uses them as the spine of the report, adds the plan table and the annual debt score beside them, and says what to leave out.

What are the four measures a board should see?

The four measures are DORA's four key metrics, published by the DevOps Research and Assessment programme and described on its own site as follows. Two describe throughput and two describe stability.

Measure	DORA's definition	What it tells a board
Change lead time	The amount of time it takes for a change to go from committed to version control to deployed in production	How long an idea takes to reach customers once the code is written
Deployment frequency	The number of deployments over a given period or the time between deployments	How often the company ships
Change fail rate	The ratio of deployments that require immediate intervention following a deployment	How often shipping breaks something
Failed deployment recovery time	The time it takes to recover from a deployment that fails and requires immediate intervention	How long the breakage lasts

DORA's guide to the metrics also names a fifth, deployment rework rate (the ratio of deployments that are unplanned and happen because of an incident in production), which a company can add once the four are stable. Google Cloud's announcement of the 2024 DORA report on 22 October 2024 described the four key metrics as the industry standard for measuring software delivery performance, and the 2024 report marked a decade of the programme's research.

The measures are read in pairs. Lead time and deployment frequency say how fast the team delivers. Change fail rate and recovery time say how safely. A quarter in which the first pair improved and the second worsened is a team going faster than it can check, which is the pattern DORA measured in AI-assisted teams: the 2024 report estimated a 7.2 percent reduction in delivery stability as AI adoption rose, and the 2025 report, from nearly 5,000 technology professionals, found stability still negatively related to AI adoption while throughput had turned positive.

Reveneau reports its own work to a fund in exactly this format, with the evaluation suite's pass rate as a fifth column, because a change that passed its evaluation before it shipped is the reason the fail rate stays down while the deployment frequency goes up; the format works for any team, whoever is doing the building. The pillar guide to technology after the deal sets the report as the fourth phase of post-deal work, the one that runs for the whole hold.

How should the measures be captured?

The measures should be captured from the deployment system itself, by the same query every quarter, and the method should be written down with the first report.

Lead time is measured from the timestamp of a commit to the timestamp of the deployment that contains it, averaged or taken as a median over the quarter. Deployment frequency is a count. Change fail rate needs a definition of "required immediate intervention" (a rollback, a hotfix, an incident opened within a set window after deployment), and that definition is the part to write down, because two teams with different definitions produce fail rates that cannot be compared. Recovery time runs from the failed deployment to the deployment or rollback that restored service.

Three rules keep the numbers honest:

1. Write the method once and do not change it. A measure whose definition moves is a measure with no trend. If the definition has to change, report both the old and the new for one quarter.
2. Capture before the work starts. The technology workstream in a 100-day plan captures the four measures as a baseline in days 61 to 100, so the first quarterly report has something to compare against.
3. Report per product where there is more than one. A buy-and-build platform reports the measures per acquired product, as buy and build: consolidating acquired software platforms describes, so the board can see which integration is degrading delivery.

What sits beside the four measures?

Two things sit beside them: the plan table and the annual technical debt score. Together the three parts fit on one page.

The plan table is the list of commitments from the first-year plan, one row per item, with owner, date, status (done, on track, late) and the measure of done. Turning the diligence report into the first-year plan describes how the table is built. In the report it is the part a director points at to ask "show me", and the measure of done column is what gets shown.

The technical debt score is captured once a year by the method technical debt across a portfolio describes, and it appears in the quarterly report as the entry score, the latest score, and the date of the next capture. It moves slowly and it is the number that will be compared at exit.

A one-page layout:

Section	Content
Delivery measures	The four DORA measures, this quarter and the last four, per product
Plan	The commitment table with status and measure of done
Debt	Entry score, latest score, next capture date
Decisions needed	At most three, each with the options and the engineering lead's recommendation
Risks	Anything that could move a delivery measure or a plan date next quarter

The decisions section is where the board earns its seat. A report with no decisions is a report the board reads and files; a report with three is a meeting.

What should the report leave out?

The report should leave out every measure of effort, because effort is what the team spent and the board is paying for what the team delivered.

Lines of code, commits, tickets closed, story points, hours logged and velocity are all effort measures. Each one rewards the behaviour it counts: more lines, more tickets, more points. None describes whether customers got anything. The SPACE framework's authors, writing in ACM Queue in February 2021, put it directly: developer productivity is about more than an individual's activity levels or the efficiency of the engineering systems relied on to ship software, and it cannot be measured by a single metric or dimension. The DORA measures are not a productivity score either; they describe the delivery system, which is what a fund is buying.

The report should also leave out prose status. "Engineering is on track" is a sentence with no measure in it. Every statement in the report should point at a number in the tables above, and a statement that cannot is a risk to be listed in the risks section.

The last thing to leave out is the colour. A green, amber or red rating compresses the whole quarter into a judgement made by the person being judged. The four measures and the plan table are the judgement, and the board makes it.

How does the report connect to the exit?

The report connects to the exit because the buyer's diligence will ask for the same numbers, and a company that has captured them every quarter for the hold has an answer nobody else in the process can match.

BCG's survey of 100 senior private equity investors, published 7 January 2026, found that 82 percent of firms track return on investment from digital initiatives and 72 percent track cost savings, while only 11 percent explicitly link digital progress to exit narratives and 40 percent use a formal digital-maturity score. A quarterly report built on the same four measures from the first quarter after closing, with the debt score beside it, is that link: it shows the buyer a delivery trend over the hold and a debt score that fell.

Bain & Company's press release of 23 February 2026 says holding periods for buyout funds now sit at seven years. Twenty-eight quarterly reports in one format, on one page each, are the engineering half of the exit story, and they cost the company one query per quarter to produce.

What should the operating partner check in the first report?

The first report should be checked for five things, and after that the check is whether the format held:

• The four measures are present, per product, with the capture method written down.
• The baseline from the 100-day workstream is the first column, so there is a comparison.
• The plan table has a measure of done on every row, and every "done" row can be shown.
• The technical debt entry score is present with its capture date.
• There is at least one decision for the board to take.

A first report that passes those five is a format the company can repeat for the hold. If the fund would rather the reporting was set up and the building done by a team that reports this way as a matter of course, building with investors and their portfolio companies describes how we work with a fund; the scaling engineering teams guide has a longer treatment of measuring engineering productivity for a company growing its own team.