The one who clicks
Why enterprise software is almost never built for the actual user.
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.