The 20-Person Inflection — Why Your Operating System Hits a New Ceiling (And What to Do)
Erwee Coetzee
Diamond Stack
Cape Town, South Africa
You’ve made it 18 months.
Your Daily Provenance Log is automatic. Three frameworks are in rotation: stone selection, design direction, pricing. Your first team member—let’s call him Mthembu—is making 80% of decisions independently. You check in quarterly. The system works.
But now you have 20 people. Not one team of 8. Three teams. And you’re feeling the friction.
The frameworks are spreading unevenly. Your new sourcing hire is applying the Stone Selection Framework differently than Mthembu. Your design team’s version of “design direction” doesn’t match your original intent. You’re starting to think maybe the framework was the problem all along.
You’re wrong. The framework isn’t the problem. The system for maintaining the framework across teams is.
The Invisible Ceiling at 20 People
In Posts 1–8, you hit a bottleneck at 8 people. The founder’s brain became the constraint. You solved it with psychological empowerment, habit externalisation, and cognitive complementarity.
You thought you were done. But you weren’t. You just graduated to the next level of the problem.
Jay Galbraith (1973) spent his career studying this exact phenomenon. He called it information processing capacity. As organisations grow, the amount of information that needs to be processed doesn’t grow linearly. It grows exponentially.
At 8 people, you have roughly 28 possible relationships (every person connects to every other). The information flowing through those relationships is manageable. You as the founder can still hold the patterns in your head.
At 20 people, you have 190 possible relationships. The information flowing through them is no longer manageable. Not because the frameworks are bad. But because the system for maintaining consistency across frameworks doesn’t exist.
Mthembu’s Stone Selection Framework is working perfectly. Your new hire applies it and gets different results. Why? He’s asking different questions. He’s interpreting “presence” differently. He’s weighing the quadrants (collector psychology, presence, seasonal fit, market position) in a slightly different order.
Individually, these differences are tiny. Cumulatively, they’re drift. Your framework is still there. But it’s splitting into variants across teams.
Why This Isn’t a Leadership Failure
Your first instinct is to blame yourself. I should have been clearer when training the new hire. I should have documented the framework better. I should have been more hands-on.
Stop. This is structural, not personal.
Weick (1979) showed that as organisations grow, they move from tightly coupled systems (everything connected, easy to coordinate) to loosely coupled systems (teams more autonomous, harder to coordinate). At 8 people, you’re tightly coupled. Everyone knows the Stone Selection Framework because they’ve watched you apply it for 18 months. They’ve asked you questions. They’ve gotten feedback.
At 20 people in three teams, you’re loosely coupled. Your new hire learns the framework from documentation or from Mthembu. They don’t get the same live feedback loop. Their interpretation diverges slightly. By the time you notice (three months later), the divergence has cascaded.
This isn’t failure. This is the inflection point where you transition from founder-dependent consistency to system-dependent consistency.
The System for Maintaining the System
Here’s the insight that changes everything: you don’t need better frameworks. You need a system for keeping frameworks consistent as teams scale.
This is meta-level thinking. You’re not improving stone selection. You’re improving the process by which stone selection frameworks stay coherent across multiple teams.
What does this system look like? Three elements:
1. Framework Guardians
You don’t stay on the stone selection team. Mthembu does. He becomes the “guardian” of the Stone Selection Framework for all three teams. His job: ensure consistency. He trains new hires. He calibrates questions. He notices drift before it becomes a problem.
You shift from executor to overseer. You check in with Mthembu quarterly (not the team). “Are you seeing drift? Are new people adapting the framework or abandoning it?”
2. Quarterly Framework Reviews
Every three months, the guardians (one per framework category) sit down together. They bring stories from their teams: “We had this edge case. Here’s how we adapted the framework.” The guardians discuss whether these adaptations should become official variants of the framework, or whether they’re personal interpretations that need to be corrected.
You attend these meetings as the integrator. You’re not deciding. You’re listening to whether the framework is evolving coherently or fragmenting.
3. Documented Rationale, Not Just Rules
Your Stone Selection Framework used to live in quarterly calibration conversations with Mthembu. Now it needs to live in a documented form that new hires can learn from without you.
But not as rules. As logic. “We prioritise collector psychology over technical specs because [reason]. We weight presence at 40% because [reason]. We have discovery vs. expected at 30/70 because [reason].”
When a new hire reads this, they understand not just what to do, but why. They can apply the framework coherently even without you there.
Why This Matters for Post 10
Posts 1–8 took you from bottleneck to operating system. The system worked. Three frameworks. Multiple teams. Your role shifted from executor to integrator.
Post 9 (this one) is the acknowledgment: your integrator role scales up to 20 people, but only if you have guardians beneath you.
You can’t be the guardian of three frameworks and the integrator of three teams. You have to choose. Most founders choose integration and delegate guardianship.
Post 10 will show you how to institutionalise decision-making at the team level so you’re not approving every decision. You’ll show you how to build a “cognitive board”—team leaders with different thinking styles who make decisions together without you.
But first, you need to solve this: How do frameworks stay consistent when they’re being applied by multiple teams without founder oversight?
Your Reflection for This Week
If you’ve implemented the 90-day CCF and you’re now at 15–25 people, you’re at this inflection point right now.
Look at your frameworks. Are they diverging? Can you see different interpretations across teams?
Which framework should you assign a guardian to first? Which team member has both deep understanding of the framework AND credibility with the other teams?
That person is your lever. That’s where you start.
Research & References
Galbraith, J. R. (1973). Designing complex organizations. Addison-Wesley.
The foundational work on information processing capacity and organisational design. Shows why organisations hit ceilings at predictable inflection points and what structural changes are needed to break through them.
Weick, K. E. (1979). The social psychology of organizing (2nd ed.). Addison-Wesley.
On tightly coupled vs. loosely coupled systems. Explains why founder-dependent consistency breaks down at scale and what mechanisms maintain coherence in distributed organisations.
Feldman, M. S., & Pentland, B. T. (2003). Reconceptualizing organizational routines as a source of flexibility and change. Administrative Science Quarterly, 48(1), 94–118.
On how routines maintain coherence while adapting. Directly applicable to understanding how frameworks can evolve across teams without fragmenting.
Argote, L., McEvily, B., & Reagans, R. (2003). Managing knowledge in organisations: An integrative framework and review of emerging themes. Management Science, 49(4), 571–582.
On knowledge transfer and retention across units. Explains why frameworks need guardians and why documentation alone isn’t enough.
