Why Test Quality Breaks Down Once a Team Passes Thirty Engineers

A head of quality at a thirty person company will usually describe the last two months the same way. The same bug came back twice, once reported by support and once by a customer on a call. Two engineers argued for ten minutes about whether a screen was supposed to show a discount before or after tax, and neither one was wrong, they just remembered different meetings. Someone asked whether a test case for the refund flow was still accurate and nobody in the room could say for sure. None of this looked like a crisis. It looked like Tuesday. This post names the mechanism behind all three symptoms, says plainly why the number thirty is a rough marker and not a law, and gives a priority order for what to write down first once a team notices it has crossed the line.

The mechanism: shared memory has a size limit

Small teams do not need documentation to stay coordinated, because the team itself is the documentation. Ten engineers who sit near each other, ship together, and argue about the same product every week end up holding a consistent, if unwritten, model of what "working" means. Nobody wrote down that refunds should show the pre tax amount, but everyone in the room was there when it was decided, or close enough to someone who was.

That shared model has a capacity limit. Below roughly thirty people, most of a team can still plausibly have been in the room, or two conversations away from someone who was. Above it, that stops being true. New engineers join without the history. Old engineers move to different parts of the product and stop refreshing what they knew. The team is still full of smart people who care about quality, but the thing they all used to hold in common no longer fits in anyone's head, let alone everyone's.

At that point, something has to carry the memory that people can no longer carry themselves. In most teams, whether they intend it or not, that something ends up being the test suite. A written test case does not forget which meeting settled the tax question. It just says what should happen, and it says the same thing every time someone reads it.

The symptoms a team notices first

The mechanism is abstract, but the symptoms are not, and they tend to arrive in a fairly recognizable order.

• A bug that was already fixed once comes back, because the person who fixed it left, or moved teams, and nobody else knew it had been an issue before.
• Two engineers disagree, in good faith, about what a feature is supposed to do, and both can point to a real conversation as their source.
• Someone asks whether a test case, or an assumption baked into a test, is still true, and the honest answer is "probably, but nobody has checked in a while."

Any one of these on its own is a bad week. All three showing up in the same month is usually the first real signal that the team has crossed the line, whether or not headcount says exactly thirty.

Why thirty is approximate, and what actually moves it

Thirty is a useful marker because it is where the pattern shows up often enough to be worth naming, not because anyone has run a study proving it. Teams should treat it as a rough zone, not a threshold with a specific headcount attached, and a few factors push the real number up or down for any given team.

• Turnover rate: a team that loses and replaces a fifth of its engineers every year hits the wall earlier, because fewer people carry the original context forward.
• Product count: a team of thirty split across one product holds shared memory further than a team of thirty split across four products, because the group that needs to agree on any one product is effectively smaller.
• Co-location and overlap: a team where most people work the same hours and talk daily can push the limit later than a team spread across time zones with little synchronous overlap.

A team of twenty in an early, single product stage might already be feeling this. A team of fifty with low turnover and one focused product might not feel it yet. The number is a description of a pattern people keep noticing, not a researched line in the sand, and this post is not claiming otherwise.

What to write down first

A team that has just noticed the symptoms does not need to document everything at once, and trying to is how documentation efforts stall out in week two. The useful order is narrower than most teams expect.

• Start with the flows that have already caused a repeat bug or a disagreement, since those are proven gaps rather than guesses about where gaps might be.
• Next, write down the cases where "working" is a judgment call rather than an obvious pass or fail, like the tax display question, because those are exactly what shared memory used to carry and what a new hire cannot infer from the code.
• After that, cover the paths a customer would notice immediately if they broke, even if they have never actually broken, because the cost of being wrong there is highest.
• Only once those are solid does it make sense to work outward toward less critical or less ambiguous areas.

Writing test cases in this order gets a team most of the benefit long before the documentation is anywhere near complete. It also gives the team a concrete artefact it can point new engineers to instead of asking them to sit in on six months of old meetings. A test case management pillar is worth reading next if this is the point a team has just reached, since it goes further into how to structure and maintain that record over time.