Lesson 0041 · Initiative Lead · Module 1
Map the Workflow Before the Components
The fastest route to a bad architecture is to turn nouns in a brief into tables and services. Start with what happens, who decides, and where the work breaks.
Mission tie-in: good boundaries follow behavior, language, policy, and ownership. Workflow discovery supplies the evidence that folder trees and system diagrams cannot invent.
Knowledge: behavior before structure
For the returns initiative, a noun-first design finds Return, Customer, Label, and Refund, then draws a service around each. A workflow tells a different story:
Return requested → order verified → policy interpreted → evidence requested → eligibility decided → label created → parcel received → refund authorized → customer notified
Actors: customer, support agent, policy owner, warehouse clerk. External systems: order platform, carrier, payments. Hotspots: policy interpretation, missing evidence, warehouse-to-refund handoff.
A noun is a compressed summary of behavior, and everyone decompresses it differently. Six people can agree on the word Return for a year while holding six different models of it. An event cannot be agreed to that cheaply: it is a fact with a time, an actor, and a precondition, so people who disagree about one are forced to discover that they disagree. That is the mechanism—mapping does not produce a diagram, it produces externalized disagreement, early, where it costs an hour instead of a release. Time order does the rest: it forces sequence, hand-offs, and waiting into view, and those three drive coupling far more than nouns do.
It stops applying when there is nothing to observe or nothing to disagree about. A genuinely new workflow has no current state. A formally specified one—a card-scheme settlement protocol, a customs declaration—is already written down more precisely than a workshop will produce, so read the specification instead. And a “workflow” that is one function call with no hand-off and no exceptions yields nothing: mapping pays in proportion to variation, and a single-path process has none.
Build this with the people who do the work, not only their managers. Ask for the last real case, including spreadsheets, copied identifiers, manual messages, exceptions, and waiting. The “unofficial” steps often contain the actual domain rules.
A lightweight EventStorming sequence helps a cross-functional group uncover the model:
- Write domain events—facts that happened—in past tense and order them.
- Add commands that caused them and the actors who initiated those commands.
- Add policies: “when parcel received, authorize refund if inspection passed.”
- Add external systems, time, manual steps, questions, and failures.
- Mark hotspots where language, rules, responsibility, or confidence changes.
Those hotspots are design evidence. “Approved” means policy eligibility to support, warehouse inspection to operations, and settled money to finance. One global status would collapse three models. The workflow suggests separate states and a translation boundary, just as lesson 0036 predicts.
Map the current state before the desired state. Otherwise the team will unknowingly preserve invented steps and miss real constraints. Then design the target workflow by removing waiting, duplicate entry, and decisions the system can safely make—not by automating every current step.
How the lead actually ran it
Week 2. Seven people: product, design, the tech lead, four engineers. The brief already says “portal” and two engineers have started sketching tables. The lead does not open the brief. She asks the support lead for one thing—the case that went badly last week—because exceptions are where the rules live and a representative case has had its exceptions averaged away. She rejects the obvious starting point, the support ticket taxonomy: tidy, available, and encoding the current tool's dropdown rather than the domain.
Ninety minutes, two rules: one real case, no whiteboard theory. Tomas objects that this is a two-day tax on a ten-week pilot. The lead does not overrule him; she accepts the timebox as the price of the objection and asks him to write the events. He finds the three meanings of “approved” himself. Two further findings changed the design:
- The warehouse clerk keeps a spreadsheet reconciling parcels against a printed sheet. It was the only place the fact parcel received had ever been recorded—a system of record nobody had listed as a system. It is why, in lesson 0045, a warehouse event is what moves a return to
received. - The policy is less codifiable than the brief assumes. The 200-case sample commissioned in lesson 0040 came back at 143 clean matches against written policy and 57 needing human judgement—71%, not the 90% the brief implied. At the pilot's expected 160 requests a day, a 29% exception rate is roughly 46 manual cases daily against a guardrail of 50. The manual review queue is not a fallback here; it is load-bearing, and it has almost no headroom.
Nine weeks on, the payoff of the first hotspot is invisible—one module writes the refund state, and a class of “both components set refunded” defects never happened. The second is highly visible: it caps the pilot cohort, and it is why lesson 0050's week-four review watches queue depth as closely as median resolution time.
| Listen for | It reveals | Capture as |
|---|---|---|
| “Usually, except when…” | A policy and its exceptions. | Rule plus counterexample |
| “Then we wait for…” | A dependency or missing event. | Time and external owner |
| “Approved means…” | Competing domain meanings. | Vocabulary boundary |
| “I keep a spreadsheet…” | Unserved state or coordination. | Manual system of record |
- EventStorming is a workshop format.
- It is an evidence-gathering technique. The stickies are residue; the model is the output. Run it without someone who has personally done the work and you have produced a large, colourful diagram of your own assumptions.
- Mapping the current state means we intend to rebuild it.
- The current map records constraints and exceptions. The target map is designed by deleting waiting, duplicate entry, and decisions the system can safely make—not by automating each existing step. Teams that skip the current map usually automate the invented steps and miss the real ones.
- Hotspots are problems to resolve in the room.
- They are design evidence to carry forward. Resolving a vocabulary collision live almost always means the most senior person's meaning wins, which destroys exactly the information you convened to collect.
When this is the wrong move
Skip the session when a formal specification already governs the process more precisely than a workshop can, when the process is a single automated step with no human hand-off, or when this team has mapped this workflow twice in six months and nothing changed—that last case means the blocker is an unmade decision, not missing knowledge, and a third map is a way of avoiding it. Where there is genuinely no current state, prototype and observe real behavior instead; there is nothing yet to elicit.
Skill: read design evidence from a workflow
Why begin with domain events?
Two teams use “approved” differently. This signals:
Why map the current state first?
Practice: tell one real story end to end
Invite one domain expert, product, design, and two engineers. Map a recently completed real case as events. Add commands, actors, policies, external systems, waiting time, manual work, failures, and vocabulary collisions. Finish by writing three candidate boundaries and the evidence for each—do not draw deployables yet.
In the lab and the capstone. The lab's phase-4 checkpoint asks you to do this against code rather than a whiteboard: recover the workflow the existing returns package implements, and mark where its vocabulary changes meaning between modules. The finished artifact is the workflow map in the strong capstone packet—every hotspot it records is used later by a driver, a contract, or a rollout gate. Compare with the weak version, which lists the same steps with no actors, no waiting, and no collisions, and so supports no later decision.
Reveal: candidate boundaries from the returns map
Eligibility owns policy interpretation and a decision with reasons. Return journey owns customer-visible progress and communication. Refund settlement belongs to the existing payments context. These are model boundaries, not necessarily three services: a modular monolith can enforce all three while one small team owns the initiative.
- In two sentences, explain to a new lead why a list of past-tense facts finds better boundaries than a list of nouns.
- Take one initiative you are on this week. Name the workflow you would map, the one real case you would ask for, and the specific design decision the map would change.
- Predict the failure: if that team never maps the workflow, what breaks in a quarter? Name the field, the two components that will both write it, and the incident that follows.
Your win
You can use a real workflow to discover domain language, rules, waiting, external dependencies, and candidate boundaries before committing to data models or deployables.
Read and watch deeper
- Introducing EventStorming, Alberto Brandolini — the canonical guide to events, commands, policies, hotspots, and collaborative modeling.
- User Story Mapping, Jeff Patton — ch. 3–5: tell the whole story and build shared understanding through activity.
- Domain-Driven Design, Eric Evans — ch. 2 and 14: ubiquitous language and maintaining model integrity.
- EventStorming, Alberto Brandolini — the technique's own site: workshop formats, notation, and the big-picture-to-design progression.
- Reference: Initiative Playbook · workflow map, and glossary: bounded context.
Give an anonymized workflow transcript to your agent-teacher and ask it to extract events, commands, policies, ambiguities, and missing actors; validate every extraction with the domain expert.