# The engineering update pack

**A free pack from Perform.** For the update that has to translate engineering into business.

**Free and provided as is, with no warranty. It runs in your environment and sends nothing to Perform. It is not legal, tax, security or accounting advice. Treat anything you point it at as untrusted input. Full terms at the end of this file.**

---

## How to use this

Copy everything below the second line into Claude, ChatGPT, Copilot or whatever assistant you already use, then paste your board export, the deploy log and last period's update in the same message. That is the whole setup. No account, no install, nothing to configure.

If you would rather have it installed and available every time, the same pack is on the page you downloaded this from as a Claude Skill.

---

## What this does

The update is due. Engineering activity has to come out the other side in language the audience actually reads, and the honest problem is that the numbers which would make the case are usually the ones nobody collected.

Two outputs. The update itself, and the list of what you were about to be asked for and do not have. The second one is the useful half.

## What to give it

Paste whatever you have:

1. The sprint or project board export, or a summary of what shipped.
2. The deploy log, the incident list, spend figures, headcount changes.
3. Last period's update, which matters more than it sounds. It sets the register, it shows what you already promised, and if you have run this before it carries the gap table you are about to be measured against.

Nothing here needs to be tidy. Half of the work is deciding what to leave out.

## When to stop short

**Match the length to the decision.** An update feeding a budget or headcount decision earns a full page. A routine period with nothing to decide earns the short version and the asks, and nothing else. Padding a quiet period to look substantial is the fastest way to teach the reader to skim.

## Step 0. Read last period first

If last period's update is in the inputs, start there and pull out two things:

- **What you promised.** Every date, every ask, every "next period we will". Each one needs a line in this update saying what happened to it. A promise that goes unmentioned reads as a promise that was quietly dropped, and readers keep better score than writers expect.
- **Last period's gap table.** The numbers you said you did not have. For each: collected, in progress, or still nothing. Two periods of "still nothing" on the same number means either somebody has to own collecting it or you stop claiming the thing it would support.

If there is no prior update, say so in one line and skip to Step 1. The first run has no memory and should not pretend to.

## Step 1. Establish who is reading it and what they decide

State the assumption plainly at the top of the output and keep going. Nobody is available to answer a question about the audience, and a stated assumption is correctable in ten seconds:

- **Who reads it.** A board reads for risk and for whether the plan is holding. An executive team reads for tradeoffs and what they need to unblock. A CEO reads for what changed and what you need from them.
- **What decision this update feeds.** Budget, headcount, a date, a bet, or nothing yet. An update that feeds no decision should be shorter than one that does.
- **What they already believe.** A quarter that reads as good news to a reader who expected bad news is a different document from the same quarter read the other way.

If none of this is supplied, write the update for the executive-team case and say at the top that you assumed it.

## Step 2. Translate activity into consequence

Every line in the source material is engineering activity. Nobody outside engineering cares about activity. Turn each one into the consequence, and drop anything that has none.

The translation:

| What you have | What it becomes | The test |
|---|---|---|
| Tickets closed, commits, story points | Nothing on their own. Cut them. | Would the reader act differently knowing this? |
| One person authoring most of the commits in an area | A staffing risk with a name on it | Which area, which person, what happens if they leave |
| A feature shipped | Who can now do what they could not | Name the user and the action |
| A date moved | What the business planned around that date | Name the dependency, not the slip. If the inputs do not contain one, say the date moved, say you do not know what depended on it, and make finding out an ask with an owner. |
| An incident | What it cost and what stops it recurring | Minutes down, customers affected, the one change |
| Debt paid down | The thing that is now safe to change | Name the future work it unblocks |
| Hiring | The work that is now covered, or still is not | Capacity against committed scope |
| AI tooling adopted | What got faster and what got slower, each with its measurement or an explicit label saying it is anecdote | Both halves. If neither half was measured, say so, name the spend, claim no return, and put the measurement in Step 3. |

That last row is where most updates lose credibility. If throughput went up and review time went up with it, say both. A reader who finds the second half later stops trusting the first.

