A few years ago I had dinner with a team of implementation consultants from one of the Big Four. These were the people who fly into global enterprises to bring a major project- and resource-management platform to life. These were absolute wizards, certified to the hilt, and knew the system to its corners. They wielded obscure configuration options in a way the people who built the tool never considered. They were the absolute masters of the craft.

At that time, my own company was using that very same tool, and I shared how even as technology adoption experts, we were struggling with, well, adopting the technology, despite clearly seeing its promise. We do highly complex work, and anything that can help wrangle that gets us very excited.

One of the experts then mentioned, with the particular pride of someone sharing a productivity hack, that he only opens the application once a week, on Fridays. He keeps his real work where his real work had always lived: in his notes, his messages, his head, and on Friday afternoon he sits down and transfers the week’s work into the system. All neat and tidy, so that clients are impressed when they see his dashboard, and so that his firm’s dashboards show the right colors on Monday.

This was not a sheepish admission of “do as I say, don’t do as I do”. This was nonchalant signaling of mastery and seniority.

I asked why he doesn’t just keep the tool open at all times and get everything done within it, eliminating the chore of copying everything over on Fridays. His reply was blunt: because everything you do in this highly structured, amazing tool requires, even when you’ve mastered it, attention and thought. Using it will always pull you out of whatever situation you’re in: a conversation, an analysis, a complex train of thought. And for someone doing complex and challenging work, such structural distraction was professional suicide.

This took me by surprise: the single most expert users of this platform, the people whose entire profession was to get other organizations to adopt it, had themselves not adopted it, and found it ill-suited for managing the complexity it was built for. They experienced this not as failure but as fluency – because in their hearts, the system was for someone else, in another situation. It was meant for the client’s teams, for their dashboards, for their work, but not for the way they themselves prefer to work.

The client’s version, the one with a budget attached, usually runs like this:

A large enterprise buys a well-regarded system.
The project gets a name, aw kickoff, and a countdown.
The integrations connect cleanly, security signs off, data migrates on schedule.
Training is thorough: high completion rates, good spirits, no complaints.
On the morning of go-live there is cake; the project report is a wall of green.

Six months later, somebody looks at the usage numbers, and adoption is barely at twenty-two percent.

This means that four out of five tasks that were supposed to run through the new system are still done the old way, touching the new system only occasionally, when they really, really must. The dashboards for the higher-ups remain either empty or inaccurate. Productivity takes a hit, because everyone now additionally blocks an afternoon every week to fulfill their reporting obligations in the new tool.

The project lead cannot explain it. He bought a genuinely good tool! He taught everyone to use it. By every input he knows how to measure, the rollout has succeeded. But the thing the rollout was for – people actually working in the new system – is not happening.

This is the most expensive recurring puzzle in enterprise technology. And the reason it stays a puzzle is that nearly everyone involved quietly carries the same false belief: that training produces adoption.

It does not.

Training produces familiarity with an interface, but not a routine revolving around it. The consultants at that dinner were proof of this, holding the highest possible familiarity and the lowest possible adoption in the same hands, and calling the combination expertise.

Everyone has dishes they cook from memory. You did not stop looking at the recipe because someone certified you had it down, you stopped because you made it often enough that the looking became unnecessary. You wanted the outcome frequently enough that repetition built the thing no training session provides: routine.

Then there are the dishes you make twice a year, for a specific occasion. You need the recipe in front of you every single time. It does not matter that you have technically made them dozens of times across a decade; twice a year is not enough for anything to stick.

No amount of instruction will move the twice-a-year dish into your routine. The problem isn’t that you lack knowledge, the problem is that you do not make it often enough because it does not slot well into your everyday cooking.

A tool that fits the daily flow of work is absorbed fast, without effort, through sheer repetition. Almost none of that routine is created by training. The tool that does not fit requires starting from scratch every time someone is forced to touch it, and remains a slow chore – no matter how good the original instruction was.

The Friday consultant was making the twice-a-year recipe, once a week, forever.

This distinction sorts every tech rollout into one of two situations that are routinely mistaken for each other:

In the first, the gap is knowledge. The team works in a way that fits the task, and the new tool does roughly what they already do, in roughly the order they already do it. The only thing standing between them and using it is knowing which button does what. In this situatuin, training works wonders for adoption, because tool knowledge is the whole gap, and teaching what buttons do is what the teams need to get going.

In the second, the gap is behavior. The tool demands a way of working that either doesn’t fit the task, or doesn’t fit the teams: different sequences, different habits, a different shape to the day. Training cannot ever bridge this gap. Not because the training is bad, but because knowledge is not what’s missing. You are asking people to change routines, and routines are not something you know your way into. They cost attention, effort, patience, and the willingness to be temporarily worse at your job while daily operations continue underneath. That cost is often worth paying, but it has to be budgeted as one.

It almost never is.

Change management through training treats every rollout as a knowledge gap. So even when the gap is behavioral, it sells a tutorial on new screens as the answer. To a budget holder, the method is seductive: training sessions can be scheduled, attendance can be tracked, completion rates can be reported. But the required attention to behavior does not vanish just because nobody is addressing it. The cost of this discrepancy gets paid anyway – involuntarily, by individuals, after hours – in the form of workarounds that route tasks around the system and into someone’s head, or an unofficial chat, or the person on everyone’s speed dial who absorbs into herself the gap the project never acknowledged.

