A project status update template for tech leads that cannot hide red

False status is rarely a lie. My book Before the Room, a field guide to leading outcomes you have no authority to command, argues that it is usually the truth from the wrong instrument: if the report asks about tickets, teams report tickets, and the path the user takes between those tickets goes unmeasured. Under the weekly "are we still on track?" sits a decision nobody has made, what evidence is allowed to count as green. The book is blunt about what happens until someone makes it: "Until that closes, the color is a mood."

Its chapter on hidden decisions has a quieter version of the same failure, in one of the book's composite scenes. A director asks an engineer to confirm a date. The engineer checks the board and sends a careful answer, "Yellow, trending green", and ten days later the date has become a hard promise to a partner, made on the strength of that answer. The status update was spent as a commitment the engineer never made. The book's fix is to ask what the answer is for before giving it, and its point about the result is the one that matters here: once the director has to answer that question, "a status update can no longer be spent as a commitment the engineer never made."

So a status template has two jobs, not one. It has to make the color hard to fake, and it has to make the update hard to misuse. Everything below serves one of those two.

Write the definitions down once, put them at the top of the status page, and do not renegotiate them per project. These follow the status definitions in Before the Room's chapter on false green, with one column added for what each color is not:

Many teams say yellow for amber. Use whichever word your organization uses; the rule is the same. Four rules make the definitions hold under pressure:

• The color describes the outcome, not the effort. A team that worked late all week on a path that has never run is amber, and saying so is not a criticism of the work.
• Missing evidence caps the color. If the path test has no date, the status cannot be green, however confident anyone feels. Confidence is an input to the next test, not a substitute for it.
• No hybrid colors. "Yellow, trending green" and "green with some risks" let the reader pick the half they prefer. Pick the color the evidence supports and put the trend in the Next line.
• Red is a fact pattern, not a mood. It fires when one of the three conditions in its row is true. A sponsor accepting a risk by name does not make the risk smaller; it makes it owned, which is what that row measures.

The red row is the part generic red, amber, green templates usually leave vague. "Risk unowned" turns a risk that everybody can see and nobody has accepted into a color, which is the only way it reliably reaches the person who can accept it.

Green needs one piece of evidence that no single team can produce alone: the whole path, run under the conditions you intend to launch with. Before the Room calls the full version a truth test, three lines: the outcome as the customer or operator will meet it, the smallest proof that it exists outside any single team's boundary, and the conditions that proof has to run under. The green status article walks through it with the evidence table; in a weekly update it shrinks to one field with four parts: when it last ran, under which conditions, the result, and the date and owner of the next run.

Two rules keep the field honest. The first comes from the book's chapter on turning ambiguity into executable work: evidence has to be observable by someone outside the team that produced it. In its words, "If only the builders can tell you whether a piece of evidence is true, that is status". The second is the failure mode the book names for its evidence table: "rows filled with activity instead of evidence", because tested and done, as it puts it, "are not observations." Write what ran, where, and what happened.

On mobile, the conditions line is where most false greens hide. A run on the newest debug build against a staging backend has not tested the path most users will take. The conditions worth naming are a release build, a production-like backend, real permissions, and the oldest app version you still support, because builds already installed keep calling your API until their owners update. If the path has never run under those conditions, write "never" in the field. It is the most useful word in the update.

Below the color, the update carries four lines. They come from my book Ticket Taker, Outcome Owner, which uses them for stand-ups and for written updates to stakeholders: Result, Next, Risk, Need. Its rule for when to send one is the opposite of a weekly habit: "Visibility does not mean constant updates. Communicate when the state changes."

For a stakeholder update, two lines need slightly more than they do in a stand-up. The Risk line gets an owner and a date, because a risk with neither is a worry. The Need line gets a deadline and a consequence: Before the Room's escalation brief asks for "the date after which not deciding is itself a decision", and writing that date into the Need line is what turns a request into something a sponsor can schedule.

