The hardest scaling problem most growing companies face isn’t technical; it’s knowledge. At five people, the founder can answer every question about the business. At twenty-five people across three cities, they can’t. Underneath every healthy scaling story is the same pattern: knowledge moving from one person’s head into containers that the rest of the team can use without that person in the room. This post is the reference for that journey, with worked examples drawn from the Greenbox story.
Why knowledge is the scaling bottleneck
Most scaling conversations are about org charts and infrastructure. Hire faster. Split the codebase. Add a director. None of those moves help if the knowledge that runs the business still lives in one head.
The pattern is universal. A founder starts a company because they understand a problem better than anyone else. That understanding is the company’s competitive advantage in the early days. Five people can build around it because the founder is in every conversation. At ten people, the founder becomes a queue. At fifteen, the queue overflows. At twenty-five, every conversation about strategy stalls until the founder weighs in, and most of the conversations that needed their input never happen, because the team has stopped asking.
The fix isn’t to clone the founder; it’s to extract the knowledge into something that doesn’t depend on them being available. That extraction is what every discovery and design technique in the modern playbook is secretly doing. Event Storming, Example Mapping, decision tables, ADRs, JTBD interviews: they look like different practices, but they share a single function, turning what one person knows into what the whole team can use.
This post catalogues the containers each technique creates, the team size at which each one starts to matter, and the failure modes when a team skips a stage.
The knowledge containers
The table below traces each container, the team size at which it typically starts to matter, and what it makes possible.
| Knowledge container | Team size | Technique | What it captures | What it enables | Post |
|---|---|---|---|---|---|
| The founder’s head | 1-5 | (nothing, the problem) | Everything about the business | Nothing, unless the founder is available | Worked example |
| Sticky notes on a wall | 5 | Event Storming | Domain events, hotspots, relationships | Whole team sees the same picture. Misunderstandings caught in hours, not weeks | Event Storming |
| Value stream maps | 5 | Value Stream Mapping | Where value flows, where waste lives | Team focuses on what matters, not what’s comfortable | Value Stream Mapping |
| Coloured cards on a table | 5 | Example Mapping | Rules, examples, unknowns for each story | Developers build from concrete specs, not assumptions | Example Mapping |
| Gherkin scenarios | 5 | BDD | Executable specifications | Tests that document business rules. LLMs that implement accurately | From Stories to Working Software |
| Impact maps | 5 | Impact Mapping | Goals, actors, impacts, deliverables | Work connects to business outcomes, not just backlogs | Impact Mapping |
| Story maps | 5 | User Story Mapping | User journey, release slices | Team sees the whole and ships coherent increments | User Story Mapping |
| Interview transcripts and sense-making | 5 | JTBD | Why customers hire the product | Product decisions based on evidence, not founder intuition | Jobs to Be Done |
| Assumption grids | 5 | Assumption Mapping | Beliefs ranked by risk and evidence | Team tests the dangerous unknowns first | Assumption Mapping |
| One-page business model | 5 | Business Model Canvas | All nine building blocks on one page | Leadership sees dependencies and second-order effects | Business Model Canvas |
| Bounded context maps | 15 | Domain-Driven Design | Where one domain ends and another begins | Teams work independently without breaking each other | Domain-Driven Design |
| Decision tables | 15 | Decision Tables | Formal rules for every condition combination | Domain logic teachable, testable, LLM-implementable | Decision Tables |
| ADRs | 15 | Architecture Decision Records | What was decided, why, what alternatives existed | New developers understand intent, not just code | Architecture Decision Records |
| Wardley maps | 15 | Wardley Mapping | Component evolution and strategic position | Build-vs-buy decisions based on strategy, not instinct | Wardley Mapping |
| Ensemble session output | 25 | Ensemble Programming | Shared understanding built during coding | Everyone understands the code, not just the author | Ensemble Programming |
| Threat models | 25 | Threat Modelling | Security risks at system boundaries | Security thinking systematic, not accidental | Threat Modelling |
| Weekly cadence artifacts | 25 | Continuous Discovery | Interview summaries, assumption checks, retro actions | Knowledge refresh happens automatically, not heroically | Continuous Discovery |
The progression: implicit → explicit → formal → embedded
Knowledge moves through four states as a team grows. Each move handles more people with less dependency on any one individual.
Implicit. Knowledge lives in one person’s head, usually the founder, sometimes a long-tenured operator. Every question routes through them. At five people this works. At ten it becomes a bottleneck. At fifteen it breaks. The signal that you’ve outgrown the implicit stage isn’t a complaint; it’s silence. People stop asking, and the questions that need to be asked don’t get asked at all.
Explicit. The first move is to get the knowledge out of the head and into the room. Workshops do this. Event Storming puts the domain on a wall. Example Mapping turns vague stories into concrete rules and examples. User Story Mapping shows the whole journey. The output is photographs and sticky notes: not formal models, but explicit shared understanding for everyone who was in the room.
Formal. The next move is to capture knowledge in structures that can be handed off, tested, and audited. Decision tables capture every condition combination for a business rule. ADRs record the reasoning behind architecture choices. Bounded contexts define where one domain ends and another begins. Formal knowledge can be delegated to a new hire, generated against by an LLMA neural network trained to predict the next token in a sequence, large enough that it generalises to tasks it wasn’t explicitly trained for. , and verified by tests.
Embedded. The final move is making the knowledge live inside the team’s daily rhythm rather than in a wiki nobody reads. Ensemble programming means everyone understands the code as it’s written. Continuous Discovery means customer insight refreshes weekly, not whenever someone remembers. The containers maintain themselves because the team’s cadence keeps them alive.
The four stages aren’t strictly sequential. A small team can build formal containers (ADRs from day one) and a large team can still have implicit pockets (whatever the founder hasn’t yet articulated). The pattern is directional, not deterministic. But the trajectory is the same in every team that scales: knowledge starts inside one head and ends up distributed across structures and practices that don’t depend on anyone in particular.
The onboarding test
The best test of whether knowledge has scaled is onboarding. When a new hire joins, how long does it take before they can contribute meaningfully?
If the answer is “they sat in an ensemble session and were productive by day two,” the knowledge containers are working. If the answer is “they shadowed the founder for three weeks,” they’re not.
A subtler version of the same test: ask three randomly selected team members the same question about a non-trivial business rule. Do you get three answers that match? If yes, the rule is in a shared container. If no, it’s in someone’s head, maybe in three different versions of someone’s head, which is worse than just one. Onboarding is the loud version of the test. Daily decision-making is the quiet one.
When knowledge containers fail
Containers don’t maintain themselves forever. Three failure modes show up repeatedly.
Stale artifacts. The Event Storm photos from month one are still on the wall but the domain has changed. Decision tables that haven’t been updated since the pricing model shifted. ADRs that describe a system that no longer exists. A container that isn’t refreshed becomes a source of false confidence — worse than having no container at all.
Missing containers. The team does great discovery but doesn’t write anything down. Knowledge lives in conversations that new people weren’t part of. The workshop creates shared understanding for whoever was in the room. Six months later, half the room has moved to other squads. The understanding left with them.
Wrong container for the scale. A founder explaining rules verbally works at five people. At fifteen, you need decision tables. At twenty-five, you need decision tables that an LLM implements and a weekly cadence maintains. Every container has a team size at which it stops working. The fix is always the same: make the knowledge more formal and more accessible, not more heroic.
How to introduce a new container
Containers don’t appear by themselves. Someone has to do the work of converting implicit knowledge into the new format. Three patterns work better than the alternatives.
Pair the keeper with a writer. The person who holds the knowledge is rarely the right person to write it down. They know it too well to remember what someone else needs explained. Pair them with a developer or operator who’s asking real questions, and let the writer take the notes. The questions force the keeper to articulate things they’ve never said out loud. The notes capture the answers. This is how the best ADRs get written and how decision tables that actually match the business get filled in.
Capture the next decision, not the whole history. Trying to document everything that’s already in someone’s head is a quagmire. Better: the next time the keeper makes a decision, document that one in the new container. Then the next. After ten or twenty decisions, the container has the live patterns. Backfilling can come later, if at all. (Most of the historical decisions don’t need to be captured; they’re either obvious in hindsight or no longer relevant.)
Use the container for the next change, not the existing system. If you’re introducing decision tables, write the table for the next pricing change, not the current pricing rules. If you’re introducing ADRs, write the ADR for the next architecture choice, not the existing architecture. Forward-only adoption is dramatically easier than retrofit, and the existing knowledge gets captured naturally as decisions get revisited.
The principle
Every technique in the modern discovery and design playbook creates a knowledge container. Event Storming creates shared domain understanding. Example Mapping creates concrete specifications. Decision tables create formal logic. ADRs create decision history.
The technique is how you fill the container. The container is what survives after the workshop ends.
The work of scaling a company is mostly the work of building the right containers in time: before the bottleneck breaks the team, while the founder still remembers enough to fill the container, before the original context is lost to turnover. Skip a stage and you don’t just slow down. You lock the company’s competitive advantage inside one person’s head, where it can’t be improved on, defended, or eventually replaced. Scaling knowledge is how a company stops being a one-person show and starts being a system that learns.
Related references
- Which Workshop When, every technique in one place
- The Planning Onion, every planning layer in one place
- Retrospectives at Every Scale: the feedback loop that catches when a container has gone stale
- LLMs as Thinking Partners: the formal containers that make LLMs useful
- The Greenbox Story: narrative behind the worked examples