From five to twenty
This is where informal coordination stops working. Add the smallest amount of structure that a repeated failure has already justified, and not one increment more.
Five engineers is one conversation. Twenty is four or five conversations that have to add up, and nobody tells you when the transition happened.
What makes this band hard is that the failures arrive gradually and each one has a local explanation. A decision gets made twice, and that's because Tom was on holiday. Something falls between two people, and that's because the ticket was unclear. Nobody connects them for months, because individually they're all just Tuesday.
The underlying change is that the informal coordination which was genuinely free at five has started costing something, and it keeps costing more.
Add process only after the second failure
The governing rule for this whole band, and the one that separates companies that stay fast from companies that become small versions of the place their founders left.
When something goes wrong, the instinct is to add a rule. Resist it once. A single failure carries almost no information about whether it's structural, and a rule added after one incident is usually a rule that prevents a thing which was never going to happen again.
When the same failure happens a second time, act. Now you know its outline, you can name it, and the rule you write will be about the actual pattern rather than about the memorable instance.
The reason this matters more here than anywhere else: process added at this size compounds for the next decade. Everything you institute now will still be in place at eighty people, being followed by people who've never heard the story behind it. Adding it late costs you two incidents. Adding it early costs you forever.
What genuinely breaks, in order
Memory goes first, around eight. Decisions get made and lost. The fix is that decisions get written down, and this is the point where written-first becomes non-optional. Not a wiki. A short document per consequential decision, in the repo.
Then ownership, around ten to twelve. Things start falling between people, especially the unglamorous ones: the nightly job, the customer-specific integration, the alerting. The fix is a list of every system with a named owning team, and a rule that nothing reaches production without a row in it.
Then onboarding, around twelve to fifteen. The tribal knowledge that transferred by proximity stops transferring, and the fourteenth hire takes twice as long to become useful as the seventh did, which nobody predicts. The fix is that every new hire writes down what confused them and you fix three of those things that week.
Then, somewhere near twenty, prioritisation. There are enough people that not everyone can hold the whole picture, and work starts happening that nobody senior would have chosen. The fix is a visible list of what's being worked on and why, updated weekly.
Four fixes, all cheap, all of them things you can do in an afternoon each. What makes them hard is doing them on time rather than doing them at all.
The first team split
Somewhere around ten to twelve, one team stops working. The standup takes twenty-five minutes, half the people are hearing things that don't concern them, and the natural sub-groups have already formed informally.
Cut on the system, not on the headcount. Find the place where two parts of the product change for different reasons and at different rhythms, and put the boundary there. If you can't find such a place, you're not ready to split, and the honest move is to reduce what the team owns instead.
What you'll be tempted to do, and shouldn't: split into a frontend team and a backend team. It's the easiest cut and it guarantees every piece of customer-facing work requires two teams to coordinate. You'll feel the cost within a month and you'll be living with it for two years.
Expect a real dip after the split. Two months, minimum. The seam has to become an interface and both teams learn where it actually is by being annoyed by it.
Your first engineering manager
Later than you think. Push it as late as you can stand.
The instinct is to hire one when the team hits twelve, because twelve reports is too many for the founder or the lead. That's true as a span-of-control fact and misleading as a decision, because what a first EM actually does is insert a layer between you and the work at the exact stage where your direct judgment about the work is the company's main asset.
The trigger I'd use isn't a number. It's when you can name the specific thing breaking that only a manager fixes: people not getting feedback, hiring stalling because nobody has time to run loops, one-to-ones being cancelled three weeks running. Name it in a sentence that isn't about span of control.
When you do add one, strongly prefer the person already doing half the job to the impressive outsider. Growing a manager from inside is covered in its own lesson, and at this size the internal candidate's context is worth more than an external candidate's experience, most of the time.
The intermediate move that buys you a year: a tech lead who owns the work and the technical direction, with people questions still coming to you. It's a real role, it develops someone, and it's reversible.
What you can still skip
Everything not listed above, and the skipping is the point.
No levels or career ladder. You'll write one when the same fairness argument has come up two or three times, and not before.
No formal performance cycle. Feedback happens in weekly one-to-ones or it doesn't happen.
No sprints, if you can help it. Continuous flow, small batches, a weekly demo.
No platform team. Platform work exists, and it's a rotation rather than a department.
No dedicated QA. Engineers test their own work, and the pipeline catches the rest.
No architecture review board, no change advisory board, no RFC process with stages. One person decides, quickly, and writes it down if it's expensive to undo.
The temptation to add these comes from having worked somewhere that had them, and forgetting that they were solutions to problems that appeared at four times your size.
The one thing that pays for itself
If you only install one thing in this band, install the written decision.
Everything else on the list is recoverable later at moderate cost. Decisions lost in this period are lost permanently, and you'll spend the next three years reconstructing why the system is the way it is, in conversations with people who weren't there.