Small teams, fewer meetings, more questions

Most of what I've read about working in small teams is written by people who want to eventually work in large ones. They treat the small team as a phase, something to survive or optimise until the headcount justifies a proper process. I don't think that's the right frame.

Small teams have properties that large teams can't replicate, and trying to import large-team process into a small team usually destroys the thing that makes it work. Understanding what those properties are is more useful than treating them as temporary.

Fewer meetings doesn't mean less communication

In a small team, the standup is often a conversation. The planning session is often a decision made in a message thread. The retrospective is often two people talking after something went wrong. None of this is scheduled, and all of it works, because the cost of starting a conversation is low when there are five people and not fifty.

What you lose with fewer meetings is the appearance of coordination. What you keep is the actual thing. In my experience, a small team with a clear shared understanding and low communication overhead ships faster and with fewer surprises than a large team with an elaborate process designed to compensate for the fact that no one actually knows what anyone else is doing.

Questions are the process

In a large team, the ticket is supposed to have all the information. In a small team, the ticket is often a starting point. The expectation is that you'll ask the questions the ticket doesn't answer, because the person who wrote it is right there and would rather answer a question than have you build the wrong thing.

A small team treats questions as part of the work, not as evidence that the work wasn't specified correctly.

This is a cultural thing more than a size thing, but small teams tend to have it by default. There's not enough distance between people for a question to feel like an escalation. You ask, you get an answer, you move. The whole thing takes three minutes and saves three days.

The thing that doesn't scale, and why that's fine

What doesn't scale in a small team is the shared context. Five people can hold the whole system in their heads collectively. Fifteen can't. At some point you need documentation, ownership boundaries, on-call rotations, architectural decision records. The small-team ways of working stop being sufficient.

"Doesn't scale" is only a problem if scaling is the goal. For a lot of teams, it isn't. And even when it is, the transition point is later than most people think. The impulse to introduce process before the team is large enough to need it is almost always a mistake. It adds the overhead without providing the benefit, and it makes the team feel bigger and slower than it is.