How Big Should a Team Be: What the Number 6-to-8 Is Buying You

“How many people should a team have” sounds like an HR question. It’s actually the book’s first and most operational piece of systems design. Larson’s numbers are direct: a manager supports six to eight engineers; a manager of managers supports four to six managers.

The numbers themselves aren’t the point. The point is that each band turns you into a completely different kind of manager — and most people only notice their job quietly changed shape long after the headcount went wrong.

6 to 8: what that number is buying

Start with the whole axis. Headcount isn’t a stress test of how many people you can handle; it’s how much time you have left each week for the investment work: coaching, writing strategy, driving change across teams.

Laid out band by band:

Direct reports	What you actually become	The cost
Under 4	TLM (tech lead manager) — still taking a share of design and implementation	Larson says it plainly: it can be a great fit for some people’s strengths, but it’s a role with limited career opportunities. It’s a position, not a stage
4–5	Barely a team	Rotation works, but one long absence empties it out (next section)
6–8	An investor — enough time for active coaching, coordinating, writing strategy, leading change	This is the sweet spot, and not because it’s “manageable”: it’s because the investment work still fits in the calendar
Over 8–9	Coach + safety net — people hit walls, you catch them	Too busy to invest in the team, or in the area the team owns. It looks busy and important, but you’ve stopped changing anything

The row worth stopping on is 9 and up. Its symptom isn’t “someone isn’t getting attention” — that’s obvious enough to get fixed. The real symptom is that you’re busy every day, every ball gets caught, and this quarter you didn’t change a single system. Back to the first post: you’ve become a machine for catching events while the source hasn’t moved an inch.

The lower bound matters more than the upper one

Most discussions of team size only cover the ceiling — “past N people, split it”. Larson also gives a floor, and the wording is harsh: a team of fewer than four is a leaky enough abstraction that it behaves indistinguishably from individuals.

“The abstraction leaks” is exactly right here. You think you’re talking to a team; you’re actually talking to one person. The things the team abstraction is supposed to provide — rotation, absorbing variance, continuing to run when someone is away — none of them exist below four. One person takes leave and the team doesn’t lose 33% of its output; an entire area goes dark.

Larson actually does this arithmetic in the original essay behind this section (“Sizing engineering teams” on lethain.com), and he does it from the rotation: a two-tier, 24/7 on-call rotation takes about eight engineers. In other words, the real floor calculator is the on-call rotation: a team that carries a pager and doesn’t have the people for a rotation doesn’t have a rotation — it has that one person. He takes a holiday, gets sick, resigns, and nobody picks it up. The SRE post covers the mechanics of alerting and on-call, but every one of those mechanics assumes there are people to rotate through; below the floor, the prettiest runbook in the world is a document one person writes for himself.

So a squad of three isn’t a “small team” — it’s one person plus two helpers. That isn’t necessarily bad; plenty of stages look exactly like that and move fast. What’s bad is managing it in the language of teams: team goals, team process, an expectation of team resilience — and then discovering on the day that person resigns that none of it was real.

How teams are born: grow to 8–10, then bud — never create an empty team

So how do you get from one team to two? Larson’s answer is counterintuitive and the logic is tight: grow the existing team to eight or ten, then bud it into two teams of four or five — never stand up an empty team and hire into it.

“Never create empty teams” gets broken constantly at small companies, because naming a team costs nothing: put it on the org chart, open a channel, name an owner, done. But a team is a commitment, not a label — the moment it exists, people start throwing requests into it and counting roadmap work against it, and until it actually hires, its only source of capacity is the team it came from.

The same logic applies to “we’ve got too many people, let’s split into two”. Splitting 8 into 4+4 is budding. Splitting 6 into 3+3 manufactures two groups that behave like individuals, and hands you a coordination boundary you didn’t have before. The question to ask before splitting is never “how many people” — it’s “can these two bodies of work actually move independently?” If they can’t, all you’ve done is convert internal conversation into cross-team conversation, at double the price.

Managerial scope isn’t headcount

Chapter 4 has a section on managerial scope, and read alongside this chapter it corrects a common misconception: growing isn’t asking for more headcount, it’s taking on something more important and more complex.

