Every ceremony you added replaced information a smaller team got for free. On-call is the one line item that runs the other way, and it’s the one nobody reads until the exit interview.
We went six months without a single retro.
Nobody declared retros dead. There were two of us, we sat near each other, we had lunch together, and I already knew what was annoying him because he had told me on Tuesday while we were both staring at the same failing build. A meeting to surface that would have been a meeting to tell each other things we had already said.
Then a couple of new engineers joined, and within a few weeks somebody asked for a retro. We started running them. The reflexive read is that the new people brought process baggage with them from wherever they came from.
That read is wrong. They asked for a retro because they genuinely did not know how anyone was doing. That information used to arrive for free, at lunch, in the hallway, in the three minutes before a call started. At two people the channel carried everything the team needed to know. At four it didn’t, and the retro was the first line item on the bill.
I’ve since worked on a team of five with a product owner and a manager who was also running several other teams, and a team of ten with one product owner. Every ceremony we added was the same purchase: a charge for a channel that used to carry the information by itself. Your calendar is an itemized bill for your team size, and it’s the only number you can actually read, because output is hard to see from the inside and easy to lie to yourself about.
Then the pager goes off, and the whole account runs backwards.
the ceremonies are all the same purchase
Every standing meeting on your calendar exists to move information that used to move on its own. The daily moves status, the retro moves how people feel, planning moves shared understanding of what the work is, code review moves knowledge of what changed.
At two or three engineers, all of those channels are already saturated by simply working. You know what the other person is doing because there are only two threads of work and one of them is yours. You know how they feel because you had lunch. You know what changed because you reviewed it, and you reviewed it because there was literally nobody else to do it.
So the meetings feel like theater, and at that size, they are. You can skip the daily outright. Nobody needs a status update on a person sitting four feet away.
What most teams do as they grow is add the ceremonies back one at a time and treat each one as a separate decision. Should we do a daily? Should we retro every two weeks or four? That’s the wrong question. They’re not four decisions. They’re one decision, and it already got made for you when you hired the fifth person.
code review is the line item you can’t see
Meetings are the bill you can see. Review is the expensive one, and it breaks in a way that’s genuinely hard to fix.
On a two or three person team, review assignment is not a question. The PR is yours, so the reviewer is the other person. They’re familiar with the code because they were in it last week. They understand the change because you talked about it before it existed. Nothing sits.
At ten, two separate things go wrong and they compound.
The first is the bystander effect, which is exactly what it sounds like. A PR lands in a channel where eight people could review it, and every one of them assumes somebody else will. It sits for two days. Nobody did anything wrong. Everyone made a locally reasonable decision.
The second is worse, because it looks like a good thing. Teams that size specialize. You get frontend people and backend people, and eventually people who own particular services. Now the pool of people who can meaningfully review a given PR isn’t eight, it’s two. And when a backend engineer reviews frontend code, you get an approval, but you don’t get a review. Nobody is checking the thing that actually needed checking.
There’s a real argument that this is fine, that clear ownership is better than everyone pretending to review everything. I’m sympathetic. But run the vacation test. One of your two frontend people takes two weeks off. Now there is one person on the team who can competently review frontend changes, and if they’re the one writing them, you have zero. On a three-person team that scenario doesn’t exist, because everyone has been in all of the code.
Bigger teams have more people and less coverage. That’s not a paradox once you notice that coverage is about shared context, not headcount, and specialization spends shared context to buy depth.
estimating across code nobody holds
Planning runs on the same account, and once you know shared context is what’s being spent, the mechanism is obvious. On a small team estimation is basically free, because everyone has touched everything and you’re both drawing on the same picture of the system. Scale up and people start estimating work in parts of the application they have never opened. They aren’t wrong, exactly. They just can’t be confidently right, so the conversation has nowhere to land. Two engineers disagreeing about a service they’ve both worked in settle it in a minute with specifics. Two engineers disagreeing about a service neither has touched can go ten minutes on vibes.
five is where the bill comes due
Review and planning are the quiet charges. The daily is the one you actually watch yourself pay. At five or six engineers, the daily starts earning its slot. There’s enough parallel work that you can genuinely lose track, and the part that matters is not the status. It’s the blockers. Somebody says they’ve been stuck on a flaky integration test for a day and a half, and somebody else says oh, that’s the container startup race, here’s the workaround. That exchange is worth the fifteen minutes.
But notice what happened to the meeting itself. Five people each describing what they did, what they’re doing, and what’s in their way is not a fifteen-minute meeting unless someone enforces it. Every person you add makes the meeting longer, and makes the share of it that’s relevant to any given attendee smaller. Those two curves move in opposite directions, which is the whole problem in one sentence.
At ten, they’ve crossed. Person seven is describing work in a service you’ve never opened. The rational response is to half-listen, stay ready for your turn, and get actual work done in the other window. Which is what everyone does. Look around your next ten-person standup and count how many people are typing.
Once a meeting has degraded into „answer quickly when your name comes up, otherwise work in parallel,“ it has stopped being a meeting. It’s a roll call you’re all paying for with a context switch. And the tell that it’s dead is that nobody proposes cancelling it, because it’s part of the framework, and cancelling it would require a conversation nobody wants to have.
That’s usually the signal to split. Not to run a better standup. If the team has grown past the point where one status channel serves everyone, the honest move is two teams with two standups, and if that sounds like it would create coordination overhead between them, it will. You had that overhead already. It was just hiding inside a meeting where seven of the ten participants weren’t listening.
on-call is the one thing that gets better
Everything up to here says small. On-call says the opposite, and it says it loudly enough to overrule the rest.
The mechanism is arithmetic. One person carries the pager for a week. Six engineers means you’re on every six weeks. Ten means every ten. Three means every third week, which is roughly a third of your professional life spent sleeping next to a phone.
How bad that is depends entirely on the system underneath it, and the variance here is enormous. Some systems don’t page at all. Some page once a quarter. And some page constantly, and on those, on-call isn’t an inconvenience, it’s a second job that runs on top of your first one. You’re not building anything that week. You’re doing operations, and you’re doing them tired.
Now put that on a three-person team. Every third week, in perpetuity, with no slack in the system. Somebody gets sick and there’s no substitute. Somebody takes a holiday and the rotation doesn’t absorb it, it just lands on whoever is left. That’s not a process problem you can retro your way out of. It’s a durable, structural way to burn out good engineers, and I’d rate it as the single strongest argument against running teams at two or three.
The workaround is sharing on-call with another team, and it’s a real option, but be honest about the price. It only works with runbooks good enough that someone who has never read your code can diagnose and mitigate your system at 3am. Writing those is real work, it’s the kind of work that gets deprioritized every sprint, and it goes stale the moment the architecture moves. Most teams that say they’ll do this don’t.
So the small-team advantage is real, and it has a floor. Below a certain headcount you’re not running a fast team. You’re running a team that’s fast until the pager goes off.
so what’s the number
There isn’t one, and I’d be suspicious of anyone who gives you one.
The two-pizza rule survives as a rule of thumb, but the reasoning behind it is usually stated backwards. It’s not that large teams communicate too much. Large teams communicate about the right amount for their size. The problem is that the communication has to be scheduled, and scheduled communication is enormously more expensive than the kind that happens because two people were already in the same conversation. That surcharge is the whole difference, and it’s why the answer is a direction rather than a formula.
You cannot measure how much a ten-person team would have shipped as a five-person team. That experiment isn’t available to you. But the calendar is right there, and it’s itemized. Read it on Monday and name what each ceremony replaced.
Then notice which bill you can’t read that way. The calendar one is visible and continuous. It shows up every Tuesday, everyone feels it, and it’s easy to complain about, so teams over-correct toward small and feel efficient doing it. The rotation bill is invisible right up until it isn’t. It doesn’t arrive as wasted hours in a meeting you can point at, it arrives as attrition, and you read it in an exit interview eighteen months later. That one comes due in people, not in calendar time.
The silence is the whole problem. It’s why teams keep shrinking past the point where shrinking helps, and feel fast the whole way down.