Anika sends Charlotte a message on a Tuesday morning. It’s long, by Anika’s standards.
“The Melbourne squad just spent 25 minutes Example Mapping ‘update subscriber email address.’ No red cards. Two examples. One rule: the email has to be valid. I watched five adults sit in a room with coloured cards to collectively arrive at the conclusion that an email address has to have an @ sign.”
Charlotte asks how workshops feel generally.
“Burned out. We’ve been Example Mapping every story for three months. The discipline is good when the story is complex. But most of our stories aren’t complex any more. We’ve mapped this domain to death. People show up, do the cards, and leave. The energy is gone.”
Tom said the same thing last week. “We map stories where everyone already knows the answer. Then we skip discovery for the stuff that actually needs it because nobody has the energy left.”
Meanwhile, Greenbox is about to expand to Brisbane. New city, new farms, new logistics, different climate, different households. Genuinely complex work that needs deep discovery, JTBD interviews, assumption mapping, maybe a fresh Event Storm. But the team’s discovery budget, both time and energy, is being spent on Clear stories that don’t need it.
Cynefin
Charlotte introduces the Cynefin framework at the next all-hands. Created by Dave Snowden, it’s a sense-making framework, a way to look at a problem and determine what kind of approach it needs.
Four domains:
Clear. Cause and effect is obvious. Best practice exists. Don’t over-think it. Updating a subscriber’s email address. (Older write-ups call this domain Simple, and for a while Snowden called it Obvious; Clear is the current name for the same thing.)
Complicated. Cause and effect is discoverable, but requires expertise. Rules exist but they interact. Needs analysis. Building the allergen substitution filter.
Complex. Cause and effect can only be seen in retrospect. The answer doesn’t exist yet, it emerges from trying things. Expanding to Brisbane.
Chaotic. No perceivable relationship between cause and effect. Act first, understand later. Payment system down, subscribers being double-charged.
Charlotte’s rule of thumb, printed and pinned on each squad’s wall:
If three people agree in a five-minute conversation, it’s Clear. Don’t workshop it.
If an expert can figure it out with some research, it’s Complicated. Example Map it.
If nobody knows the answer and you need to try something to learn, it’s Complex. Experiment.
If the building is on fire, it’s Chaotic. Act.
Mapping the backlog
Charlotte asks each squad to sort their current backlog into the four domains. Five minutes.
Perth has 34 stories. When they sort: 62% Clear, 23% Complicated, 12% Complex, one lingering production issue (Chaotic).
Sixty-two per cent of their stories are Clear. Each had been getting a 25-minute Example Mapping session. That’s roughly ten hours a month of workshops confirming what everyone already knew.
This is actually a sign of success. If most of your work is Clear, it means the team has internalised the domain. The Event Storms, Example Maps, and decision tables did their job. The irony: the better your discovery process works, the less often you need it for routine work.
The adjustment
Clear stories get a quick conversation during planning. No workshop. If questions arise, the developer asks someone.
Complicated stories keep Example Mapping. The sessions improve when they’re not diluted by Clear ones, people show up with more energy, the questions are sharper, the red cards are genuinely surprising.
Complex challenges get the full discovery treatment: JTBD interviews, assumption mapping, safe-to-fail experiments. The Brisbane expansion gets a dedicated discovery track.
Charlotte is careful: “Cynefin is about discovery process, not delivery process. Clear stories still get tests, code review, and the standard pipeline. What changes is how much structured thinking happens before the developer starts building.”
The Brisbane experiment
Now that discovery energy isn’t being spent on Clear work, Charlotte and Lee carve out a proper Complex track for Brisbane.
Lee runs JTBD interviews. Brisbane interviewees care more about organic certification than Perth subscribers do. Average household size is different, a larger proportion of single-person households wanting a smaller, cheaper box.
One Tuesday interview catches something critical. A Brisbane prospect named Tanya mentions she already gets a produce box from “a Sydney company” but the boxes are too large for one person. She names it: Freshly. They’re already in Brisbane.
The first experiment, a “friends and family” pilot with twenty households, produces contradictory data. Half say the boxes are too large. Half say too small. Charlotte looks at it for a long time.
“We’re treating Brisbane as one segment. But we’re lumping singles and families together.”
She splits the feedback by household size. Every single-person household said too large. Every family said too small. No contradiction, two segments with opposite needs, averaged into nonsense.
The Cynefin classification was right. Brisbane is Complex, requiring experiments. But the experiment design was wrong. Frameworks tell you which direction to look, not what you’ll see.
The mis-classification risk
Within a fortnight, Ravi classifies a story as Clear: “Bring us in line with the Privacy Act and the Notifiable Data Breaches scheme.” His reasoning: it’s a regulation, the rules are written down.
Charlotte pushes back. “Which data? Subscriber addresses, payment tokens, dietary preferences, allergen profiles, delivery history? Which of those count as personal information under the Privacy Act, and which combination, if it leaked, would make a breach notifiable? And which rules, the obligation to destroy data we no longer need conflicts with seven-year financial record obligations. Who decides whether a breach is ‘likely to result in serious harm’, and based on what?”
Ravi recategorises: Complicated at minimum. Possibly Complex where legal interpretation is uncertain.
Charlotte didn’t mention it at the all-hands, but Cynefin has a fifth domain: Disorder, the state of not knowing which domain you’re in. Ravi’s story spent a fortnight there, treated as Clear while it was anything but, and that’s the most dangerous place for work to sit, because you apply whichever approach feels comfortable rather than the one the problem needs.
Charlotte establishes a check: during planning, after classification, she asks “What would have to be true for this to be in a different domain?” If the team can’t articulate why a story is Clear rather than Complicated, it probably isn’t Clear. It’s in Disorder, and the first job is getting it out.
Cynefin and LLMs
| Domain | Discovery approach | 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. |
|---|---|---|
| </span> role | ||
| Clear | Quick chat | Solo implementation partner |
| Complicated | Example Mapping | Ensemble navigator tool |
| Complex | Experiments, JTBD | Research assistant, sense-making |
| Chaotic | Incident response | Rapid debugging partner |
The classification determines not just which discovery technique to use, but how to use the LLM.
A month later
Workshop sessions drop 60%. The sessions that remain are for genuinely Complicated stories, faster, more focused, more useful. The Complex work. Brisbane expansion, a new B2B offering, gets proper attention for the first time.
Anika messages Charlotte: “One Example Mapping session this week instead of four. The one we ran was genuinely useful. The team’s energy is completely different.”
Tom at the Perth retro: “For the first time in months, I don’t dread Wednesdays. The sessions we run now are actually useful.”
Problems don’t stay in one domain. The subscription system was Complicated when they built it. Two years later, it’s Clear in Perth. But in Brisbane, with a different market and a competitor already in it, it’s Complex again. Classification happens per story, not per domain.
Maya puts it best: “We spent a year learning how to do discovery. Cynefin taught us when to do it. That’s just as important.”
The teams now know which problems need deep thinking. But there’s one question nobody is asking at all. Every technique in the toolkit answers some version of “are we building the correct thing?” None of them asks what someone could do with the thing once it’s built. The LLM writes code that works; whether it’s safe is a different question, and it’s the subject of threat modelling. The team is about to learn it the uncomfortable way.
The next chapter, Threat Modelling: What the LLM Didn't Think About, publishes around 11 August.