None of these informal workarounds show up in a status report. Money spent on the platform is real and visible. Hours logged in training are real and visible. Completion rates on the learning trail are real, visible, and reassuring. But not one of them measures whether someone’s working day actually changed. Not one of them shows if the new tool has a hidden cost that the teams need to endure. The organization is reading training attendance as operative outcomes – the way you might weigh the groceries and conclude that dinner is made.

The research on technology acceptance (the real, academic research, not the consultancies’ whitepapers) has spent decades trying to predict under which conditions teams will actually use a new system. The predictors are now well understood and not exotic. Does the person believe the tool will help them do their job? Do they believe it will be easy to use? Training nudges the second, a little, temporarily. It does not touch the first at all.

But there is a third predictor, and it is the one that matters here, because it does not predict intention – it predicts actual use. The academic term is “facilitating conditions”, and the methodically complex, but actually quite plain question it asks is: does this person’s real day – their workflow, their available time, their actual support structure – make it possible for them to use the new thing?

This is the question of whether a tool fits someone’s random Tuesday.
If the superb project management suite matches the Big Four’s workdays.
If technological transformation is understood as just shopping, or invasive surgery on the very essence of how an organization works.

Most importantly, it is the question training plans don’t ask. It is the question nobody budgets for when the behavioral gap stays invisible. It is where rollouts go to die.

Teams end up here not because they were under-trained or unconvinced, but because the conditions of their working day did not support the new routine.

Most of these calls are easier to make before an organization commits to a new technology; the decision whether to go for it or not is easier to make when you have all the costs and numbers in front of you.

Sometimes this means that the technology purchase won’t happen, simply because the cost of change turns out to be way beyond any of the financial benefits that could arise from it.

Sometimes it means that another technology is better – something incrementally improved instead of a full transformation.

And sometimes the key to all of this is simply budgeting for a bit more time – giving the teams a less steep incline to climb to a new level of work.

The trouble started in the second week. A large German manufacturer had rolled out an app that let its assembly-line workers trade shifts: propose a swap, someone accepts it, done. It was built to free their foremen of menial work. Two weeks in, these same foremen were overriding most of the shift changes and complaining about the chaos the app was creating.

The app was first updated, then tweaked and then thoroughly reworked, but the overrides continued. Then an approval step was added to give the foremen more control. Then the notification logic was adjusted. Then the interface was rebuilt. And still: the overrides continued unchanged, albeit through a significantly more pleasant interface.

After enough rounds of this, somebody went down to the floor and watched. No survey, no workshop, no interviews, just a shift observed from a glass cubicle right next to the line.

The app aimed to replace busywork, and it did, splendidly. But it also replaced a ritual: for decades, a worker who wanted to trade a shift went to the foreman and asked. That swap request, it turned out, had been the plant’s only recurring one-on-one between a foreman and each of his workers. Two minutes, maybe three, about something small and safe, initiated by the worker. Inside those minutes, everything else surfaced: that someone’s kid was being bullied at school, that a good machinist had oddly precise questions about notice periods, that the new hire was avoiding someone. A foreman with a just-in-time team of thirty cannot schedule candor, but the swap conversation produced it on its own, at a steady trickle, for free. Swapping shifts in a messy excel file had been menial work for the foremen, yes. But it was also the plant’s early-warning system, and a genuinely good app had just switched it off.

The shift swap conversation was an informal process. An essential one, with tremendous impact on the trajectory of everyday operations. It was recurring, load-bearing, and consequential, but existed out of view of every position that could own it, staff it, or fund it. No document, no dashboard, no org chart noted its existence.

In the 1970s, astronomy ran into this exact problem. Vera Rubin found that stars at the edges of galaxies were moving far too quickly. Given what was visibly there – stars, gas, dust – galaxies spinning at that rate should fly apart. They did not. So either gravity was failing at galactic scales, or there was something out there that didn’t emit light, didn’t reflect it either, and revealed itself only through its influence on everything else. Astronomers named it dark matter, and by current accounting it outweighs all the visible matter in the universe about five to one. Today, fifty years on, no instrument has caught a particle of it yet. Its entire existence is proven by the motion of everything else: things behave as if it were there.

Informal processes are the dark matter of organizations. Direct inspection in a mapping workshop or process review won’t find them; what gives them away are behaviors and dynamics that formal activities alone cannot account for. In the case of our assembly lines, they made things run smoother, and a surplus of smoothness isn’t something an organization tends to investigate.

The origins of informal processes are worth taking apart, because their origin determines how to detect and handle them.

Some informal processes are fixes: When a formal process has a flaw – a missing step, an approval that arrives after the moment it was meant to govern, a system that demands information nobody has yet – the people inside it build a bypass so the work can survive the defects of its own procedure. The organization corrects itself, quietly, without a project or budget line. While this is, in general, a good thing, it also makes the defective formal process behind it appear to work. This is read as proof that the design was sound, delaying much needed improvements.

Other informal processes are improvements that live in the teams’ heads, because nobody ever turned them into structure. When an obviously better way of doing something emerges – found by accident, imported by a new hire, or worked out during a disruption – it tends to spread sideways, peer to peer, without ever passing through the hands of anyone entitled to make it official. Ten years later, the improvement is fully metabolized, and is now how the company actually does something, while the official procedure ages undisturbed on a sharepoint, like a national anthem everyone stands for and nobody sings.

And then there are the informal processes that are sediment, the residue of human beings working together. A handoff detours through a third department because, fifteen years ago, two long-gone managers stopped talking to each other. A weekly call exists because of a crisis nobody on the call was there for. A specific decision only happens in a specific Teams chat because everyone wants it on the record. Every company of any age is still burdened with these consequences of an old friendship, an old feud, or a misunderstanding nobody ever cleared up.

