Go/no-go readiness without greenwashing

Go/no-go fails when readiness becomes a performance. Every metric on the slide is green, every risk sits in a footnote, and the meeting takes ten minutes because nobody has been given anything to decide. Then the release meets production and the footnotes turn out to have been the important part.

I call this greenwashing: making a release look readier than the evidence says. It is rarely dishonest. It comes from people rounding up under date pressure, one cell at a time, until the summary no longer describes the build. Product and Engineering deserve an honest call, and the go/no-go meeting is the final chance to give them one.

What a go/no-go meeting is for

A go/no-go meeting exists so that the people who can accept risk do so knowingly. It is a decision, taken by named people, about a specific build. QA does not make it. I bring the evidence and a recommendation. Product, Engineering and the business owner decide, because they carry the commercial and operational consequences.

That only works if the reading happened beforehand. I send the readiness note the day before, written the way I describe in Release readiness people can actually read, so the meeting can spend its time on what is open and not on a tour of what passed.

How risk gets hidden in release readiness

Greenwashing has a smell. These are the forms I look for, in my own notes as much as in anyone else’s.

The last row is the hardest to catch, because absence does not look like anything. A report organised around what was tested will never show what was left out. So I organise mine around the user journeys that changed in this release. For each one I state what was exercised, on which environment, with what data, and what remains open. A journey with nothing written against it is then a visible gap. Numbers support that narrative. They do not replace it.

How I run the go/no-go meeting

1. Open with the recommendation. Ship, wait, or ship with conditions, and the reason in one sentence. People should be arguing with it, not waiting for it.
2. Walk the changed journeys. Not the test cycles. For each journey: exercised or not, where, with what data, what is open.
3. Take deferred risks one at a time. Each is read out as what the user will experience, how often, and what the workaround is. Someone with the authority says they accept it, or does not.
4. Say what is not known. Areas left out of the regression scope, environments that differ, integrations checked only against a stub.
5. Agree who watches what after go-live. Named people, the first hours, and the signal that would trigger a rollback.
6. Record the decision. Who decided, on which build, with which conditions, and any dissent.

The third step is where the meeting earns its time. A business owner cannot accept a ticket number and a severity. They can accept a sentence about what a customer will see and what Support should say when the customer calls. I hold deferrals here to the standard I use in UAT: a named risk, an owner, a review date. Verbal acceptance that is not written down will be remembered differently by everyone in the room.

By the end, three people should be able to answer for themselves. The Head of Engineering: is Friday wise? Product: what will users feel? The business owner: what have I just agreed to carry?

When the room wants green

The pressure is predictable. The date is public, and an amber line in the note feels like an accusation. I hear two things. One is that the note makes the release look worse than it is. The other is a request to move a defect down a severity so the exit criteria pass.

To the first: the note describes the release as it is, and shipping with known risk is a perfectly good decision. Most releases go out that way. What I will not do is describe the risk as absent. To the second: severity describes user impact, and it changes when the impact changes. If the business wants to ship with a serious defect open, the honest route is to accept it by name in the meeting. Relabelling it only removes it from the conversation.

A no-go needs the same discipline. The meeting is not finished until it has said what would turn the answer into a go: which fix, verified how, by when. A “no” without a path moves the same argument to next week.

Good go/no-go work feels slightly uncomfortable, because it names what we do not know in front of people who would prefer not to hear it. That discomfort is cheap. The expensive version is a holiday incident, with half the team away, that traces back to confidence nobody had the evidence for.