The practical value here is a route to growth that doesn’t require the org to expand: take the mess nobody wants, take the cross-team coordination, take the system that ends up in the press. Headcount waits for the company to grow. Scope usually just needs you to raise your hand.

One line to keep straight: managerial scope here isn’t the same thing as the “neck width” from The Responsibility Funnel — scope is the area you’re accountable for; neck width is the bandwidth you can responsibly accept. Let the area grow without the bandwidth and you end up signing off on a pile of things you never understood.

The Four-Engineer Version

What this chapter gives a four-person team isn’t a plan to reach 6–8 — you can’t — but three things you can do on Monday:

1. Admit you’re a TLM, out loud. A lead of four has no “leave the production line” option; that isn’t failure, it’s the normal shape at this size. But take Larson’s “limited career opportunities” seriously: a TLM is a position, not a stage that grows into the next one by itself. If you want to grow, the road is scope, not headcount.
2. Buy insurance for the floor. You can’t add people, so patch the leaks in the abstraction another way: at least two people who have touched each area, decisions written down instead of held in someone’s head, a rotation even if it only has two names on it. The goal isn’t to become a real team — it’s to make sure the system doesn’t disappear when one person does.
3. Don’t split the line just to look like an org. Four people split into 2+2 doesn’t give you two teams. It gives you two individuals and a new coordination cost.

Reflection

Four people on the storefront line — right on Larson’s floor

That post about the team did this arithmetic once: six engineers, but the storefront line was really four — a backend lead (me), one backend engineer, two frontend engineers, plus a CTO who wrote no code and did product full time. Every system in the seventeen chapters before it was built by those four.

Measured against this chapter, that setup was sitting exactly on the floor: one person fewer and the team abstraction leaks out completely. And this kind of fragility has one defining trait: you can’t see it on an ordinary day — with everyone in, the team looks like a team; it takes someone going on long leave, or handing in notice, to find out who each area was actually resting on. That’s precisely the insurance the second point of The Four-Engineer Version is buying: at least two people who have touched each area.

What came next: a month after development was paused, the team was three people — me, one frontend engineer, and the CTO. By this chapter’s standard that’s no longer “barely a team”; it’s indistinguishable from individuals.

A TLM is a position scale pushes you into, not a path that climbs on its own

My own arc is recorded in the team post: at the start I was the only backend engineer, and the day the second one joined, I started leading. A lead on a small team has no “leave the production line” option — on top of sustaining high output came three checkpoints: technical breakdown of tasks (the entrance to work), review (the exit of code), and technology choices (the system’s boundary).

Set against this chapter, that job comes very close to what Larson calls a TLM — still sharing design and implementation, while also gatekeeping what the team ships; in other words, the row in the table above marked limited career opportunities. The role arrived together with headcount, and a role that arrives that way comes with a built-in trap: it’s easy to mistake for a path that climbs on its own, as if doing the lead job well were enough for the next level to show up.

The way out this chapter offers isn’t headcount, it’s scope. For the lead of a four-person team, the nearest piece of scope is usually right next door: the other line, the technical boundary between the two, the integration nobody owns. Headcount waits for the company to hand it to you; scope only needs a raised hand.

Splitting the line splits the org — and the information boundary follows

The same post describes the two lines, storefront and bidding, each with their own people and their own PM — and across the seventeen chapters before it, bidding barely appears; the one appearance with a story is secondhand. That post says it plainly: I don’t know the bidding system well. Its reflection has a line of my own on exactly this: “That looked like a natural division of labour at the time, and now it reads as foreshadowing: how the organisation splits is how the system grows, and where the wall is built is where the split line falls.”

Put that line in this chapter’s terms: when you sort people into two piles, you’re also deciding who gets to know what. Conway’s law says the shape of the org ends up in the system; the reverse holds too — the boundary of the org sets the boundary of information, and the boundary of information eventually becomes the boundary between people. People on one line not knowing the other line is the default outcome of that kind of boundary.

So “should we split into two teams” was never just a headcount question; it’s also deciding whether these two areas will talk only through meetings from now on. One question worth asking before the split: afterwards, will the two sides still read each other’s code? If not, the boundary costs more than one re-org — headcount will keep growing, but a boundary, once up, is very hard to take down.