Very little of this informal layer is hidden or concealed. Most of it is invisible for the opposite reason: because everyone knows. A thing can be so thoroughly obvious to everyone that nobody has said it aloud in years, and what is never said never becomes a slide. Ask any team to walk you through how their work gets done and they will walk you through the formal system, honestly and completely, and never mention the informal part because it’s so obvious to them. Like explaining how to walk without ever mentioning shoelaces.

During ongoing operations, none of this needs to be visible, none of it needs to be actively considered. But when there’s restructuring, or new systems, or a merger, any change that doesn’t consider the informal layer runs the danger of unexpectedly breaking something important – like the shift app did.

The practical conclusion of this is modest: The informal layer belongs on everyone’s agenda. Ideally in mapped form, but at least assumed to be there, asked after, and treated as real whenever processes are reviewed, redesigned, or handed off to a system. Astronomers did not wait to see dark matter before putting it in their equations. A process review is better off to extend the same courtesy to the part of the company it cannot see. But the goal should be to not only map the known unknowns, but also the unknown unknowns.

Formal processes are a pleasure to map: They have owners you can interview, documents you can request, and systems that enforce their steps. The whole landscape of business activities can be assembled in conference rooms. Process experts love this: the satisfaction you get from neatly mapping something intricate, precise and important is why many people get into the profession.

Mapping the informal layer is a fundamentally different craft. You cannot schedule the mapping of an informal process by name, because it doesn't have one. It surfaces through attention, experience, and presence: by seeing motion that doesn't fully match the official plan, by reacting to the weird silence in a formal mapping session, by sitting in on the shift change, and through the sideways questions sociologists live to ask: "What happens when this goes wrong? Who are you supposed to call, and who do you actually call?"

Most process consultants stay clear of such imprecise, fuzzy territory because it is slow, destroys deadlines, and demands a skillset that has nothing to do with notation. The visible mass of a company is easy to chart, so the professionals chart it, beautifully. The maps just tend to come out weighing a good deal less than the companies they describe.

I was late to the meeting, and what greeted me as I quietly stepped in was the Gartner Hype Cycle, projected through floating dust. That omnipresent curve with the tall peak and the long dip in the middle. A bright red dot sat at the bottom of the dip: “you are here”. I knew every soundbite that was about to be said in that room by heart, because I had heard them all before, in other rooms, about other dots.

The meeting was about a CRM system that had gone live some months earlier. The team that built it had been sure of their work, and the confidence was not misplaced: The system was, by any measure I could apply, the best possible version they could have built.
The active use dashboard, however, sat at fifteen percent. Only fifteen percent of the people the system was built for were using it, even though everyone had been trained and certified on it. And yet, they were running their day the way they had always run it: in spreadsheets, inboxes, and phone calls. As if the launch had happened to some other company.

The consultancy that had built the system had several people in the room, and one of them, a senior consultant of perhaps twenty-eight, stood in the projector’s beam and walked the room through the curve with eloquence, grace, and empathy: the peak of inflated expectations, the trough of disillusionment, the slope up and out. “Adoption always dips after go-live,” she said; it is expected, it is in the literature. She may well have believed every word, but I didn’t. This made no difference: the slide did its job – to spin the catastrophic fifteen percent from a failure into a planned station on an anticipated path.

It is worth being precise about what was actually on that slide.

The Hype Cycle is not a natural law, but a marketing story. An analyst named Jackie Fenn drew it at Gartner in 1995 as a vivid way of talking about the trajectory of new technologies, one that would get people to subscribe to Gartner’s research services.

It was not based on research data and never substantiated its predictive claim. It was mostly built on narratives about how technology introductions went down in the ‘90s, when the world was first exposed to a new tempo of technological strides. It was also always about how technologies arrive in the market at large, not in a specific organization.

But because it is so poignant, so intriguing and relatable, it somehow hardened into canon. Now, three decades on, it appears in board decks and go-live meetings the way a geological survey appears in an engineering report, as if the peak and the trough were essential realities of the terrain that any serious plan must account for. “This,” consultants will have you believe, “is how technology introductions must go. And it is fine.”

As it was becoming more and more normative, researchers did eventually go looking for the cycle in the wild. The standard review – Dedehayir and Steinert, 2016 – found weak empirical support and no reliable mechanism. And when you read two decades of Gartner’s own annual cycles side by side, the railway dissolves under the train: most technologies placed on the curve never reach the plateau at all, and simply vanish from one edition to the next. Others skip phases, or jump backward, or appear once and are never seen again. Even in Gartner’s own editions, the trough of disillusionment behaves less like a mandatory stage that technologies pass through than like a common failure pattern, stylized into a planned stop and requiring nothing of anyone.

There is actual value to something like this, and it is anesthesia; the dip works like an epidural for bad rollouts. The technology falters, the technology recovers, and it was all just a phase, because you do not hold a train responsible for stopping at the station. So nobody holds the rollout team responsible either; everyone gets a second chance at saving face and making it work, and the twenty-eight-year-old senior consultant gets to sell additional trainings.

As someone who’s seen this run differently, without a dip, on a regular basis: the trough is what it feels like to discover (all at once, and under load) things that would have shown up in advance – if anyone had looked.

You see, the economists have a curve of their own, and theirs was measured rather than sketched. Erik Brynjolfsson calls it the productivity J-curve: when a genuinely new technology arrives, it is only one part of a fully functional purchase.