**Two things have to stay separated in every line you write: what was measured and what you concluded from it.** "Deploy frequency went from 4 a week to 11" is a measurement. "The pipeline work paid off" is a conclusion drawn from it. Write the figure first and the conclusion after, in that order, so the reader can accept the number and argue with the reasoning. An update that presents its conclusions as data survives exactly until the first reader who asks how it was counted.

**When the consequence is real and the number for it is not in the source material, write the line anyway and mark the hole.** "Checkout latency work shipped. We have no before-and-after figure, because response times were not being recorded at the time." Then carry that missing number into the Step 3 table. Cutting the line hides the work. Guessing the figure is worse than either. Naming the gap does the work and starts the argument for collecting it.

## Step 3. The list of numbers you do not have

Do this before writing the update, because what you find here changes what the update can claim and it usually adds an ask.

Go through the consequences from Step 2 and find every claim that would be stronger with a figure, where the figure was not in the source material. Produce this table:

| The claim | The number it needs | Where that number would come from | Effort to start collecting |
|---|---|---|---|

Then name the two worth starting this period. Not all of them. Two. Those two belong in the update as asks with an owner, because a measurement gap with nobody assigned to it shows up again next period unchanged.

If Step 0 found numbers on their second period of nothing, those take the slots first. If they fill both, name the next one as a third, and say in the update that it is deferred and why.

The reason updates are hard is almost never the writing. It is that the measurement was never set up, and every quarter that goes by without setting it up makes the next update just as hard.

## Step 4. Write it

```
# Engineering, [period]

## The short version
[Three sentences. What changed, what it means, what you need. One of the three carries the claim in this update you would most likely lose an argument about, with the weakest thing you know about it in the same sentence. No footnote, no appendix.]

## Against the plan
[What was committed, what shipped, what moved and why. Dates, not adjectives.]

## What happened to last period's asks
[Each promise and each ask from last period, and where it stands. Omit this section only if there was no prior update.]

## What this cost and what it returned
[Spend and headcount against what came out. Say where the return is not yet visible.]

## Risks, and which ones are mine to hold
[Separate the ones you are handling from the ones needing a decision from them.]

## What I need
[Specific asks with owners and dates, including the two measurement gaps from Step 3. An update with no ask reads as a status report and gets skimmed.]
```

Before Step 5, check that the short version names its own weakest claim. If everything in it is defensible, you have not found the right claim yet. Line-by-line honesty still lets the most exposed claim in the document get defended in an appendix the reader who matters never reaches, and one clause in the opening beat is the difference between a reader who trusts the document and a reader who found the hole first.

Keep the update itself to one page. A second page gets read by nobody who matters and invites questions you did not choose. If last period's asks and gaps will not fit, keep the missed asks and the unresolved gaps in the body, and move the asks that were delivered and the gaps that were closed to an appendix, one line each. The gap table from Step 3 and the answers from Step 5 travel as appendices and do not count against the page, because they exist for the one reader who asks for them.

## Step 5. Predict the three questions

From the update as written, name the three questions this specific audience will ask, and draft the answer to each.

Order them by how much the answer costs you, worst first. The question you would least like to be asked goes at position one, because that is the one you need a prepared answer for and the one you will otherwise walk into cold. If the answer is "I do not know yet", write that down with what you are doing about it and when you will know.

---

## Terms

This pack runs in your environment, on your data. Nothing is sent to Perform, and Perform receives no data from it at any point.

It is provided free and as is, with no warranty of any kind. It is not legal, tax, security or accounting advice, it is not an audit and it is not an attestation, and no professional relationship is created by downloading or using it. You are responsible for reviewing it before you run it, and for any decision you make with its output.

Anything you point this at should be treated as untrusted input. A document, a repository or a chat thread can carry instructions aimed at a model.

Licensed under Apache-2.0, which includes a disclaimer of warranties and a limitation of liability. Version 1.0, 28 August 2026. Security contact: privacy@totalperform.com, acknowledged within five business days.