The exceptions were the job

Every process document I’ve written describes a version of events where everyone behaves.

The information arrives in the right format, the two systems agree about what the record says, and the person who owns the decision turns out to be the person named in the document. The steps work under those conditions, and I’ve drawn a lot of those diagrams and felt pretty pleased with them at the time.

Then you sit with whoever runs the process and watch them work for an hour, and the diagram starts to look naive. I’ve had that happen more than once. The flow I’d modelled as the main event took up very little of their time, while the handling I’d left in a footnote was most of their week.

A mandatory field comes through empty, and they recognise that the record arrived through an old integration, so they carry on. The policy points one way while the sensible outcome points another, and they find a route that satisfies both. Something passes every rule in the system and still looks wrong, so they stop, although explaining why could take twenty minutes and several details that never made it into the document.

We call these edge cases, but people doing the work meet them several times a day, which makes edge case a strange name for the bulk of somebody’s job.

What experience is made of

Experienced people can seem to reach an answer without showing their working, and I think much of what looks like intuition is memory moving faster than explanation. They’ve seen this combination before, so they know that a field often means something different in this situation, that the documented owner will probably send the decision elsewhere, and that the obvious fix will hand another team a problem next month.

The answer comes from recognising what tends to follow, and that recognition builds one strange case at a time. It also builds unevenly, which is part of why time served and real experience come apart so easily. Someone can spend five years in a role and meet very few difficult exceptions, while another person can spend eighteen months near the messy end of the process and see a hundred.

Much of that knowledge never reaches the documentation because people learn it by sitting near one another, watching somebody more experienced pause at a detail they would have ignored, and getting a case wrong in front of someone who can explain what they missed. It travels through a workplace in much the same way as the org chart nobody wrote down, carried by people who have learned how the place behaves when the written version runs out.

The work that remains

When an AI agent handles the routine cases, fewer cases reach a person, but each one has already reached the edge of what the system could resolve. Somebody who once worked across a mix of ordinary and difficult cases can end up waiting for a machine to become uncertain, then receiving the strangest work with whatever context survived the handover.

That changes the job in ways the volume alone cannot show. A dashboard can record a large fall in manual work while the person at the end has fewer completions, more ambiguity and greater responsibility for every decision they make. They also have to understand what the system saw, what it tried, what it ruled out and why it stopped, and when that context arrives as a short summary, reconstructing the case becomes part of the work.

Wider use can make the gap harder to see. A small share of cases still becomes a large queue when the system is working across enough volume, and every case in that queue has already been selected for difficulty. A team staffed for an early rollout can therefore feel busier as the business celebrates how much manual work has disappeared, because the count has fallen while each case asks more of them.

The ordinary cases also gave the day some rhythm because they offered small completions between the harder decisions and contact with people whose situation was going as expected. Once those cases disappear, a person may spend every conversation with someone who is already frustrated about a problem that resisted the first attempt to solve it. I’d expect that to change how the work feels, even when the number of cases falls, because almost everyone they meet is arriving after something has gone wrong.

How people learn the exceptions

The same routine work was teaching people what normal looked like. By handling ordinary cases, you learned their shape well enough to notice a small deviation later, and by watching somebody senior take the unusual ones, you heard the questions they asked before gradually taking on those decisions yourself. The repetition gave you a reference point, and the exceptions taught you when that reference point had stopped being useful.

Automation usually reaches the repeatable work first, which can leave an organisation asking for experienced judgement after reducing the work through which that judgement developed. Putting a person at the end of the process gives the system somewhere to send a difficult case, but the position alone does very little to prepare that person for the decision waiting there.

The people who already have experience face a related problem because recognising an exception depends on a current sense of the ordinary case. If the system handles every routine case, they stop seeing how normal behaviour changes over time, so their judgement may remain sound while the reference point beneath it grows old.

I’d like to believe that judgement will move higher up, towards deciding which cases deserve attention and which outputs can be trusted, although I know that is also the answer I’d prefer to be true. We may be removing a way of learning and only understand the loss after people have stopped coming through it, which makes this harder to dismiss as a temporary gap that training will eventually solve.

Sampling ordinary cases could preserve some of that contact, while reviews of automated decisions could keep experienced people close to what the system is seeing and give newer staff access to the context behind difficult handovers. Those arrangements need deliberate ownership because the automated process will do the work it was designed to do, while everything people used to learn by being inside the process needs somewhere new to happen.

Some repetitive work teaches very little and takes energy people could use elsewhere, so removing it can make a job better. My concern is with everything that can travel inside a routine task without appearing in the process document: the practice that builds judgement, the contact with a customer before something goes wrong, and the early sign that the rules have stopped matching reality.

I still want the repetitive work automated, and I want us to be honest about what the work was carrying before we remove it. If it was where people learned what normal looked like, met customers before they were upset, and noticed when the rules had stopped matching reality, then those things need a new place in the job. Otherwise the automation can work exactly as designed while the role around it becomes harder to do and harder to learn. For me, designing the automation includes deciding what kind of work, and what kind of working life, we leave with the person at the end.