Scaling Without Chaos: Governance Frameworks for Fast-Growth Teams
A little over two years ago I was asked to look at a B2B software company that had gone from forty people to just over two hundred in eighteen months. Revenue had tripled. The product had shipped three major releases. Every headline metric a board could want was pointing in the right direction. And yet the CEO called me in because, in his words, “we’re growing and somehow getting slower at the same time I can’t figure out why.”
What I found, over the following few weeks, was not a company in crisis. It was something more subtle and more common: an operating structure designed - quite reasonably - for forty people, never redesigned as headcount multiplied by five. Nobody had made a bad decision. Nobody had been negligent. The company had just kept running the same decision-making architecture at a scale it was never built for the cracks that produces don’t look like crisis. They look like drag.
Specific symptoms, once I started asking the right people the right questions: product decisions that used to take a same-day Slack thread between the CEO and the head of engineering now required four separate meetings across three time zones, because the two people who used to just decide were no longer close enough to the work to decide alone, but nobody had explicitly given that authority to anyone else. Marketing had launched a campaign that finance discovered only after the invoices arrived, because there was no defined threshold above which spend needed visibility before commitment. Two regional teams had built, independently and in parallel, functionally identical internal tools, because neither had any mechanism for knowing what the other was working on. And underneath all of it, the company’s most capable senior people - the ones who had joined at twenty employees and scaled personal responsibility along with the company - were quietly burning out. Not from overwork, exactly, but from being the accidental, unacknowledged decision bottlenecks for a company that had outgrown their bandwidth six months earlier.
This is the pattern I want to work through in this piece the governance framework for fast-growth teams I now use to fix it - because the pattern is close to universal because the standard responses to it - hire a COO, adopt a framework, restructure the org chart - routinely miss what is actually wrong.
The Diagnostic: Growth Doesn’t Break Governance, It Reveals That You Never Built Any
The uncomfortable truth I have to deliver to founders in this situation, almost every time, is that their forty-person operating model was never really a governance structure. It was a set of informal habits that worked because of proximity. At forty people, in one or two locations, everyone who mattered could see everyone else’s work. The CEO could sit in on most important conversations. Decisions didn’t need explicit decision rights because trust and visibility substituted for structure. This is not a design flaw at that stage - it is, in fact, the correct way to run a company that small. Formalising decision rights at forty people would likely have been premature bureaucracy, adding friction the company didn’t yet need.
The problem is that proximity-based governance has a hard ceiling organisations blow past it without noticing, because the transition from “small enough that trust and visibility work” to “too large for that” doesn’t happen at a dramatic, visible threshold. It happens quietly, function by function, as new offices open, as management layers get added as the founders’ bandwidth to be personally present in every important conversation gets divided across an ever-larger set of demands. By the time a company passes roughly 150 to 200 people, the informal model has quietly failed everywhere at once - and nobody sent a memo announcing it. That threshold is not arbitrary. It echoes a long line of organisational research on the limits of informal coordination, most famously Robin Dunbar’s work on the cognitive ceiling of stable social groups: past it, trust and visibility can no longer substitute for structure, whatever the industry.
What makes this diagnosis hard to make from the inside is that the symptoms rarely present as a governance problem. They present as individual, seemingly unrelated frustrations: a slow decision here, a duplicated effort there, a surprised finance team, a burned-out VP. Leadership teams treat these as isolated performance issues - this person needs coaching, that team needs a better process, this function needs a new hire - when the actual root cause is structural: nobody has explicitly decided who has the authority to decide what, at what threshold visibility is required before a decision proceeds what information needs to flow between which teams before those teams can operate independently without colliding.
This is the core insight that most fast-growth leadership teams miss it’s worth stating plainly: chaos at scale is very rarely a symptom of too little management effort. It is almost always a symptom of an operating model that was never designed for the scale it is now being asked to carry. You cannot manage your way out of a structural gap. You have to build the structure.
Why the Conventional Responses Make It Worse
Faced with this pattern, most leadership teams reach for one of two conventional fixes I want to be specific about why each one, on its own, tends to fail - because both come from a reasonable instinct and both routinely backfire.
The first is importing enterprise process wholesale. A founder who has read about how a much larger, more mature company runs its planning cycles or its approval chains decides to adopt something structurally similar, all at once, across the organisation. This usually fails for a simple reason: enterprise governance structures are calibrated for enterprise risk profiles and enterprise coordination costs. A two-hundred-person company does not have the same risk surface as a ten-thousand-person one importing that level of process produces exactly the kind of decision latency and accountability diffusion that slows a fast-growth company down without meaningfully reducing its actual exposure. I have watched scale-ups install multi-stage approval chains for decisions that, a year earlier, one person made unilaterally in an afternoon - and watched the same organisation’s actual velocity collapse by a third within two quarters, while the underlying coordination failures that prompted the change remained almost entirely unaddressed. The new process targeted the appearance of the problem, not its structure.
The second conventional response is hiring a senior operator - a COO, a VP of Operations, sometimes an entire “PMO” - and delegating the governance problem to them as a headcount solution rather than a design problem. This can work, but it fails more often than it succeeds the reason is instructive: a single hire, however capable, cannot retrofit governance onto an organisation through personal authority and hustle any more effectively than the founders could. If the new hire’s mandate is vague - “fix how we operate” - they inherit exactly the same informal, proximity-dependent decision model the founders were running, just with one more person now expected to be everywhere at once. Within two or three quarters, the new operator has become the new bottleneck the company is back where it started, with an additional salary line and no structural change to show for it.
Both failure modes share the same underlying error: they treat governance as a resourcing question - more process, more headcount - rather than a design question about where decision rights actually sit and how information needs to move for those rights to be exercised well. (This is the same structural misdiagnosis I’ve written about in the context of over-engineered process more broadly - see Complexity Traps: Why More Process Doesn’t Mean Less Risk - but at the fast-growth stage it shows up specifically as a decision-rights vacuum rather than an excess of controls.)
A Governance Framework: Decision Architecture for Fast-Growth Organisations
What I use with fast-growth leadership teams what we eventually built with the software company from the opening, is a framework built around four elements. I want to be precise about each, because the value is in how they interact, not in the labels themselves.
Decision mapping by category, not by org chart. The first move is to stop thinking about decisions in terms of who reports to whom start thinking in terms of decision categories - pricing changes, hiring above a certain level, spend above a certain threshold, product scope changes, external partnership commitments - and assigning each category an explicit, named decision-maker along with the specific conditions under which that decision-maker must consult others before acting. This sounds like a RACI exercise structurally it resembles one, but a RACI chart starts from the assumption that authority already exists and merely needs documenting. This exercise starts from the opposite assumption: that for a meaningful share of decision categories, authority has never actually been assigned - and the point of the walkthrough is to force those assignments for the first time. Which means the exercise itself - asking “who, specifically, decides this who genuinely needs to be consulted versus merely informed” - surfaces disagreements and gaps the organisation has been quietly living with, sometimes for a year or more. At the software company, this exercise revealed that no one had actual, sole authority over marketing spend commitments above five figures; three different people believed, independently and in good faith, that the authority was theirs. This is a close cousin of the diffuse-ownership problem I’ve described in software delivery contexts - see Execution Accountability: How to Build a Culture That Delivers - except here the ambiguity sits at the level of company-wide decision categories rather than individual workstreams.
Escalation thresholds, not escalation vibes. Once decision categories have named owners, the second element is defining, in specific and falsifiable terms, what triggers escalation beyond that owner - a monetary threshold, a customer-facing risk, a cross-functional dependency, a reversibility question. The instinct in fast-growth companies is to rely on judgment: “use your discretion, escalate if it feels big.” This sounds sensible and is, in practice, close to useless, because “feels big” is calibrated differently by every individual the people most likely to under-escalate are precisely the confident, capable operators a fast-growth company depends on most - the ones whose judgment has been correct often enough that they’ve stopped questioning where its limits are. Specific thresholds remove that ambiguity. A spend commitment above a defined figure requires visibility before, not after, commitment. A product change that affects a named enterprise account’s contractual terms requires a specific sign-off. This is not about distrust of good operators. It’s about giving good operators a clear, low-friction signal for when their excellent individual judgment needs to be joined by someone else’s context.
Information flow designed around collision points, not comprehensive reporting. This is the element fast-growth companies get most wrong, usually by overcorrecting into more status meetings and more dashboards once they sense a coordination problem. The actual fix is narrower and more surgical: identify the specific points where two or more teams are likely to make decisions that affect each other - parallel product workstreams, regional teams solving similar operational problems, sales commitments that touch delivery capacity - and build a lightweight, specific information channel at exactly those collision points, rather than a general-purpose reporting layer that tries to give everyone visibility into everything. More reporting volume does not solve a coordination problem; it usually just buries the specific signal that matters inside noise nobody has time to read closely. There, the fix for the duplicated internal tools problem was not a new all-hands reporting cadence. It was a single, mandatory, thirty-minute cross-regional sync specifically for engineering leads before any new internal tooling project began - a narrow, targeted channel aimed precisely at the collision point that had actually caused the duplication. Left unaddressed, this kind of uncoordinated parallel build-out is exactly how organisations accumulate the kind of fragmented internal tooling and integration debt I’ve written about separately - see Integration Debt - The Hidden Cost of Point Solutions.
Review cadence tied to growth stage, not to the calendar. The fourth element the one leadership teams find hardest to internalise, is that the governance structure you build is not a permanent artefact. It is calibrated to a specific headcount, complexity level geographic footprint it needs a scheduled review - not an annual ritual, but a trigger tied to actual growth milestones: doubling headcount, opening a new region, crossing a defined revenue threshold, adding a management layer. That leadership team committed to reviewing its decision map and escalation thresholds at every 50% headcount increase, treating governance the way a good engineering team treats technical architecture: something that was correct for its scale yesterday and needs deliberate, scheduled reassessment, not something you get right once and leave alone.
Implementation Risks and Trade-offs
None of this installs cleanly leaders who expect a frictionless rollout will misread the early resistance as a sign the framework is wrong, when it is usually a sign it is working.
Decision mapping surfaces uncomfortable ambiguity surfacing it is uncomfortable by design. Some of your most capable people have been operating with informal authority they were never explicitly granted clarifying decision rights will, in some cases, mean taking authority away from someone who has been exercising it - often well - without a formal mandate. Expect this to generate genuine friction expect some of the most articulate objections to come from exactly the people whose informal scope is being narrowed. This does not mean the objection is wrong every time. Sometimes the existing informal arrangement really is the right one the exercise should confirm and formalise it rather than change it. But the assumption should not be that resistance signals a design flaw. Often it signals that the design is doing precisely what it is meant to do.
Escalation thresholds, set too conservatively, recreate the exact problem you are trying to solve. If every threshold is set low enough to catch every possible risk, you have simply rebuilt centralised bottleneck decision-making with extra paperwork. This is the single most common failure I see in early implementations: leadership, nervous about losing visibility, sets thresholds so low that nearly everything still routes through the same one or two people the company experiences no meaningful improvement in velocity while believing it has “done governance.” Thresholds need real calibration, revisited genuinely at each growth-stage review, not set once out of caution and left untouched.
There is also a real cost to the initial mapping exercise itself. It takes real senior time - the team spent roughly three weeks of concentrated leadership effort building the first version of its decision map - and it will, in the short term, feel like a distraction from the operational fires the framework is ultimately meant to reduce. Leaders under real pressure will be tempted to defer it indefinitely in favour of firefighting the immediate crisis. This is precisely backwards, because the immediate crises are, in a fast-growth company that has outgrown its informal model, usually downstream symptoms of the exact structural gap the mapping exercise is designed to close.
And finally: none of this survives a founder who, having built the framework, continues to personally intervene in decisions the framework has explicitly delegated elsewhere, out of habit or discomfort with letting go. I have watched this specific failure sink an otherwise well-designed governance rebuild more than once. If the CEO keeps overriding the named decision-owner for a category they have formally delegated, the organisation learns, correctly, that the framework is decorative reverts within a quarter to routing everything through the founder informally again, regardless of what the documentation says. Governance frameworks are tested either validated or destroyed, by leadership’s actual behaviour the first time a delegated decision goes a way the founder wouldn’t have chosen personally.
What Changed What It Cost
Eight months after the initial diagnostic, the company had a functioning decision map covering eleven major categories, calibrated escalation thresholds reviewed at their most recent headcount milestone, four targeted cross-functional sync points replacing what had briefly become an over-correction into excessive general reporting a scheduled governance review tied explicitly to their next growth trigger rather than the calendar. Decision cycle time on the categories we mapped dropped by roughly half within the first quarter, measured simply by tracking time from “decision needed” to “decision made” across a sample of recurring decision types. More tellingly, the CEO reported something he hadn’t anticipated: he was in noticeably fewer meetings, not because the company had become less active, but because a large number of decisions that used to require his informal presence now had an explicit, legitimate owner who didn’t need him in the room to act.
The duplicated tooling problem did not recur. Marketing spend surprises didn’t recur in the two quarters that followed - not through more scrutiny of marketing, but through a threshold that made pre-commitment visibility automatic rather than dependent on someone remembering to mention it. And several of the senior people who had been quietly burning out as informal decision bottlenecks reported, unprompted, that they finally felt like their actual scope matched what they had authority to decide - which turned out to matter more for retention than any compensation adjustment the company had considered making instead.
The Strategic Reflection
Fast-growth companies do not fail at governance because their leaders lack discipline or their teams lack talent. They fail because the informal, proximity-based operating model that got them through their first hundred employees quietly stops working somewhere past it nobody schedules the redesign, because there is no dramatic moment that announces the model has broken. It just gets slower, more duplicated, more surprising more exhausting for the people holding it together informally.
The organisations that scale without descending into chaos are not the ones that grew slower, or the ones that hired the single right operator to hold it all together through force of will. They are the ones that treated their decision architecture the way they would treat any other piece of infrastructure under load: something designed for a specific scale, monitored for signs it has been outgrown deliberately redesigned at defined intervals rather than left to erode until a crisis forces the conversation.
If you are leading a company somewhere on that curve - past the size where everyone can see everyone else’s work, but without an explicit answer to who decides what and at what threshold visibility is required - the uncomfortable but useful question is not “do we need more management.” It’s “have we actually designed decision rights for the size we are now, or are we still quietly running the structure that worked when we were a third this size hoping nobody notices it’s stopped fitting.” Answer that honestly the drag that looks like a hundred unrelated problems usually turns out to be one problem, wearing a hundred different disguises.
Gustavo De Felice is a senior digital project leader and systems architect with over 1,200 managed projects across technology, logistics digital transformation. He writes on execution governance, performance accountability the structural design of teams that deliver under complexity.