Your QA Process Has an Office in a Building You Moved Out of Five Years Ago

Companies usually worry about processes that are too small for them. Nobody warns you about the opposite problem.

But it happens constantly, especially in the wake of layoffs, pivots, and acquisitions. A team shrinks from sixty to fifteen, or a startup gets acquired and inherits the parent company's quality playbook — and suddenly five engineers are navigating a release process designed for five hundred. The bureaucracy doesn't shrink with the org chart. It just keeps meeting, week after week, guarding gates that no longer guard anything.

Here are five signs your QA process was designed for a company roughly twice your size — and what a right-sized version looks like.

Sign 1: A Release Requires a Sign-Off Meeting That Could Have Been an Email

If releases wait on a formal go/no-go gathering where a room (or a Zoom) of people who haven't touched the code listen to a summary of testing, you've got enterprise ceremony without enterprise stakes.

The right-sized version: replace the meeting with an automated release checklist — CI green, smoke tests passed, open blockers reviewed asynchronously in the release ticket. Sign-off becomes a comment, not a calendar invite. Reserve synchronous discussion for genuinely risky releases, which for a lean team should be a short, identifiable list, not everything.

Sign 2: Test Cases Live in a Spreadsheet Nobody Under 40 Has Opened

Somewhere there's a 900-row test matrix, last meaningfully updated two product pivots ago, that new QA hires are told to 'work through.' Rows reference features that were sunset in 2022.

The right-sized version: your test documentation should live next to your code. Acceptance criteria in the ticket, executable checks in version control, and a thin exploratory charter for what automation can't cover. If a manual test case can't be traced to a feature that currently exists, it graduates to the recycle bin — ceremonially, if your team needs closure.

Sign 3: Every Bug Gets a Triage Meeting With a Quorum

Severity matrices, priority committees, a weekly bug council where engineers argue P2 vs. P3 for a typo in the footer. This made sense when hundreds of people touched the product and nobody had full context. It's friction when the person who wrote the bug is three desks away.

The right-sized version: two-tier triage. Anything blocking or customer-visible gets handled same-day by whoever sees it, no meeting. Everything else lives in the backlog with a default priority that the product owner adjusts in batch, weekly. Most bug debates at small scale are two people who could just fix it in the time the debate takes.

Sign 4: You Have a QA Team as a Separate Department, and a Wall Between Them and Engineering

The classic assembly line: engineers toss builds over the wall, QA finds problems, tickets bounce back, everyone resents everyone. This model exists to protect large orgs from chaos — but at lean scale, it mostly protects engineers from learning what broken software looks like.

The right-sized version: quality as a role, not a department. One or two people with deep testing expertise embedded in the product squad, paired with engineers who own automated tests for what they ship. Small teams can't afford the handoff tax; the good news is they don't need to pay it.

Sign 5: Your Regression Suite Takes a Day and a Half, So It Runs 'When We Can'

A regression pack built for quarterly enterprise releases, now run 'before big launches' by one patient contractor. Because it takes so long, it runs rarely; because it runs rarely, it fails in big scary batches; because it fails in batches, nobody trusts it enough to fix it. The suite has become a museum.

The right-sized version: invert the pyramid, aggressively. A lean team should be able to run its core regression suite in under fifteen minutes on every pull request. That means ruthless pruning — delete tests that haven't caught a bug in a year — and pushing coverage down into fast unit and API-level checks. A slow suite you run sometimes is worth less than a fast one you run always.

The Underlying Question

Every one of these signs is the same disease: process built for coordination cost you no longer have. Enterprise QA bureaucracy exists because at scale, you can't trust everyone to talk to everyone. At fifteen people, you can — so the process should spend its complexity budget on automation and risk-based coverage, not on meetings that simulate oversight.

Audit your process by asking one question of each ritual: if we deleted this tomorrow, what concretely breaks? If the honest answer is 'a meeting gets cancelled,' you've found your first candidate. The goal isn't less rigor — it's rigor aimed at your actual risk profile instead of the one your org had three reorgs ago.