It reveals that a technology never arrives as a free-standing, monolithic investment: to function at all, let alone pay off, it needs to be flanked by “complementary investments”. These are unglamorous and routinely skipped housekeeping items, and researchers agree that these, rather than the purchased technology, are the actual asset being created, since they remain in place, functional and relevant even after the technology they accompanied is eventually replaced.

So what are these unglamorous, intangible investments? They’re things like a detailed assessment of the behavioral properties of the teams tasked with using the technology, so that the implementation can be tailored to them. Or the documentation of how processes actually run in the organization (as opposed to the version a tired room can agree to) so they can be tweaked to better extract the value of the new technology. Or the scoring of workplace routines that the new tool will displace, in order to understand how much the business will slow down in the first weeks with the new tech.

This is a massive correction of the traditional growth accounting framework, which merely contrasts the cost of an investment with direct potential gains, resulting in not only a more realistic landscape of both cost and potential, but also data that makes it possible to fully avoid Gartner’s unavoidable dip.

Once these costs are visible, some changes may need to be sequenced differently, or might turn out to not be worth making; the speed records in typing have mostly been set on the Dvorak keyboard layout, but the world types on QWERTY, because the shift would be too costly.

In essence, avoiding the dip is about reading, in advance and team by team, an organization’s absorptivity: how much new working reality it can take at this particular moment.

This absorptivity varies across the organization, and cannot be asked of a department head or read off an org chart, because it is impacted by the countless workarounds, side channels, and informal processes that remain invisible at the strategic level.

None of this is what organizations mean when they speak of assessed readiness. What they mean is the readiness assessment in the project plan: is there a steering commission, is there a training plan, are there enough licenses. These assessments can be green across the board and still reveal nothing about the teams’ capacity to bear the implementation during ongoing operations – or about the real cost of the complementary investments still due before the technology can work.

The readings of an absorptivity assessment tend to come back uneven: some teams can take the changes with little help, others are at capacity and would normally get flagged as “resisting,” just because they objectively can’t take on anything new.

This unevenness rarely sorts the way anyone expects it to: in one unit, the managers had spent months lamenting that the older colleagues would be the problem, that they would not go along fast enough. The absorptivity check said otherwise. The older colleagues had switched systems a handful of times in ten years and knew how to handle the strain. The junior colleagues meanwhile were still absorbing the larger learning curve of corporate life itself, and their first mastery of the outgoing system was hard-earned. “We had just found our stride with it,” one of them said, “and it was hard, and now you’re rearranging it all again.”

Nobody took the uneven reading as a reason to call the whole thing off. It became the shape of the plan. Each unit got a frame it could work inside, with enough structure to produce what the strategy needed, and enough room to enact it in a way that fits the realities of the teams on the ground. The complementary investment was sized to the reading rather than to the vendor’s performance narrative.

And in the end, there was no dip.

The people running the change spent only part of their budget. Trainings did not have to be repeated a year later, because the routines had formed the first time around. There was no trough to explain. And nothing about that was luck.

I still see the curve and the red dot everywhere, always when something is not going right, always saying the same thing: you are here.

It looks like navigation, and works like absolution: nobody is at fault, this is a station, the train will move again.

That is what the curve sells, why a thirty-year-old sketch is still projected onto walls: forgiveness, issued in advance, for everything nobody looked at.

The teams that look never need to huddle around the curve. They arrive somewhere quieter, where there is nothing to forgive.

The room had been decorated, which is how you knew it was serious. In the years the company had occupied this building, the cafeteria had been decorated exactly three times: once for an acquisition, once for a product launch, and now for Steven.

Steven was turning thirty. Not in age - in tenure. Thirty years in the same company, most of them spent keeping its software systems alive. The evening was genuine: The founder, who rarely spoke at internal events anymore, abandoned his notes three minutes in and told the room about the night Steven had rewritten a payment interface in 2008 because a vendor’s update had quietly broken the invoicing chain and Monday was month-end close. The room laughed. Someone who had been there shouted something funny that Steven had said that night. Steven shook his head with a grin.

More stories followed. The ERP migration that nearly bricked the production environment, where Steven wrote a live patch while on the phone with the vendor, manually keeping order processing alive until morning. The CRM integration he built over a weekend because two newly procured systems had no way of talking to each other and the sales team needed pipeline data on Monday. The security incident where IT’s remediation plan would have taken the customer portal down for three days during peak season, and Steven found a way to patch it live in four hours. The room was amused and in awe in turns.

And then came the gift, a book. Not a purchased one. His team had spent months on it in secret: handwritten notes, emails, photos and stories from colleagues past and present. Thirty years’ worth of clippings. A retired manager had written a full page about almost not hiring Steven. A former intern, now a CTO elsewhere, contributed a note saying that watching him work a production incident taught her more than her degree. It was bound properly - cloth cover, his name embossed. When Steven opened it, the room went quiet. He read the first page, closed the book, and needed a moment.

Steven’s speech was heartfelt – and mostly about his wife. Not just about her being fine with him also being married to the company, not just about enduring his absences and schedules. But also about being genuinely into what he does, and that a few of the problems in the cool book were actually solved by her. The room applauded, some remembered how he struggled before he met her. She knew all eyes were on her for a moment, and she was comfortable with that. She knew who she married. She is his third wife.

After the formal part, the inner circle stayed. I wasn’t part of that. But Steven was told, in so many words, that he was family. That the company would not be what it is without him. This was sincere and, by any measure, true.

Every word spoken that evening was, in the room’s hearing, a celebration.

