What Breaks as a Company Grows: From Owner-Run to Corporate
Growth is a staircase, and the same thing breaks on every step: the capacity of informal coordination. Reading the transition from three desks at once.
At one point in my career I joined a company in the exact middle of a year it was passing through. By “the exact middle” I mean this: the old speed was gone, and the new system hadn’t arrived yet.
You could no longer ask the owner about something and get an answer in five minutes — a manager had appeared in between, and a form along with him. But the form didn’t work either, because nobody was reading it. So the uncertainty of the owner-run company was still there, and the slowness of the corporate had been layered on top of it. People were living the bad half of both worlds and neither good half.
Everyone was angry at everyone, and everyone was right. The worst part was this: nobody knew it was temporary. When you’re in the middle of a period, you can’t see that it’s a period.
In the first post of this series I argued that what separates company types isn’t size but where the decision gets made. This post is about the journey between those two types: what exactly breaks as a company grows, who loses what, and where you’re standing while it happens.
Growth isn’t a curve — it’s a staircase
Companies don’t grow along a smooth line. They work the same way for a while, then something cracks at a threshold, a new way of working gets built, and that way holds until the next threshold.
The numbers below aren’t a law; they’re a pattern I’ve watched repeat. They shift from company to company and vary by industry. But the order is always the same.
| Rough threshold | What breaks | The sentence you hear for the first time |
|---|---|---|
| ~10 people | The owner can no longer see everyone one by one | ”I had no idea.” |
| ~30–40 people | Middle management is born; the company gets its first two people who don’t know each other | ”There’s someone who looks after that team — let me ask him.” |
| ~100 people | Departmental silos; teams become each other’s customers | ”They’re our internal customer.” |
What breaks on every row of that table is actually the same thing: the capacity of informal coordination. The moment when what used to get solved in a corridor can no longer be solved in a corridor.
The secret of a small company isn’t that it has no process; it’s that the process lives inside people’s heads. At ten people, everyone roughly knows what everyone else is doing, and the missing piece gets filled in over a coffee break. This looks free, but it isn’t — the invoice just hasn’t arrived yet. At forty people it arrives: two people do the same work, one piece of work gets done by nobody, and one customer is given two different promises.
Question: What exactly breaks as a company grows? Answer: Not process — informal coordination breaks. Institutionalisation is what happens when the coordination people carried in their heads becomes too heavy to carry and has to be written down. Processes aren’t the cause of that need; they’re the consequence of it.
The first professional manager arrives
The most painful moment of the transition is when the first real manager comes in from outside.
This person usually does the job well. He sets up a meeting cadence, defines an intake flow, writes down who decides what. And at exactly that point, he collides with the founder’s memory of “we used to be so fast.”
The new manager has to do two things at once: build a system and earn legitimacy. The problem is that these two undercut each other. The more he builds, the more he becomes “the bureaucrat” — in the eyes of the long-tenured people on the team, the man who slowed everything down. If he doesn’t build, he becomes “why did we even hire him.” He is inside a game he cannot win, and he usually works this out in the first three months.
The conflict here isn’t personal, it’s structural. Whoever came would have got stuck in the same place. Which is why firing the new manager doesn’t solve the problem; it only postpones it, and makes the company’s next attempt more expensive — because the second person to arrive knows how the first one ended.
The founder’s grieving process
I’d rather have skipped this section, because when you’re sitting on the employee’s side it’s easy to be angry at the founder. But what I’ve seen took me somewhere else.
Letting go of control isn’t a management technique for a founder. It’s accepting that the thing he built is no longer him. For an employee, the company is a place. For a founder, it’s a limb. A decision of the company’s is a decision of his. A mistake of the company’s is his mistake — emotionally and in cash.
The advice to “delegate” is technically correct and emotionally incomplete. Nobody teaches you how to let go of a limb.
And the founder is wrestling with the urge to take back every decision he hands over. That urge doesn’t come from bad faith; it comes from the fact that the risk is still in his pocket. But the moment he takes one back, the handover is over. The team learns this within two days and never decides anything again — on paper the authority was granted, in practice nobody uses it. From that point on the company turns into an organisation that waits for decisions, and the founder reads this as the team lacking initiative.
The quiet status loss of the early employees
This is the part nobody talks about.
The employee from the company’s early years sat in the same room as the owner. He got a thing done in forty seconds. Nobody told him what to do, because he was the one who already knew what needed doing. That was never a formal authority — it was a privilege.
Institutionalisation takes that privilege away. The same piece of work now goes through an intake form, gets defended in a prioritisation meeting, and waits for the approval of a manager who joined six months after you did. What you lost isn’t a title, it’s distance: the distance between you and the owner grew, and nobody told you it had.
Here’s the cruel part: you can’t say this loss out loud. Because it sounds spoiled. Saying “I used to be able to tell the owner directly” doesn’t sound like claiming a right, it sounds like asking for a privilege. There’s no legitimate language for it.
So it doesn’t get said. Instead people say “this place isn’t what it used to be,” they say “the soul is gone,” and they leave quietly. And the company never learns why they left — the exit interview records “a new opportunity.” We covered the stay-or-leave decision separately in this series; most of the departures during a transition are the late invoice for a status loss that could never be put into words.
In this period, a senior engineer has two paths
The transition looks like a period of loss. But for someone senior it’s the opposite: one of the highest-return moments in a career.
The reason is simple. The company currently has no system at all, and somebody has to build one. Once it’s built, changing it will take years. Which means every rule written now will determine how people work for the next five years — and who writes those rules hasn’t been decided yet.
There are two paths:
- Be its architect. You propose the code review setup, the technical decision log, the on-call rotation, the hiring bar. And while you do that, you also protect your own way of working — because whoever writes the system embeds their own way of working inside it. That isn’t cunning; it’s just the person who knows how the work runs being the one who writes it down.
- Be its casualty. The process gets built on top of you. In a meeting you weren’t in, by someone who has never done your job. Then you adapt to it, and spend five years muttering “why does this stupid rule exist.”
Most people spend this period complaining. The complaint being justified doesn’t change anything. The responsibility that doesn’t come with the title is exactly what applies here: being in the room where the system gets built is an authority nobody gives you and nobody blocks you from taking. Walking in is enough.
Three desks
In this post the desks shift a little — because during a transition, everyone’s role shifts.
From the senior/early employee’s desk. The new system is taking your privilege away and you can’t admit it. Your constraint: your loss is real but can’t be expressed in legitimate language. Say it and you look spoiled; don’t say it and you look resentful. There is a third option, and it’s harder work: ask for the speed you lost back not as a privilege, but as a rule. Not “just ask me directly,” but “decisions of this type should pass with a single approval.”
From the (new) manager’s desk. You have to build a system and earn legitimacy at the same time, and the two contradict each other. Your constraint: you don’t exist in the team’s memory. You aren’t the subject of the sentence “we used to do it this way,” and every time that sentence gets spoken you’re reminded you’re the biggest stranger in the room. You cannot buy that memory; you win only if you stay long enough to produce a new one.
From the owner-founder’s desk. You’re wrestling with the urge to take back every decision you’ve handed over. Your constraint is real: the risk is still in your pocket. If the person you delegated to makes a mistake, you’re the one who pays for it — and that isn’t fair at all. But the moment you take one back, the handover is over; after that you go on carrying both the invoices and the decisions. Handing over means handing over the right to be wrong too; what you’re withholding isn’t authority, it’s the margin for error.
These three desks are living through the same event, and all three feel alone in it. None of them knows what the other two lost.
Closing
The transition isn’t anyone’s fault. If the company is growing, this period is coming; if it isn’t growing, that’s a different post.
While you’re inside it, the only thing you can see is the loss at your own desk. What you can’t see is that the people at the other two desks lost something as well. The founder a limb, the new manager a past, you a privilege.
Knowing this doesn’t make the period easier. But it does make you think twice about who you’re going to be angry at — and it makes you realise you could walk into the room where the system is being built and sit down, instead of standing outside it being angry.
Comments
Sign in with your GitHub account to join the discussion. Comments are stored in GitHub Discussions.