The Sign-Off Gate That Made Quality Somebody Else's Job
Helios Bank's payments division has 300 developers in 22 squads and a separate QA chapter of 40 testers. Squads push builds to a shared nightly drop; testers run a three-day manual regression pass and hold the only authority to approve a production release. The QA chapter lead signs the release certificate that the regulator inspects. In the last two quarters, developers marked 27% of mandatory test cases 'not applicable' to clear the queue, up from 3%, and testers responded by adding 400 more manual checks. Escape reviews name the individual tester who missed a defect; no developer has ever been named. In a skip-level session, developers said quality was 'QA's problem' and testers said developers 'never read the reports'. Release frequency has fallen from fortnightly to every five weeks, and 60% of tester time now goes to re-testing fixes.
1. Name the cultural anti-patterns in this setup and explain the feedback loop that keeps them in place.
Read the worked answer
Anti-pattern 1: quality as a downstream department. The nightly drop hands a finished artefact to a gatekeeper, so the only quality decision available to a developer is whether the build passes someone else's checklist. This is the structural root of 'quality is QA's problem'.
Anti-pattern 2: blame asymmetry. Escape reviews name testers only. Rational developers learn that defects found later cost them nothing, while testers learn that the safest behaviour is more checks and slower releases. Both behaviours are individually sensible and collectively destructive.
Anti-pattern 3: 'not applicable' as a pressure valve. The 3% to 27% rise is not dishonesty so much as a queue-clearing mechanism created by a gate with no capacity to match demand. Testers answer it with 400 more manual checks, which lengthens the queue and raises the pressure further.
The loop. Separate ownership produces a handoff; the handoff plus a hard gate produces a queue; the queue produces queue-clearing behaviour; the behaviour produces escapes; escapes produce blame on testers; blame produces more manual checks; more checks lengthen the queue. Every actor is responding correctly to their incentives, so no amount of exhortation breaks it. Only changing the gate, the ownership and the blame rule does.
Diagnostic to confirm it. Track where defects are found and who acts on the finding. If developers file few defects against their own code, the loop is confirmed.
2. Design the first 90 days of change. State explicitly what you would stop doing in week one.
Read the worked answer
Week one: stop two things. Stop naming individuals in escape reviews; replace the review with a blameless analysis of which automated check was missing. And suspend the 'not applicable' option for mandatory cases, replacing it with a mandatory reason code reviewed weekly, so the pressure shows up as data rather than as silent erosion.
Days 1 to 30: measurement and pairing. Publish, per squad, defect escape rate and time-to-feedback. Put one tester into each of the four highest-escaping squads as an embedded quality engineer, not as an approver. The goal of the embedding is not more testing but better unit and integration checks written by the people who own the code.
Days 31 to 60: shrink the gate. Replace the three-day full manual pass with an automated smoke and integration gate that a squad can run itself in under 30 minutes, plus risk-based manual exploration of the changed areas only. Target release cadence: back to fortnightly.
Days 61 to 90: move the evidence. Make the release certificate a generated artefact from pipeline evidence with a named product owner signature, and have QA attest to the quality of the evidence rather than to personal confidence.
Success measure. Developers filing defects against their own code, and a fall in the not-applicable rate. Both are leading indicators; release cadence follows them.
3. The regulator requires a named sign-off before release. Should the QA chapter keep the veto? Justify your answer.
Read the worked answer
Distinguish accountability from gatekeeping. The regulatory requirement is for documented, attributable evidence that controls were applied. It is not a requirement that a specific department holds a veto. Many teams conflate the two and then defend the veto as a compliance necessity, which stalls the culture change unnecessarily.
Position. Remove the QA veto and replace it with a signed attestation by the accountable product owner, backed by machine-generated evidence: test execution results, traceability to the regulated requirements, open-defect status with owners, and a change summary. QA's signature moves to attesting that the evidence is complete and trustworthy, plus sampling audits of a proportion of releases. That keeps a genuine independent check without making QA the decision-maker on business risk.
Reasoning. A veto held by people who do not own the code produces exactly the blame asymmetry already observed: the veto holder is accountable for outcomes they cannot control. Moving sign-off to the product owner aligns accountability with authority and makes quality a squad concern by construction.
Guardrail. Do not remove the veto in a single step. Run both signatures in parallel for two release cycles, compare outcomes, and only then retire the QA signature. If evidence quality is poor, the QA attestation is where the veto legitimately lives.