To my cynical ears, after over twenty years of measuring how work actually works, every story was also a record of Steven compensating for bad systems.

The 2008 invoicing rewrite was a vendor migration with no rollback path. The ERP patch was an implementation plan with no contingency. The CRM bridge was two systems procured without integration requirements. Each page of that book was a love letter, but each love letter also a maintenance log. This was thirty years of architecture gaps narrated as devotion.

A significant fraction of this company’s operations depended on the continued presence, health, and goodwill of one person who was never supposed to be a single point of failure – and has never been paid to be one.

This is hero dependency: the condition in which an organization’s capacity to function has quietly migrated into specific individuals, because the systems that were supposed to carry the load were never fully built. The hero is not the cause of the problem, but evidence of it.

Finding a true hero is inspiring. But it is also the exact location of a gap in the architecture.

To see how a hero gets made, you have to look at the room where the work was first designed, because that is where the gap gets created. I have described that room before and called what comes out of it truce documentation: a map of the work everyone agrees on not because it is true, but because it is the version nobody has to argue about. I have also described the other way the same gap opens: through altitude, where a process gets mapped at thirty thousand feet of abstraction and nobody disagrees because there is nothing specific enough to disagree about.

Either way, you end up with a fuzzy process map that shows that, yes, orders are received, products are shipped, and payments are received, but not how exactly. The map has holes, and no hole stays empty – because someone talented and exceptional scrambles to fill it.

Each hole is a management failure. Not in the sense that someone was negligent or unkind; Steven’s managers threw him a beautiful party and meant every word. It is a management failure in the structural sense: the decision to invest more in architecture rather than rely on a person was never made. Not once, over thirty years.

Steven was never in a position to make that decision. He was in a position to either let things fail or fix them himself, and he is the kind of person who keeps things running, which is a big part of why no one ever felt the urgency to build what would have made his heroism unnecessary. His competence and eagerness bought the organization out of its own architectural debt, every day, for three decades. And the better he got, the longer it could go unbuilt.

In the presence of heroes, organizations mistake their efforts for their own competence. You night think that this is merely a subjective observation, but it is actually measurable.

In one engagement I will draw on here, we mapped a large beverage company’s internal administrative processes all the way to the individual task level. When we counted how many of those tasks were carried by a system rather than a person, the number was 22 percent. Three quarters of this organization’s admin work was people, manually checking, remembering, following up. Not because the work required human judgment in each case, but because no one had ever built internal infrastructure that would do it better. The global average for comparable teams is roughly fifty-fifty. The organizations that run well are closer to seventy-thirty. This division was diametrically opposite of this.

That is what produces a hero. Not exceptional character alone, but having to do work in an architecture so thin that it demands exceptional character simply to function at a normal level.

The Copenhagen Psychosocial Questionnaire, or COPSOQ, can help quantify the cost of this by measuring cognitive load against clinical reference points. This is not a staff-satisfaction survey that asks people whether they feel stressed, and people answer the way people answer surveys. It is not a read on morale, it is closer to a blood screening – an objective measure of capacity.

Nearly everyone in the beverage operation above was operating at levels of overwhelm that are clinically considered unsustainable. About a quarter were at levels the literature associates with the onset of burnout. But the teams were not unhappy, not disengaged, not faltering. They were burning out comfortably: while being praised for it, while getting raises, just like Steven. And they were burning out not while working the market, engaging with customers, or innovating, but while doing menial internal administrative work that everyone else was delegating to software systems.

Before we mapped and measured, the organization did not know any of this. Not because someone hid it: the late nights were visible, the cancelled holidays were visible, and the appreciation of the heroes (a big part of this firm’s culture) was extremely visible. Every piece of evidence was in plain sight.

The issue was that the lack of supporting structures was seen as destiny, as the very nature of their work, as “that’s just how we do things here.” But when they saw the measurements and risks, especially the burnout risk numbers, the conversation changed, and fast. Not because the numbers were shocking (they were), but because numbers move heroism from identity into engineering, to a task that can be tackled.

When organizations describe their reliance on extraordinary people, they don’t reach for the language of risk. They reach for the language of praise.

“If it weren’t for Steven, half of this wouldn’t run” is not filed as poor process design; it is filed under culture. And the moment a structural fact gets filed under culture, it stops being visible as a structural fact, because culture is “who we are”, and risk is “what could make things break”, and those live in different drawers in the organizational mind.

Calling hero dependency “culture” gains the organization, gains management permission to do nothing. If heroism is culture it is identity, and you do not fix identity – you celebrate it. The hero story works so well because it is an emotional, relatable story about people, and the process story is a nerdy explanation of systems. A speech about Steven makes a room cry, a presentation about a well-designed escalation matrix makes it zone out. This emotional asymmetry between the two stories favors the one that preserves the problem.

You can run a risk assessment on a server with no backup, but you cannot run it on “we have amazing people who go above and beyond.” So the hero dependency does not appear on the risk assessment, not because anyone is negligent – risk assessors are conscientious people – but because the language available for describing the hero, the warm, grateful, anniversary-dinner language, is structurally incapable of rendering them as exposure. The risk is encoded in a vocabulary that reads as a virtue.
That is what makes it invisible: not secrecy, but translation.

And this is why a typical organization cannot really hear this. You can say, plainly, in a meeting, “you are dangerously dependent on Steven,” and the room will nod, and genuinely agree, and do nothing, because the sentence lands as another version of the compliment. “Yes, he really is invaluable.” You can say “you should invest in turning Steven’s capabilities into systems,” and at least one person will hear an attempt to replace him instead of to relieve him. And even if there is agreement that operational gaps should be filled with structures rather than someone’s weekends, the prevailing instinct will be to defer this, because things are stable for now, Steven is still there holding the fort, and they will get to it once all other priorities are resolved.

