Process Mapping: Map the Seams, Not the Boxes

A process map, freshly drawn, is a satisfying thing to look at. Neat boxes, tidy arrows, a clean left-to-right flow, every step accounted for. It is also, more often than not, a map of the parts that were never going to break, drawn in loving detail, with the parts that always break rendered as thin arrows you could miss. The instinct is to map the work each team does. The work that needs mapping is the work that falls between them.

Process mapping is the practice of drawing how work moves through an organization, step by step, and the value of a map comes less from the action boxes than from the decision points and handoffs between roles, which is where work actually breaks. Carry that emphasis through the whole exercise, because it inverts how most maps get drawn.

The practice is older and more deliberate than the tidy diagrams suggest. The flowchart was formalized in 1921 by Frank and Lillian Gilbreth, the industrial engineers who pioneered motion study, and adopted by the American Society of Mechanical Engineers as a standard set of symbols. A century later it has hardened into BPMN, the Business Process Model and Notation standard, with its own elaborate vocabulary of gateways, events, and pools. The notation has grown rich. The instinct underneath it has not changed and has not improved: draw every step, in order, and the picture will tell you where the trouble is. It rarely does, because the trouble is almost never in a step. It is in the space between two of them, and that space is the part the standard symbols render thinnest.

What are the symbols you actually need in a process map?

A process flow diagram can use dozens of symbols, but four carry nearly all the meaning, and two of them carry the risk. Good business process mapping spends its attention on those two.

• Terminator. The oval that marks where the process starts and ends. Cheap to draw, easy to agree on.
• Action. The rectangle, a single step of work. These are the boxes teams over-detail, because they are the parts each team already understands.
• Decision. The diamond, an if-then fork. This is where people diverge unseen, each picking a different branch, and where a process splinters into a dozen private versions.
• Handoff. A crossing between swimlanes, where work passes from one role to another. This is the single highest-risk shape on the map.

Why do the seams break and the boxes hold?

Because of a pattern named in 1968 by a programmer named Melvin Conway, and it has held up for half a century. Conway’s Law states that any system an organization designs will mirror the communication structure of that organization (Conway’s Law). Applied to a process map, it predicts something specific: the process will fragment at the boundaries between teams, because that is exactly where communication is thinnest and where no one owns the transition.

This is why a lead goes cold in the gap between marketing and sales, why a signed deal stalls between sales and onboarding, why a frustrated customer falls between onboarding and support. The work inside each team is fine. The seam is unowned. A process map that renders those seams as thin arrows is hiding the only thing worth seeing, which is why so much process mapping looks complete and improves nothing.

The pattern is not folklore. Researchers at Harvard and MIT tested Conway’s hypothesis directly, comparing software built by tightly coupled teams against the same kind of software built by loosely coupled ones, and found the products did mirror the organizations that made them, closely enough that they called the effect “the mirroring hypothesis” and confirmed it across multiple industries (MacCormack, Baldwin & Rusnak, Harvard Business School). Where two teams barely talked, the seam between their work was brittle. The org chart printed itself onto the product. A process is a kind of product too, assembled by the same fragmented organization, and it inherits the same fault lines. Draw the org chart and you have, in rough outline, already drawn the map of where your process will leak.

Look at where the detail goes in a typical mapping effort, and the misallocation is plain.

There is a reason teams over-draw the boxes. The work inside a team is the work that team understands, so mapping it is comfortable and quick, and the map fills up fast and looks thorough. The handoff is the part no single person fully owns, the part that requires two teams in a room admitting where the baton gets dropped, and that conversation is slow and slightly uncomfortable. So it gets rushed. The map ends up detailed exactly where detail was cheap and vague exactly where it was expensive, which is the opposite of useful.

How do you do process mapping that actually helps?

Start at the seams. Walk every handoff and decision first, name who owns the transition, and write down what “done and handed off correctly” means at each one. Only then fill in the action boxes inside each lane. The map you want is honest about its fault lines, not flattering about its flow. The concrete moves:

• The seam inventory. Before any boxes, list every point where work passes from one role to another. For most sales motions that is a short list, lead to SDR, SDR to AE, AE to solutions engineer, closed deal to onboarding, and each entry is a known risk until proven otherwise.
• An owner per transition. Name the single person accountable for each handoff, not the team. A handoff owned by “both teams” is owned by neither, which is the unowned-step problem wearing a friendlier label.
• A definition of done at the seam. Write what “handed off correctly” means in checkable terms, what must be true and recorded before the baton passes. A handoff with no definition of done is an invitation to drop it.
• Boxes last, and only as deep as you will run. Fill the action steps inside each lane after the seams are solid, and stop at the level of detail you genuinely intend to follow and inspect. Detail past that point is decoration.

The map you produce this way is honest about its fault lines, not flattering about its flow. Once the map is right, the next move is to make the seams hold in practice, which is a delivery and inspection problem covered in process documentation and workflow documentation.

A drawn map, though, is only a diagnosis, and a diagnosis cures nothing. This is where most mapping efforts end, with a handsome diagram in a shared drive and a process that still leaks at exactly the seams the diagram exposed. The field data shows the gap: 89 percent of the 198 sales leaders we surveyed have a defined process, and only 36 percent say their reps follow it (The State of Sales Enablement 2026). A map is the defined process made visible. Closing the 53-point gap between defined and followed is a different job, and it happens at the seam, in the flow of the work, not on the diagram.

What we recommend

Invert the usual order. Map the decisions and handoffs first, in detail, because Conway’s Law guarantees the process leaks at the seams between teams, and the action boxes inside each team are the parts that already work. Name an owner for every transition, define what a correct handoff looks like, and treat any seam without an owner as a known defect, not a detail. Then remember that the map is a diagnosis, not a cure: a process leaks at the seams whether or not you draw them, and closing the leak takes delivering the right step at the handoff and inspecting that it happened. Map to see the fault lines. Fix them where the work is.

From here: the broader practice in process documentation, the detailed-step view in workflow documentation, and the reusable structure in process map template.