Where Quality Capability Lives: Team Topologies for Quality Leaders

Composite scenario, built from common patterns; not a real organisation. A mid-sized insurer dissolved its central QA department and "embedded" its fourteen testers across nine product teams. The announcement used the right words: quality is everyone's job, testers are now part of the team, no more throwing builds over the wall. Eighteen months later the head of quality ran the numbers. Escaped defects per release were roughly where they had started. Each team's automated suite had been written almost entirely by its embedded tester. And when one of those testers resigned, her team's end-to-end suite went red within a month and stayed red, because nobody else knew how it worked.

Nothing about the reorganisation was lazy. The testers were good, the teams welcomed them, and the work got done. What didn't happen was the thing the reorganisation was for: the capability never moved from the tester into the team. It lived in a person on permanent loan.

This piece is about where quality capability lives in an organisation, and how to decide deliberately. The vocabulary comes from Matthew Skelton and Manuel Pais's Team Topologies (2019; second edition 2025). Most write-ups of that book are about delivery flow. Read with a quality leader's question in mind (if this person left, what would stop?), it turns into a placement method.

Why embedding looks like the answer

Embedding is attractive because it fixes the visible problem. A central QA team is a queue: builds wait for testers, testers wait for environments, and developers learn that quality is somebody else's stage. Put the tester inside the team and the queue disappears from the board.

What it doesn't fix is ownership. In Team Topologies terms, an embedded tester is a long-running collaboration between two kinds of expertise, and the book treats collaboration as an intense mode that should be time-bounded, because it is expensive and blurs responsibility. When collaboration has no end date, the team settles into a division of labour: developers write features, the tester writes tests. That is a handoff again, just shorter.

The test you can run: for each team with an embedded quality person, list the last ten automated tests merged. Count how many were written by someone other than the quality person. If it's two or fewer, the capability lives in the person, not the team.

The three placements, and what each one means for quality

Team Topologies names four team types. Three of them answer the question "where does this quality practice live?"

In the stream-aligned team. The team that owns the product owns the practice: writing tests, defining acceptance criteria, watching its own production signals. This is where most quality work should end up, because the people who change the code are the only ones who can keep its tests honest over time.

In a platform, consumed as a service. Some quality capability is the same for every team and expensive to build: a test-data service, ephemeral environments, a flaky-test dashboard, contract-test infrastructure. A platform team builds it once, and stream teams use it without filing a ticket. The interaction mode is X-as-a-Service: low bandwidth, a clear interface, no meetings required.

In an enabling team, temporarily. When a team needs a capability it doesn't yet have (property-based testing, performance budgets, testing an LLM feature), an enabling team works alongside it in facilitating mode for a fixed period, then leaves. Success is measured by what the team can do after the enabling team has gone.

The fourth type, the complicated-subsystem team, matters for quality in one specific case, covered under exceptions below.

Behind all three sits the book's central constraint: team cognitive load. A stream team asked to own its product, its pipeline, its test infrastructure and specialist test design at once will drop something, and it is usually the tests. Placement is how you keep the load a team carries within what it can actually reason about.

The test you can run: write down every recurring quality activity in one product area (there are usually twelve to twenty). Next to each, write where it lives today: a stream team, a platform, an enabling team, or a person. Any line that says "a person" is a placement you haven't made yet.

The insurer, placed again

Here is what the head of quality did next, still as a composite. She started from the activity inventory, not the org chart, and asked three intake questions of each activity:

Activity	How often is it needed?	How specialised?	Can it be self-served?	Placement
Unit and integration tests	Every change	Low	n/a, it's the work	Stream team
Acceptance criteria and exploratory testing	Every story	Medium	No	Stream team, coached
Test data for policy and claims records	Weekly, by every team	High (masking, referential integrity)	Yes	Platform
Ephemeral test environments	Daily	High	Yes	Platform
Flaky-test detection and quarantine	Continuous	Medium	Yes	Platform
Contract testing between services	Every interface change	Medium, new to most teams	After adoption	Enabling, then stream team
Performance testing before peak renewal season	Twice a year	High	Partly	Enabling engagement per team

The result was three structures instead of one. Six of the fourteen testers became a quality enabling team of three pairs. Four formed a test platform team that owned test data, environments and the flake dashboard as products with their own backlog. The remaining four moved into the stream teams that needed a permanent specialist, with an explicit brief to make themselves less necessary.

The artifact that made the enabling team work was a one-page engagement charter, agreed with each team before starting:

Engagement: contract testing for the claims service and its three consumers Duration: 8 weeks, ending on a fixed date Exit criteria: (1) every consumer–provider pair has a contract test in CI; (2) at least two developers on the team have each written a contract test unaided; (3) a broken contract has blocked a merge at least once and the team fixed it without help What the enabling team will not do: write the team's contract tests for it after week 3

The third exit criterion is the one that matters. It shows the practice working under real pressure, which a training session can't.

The test you can run: take your most recent quality initiative that involved specialists helping a team. Did it have an end date and an observable exit criterion agreed before it started? If not, it was embedding with a different name.

