Key takeaways
  • A Quality Piece owns prevention, not policing. The cost of catching bugs late is exponential.
  • Startups defer it and pay later; scaleups hit a wall; enterprises need it sharper still.
  • It isn't just "more testers". It's process, risk and release confidence.

Every product team in history has said the words "we'll add tests later" at some point. The question isn't whether the team said it — the question is what eighteen months later looks like. Most teams that come to us for The Quality Review found out the answer the hard way: a release that scared everyone, a bug that escaped to a customer, an audit that surfaced what the team already half-knew.

This is the fourth in our five-piece series on the Core. N°26 was the CPO; N°27 the PM; N°28 the PO. This one's about the seat your function probably treated as optional, until it wasn't.

What the Quality Piece actually does.

The Quality Piece is the senior seat that owns quality. Not the person who tests things, but the person who designs the discipline that makes the team good at preventing bugs in the first place. Strategy, not execution. The QA testers, the automation engineers, the CI checks, all downstream of the Quality Piece, all working better because there's a senior practitioner setting the bar.

What they own, in practice: the test strategy (where coverage lives, what gets automated, what gets manual), the prevention culture (code review standards, definition of done, pre-merge checks), the toolchain (CI, test runners, observability into production), and the release confidence model (what gets shipped, when, by whom, with what evidence). At enterprise scale, they also own audit-ready quality records and regulatory test traceability.

Why this is so often the missing piece: most teams treat quality as an activity (we'll add tests; we'll do QA) rather than a function (someone owns the discipline). The activity model means quality is whatever the most stressed engineer has time for. The function model means there's a senior bar that doesn't move when delivery is hot.

Diagram · Cost of a bug, by where you catch it
Cost of a bug, by where you catch it A bar chart showing the relative cost of fixing a software bug as a function of where it's caught in the development lifecycle. The bars grow exponentially from left to right. Dev (whilst coding) costs 1 times. Review (pre-merge) costs 2 times. QA (in test environment) costs 5 times. Staging (UAT or pre-prod) costs 10 times. Production (found by internal team) costs 30 times. Customer-reported in production costs 100 times or more — shown as a marigold bar with an ink border to emphasise the impact. The cost of finding a bug late compounds exponentially. The Quality Piece's job is to move the catch as far left as possible. RELATIVE COST Dev 1× whilst coding Review 2× pre-merge QA 5× in test env Staging 10× UAT / pre-prod Production 30× team finds it Customer 100×+ customer reported it cost compounds exponentially →
A bug caught while the engineer is still typing it costs 1×. The same bug, found by a customer in production, costs 100× or more: in dev time, support load, trust, and sometimes revenue. The Quality Piece's job is to move the catch left.
Quality isn't a tooling problem. It's an ownership problem. Buy the discipline; the tools follow.

Why startups defer this, and when it costs them.

Pre-product or early MVP, deferring formal quality is rational. You're shipping to learn, not to scale, and over-engineering test coverage on code that's about to be deleted is waste. Most early-stage teams should have unit tests on the parts that matter, sanity-check the rest, and ship.

But there's a window, usually somewhere between first paying customers and Series A, where the "we'll add tests later" decision starts costing money. Bugs in front of paying users. Engineers spending Friday afternoons firefighting instead of building. A founder who can't enjoy a holiday because the on-call rotation is them. That's when a Quality Review Set Piece (1–2 weeks) earns its keep: an honest audit, a risk register, and a 90-day plan that respects the team's velocity while raising the floor.

Why scaleups hit a wall here.

This is the most common entry point for the Quality Piece. The team has been shipping for a year or two. Engineering is 8–25 people. Customers are growing. Then, slowly, then suddenly: bugs are increasing, releases are starting to feel scary, the support inbox is louder than the product roadmap, and someone said in a retro "we should probably have a QA function."

The fix is rarely "hire some testers." Testers without a Quality Piece become a fire-fighting cost centre. The fix is a senior Quality Piece who designs the function: which tests live where, what gets automated, who owns regression, how releases get cut, where observability lives, and how prevention beats detection. Once the function is designed, hiring testers (or training existing engineers up) actually pays off.

Typical engagement: a Quality Review to assess + plan (2 weeks), then an embedded Quality Piece for 3–6 months to stand up the function, hand over to whoever's next.

Why enterprises need it sharper still.

Enterprise quality isn't optional — it's audited. Regulated platforms (financial services, healthtech, public sector) need quality records that survive scrutiny. AI products need test strategies for non-deterministic behaviour. Multi-team platforms need quality discipline that doesn't fragment across squads.

Two common shapes at this scale. Specialist depth: a Quality Piece with regulated-platform scars. Someone who's lived through an FCA, FDA or SEC audit and knows what the artefacts need to look like. Transformation: the existing quality function is mature but the bar isn't where it needs to be. The Quality Piece resets the standard, leaves the team upskilled, and hands back a function that runs differently.

What the Quality Piece isn't.

  • It isn't a tester. Testers test; the Quality Piece designs the system testers operate in.
  • It isn't a tooling salesperson. No, you don't need to buy yet another test platform.
  • It isn't a release manager. Release management is a downstream operational function; quality is upstream of it.
  • It isn't somebody else's problem. If quality slips and your function doesn't own it, the founder/CEO owns it. That's the worst place for it to live.

How to plug one in.

Start with the Diagnostic. If the answer is a Quality Piece, the natural first move is the Quality Review Set Piece (1–2 weeks, fixed price). From there: embedded Quality Piece for 3–6 months to stand up the function, or interim Head of Quality cover during executive search.

Next issue: the Coaching Piece. Why levelling up beats replacing. Published 9 July.