Heroism is not just a powerful aesthetic; it is also a powerful anesthetic.

Making hero dependency addressable means, in practice, dissolving the heroism. Not by attacking the hero, but by descending to the level of the work:

Map the actual tasks.
Document the actual workarounds.
Measure the actual load.

The instant you do this, the heroism resolves into its components, and they are not heroic at all - they are quite ordinary, sometimes even sad, or boring. A process gap here, an undocumented decision rule there, or a system limitation that someone has been routing around for years, with notebooks and keyboard shortcuts and modifier keys worn smooth.

Steven does not vanish in this view. Instead, he finally comes into true focus, for the very first time. He becomes visible not as a marvel but as what he structurally is: a person doing, every day, the work that an unfinished architecture left undone, and being celebrated for the size of the gap he agreed to stand in. A victim of a management failure so thoroughly dressed up as culture that even he doesn’t see it that way.

The state on the far side of this, once there is infrastructure that frees Steve up to do more valuable things, isn’t cool productivity, it is sovereignty: the condition of an organization that understands its own complexity thoroughly enough to discuss its capabilities and gaps without emotional terms, without heroes and villains.

Such an organization doesn’t lose its heroes, but sends them to new frontiers instead of the engine room, so that they can do their magic on work that not just needs it, but also deserves it.

A few years ago, at the start of a process documentation engagement, we received a dump of the client’s previous process work. It was substantial – somebody had clearly put time into it. It included a full mapping of the company’s sales processes, built during a half-day workshop with senior sales leaders the year before.

One of these mapped processes, “Manage Sales Teams,” was described in exactly three tasks:

1. “Review activities of the sales representatives (ongoing, on demand).”

2. “Prepare and conduct sales team meeting to review activities.”

3. “Define actions (including owner, deadline, etc).”

It was not wrong. A person managing a sales team does, at some point, review what the reps are doing, talk about it in a meeting, and derive actions from the conversation. The diagram captured these things.

But it captured nothing else.

No target setting, no training, no task coordination, no strategy development, no account distribution, no regional segmentation, no performance criteria. The highly complex work of organizing dozens of teams of regional sales representatives across a whole continent, with different portfolios, different maturity levels, and different degrees of needing to be managed, had, in all seriousness, been reduced to: look at what they do, talk about it, decide what to do next.

Absurd.

The diagram described the process the way you might describe getting across a city: head north, turn east, walk until you’re there. Technically not wrong. But try actually getting from A to B with it.

When we began engaging with the sales leaders to map their actual work, all the stuff beyond those three banal steps, the response was almost uniform: “We already did this in that workshop last year. Now you want to do it again, but slower? No. Just make this executable in our CRM, and we’ll do the rest.”

This reaction was honest, and common.

The sales leaders were not being difficult. From their perspective, the process had been documented: They had participated in a workshop with a well-known firm, they had agreed on a diagram, and the diagram had been signed off on. Anyone now asking them to do it again was, at best, overeager.

What they did not yet see was that the agreement they had reached in that half-day workshop was an agreement at altitude, far away from operative terrain. At thirty thousand feet, “manage sales teams” looks like three activities, and nobody disagrees – because there is nothing specific enough to disagree about.

But the moment you descend to where the work actually happens, the agreement evaporates.

With this team, it evaporated fast. Minutes into their first mapping session with us, it became clear that almost every sales leader had their own sales team management practice, most of them fundamentally different from each other. On top of that, about three quarters of them were unaware that the organization actually had a detailed set of sales team management criteria, built during a long forgotten MBB engagement, designed specifically for ongoing sales steering. These had been delivered a few years ago and then quietly ignored, because they had never trickled down to the level at which the actual work happens. Because they, too, were too general.

Our mapping sessions with these sales leaders were long and contentious. We are now, some years later, on good terms with them, they now get what we had to do. But in the early weeks, we were seen as manufacturing unnecessary work and ignoring the obvious fact that “this had already been done.”

It had not been done. What had been done was the easy part.

There is a pattern here: the higher the abstraction level of a process diagram, the easier it is to reach agreement, and the less that agreement is worth. A diagram with three activities can be signed off on in an afternoon, because there is nothing in it to push back on. The abstract diagram did not resolve the hard questions, but simply hid them in generalizations before anyone could notice them.

I have written elsewhere about “truce documentation”: the maps that emerge from workshops where a team, through exhaustion, or conflict aversion, or facilitator passivity, documents not the process as it runs but the process as it can be agreed on without an argument. The three-activity sales map is a close relative, but the mistake that was made is slightly different: Truce documentation happens when the room avoids the conversation. What happened here is that the room had the conversation at the wrong altitude, and then mistook the map for the territory.

These two failures are siblings:

One is social: the team avoids the contentious points.

The other is structural: the abstraction removes the contentious points before anyone has to face them.

Both produce diagrams that look finished, but are not.

There is a cybernetics principle (“Ashby’s law”) that applies here: a controlling system needs to be capable of having more possible states than the system it controls. If your map of a process has three activities, you are equipped to steer three activities. If the actual process has thirty, but your map still has three, the actual process escapes your control. The instructions did not fail – they were never built for the territory. The simplified map gave a confident, incorrect account of what the job requires.

