Ask how to structure QA and the answer comes back as a ratio. The ratio is the wrong unit. Whichever of the three structures a team picks, one seat has to exist first: a named person who reads every incoming report and says what it is. Leave that seat empty and the structure fails at any headcount.
The ratio question hides the seat question
The question arrives as a number because a number is what a hiring plan needs. A founder with six developers wants to know whether the seventh hire is a tester. An engineering manager with three squads wants to know whether each gets a QA engineer or they share one. Both are asking how many, and the honest answer is that the count matters less than a job nobody has put on the org chart.
That job is reading. Every team, whatever its structure, produces a stream of reports about things that are wrong: from developers, from a tester if there is one, from support, from a client on a preview link, from a founder on a phone at the weekend. Somebody has to open each one, decide whether it is a defect or a request or a duplicate, decide how bad it is and how soon it matters, and hand it to the person who will act. That is bug triage, and it is the work the three structures distribute differently. It is also the work a ratio does not count, because a hiring plan assumes it happens in the gaps.
It does not happen in the gaps. A report nobody has read is a report that has been handled by nobody, and a queue of them is the state most teams are in when they ask the structure question.
Three structures, and where each one drops the report
The three usual answers, and the sentence each one leaves unfinished.
| Structure | Who finds defects | Who reads incoming reports | Who fixes | Where the report gets dropped |
|---|---|---|---|---|
| Central QA team | Testers, on a plan, before release | The QA lead, for everything | Whichever developer the lead assigns | Between QA and the squad: the lead reads it, the squad receives it after a hand-off, with the evidence older than it was when found |
| QA embedded in each squad | The squad’s tester, alongside the work | The squad’s tester, for that squad | The squad | Between squads: a defect found by two squads is read twice, or by neither because each assumed the other owned it |
| Developers own quality | Developers, through tests and review | Nobody named | Whoever wrote the code, if they see it | Anything from outside the team: a client’s report or a support ticket lands on a board with no reader |
Every row drops something, which is why the last column is there. A central team is slow across the boundary and reads well within it. Embedded QA reads fast and cannot see across squads. Developer-owned quality finds what its tests were written to find and has no answer for the report that arrives from outside.
The row to fear is the third, because its gap is invisible. A central team that is slow produces a visible backlog. Embedded testers who miss a cross-squad defect produce an escaped defect with two squads pointing at each other. Developers who own quality and have no reader produce a board nobody watches, and the reports on it are not late, they are unread until a customer asks.
The first hire is a reader, whatever the structure
So the first decision is who reads, and the structure follows. In a central team that is the lead, and it is a full job at any size that justifies a team. In an embedded model it is one person per squad, plus a rule about which squad reads a report that names no squad. In a developer-owned model it is a rota, and the rota has to be written down, because a reader who is “whoever is free” is nobody.
The reading has a shape, and the shape is what a board should enforce. A report lands in a received state where nothing has been decided about it. The reader then decides two things separately: how bad it is, which is a property of the defect, and how soon it matters, which is a property of the release. Severity and priority get conflated into one field on many boards, and conflating them is how a cosmetic defect on the pricing page gets fixed before a data-loss defect in the admin screen: the first was loud and the second was quiet. A board that keeps them as two fields, and that opens every report in Received before anyone has moved it, gives the reader a queue that is honest about what has and has not been read.
The count follows from the reading. A reader who cannot clear Received in a working day is a reader who needs another reader, or a team that needs fewer reports, and either is a better basis for a hiring decision than a ratio copied from a company of a different shape.
Developer-owned quality still needs a reader
Developer-owned quality is the structure a small team ends up with by default rather than by decision, and it is a good structure for the defects it was built for. A build verification test in the pipeline stops a broken build reaching anyone. A definition of done that includes tests and review catches most of what a developer can anticipate. What it was not built for is the report from someone who is not a developer.
Those reports come from three directions. Support forwards a customer’s message. A client on a preview link writes “the form does not submit”. The founder, on a phone at the weekend, sends a screenshot to a chat channel. In a developer-owned structure with no reader, each of those goes to whoever saw it first, which means the loudest channel wins and the quiet ones are lost.
The fix has two parts. The first is the reader from the previous section, on a rota, with the board as the only place reports are allowed to land, so that the chat channel and the forwarded email stop being queues of their own. The second is making the outside reporter’s report readable on its own: a client who files from the page instead of from an email sends the console lines and the failed request along with the complaint, and the reader classifies it in one sitting instead of opening a thread. A reporter portal closes the loop from the other side, so the client who filed it can see it was read and moved, and stops filing it again through a second channel.
None of that requires a tester, and the seat can be held by a developer. What it cannot be is unheld.
Triage is one named person per week
The limit is that triage is a decision, and a decision made by a committee or by a tool is not made. A team that “all watches the board” has a board nobody reads, for the same reason a group email gets no reply. The reader for a given week is one person, named, and that name is the structure. Everything else, central, embedded or developer-owned, is a decision about where the readers sit and how many there are.
The rule has a cost in each model. In an embedded model the same defect found by two squads is read twice, and the only cure is a reader who scans across Received for duplicates, which is a small piece of central QA reappearing inside the embedded model. And in a founder-led company the founder is the reader by default, which works until the founder is in a fundraising week and the queue stops moving. The first structural change most small teams need is to move the reader’s seat off the founder and onto a written rota, and that change costs no headcount at all.