The weak column has one thing in common: it reports activity. "No blockers" is the most expensive of the four, because it is often written while the team is waiting on a decision nobody has been asked for. If you are waiting, that is a Need.

Copy the block below into the channel, email or page where your sponsor reads status. The top half is the evidence for the color, the middle is the four lines, and the bottom is what keeps the update from being misread: the risks someone has accepted by name, and the threshold you have already announced.

STATUS UPDATE: <project or launch>              <date>
From: <you>          To: <the person who decides>
Copy: <only the people who must act on this update>

Status:       GREEN | AMBER | RED         (last update: <color>)
Because:      <the evidence for this color, in one or two lines>
Path test:    Last run: <date, or "never under launch conditions">
              Conditions: <build, backend, permissions, oldest supported version>
              Result: <pass | fail | not run>   Next run: <date>, <owner>

Result:       <what changed since the last update, observed, and who can act on it>
Next:         <the next meaningful state, and the date you expect it>
Risk:         <what changed in risk: what it would hit, its owner,
               and when you will know>
Need:         <the decision, person or help; from whom; by when;
               and what happens if nobody decides>

Accepted:     <risk / accepted by (name) / date>, or "none"
Threshold:    If <condition> by <date>, I will bring <decision> to <name>.
Next update:  <date>, or sooner if the color changes.

Three fields are worth a sentence each. To is the person who decides, not a distribution list; an update addressed to everyone asks no one for anything. Accepted keeps a sponsor's decision to carry a risk visible every week after they made it, so nobody rediscovers it as a surprise. Threshold is the escalation you would make, written in calm weather, so that when it fires it reads as the plan and not as a threat.

An illustrative example, invented for this page: a one-tap reorder feature in a mobile release, the week the status moves from green to amber.

STATUS UPDATE: one-tap reorder, release 4.12          Week 3
From: checkout tech lead       To: launch sponsor
Copy: product lead, support lead, backend lead

Status:       AMBER                       (last update: green)
Because:      Backend and both apps are locally complete. The full reorder
              has never run on the oldest app version we still support.
Path test:    Last run: never under launch conditions
              Conditions: release builds, production-like backend, real
              permissions, oldest supported app version
              Result: not run   Next run: Thursday, checkout tech lead

Result:       Endpoint and both apps merged; a staging reorder passes on
              current builds. Support can start the runbook from today.
Next:         Thursday: path test on the oldest supported version.
              Friday: rollback rehearsed with the production flag.
Risk:         Older app versions send the previous order payload. If the
              endpoint rejects it, reorder fails for everyone who has
              not updated. Owner: backend lead. Known: Thursday.
Need:         Launch sponsor: decide by Wednesday noon whether 4.12 may
              launch with reorder on current builds only, if
              Thursday's test fails. With no decision, the plan keeps full
              scope and this risk stays unowned.

Accepted:     none yet
Threshold:    If the path test has not passed by Friday, I bring you
              three options on Monday: delay, current builds only, or
              launch with this risk accepted by name.
Next update:  Friday, or sooner if the color changes.

Read the example for what it does not say. It does not blame the backend team for the payload risk; it names the risk, the owner and the date. It does not ask the sponsor to "be aware"; it asks for one decision by a time. It keeps each team's finished work in the Result line, so the move to amber reads as a missing piece of evidence, not as a failure. And it says when the next update comes, so nobody has to chase it.

The template makes bad news easier to write. It does not make it easier to send. These are the habits that get it sent while it is still a planning input:

• Send on a state change, not on Friday. Ticket Taker lists the moments: an outcome reached, the next step changing, a new risk, a blocker crossing its threshold, a decision needed, confidence in the timeline changing, someone able to begin or forced to wait. Its line for why: "Silence does not remove risk. It transfers the surprise to somebody else."
• Raise it a week out, not at the gate. Before the Room puts the timing plainly: the evidence question raised for the first time in the final review makes you the person who blew up the launch; raised a week out, while there is room to fix what it exposes, the same question reads as leadership.
• Ask what the answer is for before you confirm. When someone asks you to confirm a date, ask whether they are about to promise it to someone outside the team. An internal target and an external promise deserve different answers.
• Give the next evidence point, not hope. Ticket Taker's example for a slipping task ends with when the revised estimate arrives, and its rule is short: do not end with a promise to try; "Give the next evidence point."
• Name the risk, not a villain. Before the Room calls one familiar line "an accusation in the shape of a status update": "This has been sitting with platform for five weeks." Write the risk on both sides instead, yours and theirs, and the decision between them.
• Say your part first. If the slip is partly yours, write that in the Result line. Ticket Taker: "Owning an error clearly creates more trust than hiding it behind vague complexity."
• Agree the threshold before you need it. "I will escalate if this goes badly" can never fire cleanly. A named condition and date, said to the other lead first, can. The ladder and the brief are in how to escalate as a tech lead.

If you are the person receiving status, one habit matters more than the template: do not punish early amber. Before the Room's warning is exact: "If the status system punishes early amber, teams hold green until red is undeniable". Early, accurate amber is the most useful thing a team can send you.

Agree a rhythm with the sponsor, usually weekly, and keep it even when nothing moved; a short "no state change, next evidence Thursday" is still an update. Then add one rule: a change of color goes out the same day, outside the rhythm. Ticket Taker says the other half: "Do not send daily status by habit when nothing changed."

Keep one update and send it to the people who decide, with a copy to the people who must act. The team channel gets the same four lines; it does not need a separate, more optimistic version. Two versions of status are how a sponsor and a team end up believing different things about the same week. For the habits that keep your own reporting from needing to be chased before any of this, see the engineer nobody chases.

Three limits are worth knowing before you rely on it. A path test proves the path runs end to end, not that you built the right thing; Before the Room says so in its own boundary for the chapter, and green on this template is not product validation. Exploratory work has no outcome to prove yet; for research, report what you learned and the next question, and do not force a color onto it.

And the template cannot protect anyone in an organization that punishes honest evidence. The book's list of when to stop using its moves includes that case, and its advice is to protect yourself first: document, seek formal support, and weigh moving teams or leaving. A better status format is not a fix for that.

The short version fits on a card. A color is a claim, so put the evidence next to it. No green without a dated path test. Four lines: result, next, risk, need. Send it when the state changes, with a decision attached, while there is still time to use it.

What should a project status update include?

A color with the evidence behind it, then four lines: the result that changed since the last update, the next meaningful state with a date, the risk that changed with an owner and a date, and the decision or help you need, from whom and by when. Add any risk someone has accepted by name and the threshold that would make you bring a decision to the sponsor. Activity, effort and history stay out.

What is the difference between green, amber and red status?

Green means the outcome is proven: the end-to-end path ran under launch conditions, with rollback and support recovery tested. Amber means it is not proven yet: local work may be done, but the path has not run under real conditions, or recovery evidence is missing. Red means the path fails, rollback or the end-to-end owner is missing, or a risk above the agreed limit has no sponsor who accepted it by name. Many teams say yellow for amber; the rule is the same.

How often should a tech lead send a status update?

On an agreed rhythm, usually weekly for a sponsor, and immediately when the state changes: the color moves, a new risk appears, a blocker crosses its threshold, a decision is needed, or confidence in the date changes. Do not send a daily update by habit when nothing changed.

How do I report a project at risk without sounding negative?

Report the evidence, not a mood, and attach a decision to it. "Amber: the path has not run on the oldest supported build; the test is Thursday; I need a scope decision by Wednesday noon" is a plan. "Things are looking a bit shaky" is a feeling. Name the risk, not a team, and keep each team's finished work intact in the same update.

Should I report amber if I think we can still recover?

Yes. Amber is not a prediction of failure; it says the outcome is not proven yet. Reporting it early, with the evidence that would turn it green and the date of that evidence, gives the sponsor time to choose. Holding green until you are sure turns a planning input into a surprise.