This is the real cost of abstraction in process documentation:
Not inaccuracy. But misplaced confidence.
The false feeling you’re aware of every factor.

I’m not advocating to always map a process down to the task level. It is crucial, instead, to match the resolution of a process map to the needs of the audience it is made for. From our experience, there’s at least four different audiences for process diagrams, each demanding something the previous one did not. Most diagrams we encounter are built for the first, and frustrate everyone by being useless for the next three.

The first audience is a meeting: a set of people who need a shared picture to have a productive conversation. Here, reducing sales leadership to a Deming Cycle is not only acceptable, it may simply be the only viable approach. A whiteboard sketch or a PowerPoint slide serves this audience fine. The trouble starts when the rough picture is mistaken for a complete one. The three-activity sales map worked for the half-day workshop. It could not work for anything that came after.

The second audience is the team that has to take responsibility for the process. This is where the gap between an illustrative flowchart and a formalized process diagram becomes most clear. A flowchart is a photograph of a key. A formalized notation is the actual key. One can be studied and understood, the other actually opens a door. An experienced team might read the simplified diagram and mentally fill in the blanks, the parts it omits, but this only works out as long as every reader fills in the same things (they never do).

At this level, the diagram has to take positions, and the positions are specific. In BPMN, there are at least four kinds of forks in a workflow: an exclusive choice, a parallel join, an inclusive gateway, an event-based split. Each has different consequences for who waits, who proceeds, and who is accountable when something goes wrong. This audience, the people structuring and doing everyday operative work, needs all of these details. A high-level flowchart cannot provide them.

The third audience isn’t people, but the system that the process will run on. BPMN 2.0 is not the most popular process notation because it is a good drawing format, but because it is an XML standard: underneath the graphical representation of a process is structured, machine-readable and executable code that a piece of software can read as a sequence of instructions and act on directly. It can instruct a CRM or workflow engine what to do. The sales leader I mentioned, the one who said “just make this executable in our CRM”? He was asking for exactly this, and did not know the three-activity diagram could not get there. A task named “review activities” means nothing to a piece of software; it needs to know what is reviewed, by whom, against which criteria, in what sequence, and with what exceptions.

The fourth audience arrived recently and nobody was planning for it: the AI agent. The same structural precision that makes a BPMN file executable by an ERP also makes it legible to a large language model. An agent can read the XML, understand the underlying process’ structure, autonomously identify which steps are candidates for automation, and ask sensible questions about handoffs. This turns boring, precise, sometimes resented process notation into AI gold; you’ll never forget the first time you input a core process XML into an LLM and see it reinvigorate a corporate unit. Structured process documentation is what autonomous systems thrive on: business objects with states, owners, verbs, history, and permissions, instead of long-winded narratives with loose ends.

Most organizations have all of their processes in first-audience flowcharts, so they can talk about them in meetings. They haven’t yet experienced maps that can feed the next three: how consultancy projects improve when the flow of tasks is transparent, how systems implementation speeds up when the mapping is done in machine readable form, and how AI tools turn from brilliant strangers to trusted colleagues when they know, precisely, how work works.

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.

When she’s on holiday, everything stops. Or, rather, it would stop, if she didn’t use the quiet moment after dinner, while the kids are running around the resort, to log in to her dashboard for 10 minutes and resolve everyone’s bottlenecks back home.

“Thanks, Sandra!” is probably the most common phrase in all of the company’s emails.

Sandra is back at her desk, a week later, Monday morning. She has been there since seven, to catch up on what she has missed.

The keyboard in front of her is worn unevenly. The actual letters are fine, but what’s gone are the modifier keys: Ctrl, Alt, Shift. The ingredients to keyboard shortcuts that bypass the interface Sandra stopped needing years ago. She does not have time for the mouse.
Whether she found these shortcuts in the manual, on a support call, or through her own trial and error, she no longer remembers. They’re in one of her notebooks now: eight of them, stacked on the left of her desk, each labeled with a year, the older ones soft at the corners from being opened and closed thousands of times. The notebook from the year when the current ERP was launched is barely held together with duct tape.

The notebooks contain things that are not in any system, or sharepoint, or process documentation, or onboarding manual. They contain customer codes that map to credit-check exceptions. They contain phone numbers for people at companies whose ERP cannot accept invoices in the format that Sandra’s ERP exports. They contain the order in which to click through a particular screen when a particular field refuses to validate.

These well-worn notebooks are the core of the firm’s digital infrastructure.

Sandra is on everyone’s speed dial. Not because she is senior (she is not) or because she manages anyone (she does not). She is on speed dial because, when an invoice does not go out, when a payment cannot be matched, when a customer escalates over a credit note, somebody upstairs will say, eventually, “Sandra will know.”

Nobody understands the work she is getting done this morning. It’s detailed, technical, and mostly undocumented. Everybody’s happy that they don’t have to do it. If you ask Sandra’s CFO what she does, they will give you a well-meaning, appreciative, but simply wrong answer. If you ask the head of accounts payable, you will get a more accurate answer, but it will still be wrong in the particulars.

Sandra is not an anomaly. She is not even unusual. She is the predictable downstream consequence of an organization designing its work at an altitude where everything seems simple and everyone can agree, leaving the details to be figured out by voluntary heroes that are willing to actually execute, or to be ignored until something breaks.

There is a Sandra in invoicing, a Sandra in fulfillment, a Sandra in master data. Sometimes there’s a Sandra in IT, and almost always a Sandra somewhere in customer service whose absence breaks something nobody can even name. They all have notebooks. They all have modifier keys worn down. They are all on speed dial and blatantly underpaid.

