Founders tend to ask this as a timing question: should we build proper systems before we scale, or wait until growth forces our hand? Put that way, it sounds like there’s a right answer waiting to be found — a magic headcount or revenue number where you flip the switch. There isn’t. The more useful question isn’t when, on a calendar. It’s which of two very different failure modes you’re actually at risk of, because “too early” and “too late” break a business in almost opposite ways, and most founders only ever prepare for one of them.
The case for waiting
Paul Graham’s essay “Do Things That Don’t Scale” makes the strongest argument for not building systems too early, and it’s held up well as startup advice because it’s built on real founder behaviour rather than theory. Brian Chesky personally photographed early Airbnb listings and managed hosts by hand. Jeff Bezos packed Amazon’s first book orders himself. Neither of them built an automated, scalable system for those jobs — because they didn’t yet know what the right system was supposed to do. Doing the work manually first is how you find out. Graham’s version of the underlying principle, via Chesky, is blunt: do it until it hurts, then automate it away.
There’s a real cost to skipping this. Systemise a process before you’ve actually learned what the process should be, and you lock in a shape that was guessed at rather than earned — and unwinding a bad system, once people and habits and reporting are built around it, is a lot more expensive than unwinding a bad manual workaround. The Startup Genome Report — a 2011 study of roughly 3,200 high-growth technology startups — put a number on exactly this failure mode. It found premature scaling behind an estimated 74% of internet startup failures, and that companies which scaled prematurely along some dimension grew roughly 20 times slower than those that scaled in step with actual demand. Seventy percent of the startups studied had scaled prematurely on at least one dimension — customer, product, team, business model, or financials — and none of the startups that did so ever reached 100,000 users. It’s worth being honest about the limits of that data: it’s a study of venture-backed internet startups from over a decade ago, not a universal law for every small business. But the mechanism it’s describing — building infrastructure ahead of validated demand — isn’t specific to tech. A manufacturing business that builds a full quality-management system around a product line that hasn’t found its market yet has made the same mistake with different tools.
So there’s a genuine, well-evidenced case for staying manual longer than feels comfortable. But it’s easy to turn “don’t systemise too early” into an excuse for “never systemise,” and that’s a different mistake with its own cost.
[Read More: What is a DPR Report? A Complete Guide to DPR (Detailed Project Report) ]
The case for redesigning sooner than you think
Larry Greiner’s model of organisational growth — first published in Harvard Business Review in 1972 and still one of the more accurate descriptions of how companies actually grow — argues that growth doesn’t happen smoothly. It happens through a repeating pattern of evolution and revolution: a company grows steadily under one kind of structure, and that exact structure eventually produces a crisis that only a different structure can resolve.
Greiner’s early phases map onto this cleanly. A young company grows through creativity — informal communication, founders making most calls directly — until it outgrows that informality and hits what he calls a leadership crisis: decisions bottleneck on people who can no longer personally track everything, and the business needs actual management structure and formal communication to keep functioning. Resolve that, and the company grows through direction — clearer structure, budgets, defined roles — until that structure produces an autonomy crisis, where capable people lower down the organisation are constrained by decisions still sitting with the top, and the fix is delegation. Delegate too far without coordination, and you hit a control crisis, where senior leadership has lost visibility into what’s actually happening across a now-dispersed set of decision-makers.
There’s a fairly precise mechanical reason informal coordination is the first thing to break as a company grows, and it comes from outside management theory. The anthropologist Robin Dunbar’s research on primate social groups produced the widely cited “150” figure — the rough upper limit of relationships a person can maintain with enough trust and shared context to coordinate informally, without needing explicit rules. Dunbar himself treated it as an approximate midpoint rather than a hard line — later work puts the plausible range closer to 100–250 — but the mechanism behind it is what matters here: the number of possible communication channels in a group grows as a function of roughly n(n-1)/2, not in a straight line with headcount. At 50 people, that’s about 1,225 possible communication pairings. At 150, it’s over 11,175. Nobody decided to make coordination harder at that stage — it became mathematically harder, whether anyone noticed or not. That’s a large part of what Greiner’s leadership and autonomy crises actually are: the point where informal, relationship-based coordination runs out of road and something more deliberate has to replace it.
Waiting for a “we’ve clearly scaled now, time to fix things” moment usually means waiting until you’re already deep in the crisis Greiner describes: decisions stuck on one person, teams that used to coordinate informally now actively working against each other, growth that’s technically still happening but getting harder every quarter to sustain. The cost of that delay shows up in day-to-day time, not just strategy documents. Asana’s 2021 Anatomy of Work Index, based on a survey of over 13,000 knowledge workers globally, found that employees were spending an average of 61% of their time on what the report calls “work about work” — status-chasing, duplicated effort, switching between tools — rather than the skilled work they were actually hired for, with U.S. respondents reporting roughly 308 hours a year lost to duplicated or irrelevant work and another 187 hours a year in unnecessary meetings. That’s not proof any single company is in crisis, but it’s a reasonable proxy for what a coordination breakdown costs once informal structure stops being enough: it doesn’t show up as a dramatic failure, it shows up as several extra hours a week, quietly, for everyone.
These aren’t actually contradictory — they’re answering different questions
Graham’s advice and Greiner’s model look like they’re pulling in opposite directions, but they’re really describing two different moments. Graham is arguing against systemising a process you haven’t validated yet — building infrastructure around a workflow whose shape you’re still guessing at. Greiner is describing what happens once a validated way of working keeps running past the point where it fits the company’s actual size and complexity. “Too early” means locking in a system before you know what it should do. “Too late” means keeping a system you already know isn’t working, because nobody’s flagged the specific crisis it’s causing.
That reframes the practical question nicely: not “have we scaled enough yet,” but “do we actually know what this process should look like, and if we do, is the current version of it still working.” Those are answerable without guessing at a headcount threshold.
It’s also worth being honest that getting the redesign itself right, once you’ve decided it’s time, isn’t a given. McKinsey’s Global Survey on organisational redesigns found that only about 21% of redesign efforts were rated successful — fully implemented, meeting their original objectives, and actually improving performance — with less than 30% of respondents rating even a single phase of the process as very successful, and nearly half reporting that a redesign effort was abandoned before it was ever implemented. That’s a useful check on both failure modes at once: acting too early wastes effort on infrastructure you didn’t need yet, but acting too late — under crisis pressure, in a hurry — is exactly the condition under which most redesigns seem to fail.
[ Read More: Process and System Design Services ]
Signs you’re in each camp
You’re probably still in “stay manual, keep learning” territory if nobody on the team could confidently describe the standard version of a process because there isn’t one yet worth standardising — volume’s too low, or you’re still finding out what customers actually need from it, or the team doing the work is still actively changing how they do it week to week. Formalising a process at that stage usually just freezes an early, imperfect version of it.
You’re probably overdue for a redesign if a small number of people — often just the founder — have become the bottleneck for decisions that used to be routine; if onboarding a new hire takes weeks because nothing about how work actually gets done is written down anywhere; if the same operational fire keeps recurring because there’s no process actually preventing it, just people reacting to it each time; or if coordination between teams that used to just talk to each other informally now needs a standing meeting to avoid dropped handoffs. Those are Greiner’s crisis symptoms showing up in plain language, not scaling milestones — and they’re the actual signal, regardless of what your revenue or headcount number happens to be.
[ Read More: Brand Management Services: Build a Strong, Clear, and Consistent Brand ]
Getting this diagnosis right — whether a business is still in the phase where manual and flexible beats systemised, or already past it and absorbing the cost of a structure it’s outgrown, and then executing the redesign well enough to land in the minority that actually succeeds — is a lot of what process and system design work actually starts with. Not building a system because a business has “reached a certain size,” but figuring out honestly which of these two situations it’s actually in, and sizing the redesign to that reality rather than to a calendar date or a milestone that doesn’t tell you much on its own.
