How you worked at 20 breaks at 200
The hallway conversation that ran a 20-person company does not scale to 200, and the failure is rarely loud. It shows up as rework, crossed wires, and a creeping sense that everything takes longer than it should.
At 20 people, the company runs on a kind of informality that is genuinely productive. Everyone knows what everyone else is doing because they can hear it. A decision gets made in a hallway, and by lunch the whole company has absorbed it without a single document changing hands. Nobody calls this a process, but it is one, and it works because the company is small enough to hold in one room and one shared memory.
Then you hire. New teams form who cannot see what the others are building. The hallway no longer fits everyone, and the shared memory fragments into a dozen partial ones. The speed that was your competitive edge starts leaking away, not in any dramatic failure but in small recurring frictions: two teams shipping conflicting changes, a priority everyone assumed was settled turning out to mean three different things, a dependency nobody flagged surfacing the week it was due. Founders feel this and reach for process, which is exactly the right instinct. The trap is in what they reach for.
Process is a response, not a milestone
The reflex, often encouraged by people who should know better, is to treat a certain headcount as the moment you adopt a framework. You crossed 100, so now you do the big-company thing: the scaled ceremonies, the program increments, the planning cadences that the conference talks promise will bring order. The reasoning sounds responsible. We are bigger now, so we should work like a bigger company works.
I want to be careful here, because the founders who do this are not foolish. They are pattern-matching against a real problem, and adding structure is the correct response to growing pains. The error is subtler than that. It is treating process as something you graduate into rather than something you install in response to a specific bottleneck you have actually hit. A heavy framework adopted because you grew, rather than because a named constraint demanded it, buries the team in ceremony that addresses problems they may not even have, while the one that is actually hurting them gets the same generic treatment as everything else.
Most scaling pain, when you look closely, traces to one or two constraints, not a general condition of bigness. Priorities have gone unclear, so teams optimize for different things. Dependencies have gone invisible, so work stalls in the gaps between groups where no one can see it. Quality is slipping as the codebase grows past what any one person holds in their head. These are distinct problems with distinct fixes, and they rarely all arrive at once.
The goal is not more process. It is the least process that lets a hundred people move like twenty, added the moment a real constraint demands it and not one milestone sooner.
So the discipline is narrower than picking a framework. It is diagnosis. Which constraint is the one currently costing you, and what is the lightest structure that resolves that specific thing? If priorities are the problem, you need a shared and visible way to set and sequence them, not a new release train. If dependencies are vanishing into the spaces between teams, you need those dependencies made visible and owned, which is a smaller change than it sounds and a far larger return than a planning ceremony. If quality is the issue, the answer lives in how work moves to done, not in another layer of coordination on top.
Good process takes friction out of the day. That is the test, and it is a strict one. If a new ritual does not obviously earn its place by removing more friction than it adds, it is not maturity. It is tax, and the team pays it every week whether or not it ever helps.
The platform is where the constraint gets resolved
The practical reason this matters is that coordination which used to happen by being in the same room now has to live somewhere the whole company can see. As teams multiply, the work itself has to carry the context that proximity used to provide. This is where a well-configured Atlassian platform earns its keep, and it is worth being specific about what that means, because configuring tools and resolving a constraint are not the same act.
A constraint resolves when the structure maps to the actual problem. Invisible dependencies stop being invisible when a dependency has a state and an owner that both teams can see, rather than living in one person’s memory of a conversation. Unclear priorities settle when the ordering of work is written down as a deliberate choice in a place everyone reads, rather than re-litigated in each team’s standup. Quality holds when the path to done runs through the platform in a way that is traceable, connected to delivery, so a regression has a trail instead of a mystery. The tooling is not the point. The point is that each of these is a small, specific agreement, made once, in response to a constraint you actually hit, and the platform is simply where that agreement becomes durable instead of evaporating the way hallway agreements do at scale.
We have watched this play out. At a 150-person B2B SaaS company, aligning the way teams worked with a platform that made the work visible took them from releasing twice a year, defect-heavy, to monthly releases with 10x fewer defects per release and 6x the release frequency. What changed was not that they adopted more process. It was that they added the right process at the points where growth had broken the old informal one, and no more than that. The full story is here.
Where AI fits the same logic
The same discipline governs AI, which arrives at scaling companies as a tempting general answer to specific problems. It is a real lever. It clears the toil that piles up as a company grows: the refinement busywork, the documentation that never gets written, the status reporting that eats an afternoon a week. Pointed at that toil, it gives engineers their attention back. Pointed at judgment, it erodes the thing that made the company good. The teams that get value from it aim it at the work nobody should be doing by hand, keep people on the calls that require judgment, and put the governance in place before they switch it on rather than after. It is the same move as everything else here: a precise response to a named constraint, not a thing you adopt because the moment seems to call for it.
None of this is about resisting structure. A 200-person company needs more process than a 20-person one, and pretending otherwise is its own kind of failure. It is about earning each piece. Add the lightest thing that resolves the constraint in front of you, when you hit it, and let the next one wait until it is real. Scaling while staying fast is not something that happens to disciplined companies. It is something they design, one deliberate decision at a time.
If you want to find the one constraint that is actually costing you, see where delivery is getting stuck.