The interesting question is not what all these Sandras know; this is easily uncovered by putting in some effort to fully engage with what they do.

What I want to explore today is what happens when organizations never bother.

In more than 20 years of supporting technology introductions I have encountered only one organization that actively found and involved their Sandras before selecting their new tech, and that was thirteen years ago. This might simply be an inversion of survivorship bias, because organizations that do it right tend to not need my help. But it is just as unwise to buy administrative software without catering to the everyday realities of the operators as it is to purchase a truck fleet without consulting the drivers (something I actually saw happen).

You see, after a vendor demos a system to the CFO, the CFO typically gets the head of accounts payable on board. Then, diagrams of how accounting works are drawn, at an altitude where agreement is easy: a sale is three activities, an order is four steps, and new customer onboarding is two. The system is procured, implementation begins, and the new tool is launched.

The new system perfectly caters to the teams who work with its outputs, i.e. deciders who look at dashboards and approve things. But for Sandra – the person who feeds the dashboards, who flags the exceptions the report cannot show, who must click through whatever the workflow does when a customer’s payment terms are not what the system expects – nothing has improved. Quite the opposite: with the launch of the new system, everything she knew about the old system is instantaneously worthless. She must now keep invoicing alive while rebuilding, from scratch, a whole new set of workarounds that the people building the new system never heard about, because Sandra wasn’t in the room. The invoicing process slows to a crawl.

The vendor explains this drop in productivity with the familiar shape of the Gartner Hype Cycle: a trough of disillusionment that everyone must pass through, a station on a fixed railway between inflated expectations and a plateau of productivity. The framing is convenient for exactly one party in the relationship: if every technology must first pass through a dip, then no vendor is responsible for it. “The system is optimal,” they point out. “Maybe the processes need a touch-up?”

So a consultant arrives to review and fix the invoicing process. There is a high probability that the consultant will not meet Sandra in the first week. There is a non-zero probability that the consultant will not meet her at all.

This is not malice. It is the social dynamics of the engagement: the CFO makes the introductions, the head of accounts payable describes the process, a workshop is held with the team leads (six people in a room who between them have not processed an invoice in nine years) and a diagram gets built from their descriptions. The consultant adds best practices to produce a new, improved process blueprint, and it all finally makes sense. But somewhere on the wall, a sticky note says “Process the invoice.” Nobody asks what is inside the sticky note. It is truce documentation: the version of the process that reflects what everyone could agree to in a room together. And inside that sticky note – undocumented, making the process work despite all its flaws – is Sandra.

The new, improved process is aligned and the ERP adjusted, but it didn’t account for Sandra’s clicks. They still don’t go away, and instead migrate yet again, for the second time in two years. Sandra starts a new notebook to figure out new workarounds. And by the time she has stabilized the new workflow, she has amassed dozens of unused days off that she will now spend, as before, at a resort, logging into her dashboard after dinner to keep the firm alive.

This is the reality behind what is classically called “low adoption” or “user resistance,” but neither term is accurate. The tools have been adopted. The users have absorbed them into their workflows, as much as they could, but since they were built for a workshop fantasy of that workflow, and not the everyday operational reality, the tools aren’t adequate to the workflow, and the users, being competent and conscientious, have done what competent and conscientious users always do: they made it work with what they have. By routing the actual operational knowledge back into their own head.

Every new workaround Sandra now develops is a new piece of organizational knowledge that lives only in her. The notebooks get thicker. The shortcuts on the modifier keys grow more elaborate. And because each system change resets her workarounds to zero without removing the need for them, every cycle makes the dependency worse, not better. The new system, at considerable expense, has not closed the gap between what the software can do and what the work actually requires. It has moved the gap, and Sandra has filled it again, with procedural understanding only she is willing to build and maintain.

The vendor will not see this. The implementation team will not see this. The CFO will only see that everything is working and wonder what all the fuss is about. Sandra is the only person in the building who can describe what has happened, but what has happened is detailed and complex. Nobody has time to listen to it, because it does not fit in an executive summary.

The corrective to all this is not subtle, and not diplomatic. It asks the people commissioning the work - the leaders, planners, and drivers - to relinquish most of their prerogative to shape the workings of their organization to a person who doesn’t even get a named parking spot.

You cannot understand how an organization runs by talking only to the people who can describe it. Describing structures is a management skill, and it is a different skill from doing the actual work. The two correlate weakly, and in mature organizations they correlate inversely, because the people who can describe the work have not done it for years, and the people who do the work do not have the time, incentive or mandate to describe it.

The remedy is to sit with the people who do the actual operative work, and have them walk through all the clicks.

This sounds slow, and it really, truly is. It is slow in the way that a doctor listening with a stethoscope is slow, compared to a doctor reading a chart. The chart is faster, but also thin on the particulars.

When you do this, when you get technical, detail-oriented, fully immersed Sandra into the room to explain how invoicing works step by step, you finally gain the material to build an honest process map. From which, for the very first time, a fitting software requirement can be drafted. From which, finally, a functioning automation setup can be planned and executed. The maps that result from this are less elegant than the maps you can build from management’s descriptions, or copy/paste from the consultants’ best practices repository. But they are also simply true. Based on them, the next system you buy can, at last, be specified for the user who will keep it alive, instead of for the buyer the vendor has been demoing it to.

It is nine pm.

Sandra closes the spreadsheet. All the invoice tickets that remained open during her holiday are now resolved. Upstairs, somewhere, a dashboard turns green.