It comes up in every third retro. A release went sideways, somebody spent Thursday night reverting, and someone finally says it out loud: "Should we just hire a QA person?" Then someone else — usually whoever used to work somewhere bigger — gives the standard answer: "Google doesn't have QA." Meeting moves on. Same question, next month. This is how to settle it for good: when to hire a QA engineer, and when the no-QA answer genuinely still holds.
Key takeaways
When should you hire a QA engineer? When two or more of these are true: releases feel risky, bugs reach you through customers instead of CI, senior engineers spend more time fixing regressions than building, the regression suite has stopped growing, or AI-generated code volume has outrun your review capacity.
The standard answer is true. It's also doing much less work than it appears to.
The Pragmatic Engineer surveyed how tech companies handle testing, and the finding is blunt: "most teams and orgs at Big Tech have no dedicated QA roles, except for Apple and teams with hardware divisions, like Google and Meta" [C1]. Microsoft retired its SDET role back in 2014 [C2]. As one engineering director at a 4,000-person public company put it: "Developers are responsible for testing and automated testing" [C3]. So if your developers own testing, you're not cutting a corner. You're running the same model as most of the industry's most admired engineering organizations.
But "should we hire QA?" was never the right question. The right question is whether you've crossed the threshold where the model those teams run stops working for yours. Because the model was never "no QA." It was "no QA, plus a lot of machinery", and the machinery is the part nobody quotes in the retro.
Look at what teams actually running dev-owned testing say about how they run it. The companies in the same survey describe their conditions in detail: "We frequently deliver small pieces of software behind feature flags using continuous deployment." "Before merging, we run unit and integration tests – we have a lot of them!" Staging environments before anything touches production. And from a 20-person Series A startup: "Engineers tend to follow Test Driven Development (TDD) and we have production metrics that feed back for engineers to observe" [C4].
That's the real model: small changes behind flags, heavy suites at merge time, staging, TDD, production telemetry closing the loop. The absence of a QA title is the least interesting part of it.
So score yourself against the conditions, not the headline. If you have most of that machinery, dev-owned testing will probably hold for a long time yet. If you have almost none of it and you're pointing at Google's org chart anyway, you've copied the conclusion without the argument.
Add QA when at least two of five signals fire: risky releases, bugs arriving via customers, seniors firefighting instead of building, a regression suite that isn't growing, and AI code volume beyond review capacity. At zero or one signal, dev-owned testing is holding; invest in the machinery instead.
The threshold isn't a headcount or a revenue milestone. It's load: release cadence, product surface, cost of a failure, and lately the sheer volume of code. Five signals tell you it's been crossed:
A QA-services vendor's checklist for the first QA hire — noted, they sell the conclusion — lands on the same signals: paying users, bugs causing real business damage, risky releases, developers fixing regressions instead of building, and "customer support is overwhelmed by preventable issues" [C12].
Two or more of the five, and you're past the line.
Start with a debunk, because the number you've heard is shakier than the slide decks admit. The famous "bugs cost 100x more in production" multiplier traces back to internal IBM training materials from 1981 — not a published, peer-reviewed study. The source conceding this is itself a QA vendor with every incentive to keep the stat alive, and even they admit "the supporting data is thin" [C5]. Retire the slide.
What survives the debunk is the direction. NIST's 2002 work and Capers Jones's data point the same way: later is more expensive [C5]. Modern numbers put shape on it. PagerDuty surveyed 500 IT leaders at companies with 1,000+ employees and found the average incident takes 175 minutes to resolve, with downtime estimated at $4,537 per minute, or roughly $794,000 per incident [C13]. PagerDuty sells incident management, so hold the precision loosely, and your company is smaller, so your number is too. But the shape is the same — incidents cost hours and real money — and customer-impacting incidents in that study rose 43% year over year [C13].
Then there are two quieter bills. The first is senior firefighting time. 23% of developers already report working overtime 10 or more days a month [C6], and 38% say their hours got longer over the past year against 7% who say shorter [C7]. That converts into attrition risk: 52% of developers name burnout as a primary reason peers quit [C6]. When your best engineers spend their evenings bisecting regressions, you're not just losing feature velocity — you're loading the departure spring.
The second is the asset you're not building. Every release shipped without adding regression coverage makes the eventual catch-up bigger. As we put it in the QA buying guide: the pass/fail on this release is a moment; the suite is the asset. Skipping a month of testing doesn't cost you a month — it costs you the compounding.
The obvious pushback deserves a straight answer: yes, better test discipline is the correct first move. It's literally the machinery from the survey companies: suites, flags, staging, TDD [C4]. If you can build that with the team you have, do it. No hire, no vendor, no further reading required.
The threshold is when the people who would write the tests are the same people doing the firefighting. Then both jobs lose: the suite doesn't accrete because everyone's triaging, and triage never shrinks because the suite isn't accreting. At that point you don't have a discipline problem. You have a capacity problem, and no amount of exhortation in the retro converts one into the other.
And before "AI will write the tests" gets offered as the escape hatch: there's a circularity problem. As one testing vendor put it (arguing against its own category's hype, which earns it some credibility), "you cannot use the same AI system to write code and then test it" [C14]. The model that generated the assumptions can't be the auditor of them.
Deciding to hire QA doesn't add QA. It starts a project: the median technical role takes 75 days to first fill [C10], plus $9,000–25,000 in in-house recruiting costs by one staffing firm's estimate [C11]. Meanwhile the signals that triggered the decision keep compounding through every one of those 75 days. The roadmap math on that is in our stalled-roadmap post. By the time your hire starts, the threshold you were solving for has moved.
The dissolve is to stop treating QA as a hiring project. When adding QA is a monthly decision, you no longer have to time it perfectly. Add a QA engineer the month the signals fire — working inside your codebase and environment, under your access controls — and judge the output task by task, with a 3-day task cycle and daily async updates. Keep the role while the signals hold; add or change roles any month, cancel any time when they don't. The full cost math is on the QA cost page.
Count your signals from the list above. Zero or one: the model is holding. Invest in the machinery and re-count next quarter. Or, if a different gap is louder than testing, start with which role to hire first. Two or more: run the cheap experiment before the expensive one. Hand one real release or regression pass to a QA engineer as a one-task Proof of Quality: 15-minute fit call first, then judge what they catch before you subscribe to anything. If it earns the subscription, it's $3,495/month for a single stream, same-day match, first task within 5 business days, and you own all the IP.
Your developers can own testing. Most of Big Tech's do [C1]. The only question worth a retro slot is what it's currently costing them to.
When two or more of five signals are true: releases feel risky, bugs arrive via customers rather than CI, senior engineers spend more time fixing regressions than building, the regression suite has stopped growing, or AI-generated code volume has outrun review capacity. At zero or one signal, invest in test machinery instead.
Not necessarily. Most Big Tech teams have no dedicated QA role, and developers own testing [C1]. But that model assumes machinery: small changes behind feature flags, heavy suites at merge time, staging environments, TDD, and production telemetry [C4]. Score your dev team against those conditions, not the headline.
The famous "100x in production" multiplier traces to 1981 IBM training materials and is poorly supported [C5], but the direction holds: later is more expensive. PagerDuty found the average incident at 1,000+-employee companies takes 175 minutes to resolve at an estimated $4,537 per minute [C13] (smaller company, smaller number, same shape), and senior firefighting feeds burnout — 52% of developers name it a primary reason peers quit [C6].
Yes — better test discipline is the correct first move, and it's the machinery the no-QA companies actually run [C4]. The threshold is when the people who would write the tests are the same people doing the firefighting; that's a capacity problem, not a discipline problem. And AI isn't the escape hatch: "you cannot use the same AI system to write code and then test it" [C14].
The median technical role takes 75 days to fill [C10], plus an estimated $9,000–25,000 in in-house recruiting costs [C11]. A subscription model dissolves the timing problem: add a QA engineer the month the signals fire, judge the output task by task, and cancel when the signals stop holding.
