Part of The GreenBox Story — a standalone reference for the full series.
The hardest scaling problem isn’t technical — it’s knowledge. At five people, Maya could answer every question about the business. At twenty-five people across three cities, she can’t. The GreenBox story is partly about discovery techniques and planning frameworks. But underneath, it’s about how knowledge moves from one person’s head into containers that scale. This is the reference for that journey.
The knowledge containers
Every technique the GreenBox team adopted created a new way to store and share domain knowledge. The table below traces each container in the order it appeared, the team size when it was introduced, and what it made possible.
| Knowledge container | Team size | Technique | What it captures | What it enables | Post |
|---|---|---|---|---|---|
| Maya’s head | 1–5 | (nothing — the problem) | Everything about the business | Nothing, unless Maya is available | The Wrong Kind of Fast |
| 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 synthesis | 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
Knowledge starts implicit — it lives in Maya’s head, and every question routes through her. At five people this works. At ten it becomes a bottleneck. At fifteen it breaks.
The first move is to make knowledge explicit through workshops. 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. These workshops create shared understanding in the room — but the output is photographs and sticky notes, not formal models.
The next move is to make knowledge formal. 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, tested, and handed to an LLM.
The final move is to make knowledge embedded in practice. Ensemble programming means everyone understands the code as it’s written. Continuous Discovery means customer insight refreshes weekly, not whenever someone remembers. The knowledge containers maintain themselves because the team’s rhythm keeps them alive.
Each stage handles more people with less dependency on any individual.
The onboarding test
The best test of whether knowledge has scaled is onboarding. When Kai joined in month eight, how long did it take before he could contribute meaningfully? If the answer is “he sat in an ensemble session and was productive by day two,” the knowledge containers are working. If the answer is “he shadowed Maya for three weeks,” they’re not.
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. Maya explaining rules verbally works at five people. At fifteen, you need decision tables. At twenty-five, you need decision tables that the LLM implements and the 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.
The principle
Every technique in the GreenBox story 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.
Related references
- The GreenBox Cheat Sheet — every technique in one place
- The Planning Onion — every planning layer in one place
- LLMs as Thinking Partners — how LLM usage evolved
- Retrospectives at Every Scale — feedback loops at every layer
- The GreenBox Story — the full series