Your team has stopped trusting red builds because most failures turn out to be flakes. How do you fix that?

## Name the failure correctly The visible symptom is a team that re-runs first and reads second. The underlying failure is that the pipeline's verdict has stopped carrying information, and people have adapted rationally to that. This is normalisation: the deviation becomes the working method, and it is not fixed by asking people to be more diligent about failures that are usually meaningless. Diligence is not the scarce resource — signal is. The cost lands in three places. Engineering hours go into re-running and re-reading. Release cadence slows while runs are repeated. And, most expensively, genuine regressions get discounted along with the noise. Consider a 340-case nightly regression pack for a utility billing run, taking about 47 minutes, where roughly nine cases were known to fail sometimes and always passed on re-run. The team's habit became: re-run the pack, then look. A currency-rounding drift of a hundredth of a unit surfaced in that pack and was absorbed by the habit; it reached invoices weeks later. The suite had done its job on the first night. The trust deficit is what made that irrelevant. ## Move 1 — state what red must mean Write down the obligation: a red result on the blocking gate stops the line and someone owns it before anything else proceeds. That standard is only credible if it is achievable, which is why it is stated over a *scope you can defend* rather than over everything at once. ## Move 2 — preserve one signal people believe The instinct under pressure is to make the whole suite non-blocking until it is clean. That reliably fails: an advisory suite is one nobody reads, its failures become nobody's work, and the instability rots in place while genuine regressions accumulate unnoticed. The better move is a carve-out — identify a subset you can stand behind, make that the blocking gate, and hold it to the standard absolutely. A small trusted gate beats a large ignored one, and it gives the cleanup a target to grow rather than a hole to climb out of. Moving unstable cases out of the blocking path is a legitimate tool here, but on its own it only relocates the problem; the trust comes from what remains blocking, not from what was moved. ## Move 3 — stop the inflow before draining the backlog Cleanup without an inflow control is a treadmill, and the team will notice within a quarter. Inflow control is mostly about what authoring a case costs by default: * seams so any case can control time, randomness, identifiers and ordering without heroics; * per-case isolation and cleanup as the default the harness provides, not a discipline each author reinvents; * an expectation at review that a new case names what it waits on and what it controls; * exercising new cases repeatedly before they are allowed into the blocking path, so an unstable one is caught while it is still one team's problem. ## Move 4 — fund it as work, not goodwill Unstable cases are defects, and defects that live in a backlog labelled "when someone has time" do not get fixed. Give the effort named owners, a place in the plan, and enough capacity that the backlog visibly shrinks — visible progress is itself part of restoring belief. Expect to make a call about cases whose cost exceeds their value; the decision to remove coverage is a real one and should be made deliberately, with an understanding of what was covered, rather than by whoever is annoyed at midnight. ## What to refuse * **Blanket automatic re-runs** to make the pipeline report green. They convert a visible problem into an invisible one and let genuinely intermittent product defects pass the gate. * **Turning everything non-blocking** with no end date and no replacement signal. * **Exhortation** — asking people to read failures more carefully while the base rate of meaningless failures stays where it was. * **Declaring victory on green.** Green with re-runs is not trust. ## How you know it worked Judge by behaviour, not by colour. Does a red result on the gate get investigated rather than re-run? Do engineers cite a failure in review as evidence? Does the team stop asking whether the failure is "real"? Those are the observable signs that red carries information again. Pair them with the incidents you no longer have: escaped defects that the suite had actually caught are the strongest argument you will ever make for the investment, and the one that unlocks capacity from people outside the team. ## What interviewers listen for They want the tradeoff owned out loud: what you block, what you tolerate, what it costs, who pays, and what you refuse to do to reach green. An answer that reaches immediately for automatic re-runs or for making the suite advisory has optimised the colour and abandoned the signal.