On a Tuesday morning in March, the founder watched her company's Slack explode with messages. The mobile team had shipped a feature that broke the API the backend team was refactoring. Customer support fielded 47 tickets in two hours. The compliance officer, hired just six weeks earlier, learned about the feature from an angry enterprise client. Three engineers spent the rest of the week rolling back changes and coordinating fixes.
Two years earlier, this deployment would have been unremarkable. Back then, the startup had eight people in a single room. Someone would shout "shipping the payment flow," and everyone knew what that meant. The entire codebase fit in one person's head. If something broke, the person who wrote it fixed it immediately. Speed was everything. Process was the enemy.
But now, with 23 employees across engineering, sales, support, and compliance, that same velocity had become dangerous. The company had crossed an invisible threshold, one that catches nearly every fast-growing startup by surprise. The methods that generated early success had transformed into liabilities. And the founder, like many before her, had to confront an uncomfortable truth: "just ship it" stops working at scale.
The Mathematics of Coordination
The breaking point is not arbitrary. Research into organizational behaviour has long demonstrated that communication overhead grows polynomially with team size. In a team of five, there are ten possible communication channels. At ten people, that number jumps to 45. At twenty people, it reaches 190. This is not merely theoretical: each channel represents potential misalignment, duplicated work, or conflicting assumptions.
Frederick Brooks documented this phenomenon in his 1975 book "The Mythical Man-Month," arguing that adding people to a late software project makes it later. The core insight, that coordination costs overwhelm productivity gains, has proven remarkably durable. But Brooks was describing projects in crisis. The more insidious problem occurs during normal operations, when a company quietly crosses the threshold where informal coordination ceases to function.
At eight people, everyone attends every meeting. Information flows freely because everyone shares context. Engineers know what customers are asking for because they hear it directly. Product decisions happen in conversation, not in documents. This creates extraordinary velocity. A feature can go from idea to production in days. The feedback loop is immediate. The organisation learns fast.
At twenty people, the dynamics change fundamentally. Not everyone can attend every meeting, there are too many meetings. Information flow becomes selective. Engineers no longer hear directly from customers; that information passes through intermediaries. Product decisions require documentation because not everyone was in the room. The organisation develops memory, yes, but also amnesia: knowledge becomes siloed.
The transition is gradual enough that many leaders fail to notice it happening. They still think they are running an eight-person company. They resist process improvements as "premature bureaucracy" or "corporate bloat." They celebrate speed over coordination. And then, like the founder described earlier, they watch a routine deployment trigger a cascade of failures that would have been impossible two years earlier.
When Speed Becomes Recklessness
Consider what happens when a five-person engineering team ships a breaking change to an API. The blast radius is small. The five engineers know every system that depends on that API, they probably wrote those systems themselves. If something breaks, they know immediately, and they know how to fix it. The cost of the mistake is low: a few hours of work, perhaps, and no external impact.
Now consider the same change in a twenty-person company. The engineering team has split into mobile, backend, and infrastructure groups. The person who changes the API may not know every system that depends on it. Some of those systems are owned by people in different time zones. Others are maintained by contractors who work part-time. The QA process, if one exists, may not catch the breakage because the test suite has not kept pace with the product.
The change ships on Friday afternoon. By Monday morning, the mobile app is crashing for 15% of users. Customer support, now a team of four rather than a single person, has logged 200 tickets. The support team escalates to engineering, but the original developer is on vacation. Someone else investigates. They discover that the infrastructure team made an unrelated change over the weekend, and now it is unclear which change caused the problem. The resolution takes three days. Revenue for that week is down 8%.
This is not a hypothetical scenario. It is a composite of dozens of incidents from real companies, all of which happened because the organisation continued to operate with startup velocity after it ceased to be a startup. The cost of a mistake, in time, money, and customer trust, grows non-linearly with team size. At five people, you can afford to break things and fix them quickly. At twenty people, each breakage has downstream consequences that compound.
The companies that successfully navigate this transition understand a subtle point: speed itself is not the problem. The problem is uncoordinated speed. A twenty-person company can still move fast, but only if it builds the coordination infrastructure to do so safely. This requires discipline that feels unnatural to founders who built their companies on instinct and urgency.
The Illusion of Alignment
In small teams, alignment happens naturally. Everyone sits together. Everyone hears the same conversations. When priorities shift, everyone knows simultaneously. There is no need for formal communication because informal communication is ubiquitous. This creates a powerful but dangerous illusion: that alignment is the natural state of organisations.
It is not. Alignment is the exception, and it requires work. At scale, alignment becomes an active process rather than a passive state. Yet many companies continue to operate as if alignment will emerge organically, just as it did when they were small. They discover their mistake when teams work at cross purposes, building features that contradict each other or solving problems that have already been solved.
Take the case of a payments company that grew from twelve to twenty-five people in eight months. The mobile team, responding to customer requests, added support for international currencies. The backend team, working from a quarter-old roadmap, deprecated the same functionality to reduce system complexity. Neither team knew what the other was doing. Both teams thought they were aligned with company priorities, and technically, they were aligned, just with different versions of those priorities from different moments in time.
The collision was discovered only when a major client called to ask why the feature appeared in the mobile app but did not work. The post-mortem revealed that no single person had visibility into both teams' roadmaps. The company had implemented informal check-ins, but these check-ins happened within teams, not across them. Everyone was aligned within their silo. No one was aligned across the organisation.
This pattern repeats across companies of all types. Engineering builds what product specifies, but product's specifications are based on conversations with sales from six weeks ago, and sales's priorities have shifted based on recent deals. Everyone is executing well. Everyone is out of sync. The company moves quickly in multiple directions, which is to say, it does not move at all.
Compliance and the Adult Supervision Problem
Small companies have the luxury of asking for forgiveness rather than permission. When you have eight people and a thousand customers, regulatory compliance is a distant concern. You probably do not have a privacy policy beyond a template from the internet. Your security practices amount to "we use AWS and they handle that." If a customer asks about SOC 2 certification, you say "we are working on it" and then forget about it because the customer signs anyway.
This works until it does not. The inflection point often comes not at a specific company size but at a specific customer size. When your largest customer is worth $5,000 a month, they will accept "we're working on it." When your largest customer is worth $500,000 a year, they will not. Enterprise sales require enterprise compliance. And enterprise compliance requires process, documentation, and review cycles, all of which are antithetical to "just ship it."
The company hit this wall when they landed their first Fortune 500 client. The client's procurement team sent over a 47-page security questionnaire. The questions assumed things like change management procedures, access control policies, and incident response protocols. The team had none of these. They had smart people who did reasonable things. But "reasonable things" is not auditable. Compliance requires documentation. Documentation requires process. Process requires coordination.
The company hired a compliance officer, their first non-engineering, non-sales role. The compliance officer discovered that engineers had root access to production databases. That customer support could delete user accounts without review. That the company had no formal definition of what constituted a security incident. Each of these had made sense when the company was eight people. Each was now a liability.
The compliance officer's job, essentially, was to slow things down. Not arbitrarily, but deliberately: to insert review steps, approval gates, and documentation requirements. To the engineers, this felt like bureaucracy. To the enterprise clients, it was table stakes. The tension between velocity and compliance is a defining challenge of the transition from startup to scale-up.
Some companies resolve this tension by creating a two-tier system: a fast track for low-risk changes and a slow track for everything else. This works if, and only if, the company can accurately assess risk. Early-stage companies are notoriously bad at this. They overestimate their ability to predict consequences and underestimate the complexity of their own systems. The result is that high-risk changes slip through the fast track, and the compliance function becomes either ignored or all-powerful. Neither outcome is healthy.
Customer Expectations and the Professionalism Threshold
When your product has a hundred users, those users are early adopters. They expect bugs. They tolerate outages. They appreciate your responsiveness more than your reliability. They chose your product because it does something new, not because it does something well. This gives you permission to experiment, to break things, to learn in public.
When your product has ten thousand users, the dynamics shift. Some of those users are still early adopters, but most are pragmatists. They chose your product because it solves a problem, and they expect it to keep solving that problem. They do not want to hear about your exciting new architecture. They want the thing they paid for to work. An outage is no longer an adventure; it is a breach of contract.
This shift in customer expectations often catches companies off-guard because it happens gradually. The early adopters do not leave, they remain enthusiastic. But they become a smaller percentage of the user base. The company continues to optimise for the early adopters (speed, novelty, engagement with cutting-edge users) while the pragmatists grow increasingly frustrated. The support tickets pile up. Churn starts to tick upward. And the company cannot understand why, because the product is better than ever.
The product is better. But the service is worse. At eight people, a single engineer might handle a support ticket by deploying a fix to production within an hour. The customer feels valued. The problem is solved. At twenty people, that same ticket goes to a support specialist, who escalates to an engineer, who investigates and finds that the fix requires coordination with another team. Three days later, the customer gets a response. The response is more professional, it has been edited, reviewed, and approved, but it took 72 times longer.
Companies at this stage face a choice: optimise for fast response time with high variance, or slow response time with low variance. Early-stage companies choose fast with high variance. Mature companies choose slow with low variance. The transition point is around twenty people, and many companies try to have it both ways. They want the speed of a startup and the consistency of an enterprise. They get neither.
The Architecture of Autonomy
The organisational problems at twenty people often have technical roots. Many startups begin with a monolithic architecture: a single codebase, a single database, a single deployment. This works beautifully for small teams. Everyone works in the same code. Changes are easy to coordinate because they happen in the same place. Testing is straightforward. Deployment is simple.
But monoliths scale poorly, not just technically but organisationally. As the team grows, multiple people edit the same code. Merge conflicts become frequent. The test suite slows down. Deployments require coordination because everyone's changes go out together. A bug in one feature can block deployment of another feature. The system that enabled velocity now constrains it.
The standard solution is to break the monolith into services. Each team owns a service. Teams can deploy independently. The architecture enables autonomy. This works in theory. In practice, it trades one coordination problem for another. Instead of coordinating within a codebase, teams must coordinate across services. The API becomes the interface, and any change to an API requires coordination with every team that depends on it.
Companies discover that technical architecture and organisational structure are deeply entangled. Conway's Law, the observation that systems reflect the communication structure of the organisations that build them, operates in both directions. Your architecture shapes how teams communicate, and how teams communicate shapes your architecture. At twenty people, most companies have the wrong architecture for their organisation, or the wrong organisation for their architecture, or both.
The successful transitions involve co-evolution. Teams are restructured around service boundaries. Services are refactored to match team boundaries. This takes time, often six to twelve months. During this period, the company is necessarily slower. Founders hate this. They see competitors shipping features while they are "just reorganising." But companies that skip this transition pay for it later, when the mismatch between architecture and organisation becomes pathological.
The Knowledge Problem
In 1945, Friedrich Hayek wrote an essay titled "The Use of Knowledge in Society," arguing that the central problem of economic organisation is how to use knowledge that is dispersed among many people. This insight applies with surprising force to software companies at scale. At eight people, knowledge is centralised by default. At twenty people, knowledge is necessarily distributed. The question is whether it is distributed usefully.
Consider a common scenario: an engineer needs to add a feature that touches three different parts of the system. At eight people, the engineer probably wrote all three parts, or at least knows who wrote them. The knowledge is either in their head or one conversation away. At twenty people, those three parts may be owned by three different teams. The engineer must discover who owns each part, understand each team's constraints and priorities, and coordinate changes across all three.
If the company has good documentation, this is tedious but manageable. If the company does not, and most twenty-person companies do not, the engineer must do archaeology. They read code, trace dependencies, check git history, and piece together how things work. This takes time. Worse, the knowledge they gain is tacit and temporary. The next engineer to touch these systems will repeat the same investigation.
The standard prescription is to "write things down." But documentation is expensive. It takes time to write, time to maintain, and time to keep up to date. In fast-moving environments, documentation decays quickly. Six-month-old documentation is often worse than no documentation because it misleads rather than informs. Many companies respond by not writing documentation at all, on the theory that outdated docs are worse than no docs.
This creates a knowledge trap. The company is too large for tacit knowledge to flow freely, but too fast-moving for explicit documentation to remain accurate. Information lives in Slack threads, meeting notes, and the memories of long-tenured employees. New hires struggle to get up to speed. Simple changes require days of investigation. The effective size of the team shrinks because so much effort goes into coordination rather than creation.
Some companies address this with tools: wikis, architectural decision records, automated documentation generation. These help, but only if the company commits to maintaining them. The deeper solution is cultural: treating documentation as a first-class deliverable, not an afterthought. This requires discipline that early-stage companies rarely have. They must develop it, usually through painful experience.
The Leadership Transition
Founders who are excellent at building products are not necessarily excellent at building organisations. The skills are different. At eight people, leadership means having a clear vision, making fast decisions, and working closely with everyone. At twenty people, leadership means creating systems that enable others to make decisions without you. Many founders struggle with this transition because it requires them to step back from the work they love.
The founder, in her Tuesday morning crisis, felt this acutely. Her instinct was to dive into the code, trace the bug, and fix it herself. Two years earlier, that would have been the right move. Now, it was the wrong one. Her job was not to fix the bug but to understand why the bug happened and ensure it would not happen again. This required a different kind of thinking: systemic rather than tactical.
The transition from maker to manager is well-documented in business literature. What is less discussed is the transition from manager to architect, not of code, but of process. At twenty people, the founder's primary job is to design the coordination infrastructure that enables everyone else to work effectively. This means thinking about information flow, decision rights, and feedback loops. It means creating clarity about who owns what, how teams communicate, and when coordination is required.
Many founders resist this. They see process as the enemy of creativity. They worry that structure will slow things down. They fear becoming the bureaucratic corporations they set out to disrupt. These fears are not irrational. Process can become pathological. But so can the absence of process. The art is in finding the right level of structure: enough to enable coordination, not so much that it stifles autonomy.
This requires judgment that comes from experience. First-time founders often get it wrong. They either impose too much structure too early, killing velocity, or they impose too little structure too late, letting chaos reign. The pattern is predictable: they run their twenty-person company like an eight-person company until something breaks badly enough that they overcorrect, implementing heavy process that slows everything down. Then they pull back, and the cycle repeats.
What Works: Building Coordination Infrastructure
The companies that successfully navigate the transition from startup to scale-up do several things consistently. First, they establish clear ownership. Every system, every codebase, every customer relationship has a named owner. This sounds obvious, but many companies run for years on the assumption that "everyone is responsible," which in practice means no one is responsible. Clear ownership creates accountability and reduces coordination costs because everyone knows who to ask.
Second, they create lightweight decision-making frameworks. Not elaborate governance structures, but simple heuristics about what kinds of decisions require what kinds of coordination. For example: changes that affect only your team can be shipped immediately. Changes that affect your team's API require notification to dependent teams. Changes that affect customer-facing behaviour require approval from product and support. These frameworks are not about control; they are about predictability.
Third, they invest in observability. At eight people, you know what is happening because you see it. At twenty people, you need instrumentation: metrics, logs, alerts, and dashboards. This is not just for debugging production issues. It is for understanding system behaviour, identifying patterns, and making informed decisions. Companies that lack observability fly blind. They optimise for the wrong things because they cannot measure the right things.
Fourth, they build communication rituals. Not more meetings, fewer meetings, but better ones. A weekly all-hands where everyone shares what they shipped and what they learned. A monthly review where teams present their roadmaps and dependencies. A quarterly planning process where priorities are set and resources allocated. These rituals create shared context and force coordination to happen proactively rather than reactively.
Fifth, they embrace asynchronous communication. At eight people, you can have a room where everyone gathers for spontaneous discussions. At twenty people, you need mechanisms for people to communicate without being in the same place at the same time. This means written communication: design docs, RFCs, decision records. It means threaded discussions where decisions are documented and searchable. It means accepting that not everything can be decided in real-time.
None of this is revolutionary. These are standard practices at well-run companies. But they feel foreign, even threatening, to founders who built their companies on speed and informality. The challenge is not intellectual; it is emotional. It requires accepting that the company has changed, that the old ways no longer work, and that the founder's job is now different.
The Cost of Delay
Companies that delay this transition pay for it in several ways. The most obvious is velocity. Without coordination infrastructure, teams trip over each other. Work is duplicated or contradicted. Simple changes require heroic effort. The company feels busy but accomplishes little. Engineers burn out not from working too hard but from working inefficiently, fighting systems that should support them but instead create friction.
The less obvious cost is talent. Strong engineers leave companies where their effectiveness is constrained by poor coordination. They can tolerate technical debt, that is solvable. They cannot tolerate organisational debt: unclear ownership, poor communication, and thrash. The best engineers have options. They choose environments where they can be effective. Companies that fail to build coordination infrastructure lose their best people, which makes the coordination problems worse.
The most insidious cost is strategic. Companies that cannot coordinate internally cannot respond to external threats. A competitor launches a feature, and the company needs three months to respond because the work spans multiple teams with no coordination mechanism. A customer requests an integration, and the company cannot commit to a timeline because no one has end-to-end visibility. The market moves, and the company cannot pivot because its internal complexity exceeds its adaptive capacity.
The company was lucky. The Tuesday morning crisis was painful but not fatal. It cost a week of engineering time and some customer goodwill, but the company survived. The incident became a catalyst for change. The founder hired an engineering manager to own internal coordination. She implemented a lightweight RFC process for changes that crossed team boundaries. She started weekly "demo days" where teams showed each other what they had shipped. The changes felt like overhead at first. Six months later, they felt like oxygen.
The Nature of Scale
The transition at twenty people is not the last transition. There will be another at fifty, another at a hundred, another at five hundred. Each threshold brings new coordination challenges. But the transition at twenty is special because it is the first. It is the moment when founders must confront that their company is no longer a startup in the traditional sense. It has employees who were not there at the beginning. It has customers who were not early adopters. It has complexity that cannot fit in a single person's head.
This transition requires a fundamental reorientation. The question is no longer "how fast can we ship?" but "how fast can we ship while maintaining alignment, quality, and reliability?" The answer is still "very fast," but it requires infrastructure. The companies that build that infrastructure early retain their velocity. The companies that delay struggle, often for years, as they try to retrofit coordination onto an organisation built for chaos.
The irony is that the instincts that made founders successful in the early days, bias for action, comfort with ambiguity, resistance to process, become liabilities at scale. The skills required are different: systems thinking, communication, and patience. This does not mean founders must become bureaucrats. It means they must become architects, designing systems that enable others to move fast safely.
The companies that navigate this transition successfully do not abandon their startup ethos. They evolve it. They remain fast, but they are fast in a coordinated way. They remain experimental, but they contain the blast radius of experiments. They remain informal in culture but formal in process. This is not a contradiction. It is maturity.
Just Ship It, Wisely
"Just ship it" is not wrong. It is incomplete. At eight people, shipping is the constraint. The team has more ideas than capacity, so velocity is paramount. At twenty people, coordination is the constraint. The team has capacity but lacks alignment, so clarity is paramount. The companies that thrive at scale do not abandon shipping, they build the infrastructure to ship continuously, predictably, and safely.
This requires a shift in mindset. Speed is not measured in features per week but in time-to-value: how quickly can the company go from idea to customer impact? Sometimes that means shipping a feature in two days. Sometimes it means spending a week coordinating before shipping, because the alternative is shipping something that creates more problems than it solves. The art is in knowing which situation you are in.
The company still ships fast. But now, when someone says "shipping the payment flow," there is a process. The change is reviewed by security. Dependent teams are notified. The support team sees a demo. The rollout is gradual: 5% of users, then 25%, then 100%. If something breaks, the impact is contained. The blast radius is known in advance. This does not feel like moving fast. But measured by customer value delivered, it is faster than before, because less time is spent fixing avoidable mistakes.
The lesson is clear: the tactics that work at eight people fail at twenty people. Not because they were bad tactics, but because the context changed. Coordination at scale requires infrastructure, light enough to not impede velocity, strong enough to prevent chaos. Companies that build this infrastructure retain their ability to move fast. Companies that do not spend their energy fighting themselves. The choice is straightforward. The execution is hard. And it matters more than most founders realise.