An independent test group runs a 340-case regression pack after each two-week freeze, and defects reach authors nine days later. How would you change that?

## Read the symptom before naming the cure Nine days between writing a behaviour and hearing it is wrong is an **over-the-wall** pattern, and the instinct — dissolve the group, embed everyone — is the wrong first move. It discards concentrated skill you will need and answers a question you have not asked yet: *where do the nine days go?* Break the interval into segments and measure each for a few cycles: time from a change merging to the freeze; freeze to a testable build existing; build to an environment being available; environment to the 340 cases finishing; finish to a defect being triaged and assigned; assignment to the author having time to look. In practice these are wildly uneven. If seven of the nine days are waiting for the freeze window, embedding a tester changes almost nothing and cadence is the problem. If four days are environment provisioning, the fix is infrastructure. If the pack itself takes three days because much of it is executed by hand, the fix is in the pack. Reorganising people is expensive and slow; find out first whether people are the constraint. ## Why nine days costs more than nine days A defect that arrives nine days late lands on code the author has already changed, in a mental context they have lost, sometimes on top of two more changes to the same path. Take a quote engine for insurance policies where a retried submission wrote the applicant's quote record twice. Found within an hour, it is a small correction by the person who just wrote the retry path. Found nine days later, after the path has been touched twice more, it is archaeology: which change introduced it, does the later change already mask it, is anything downstream already counting duplicates. The same defect costs several times more to fix at the far end of the loop — the direction of that effect is uncontroversial, though the frequently quoted order-of-magnitude multipliers are contested and should not be recited as fact. ## Changes worth making, in order **Split the pack by feedback budget.** A 340-case pack is not one artefact. Identify the subset that is fast, deterministic and covers what actually breaks — typically a modest fraction — and make it run on every change before merge, owned and fixed by the delivery team. What remains is the slow, the cross-team and the genuinely manual, and it stays with the group on the longer cycle. This single move usually recovers most of the latency without touching the org chart. **Give the team the environment.** If the team cannot get a build into a realistic environment without filing a request, the queue is guaranteed regardless of who owns testing. This is often the cheapest large win. **Embed testers into the delivery teams.** Move one or two testers in permanently, so their work starts before code exists — shaping cases, arguing about the requirement, working alongside the author on the risky path — rather than executing after it. Do this after the previous two moves, not before, because embedding a tester into a team that still cannot build or deploy just relocates the waiting. **Keep the group, change its remit.** Do not dissolve it. It holds the deep exploratory skill, the cross-team scenarios that no single team can construct, and whatever independent pass a regulator or a customer contract requires. Give it an enabling remit as well: tooling and data design the teams cannot build alone, technique coaching, and a peer community for the now-scattered embedded testers, who otherwise become the only tester in the room with nobody to learn from. **Change what each side is measured on.** This is the structural root. While the group's success is defects found and the teams' success is features shipped, both are behaving rationally and the wall regrows however you seat people. Measure both on the delivered outcome — escaped defects and the interval from change to feedback — and the incentive to throw work over disappears. ## Sequencing and honesty about risk Do it incrementally and prove it on one team first. Running the reduced loop alongside the existing freeze for a couple of cycles tells you what the fast subset misses, and that evidence is what convinces the people whose job you are changing. Say the risks plainly: the fast subset will miss things at first, and you need a route for those escapes back into it; skill spread thin can mean nobody is expert, which is what the enabling remit is for; and the group's members are being asked to give up the part of the role they may most identify with, which is a change-management problem, not a logistics one. The measure of success is not the org chart. It is the interval from a change being written to someone competent judging it, and whether it is still falling three months later.