A documented precedent: Google's Testing Grouplet

The enabling-then-platform sequence has a well-documented precedent. Software Engineering at Google (Winters, Manshreck and Wright, 2020) describes how a volunteer group of engineers, the Testing Grouplet, changed testing culture from about 2005. Its Test Certified programme had five levels, each achievable within a quarter, starting with basics such as setting up a continuous build, tracking code coverage and classifying tests by size. By the time it was replaced by an automated approach in 2015, it had helped more than 1,500 projects improve their testing.

Two things in that history are worth copying. The levels gave every engagement an exit criterion. And once the practices were common enough, Google encoded them into automated project-health tooling. Capability moved from people (enabling) into infrastructure (platform), and the stream teams owned the result.

The test you can run: for each practice your enabling team teaches repeatedly, ask whether a check, a template or a dashboard could carry it instead. A practice taught to its fifth team is a platform candidate.

When the platform becomes the gate

Platforms have a failure mode quality leaders are especially prone to: the test platform turns into a central QA gate under a new name. The test-data service needs a ticket. The environment request goes into a queue. The flake dashboard is owned, but the decision to quarantine a test needs platform sign-off.

DORA's 2024 Accelerate State of DevOps report found that using an internal developer platform improves individual productivity, team performance and organisational performance, but can also reduce throughput and change stability. The report ties good outcomes to platforms designed for developer independence. For a quality platform, independence is measurable: a stream team should be able to get test data, an environment or a quarantine decision without talking to anyone.

The test you can run: count the requests your test platform team handled by hand last month. Each one is a self-service feature that doesn't exist yet. If the count is rising, the platform is drifting towards being a gate.

Trade-offs between the placements

Placement	Gains	Costs	Best suited for	Warning signs
Embedded specialist (permanent)	Fast help, deep product context	Capability stays in one person; handoff returns inside the team	Teams with sustained specialist need, such as heavy regulatory test evidence	Tests written by one person; suite decays when they leave
Enabling team (time-boxed)	Capability transfers; specialists cover many teams	Needs strong coaches; slower than doing it yourself	New practices, step changes in maturity	Engagements extended "just one more month"
Platform (self-service)	One build, many users; lowers cognitive load	Product management overhead; can become a gate	Common, specialised, self-servable needs	Manual requests rising; teams building workarounds
Central QA stage	Independent view; consistent process	A queue; developers disown quality	Rarely, as the default	Release waits on test sign-off

Exceptions: when a separate quality team is right

Some contexts require verification by people independent of the builders: certain safety-critical, financial-control or contractual settings. There, a separate verification team is a control, not an anti-pattern. Treat it as a complicated-subsystem team with a clear X-as-a-Service interface (what it receives, what it returns, how long it takes), and keep developer-owned testing in the stream teams. The independent team adds assurance on top; it shouldn't replace the team's own tests.

The other exception is scale. A two-team engineering organisation doesn't need an enabling team and a platform team. It needs one person who coaches and builds the shared tooling, with the same placement logic applied to their time.

A method for the next quarter

1. Inventory (week 1). List every recurring quality activity in one product area with the people who do it. Output: the table above, with a "lives in" column.

2. Run the departure test (week 1). For each activity, ask what stops if its current owner leaves. Mark anything that stops as unplaced.

3. Place (week 2). Use the three intake questions (frequency, specialisation, self-service) to assign each activity to a stream team, platform or enabling engagement. Agree it with the team leads; placement without their consent becomes a reorganisation.

4. Charter (weeks 2–3). Write an engagement charter for each enabling engagement, with an end date and observable exit criteria, and a short product brief for each platform capability.

5. Review (week 12). Rerun the departure test. Count the activities that still live in a person.

What to do next

This week, run the first test on one team: the last ten automated tests merged, and who wrote them. That number tells you whether your current structure is transferring quality capability or only renting it.

Final takeaway

Team structure decides where quality capability lives, and capability that lives in a person leaves with that person. Put each practice in a stream team, a self-service platform or a time-boxed enabling engagement, and judge the result by what keeps working when the specialists move on.

For the organisational practices that sit on top of this structure, see Quality Engineering as an Organizational Practice. To turn the placement into a written plan, use Building a Quality Strategy from Scratch, and to check whether it's working, track the delivery signals in DORA Metrics: A Framework for Delivery Performance.

Sources

• Skelton, M. and Pais, M. (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution. Second edition, 2025. itrevolution.com/book/team-topologies

• Conway, M. E. (1968). "How Do Committees Invent?" Datamation, 14(5), 28–31.

• Winters, T., Manshreck, T. and Wright, H. (2020). Software Engineering at Google, Chapter 11, "Testing Overview" (history of the Testing Grouplet and Test Certified). O'Reilly. abseil.io/resources/swe-book/html/ch11.html

• DORA (2024). Accelerate State of DevOps Report 2024, platform engineering findings. Google Cloud. dora.dev/report/2024