We grew, and the processes are breaking
What worked at fifteen people does not work at fifty. Knowledge that used to travel across a room now sits with one or two people, and everything important queues behind them.
Why does growth break what was working?
Because small teams run on shared context, not documentation. Everyone knows why the exception exists, who to ask, and which rule can safely be bent. That is a real advantage — right up to the point where the people holding the context become a queue.
The failure looks like a process problem and is usually a dependency problem. One person is the only one who can approve, or reconcile, or explain why it was done that way. Nothing was written down because writing it down was never necessary. Then that person takes a holiday.
This is the elephant we call Guru — tribal knowledge and hero culture, where one person is the bottleneck.
What usually goes wrong when a team tries to scale a process?
- The process is documented as it was designed rather than as it is actually performed, so the document is wrong on its first day.
- The bottleneck person writes the documentation, in time they do not have, about work they find too obvious to explain.
- New people are onboarded by shadowing, which copies the habits along with the knowledge.
- The workaround holding everything together is invisible from above, so it is never resourced or replaced.
How do we take the person out of the critical path?
Find the real bottleneck
A network analysis shows who the organization actually depends on, which is rarely who the org chart suggests.
Capture what only they know
We follow the work with them rather than asking them to write it up, so the exceptions and judgement calls survive the transfer.
Automate the rote, coach the rest
The mechanical part becomes a governed workflow; the judgement part becomes a skill more than one person holds.
Sound familiar?
Start with an assessment — people, process and technology, looked at together.