Ask HN: What breaks first when your team grows from 10 to 50 people?

We're at ~15 people and things that used to "just work" are starting to crack. Decisions that everyone used to know about are getting lost. New hires take forever to ramp up. Different teams are building on different assumptions. For those who've been through this stage, what actually broke first? And what did you do about it?

It really depends on the speed. I went through it in the past few years, and it was too fast. One day I knew everybody in the whole organization, what their responsibilities are, and what they are working on. I turn around and there are more employees than I can ever know.

Every new recruit brings their own assumptions about how organizations / employment / etc. work and many of those assumptions won't be visible until after a while. This is especially true for managers. Charles Handy identified four types of organizational cultures: Power Culture, Role Culture, Task Culture, and Person Culture. Basically, 15>50 is very likely to involve a shift from one of these to another one.

Growing companies from ~10 to ~200+ has been my bread and butter for almost 20yrs now. A few relatively universal observations:

1. Your documentation of processes and procedures is NOT adequate. Document everything early. Notion is your friend.
2. Your work culture is going to change. Define some operating principles (company values) with the first 15 people.
3. Hiring gets expensive and laborious. You're reaching a point where it just isn't practical for you to be involved in every hiring decision.
4. More people means more individual questions, problems, and ultimately admin. Someone needs to be able to handle all of these issues.
5. Reconsider the financial impact of hiring experienced people. Bringing in strong leaders early can enormously mitigate the operational costs of scaling. However, ensure they are a good fit for your company size, not just big-company veterans.

There are breakpoints at multiples of 1, 2, 5 (10, 20, 50...). More formality, more processes, and more tools are needed at each stage. Documentation has to be done once, but it must be updated. It should focus on the 'Why' (architecture, decisions) rather than just the 'How' or 'What', which can often be reverse-engineered from the code or infrastructure.