Documentation by Capitulation
Why you should host the argument your team has been avoiding – right now.
It is the afternoon of the second workshop day. The room has been working on the order-to-cash process since lunch yesterday. Energy is low. The post-its pattern on the whiteboard looks almost like structure, the end is in sight. And then someone, probably from accounting, says:
“And then it goes for review.”
There is a pause. Then a soft murmur of agreement.
The process facilitator writes “REVIEW” on a sticky note, puts it on the wall, and asks:
“Who reviews? What is the exact sequence of the review? Is there any automation?”
A few people look out the window.
Someone quietly sighs.
The accounting person breaks the silence:
“It’s a manual task, it runs differently every time.”
The facilitator moves the post-it to the “HEAD OF ACCOUNTING” swimlane and glance at the team:
“Okay?”
The team nods and moves on.
And what just happened in that moment is the entire subject of this essay: they capitulated to the nasty parts of process documentation.
In reality, that one “Review” sticky note represents at least three different reviews:
Sales sometimes pre-approves a discount, depending on who the customer is and how the quarter is going.
Operations does its own check on stock and lead times, which sometimes blocks the order, and sometimes proceeds based only on someone’s intuition.
Finance sometimes does a credit check against the customer’s file. Or against their relationship with a specific sales rep.
Each of these has different inputs, different timelines, and different ways of going wrong. The team in the room knows all of this. Two of the people in the room have, in fact, complained bitterly about it only a few weeks ago.
But none of them is going to speak up this afternoon.
The post-it now says “REVIEW.” And the diagram will also say “REVIEW.” And six months from now, when an order falls through because two of the three reviews silently stopped happening, some highly paid analyst will look at the diagram and wonder:
“Who reviews? What is the exact sequence of the review? Is there any automation?”
The diagram that the team just agreed on is not a record of how the work flows. It is a record of what could be said in that room, with those people, on that afternoon. This is “truce documentation”: when a mapping workshops documents a peace treaty, when the process map doesn’t show how the work flows, but what a tired team agreed to agree about.
The team did not surrender to a bad process. They surrendered the chance to talk about a messy truth they are a part of. Why? There are four causes:
1
The first is a behavioral property of the team: conflict aversion. It is the active but mostly unconscious act of maintaining a “low temperature” mood in meetings, the prioritizing of a space from which everyone can return to their desks lighthearted. Such teams do not consciously suppress dissent, but genuinely experience disagreement as a problem to be resolved. That resolution is not necessarily clarification, but the restoration of social calm. In practice, this looks like someone reframing a real disagreement as a misunderstanding, or a vocabulary issue, or something to be parked for a follow-up conversation that everyone in the room knows will never happen. During process work, this burns a blind spot into the diagram: as a box that merely says “review”, but actually stands for complex and contentious core workflows.
2
The second reason is the process mapping facilitator. This is the most uncomfortable part of my diagnosis, because the BPMN or Aris or whatever practitioner is usually not bad at their job – it’s just that there’s a job in that room that they don’t see and don’t know how to do.
Most BPMN consultants are systems people. They were trained on the notation. At worst, they’re just running the room through a script, filling out a set of boxes on slides. At best, they’re technical mentors: They will teach you, patiently, for the hundredth time, the difference between a parallel gateway and an inclusive one. They can point out recursions and redundancies and clean up your sequence flow. They are really competent regarding the technical half of the engagement.
They are also, almost always, people who came to this work because they felt drawn to technical precision tasks, to standardized notation and systems – not to tense rooms awash with dozens of agendas. When the room goes quiet at the wrong moment, they hear it as an opportunity to move on, rather than a blaring klaxon. They are not refusing to do the social work; they simply do not know that there is social work to do.
But hearing that deafening silence is half the job, the half that determines whether, down the line, a diagram survives contact with reality. The buyer is getting only half the result, with no malice on anybody’s part, while paying full price.
3
The third reason is fatigue. Workshops are tiring in a particular way that is unfamiliar to people who do not regularly run them. Two days of process mapping, especially in organizations that are mapping for the first time, is not only cognitively but also emotionally taxing.
Not only has the team been pulled out of their actual job for a few afternoons, possibly forcing them to make up for lost time after hours. It has also been asked to air any desparate workarounds, in front of each other, with an outsider. By the afternoon of day two, everyone’s just happy to leave, and the fastest way out of the room is to agree. And the fastest way to agree is to go vague.
“Review” is easier to agree on than “request credit report from finance”, “retrieve customer history”, “assess customer credit”, “review output with team lead”, “create credit report”, and “review credit report”, because everyone knows that they’d also have to map out how all these depend on Marc from invoicing being in the office or not. For a tired, strained group, vagueness is the path of least resistance, and the diagram tends to lose all detail before lunch, in the afternoons, and after a few days of mapping.
4
The fourth reason is the mapping mandate: whether the task is to unearth the full reality of all informal processes or to just map how things are meant to run. Informal processes deal with the chronically absent CFO’s mood, which is its own decision gateway in the credit-check process. Or the key account manager who has verbally agreed with the two largest customers that orders below a certain threshold will skip the formal approval. Or the team lead who knows perfectly well that the official handoff from sales to operations is performative, because the real handoff happens in a Customer Service Teams chat that has been running for two and a half years. If documenting informal process, how things “really” run, is not part of the mandate, none of these things are going to make it onto the map this afternoon. And the people who would put them there even without a mandate have been in the company long enough to know what happens to people who put them there. The diagram does not say what they know. It cannot.
What you get, when these four conditions play out, is an aligned document everyone agrees on. The document is presented and signed off on.
Three months later, somebody is configuring an ERP based on this, but the the result doesn’t match anyone’s actual everyday work. The “review” piece is now represented by the ERP’s default sign-off mechanism that has no similarity at all with what the teams actually do (“request credit report from finance”, “retrieve customer history”, “assess customer credit”, “review output with team lead”, “create credit report”, and “review credit report”). The teams complain that the ERP is not good, and management rolls their eyes, either at their teams’ resistance to change, or the ERP implementers’ inability to just build what is on the process map. Countless review loops bloat the ERP implementation; the hours the cool new system saves are spent on debates about it.
Six months later, a senior team member is unexpectedly out for a few weeks. Their replacement follows the process documentation verbatim, but the teams complain that they aren’t doing what they’re being asked to do.
A year later, a process automation project commences and immediately stops, because they realize that the process documentation is off and they first need to figure out what the actual process is. The decision is made to map the processes again – and a whole new team of BPMN experts, once more, breezes past the silence on the second workshop day that should have made them stop and explore.
This is what truce documentation with a single-minded focus on technicality costs. It looks cheap on the invoice, because what you paid for was a workshop and a deliverable, and the workshop happened and the deliverable arrived.
But there is a massive hidden cost:
In the system you configured against fiction and had to revise four times.
In the new hire who internalized the process documentation but still needs to shadow colleagues to master how things are really done.
And in the slow corrosion of the team’s belief that anything can ever actually improve.
They tried, after all, many times. They have thick PDFs to prove it.
The alternative is not a more sophisticated workshop or better BPMN training for the teams up front. The alternative is to handle process documentation as the social problem that it is, with experts that don’t just see it as a notation problem, but know how to handle a heated room.
An engagement that results in an honest, true map has to make space, deliberately and visibly, for the conversations that the teams have been avoiding over decades.
Nobody enjoys this. The conversation is not always polite. There is a moment, usually on the first morning, when someone who is not senior enough to be safe says something that everyone knows and no one has put on record.
Here, too, the room goes quiet, but this time the facilitator does not move on.
What follows is slow and uncomfortable: The senior person in the room hears something they probably should have heard eighteen months ago. The workaround that two teams have been arguing about for three years lands on the diagram, where it will cause more arguments. But now, at least, they are the right ones.
The diagram becomes larger. Messier. And better.
The honest workshop has more silences and more post-its on the wall. The map that comes out of it is not perfect, but the fuzzy parts of it will reflect where the organization itself is fuzzy on what is happening, accurately reflecting the many discrepancies that real work almost always creates. The map becomes a to-do list for self-improvement.
This map will occupy the team outside of the workshop as well, its gaps clamoring for clarification. This diagram is not signed off on at five in the afternoon by a tired room, but the week after, by people who recognize how much they still have to hash out. This is the conflict you need your teams to not avoid.
Everything else is a rehearsal for a play nobody is ever going to perform.
The half of the engagement that makes this possible, that determines whether the process map is true, is the half that nobody puts on the invoice, because most practitioners do not know how to do it.
The buyer who knows this in advance can compensate for it. The buyer who does not is, without realizing it, paying for a peace treaty – even though they didn’t come for truce documentation, but truth documentation.