The operator is the last person anyone thinks to design for

There is a category of person who appears in almost every enterprise software sales process and almost no enterprise software design process. They are the ones who will use the product for six to eight hours a day. They are the ones whose working life will be shaped, improved, or quietly degraded by the decisions made in product reviews they were never invited to. They are the operators — the coordinators, the technicians, the dispatchers, the people whose job is to make the thing actually run — and the software industry has, for most of its history, treated them as an implementation detail.

This is not an accident. It is a structural consequence of how enterprise software gets bought.

The buyer and the user are almost never the same person

Enterprise software is sold upward and used downward. The person who signs the contract is evaluating a different set of questions than the person who will open the application every morning. The buyer wants to know about integration capability, security posture, pricing tiers, support SLAs, and whether the vendor's roadmap aligns with the company's strategic direction. These are legitimate questions. They are also almost entirely disconnected from whether the software is good to use.

The result is a market that has become extraordinarily sophisticated at answering questions that buyers ask and largely indifferent to questions that users ask. Demos are optimised for the conference room. Interfaces are designed to look impressive at the resolution of a presentation slide. Feature announcements are written for the person evaluating the category, not the person doing the job.

The operator, sitting somewhere down the org chart, inherits whatever was chosen on their behalf. In the better cases, someone thought to ask them what they needed. In the common case, they are handed credentials and a training date.

What it costs to be an afterthought

The costs of this dynamic are real and mostly untracked. They show up as workarounds — the spreadsheet that runs in parallel with the official system because the official system can't do the one specific thing that comes up every Tuesday. They show up as shadow processes — the WhatsApp group that has become the actual coordination layer because the coordination tool is too slow to use on a phone in a hallway. They show up as attrition — the quiet resignation of people who spend their days fighting software that was never designed with them in mind and have decided, reasonably, that this is just how it is.

None of these costs appear on a dashboard. They are not captured in renewal metrics or NPS surveys, because the operator is rarely the person filling out the NPS survey. They live in the gap between how a system is supposed to work and how work actually gets done — a gap that operators navigate daily and management often doesn't know exists.

There is a particular kind of learned helplessness that develops in people who have spent years using software that doesn't fit the contours of their actual job. They stop expecting better. They stop reporting friction because reporting friction has never changed anything. They develop a fluency in working around systems rather than with them, and that fluency gets mistaken, sometimes, for evidence that the system is fine.

Why the industry converged on this

It would be convenient to attribute this to malice or negligence. The more accurate explanation is incentive alignment, and it is harder to argue with.

If you are building enterprise software and you need to grow, you optimise for the thing that drives growth. Growth comes from winning deals. Deals are won in conversations with economic buyers. Economic buyers care about the things economic buyers care about — which, to be fair, includes some things that genuinely benefit operators, like reliability and security and integration with existing tools. But the felt experience of daily use is not a primary variable in most procurement decisions, and vendors have learned, over decades, to invest in proportion to what drives decisions.

There is also a knowledge problem. The people who build software are, structurally, not the people who use it in the environments where it will be used. A product team in a well-lit office with good Wi-Fi and a second monitor is not positioned to fully imagine the experience of using their product in a hospital sub-basement on a first-generation Android device with intermittent signal and a job queue that needs to be updated before moving to the next site. They can try. Empathy and user research go some distance. They do not fully close the gap.

The operators who could close the gap are rarely in the room. They are doing the work.

The brief window when this changes

Every few years, in a given software category, something shifts the balance. Sometimes it is a new entrant who builds from the operator up rather than the buyer down — who starts with the person doing the work and treats everything else as a constraint to satisfy rather than a feature to sell. Sometimes it is a technology change that makes a previously impractical experience practical: the smartphone made software usable in the field in a way that desktop software never was, and the companies that understood this early built differently than the ones that added a mobile app as an afterthought.

Sometimes it is simply that the cost of operator friction becomes visible in a way it wasn't before. A compliance failure. A retention problem that traces back, in the exit interviews, to tools. A growth ceiling that turns out to be a coordination ceiling — the organisation unable to scale because the people doing the work are spending too much of their day managing the gaps in their own systems.

When the cost becomes visible, the conversation changes. Not always, and not quickly. But it changes.

What designing for the operator actually requires

It requires, first, being honest about who the product is for. Not in the abstract — every product team will say their product is for users — but specifically. Which user. In which moment. With what constraints. On what device. With how much time, and how much tolerance for complexity, and what consequence attached to getting it wrong.

It requires, second, being present in the actual environment. Not the environment described in the discovery call, or the environment shown in the customer's onboarding deck, but the environment as it exists on a Wednesday afternoon when two technicians have called in sick and there is a machine down at a hospital thirty kilometres away. Software designed in that environment is shaped by forces that don't appear in user stories written in a comfortable room.

It requires, third, a willingness to value things that don't show up in feature comparison matrices. Speed of a single action, repeated forty times a day. The cognitive load of navigating between screens. The confidence that comes from a system that behaves predictably under stress. These are the dimensions that determine whether an operator trusts a piece of software — and trust, for the person using something eight hours a day, is the only metric that actually matters.

The buyer signs the contract. The operator decides, in the first six weeks, whether the software is real or just another thing they'll work around.

Most software companies optimise for the signature. The interesting question — the one the industry has mostly deferred — is what it would look like to optimise for the six weeks instead.