How to report engineering progress to non-technical stakeholders

The fastest way to improve an engineering update is to delete the first half of it. Most updates open with what the team did and never quite arrive at what it means. Executives read the first three lines, find no answer to the question they had, and file it.

Here is a format that survives contact with a real audience, plus the specific habits that make updates get ignored.

Start with the sentence they will repeat

Open every update with one sentence naming what is now possible that was not possible before. Not the work, the consequence.

Compare these two openings for the same fortnight:

We completed the payments migration, refactored the retry queue, and closed 23 tickets.

Customers can now pay by invoice, which unblocks the four enterprise deals that were waiting on it.

The second one is what your reader repeats to somebody else. That is the actual job of the update: to give a non-technical person a defensible sentence about engineering that they can say out loud without hedging.

If no such sentence exists this period, say so plainly. “Nothing shipped to customers this fortnight; the work went into the migration that lands next” is a legitimate update and far better than padding.

Use four sections, in this order

Shipped. What customers or the business can now do. Two to five items, each written as an outcome. Skip anything that only an engineer would notice.

In progress. What is underway, and when it lands. Give a date or a week, not a percentage. “70% done” is unfalsifiable and everyone knows it.

Risks and blockers. What is at risk, and what you need. Put this above the fold, not at the bottom. An update that surfaces a slipping date early buys you credit. The same information arriving three weeks later spends it.

Under the hood. Optional, and last. The refactors, the dependency upgrades, the test work. Include it so the invisible work is on the record, but keep it to a couple of lines and do not defend it. This section exists to answer “what were you all doing”, not to be discussed.

That order is deliberate. Readers stop early. Anything below “risks” is a bonus.

Translate, do not simplify

Simplifying means saying less. Translating means saying the same thing in the reader’s terms, which is harder and considerably more useful.

A working test for each line: name the change, then answer “so what?” once. If you cannot answer it, the line does not belong in a stakeholder update.

Engineering framing	Translated
Migrated auth to short-lived tokens	Sessions now expire properly, which closes the security finding from the vendor review
Added retries to the webhook consumer	Orders no longer go missing when the warehouse system is briefly down
Upgraded the ORM	No user-facing change. Removes a dependency that was blocking the Postgres upgrade in Q4

Note the third row. “No user-facing change” is an acceptable answer. Pretending a dependency upgrade delivered customer value is how technical updates lose their reader’s trust permanently.

Cut the metrics that describe motion

Commit counts, pull requests merged, story points, lines of code, and velocity all measure how much movement occurred. Your reader is asking whether the movement went anywhere. There is an entire category of tooling built on activity metrics, and it is genuinely useful to engineering managers tuning their own process. It answers a different question than the one in the room.

The exception is a metric tied to a business outcome you already agreed to move. Checkout error rate, page load time on the pricing page, time to first response in support. Those belong in the update because a change in them is itself the outcome.

Keep it to two or three numbers. A wall of figures reads as an attempt to look busy, which is the impression you were trying to avoid.

Fix the cadence, and keep it

An update that arrives on a predictable rhythm gets read. One that arrives when someone remembers gets treated as an exception report, which means its arrival starts to imply bad news.

Pick a rhythm and hold it, and send it even when the answer is “nothing shipped, here is why”. The empty update is the one that builds the most trust, because it proves the channel is honest. Which rhythm to pick, and which slice of the work each reader gets, is covered in choosing a scope and a cadence.

Do not make the update contingent on a meeting. If it exists only as slides in a monthly review, then for three weeks out of four your stakeholders are guessing, and guessing is what erodes confidence in a team that is actually doing fine.

The part nobody wants to own

Everything above is straightforward and almost nobody does it consistently, because writing the update means someone senior spends a couple of hours a week reading merged work and translating it. That cost is why updates start weekly, drift to monthly, and end up happening only before board meetings.

Two ways out. Either make it explicitly part of one person’s role and protect the time, or derive the update from the repository instead of writing it by hand. The mechanics of the second option are covered in the guide to GitHub reporting for non-technical stakeholders, and if you want the raw material first, what a GitHub commit actually is covers the underlying record.

DevSummary was built for the second route. It reads the branch you ship from and writes the outcome-first version of this format on a schedule, scoped to a project or a team.

The format is not the hard part. Sending it in week nine is.