Emerald map · mint transfer
Diagnose real workflow problems and leave systems people can run. Same sequence every time.
Complexity Mapping
This is the reference version of the method. What each step does, why it exists, and what done looks like.
What happens
Watch how the work actually gets done. Not the process document, not the ideal version. Interviews, shadowing, artifacts. Pay attention to the workarounds people have invented.
Why this step exists
Official process rarely matches reality. The useful data lives in what people actually do.
Done looks like
A clear, shared picture of the current work as it really happens.
What happens
Find where the work actually hurts. Delays, rework, single points of failure, unclear ownership, repeated escalations. Look for patterns and rank them by frequency and real cost.
Why this step exists
Most teams react to symptoms. This step names the structural problem underneath.
Done looks like
A short, evidence-based list of the highest-cost problems that everyone recognizes.
What happens
Draw the current system. People, handoffs, tools, decisions, information flow, and the informal paths that keep things moving.
Why this step exists
You cannot redesign what you cannot see. A shared model removes competing mental pictures of how things work.
Done looks like
A simple, visible map of the system as it actually runs today. Everyone in the room sees the same thing.
What happens
First, notice the kind of situation you're in. Some workflows are complicated, meaning expertise and analysis work. Others are complex, meaning cause and effect only become clear in retrospect. Then design the smallest useful change that removes the real problem. Prefer changes to information flow, ownership, or rules over adding more process or tools.
Why this step exists
Heavy redesigns often fail to get adopted. Light, high-leverage changes are more likely to stick.
Done looks like
A clear, prioritized set of changes that directly address the named problem, no bigger than necessary.
What happens
Build the documentation, workflows, and tools with the people who will run them. Co-creation is required. The solution has to fit the room.
Why this step exists
Systems designed without the operators rarely survive contact with real work.
Done looks like
Working documentation, workflows, and ownership already in the hands of the people who will use them.
What happens
Hand over ownership completely. Runbooks, decision rights, training, and success criteria. The test is simple. Can the team run and improve it without me?
Why this step exists
If the team still needs me, the engagement is incomplete. Transfer is the actual deliverable.
Done looks like
The system is running under the team's ownership. I am no longer required for day-to-day operation.
How the sequence is used
This is the order used in every engagement. Some clients only need the Diagnostic (steps 01–04). Others continue into Build and Transfer. The sequence stays the same. Only the depth changes.
DEVCNX · admit one conversation
Bring the workflow problem. I'll name what's underneath it and the first move worth testing.