Let me tell you a story you already know. A team ships a product. Quality is tribal. One senior engineer holds the mental model of the whole system in their head. It works, because the team is small and communication is free. Then the company scales. More PODs, more squads, more services, more deploys per day. And the person who held it all together cannot hold it anymore.
This is the 0-1-n quality problem. It is not a tooling problem. It is not a headcount problem. It is an architecture problem at the intersection of process, culture, and engineering discipline. Most organisations confuse the symptoms with the cause and wonder why nothing sticks.
Phase 0 — The Survival Mode
At zero, quality is a person, not a practice. Someone manually tests before each release. Regression is a tab in someone's head. Deployments happen on Fridays because the team is small enough to watch the dashboards over the weekend.
There is nothing wrong with Phase 0. It is the right way to build early. The mistake is staying there.
The tells that you are still at zero even after you have grown: flaky environments nobody owns, a Jira backlog of bugs older than some employees, no consistent definition of done, and an engineering team that still asks QA to "just check it" the night before a release.
Phase 0 feels functional until it suddenly does not. The failure is not gradual. One Friday a deployment kills a production flow that nobody tested because nobody knew it existed. A hotfix goes out at 2am. A post-mortem points to a test gap. Everyone agrees to write more tests. Nothing structurally changes. The cycle repeats.
Quality is not a gate you bolt on at the end of a sprint. It is the structural load-bearing wall you build before anything else goes up.
Phase 1 — The Foundation
Getting to Phase 1 means making a deliberate architectural decision: quality is a first-class engineering concern, not a handoff activity.
Practically, this looks like three things built simultaneously: a test strategy document that the whole team actually reads, a metrics baseline that everyone can see, and a deployment pipeline that cannot merge without meeting quality gates.
The test strategy is not a lengthy policy document. It is a one-page decision log. What do we automate? What do we test manually and why? What does coverage mean on this codebase? What is our acceptable defect escape rate?
The metrics baseline is non-negotiable. You cannot improve what you cannot see. DORA metrics are a good start, but they are output metrics. You also need leading indicators: flakiness rate, mean time to detect, test coverage trend, and escaped defects per release.
What good looks like at Phase 1
- Test flakiness rate across CI pipeline — under 2%
- Mean time to detect a regression — under 4 hours
- Escaped critical defects per release — less than 1
- Critical path automated coverage — 80% or higher
Phase 1 is also where culture change starts. The engineering team needs to internalise that testing is a craft, not a checkbox. That means code reviews include test coverage as a first-class concern. That means QA engineers are embedded in squads from the start of a sprint, not parachuted in at the end. That means the definition of done includes a test plan, not an afterthought.
Most organisations declare victory here and stop. They have automation, they have metrics, they have a pipeline. They think they are done. They are not. They have only built the foundation. The real problem starts now.
Phase n — The Scale Problem
Scaling from 1 team to n teams is not a linear exercise. Every new team adds combinatorial complexity. Cross-team dependencies multiply. Shared services become bottlenecks. Each squad optimises locally and breaks something globally. The quality foundation you built for one team does not automatically replicate to twenty-five.
This is the phase where most quality programmes collapse. Not because the work was wrong, but because it was not designed to scale.
The Three Failure Modes at Scale
Failure mode one — centralised quality
A central QA team becomes the quality police. Every feature routes through them before release. They become a bottleneck, then a blocker, then a resentment point. Velocity drops. Teams start treating QA as an obstacle to ship around rather than a partner to build with. The result is shadow testing, undocumented workarounds, and a QA team that is permanently overwhelmed and chronically undervalued.
Failure mode two — decentralised anarchy
You swing the other way. Every team owns their own quality entirely. No shared standards, no shared tooling, no shared metrics. Each squad builds what works for them. Six months later you have fifteen different testing frameworks, no cross-service integration coverage, and zero visibility at the engineering leadership level. Incidents happen at the seams, which is exactly the place nobody tested.
Failure mode three — platform without adoption
You build a beautiful quality platform. Shared test infrastructure, unified dashboards, centralised reporting. You mandate its use. Teams comply on paper and ignore it in practice. Low adoption looks like tooling failure. It is almost always a change management failure. Engineers adopt tools that solve their daily pain, not tools that solve leadership's reporting problem.
The Architecture That Actually Works
After building quality practices at scale across institutions with hundreds of engineers and dozens of delivery teams, the pattern that works is the same every time. It has three components: a federated ownership model, a thin centralised platform, and a quality index that translates engineering behaviour into leadership-visible signal.
Federated ownership
Each squad owns their quality outcomes. Full stop. They write the tests, they own the flakiness, they own the escaped defects. Central QA does not own delivery quality. Central QA owns the standard that delivery quality is measured against, and the coaching capability to help squads reach it.
This mirrors how the best engineering organisations structure reliability: the SRE model. Central SRE owns the platform and the error budget policy. Product teams own their reliability posture within that policy. Quality at scale works the same way.
Thin platform
The central platform does three things only: provides shared test infrastructure that squads would be stupid to rebuild themselves, aggregates quality signals into a unified view, and enforces the non-negotiables at the pipeline level.
It does not dictate frameworks. It does not mandate test case management tools. It does not review test plans before a sprint starts. The moment a platform team starts doing those things, it becomes overhead instead of enablement.
What the platform actually owns:
- Shared environments with environment-as-code provisioning
- Contract testing infrastructure for service boundaries
- Unified observability dashboard readable by non-engineers
- Pipeline gates with a clear, published policy for what blocks and what warns
- A self-service quality maturity assessment squads can run themselves
Quality index
Leadership cannot read test coverage percentages and make decisions from them. They need a single quality signal per team that aggregates the leading and lagging indicators into something actionable. The quality index does that.
A well-constructed quality index combines: escaped defect rate, release cadence consistency, time to detect, automation coverage trend, and incident rate attributable to test gaps. Weight them by the maturity level of the team. A team in their first quarter of serious quality investment should not be judged against the same index as a team three years into the programme.
The quality index is not a performance management tool. It is a conversation starter. The only useful output of a quality index number is a question: what would it take to move this one point in the next quarter?
What Nobody Tells You
The technical architecture of quality at scale is the easy part. Solve the people problem and the technical parts mostly sort themselves out.
Engineers need to feel ownership, not compliance. The fastest way to kill a quality programme is to design it so that engineers experience quality work as something done to them rather than something they participate in. Every design decision in your quality platform should be tested against one question: does this make an engineer's daily work easier, or does it add friction?
Leadership needs to protect the investment horizon. Quality at scale does not produce visible ROI in a quarter. The feedback loop is measured in years. Technical debt accumulated over three years of shipping fast does not reverse in a sprint. The organisations that build lasting quality culture are the ones where engineering leadership has the spine to protect a multi-year investment against short-term velocity pressure.
Quality is a product problem, not just an engineering problem. Some of the worst quality escapes I have seen were not caused by missing test coverage. They were caused by missing acceptance criteria. A feature shipped with no clear definition of what correct behaviour looks like cannot be tested into quality. Product and engineering need shared ownership of the definition of done from the first line of the user story.
The 0-1-n Framework, Compressed
- Zero — accept that this is where you are, do not be ashamed of it, and treat escape from it as an engineering priority not a QA hire.
- One — build the foundation before you build the features; test strategy, metrics baseline, and pipeline gates as a triad, not in sequence.
- n — federate ownership to squads, build a thin enabling platform, and express quality as a business-readable index that drives conversations instead of compliance.
- At every phase — measure what matters, show the trend, and protect the improvement cadence from the urgency of the sprint.
- The invisible n+1 phase — embed quality into hiring, onboarding, and architecture review so the system regenerates itself without depending on any single person.
The organisations that crack this are the ones that stop treating quality as a department and start treating it as an engineering discipline. It is not about having a QA team. It is about having an engineering culture where quality is the default, not the exception.
That shift does not happen by accident. It happens when someone decides to build it, and builds it like it deserves to last.