Let me tell you about a job I had a few years ago.
I was working in online gaming. Largely in unregulated markets. Global. Fast. Chaotic. The kind of industry where a change of government in a country you'd never visited could close a market overnight. Where competitors were constantly pushing for the same eyeballs you were trying to keep. Where a single second of downtime at the wrong moment didn't just cost revenue. It cost loyalty.
High stakes. High velocity. Not a lot of patience for anything that slowed the organisation down.
When I joined, I was introduced to the chap responsible for customer support. We sat down. And he opened with his certifications.
I'm not exaggerating. Within about ninety seconds, we were in ITIL. The version. The modules. The journey. The framework fluency. A full tour of his professional wardrobe, carefully laid out for inspection.
And I'm sitting there thinking — we are a global software-led organisation operating in unregulated markets with real-time technology risk and customers who will leave us for a competitor while this conversation is still happening.
This was not a good match. He didn't last long.
But here's the thing. I've seen that conversation more times than I can count. In interviews. In leadership assessments. In service reviews. Different industries, different organisations, different job titles. The pattern is always the same.
Someone walks in and tells you where they've been. What they've achieved. What framework they hold. What process they governed. What version they're certified in. And you're sitting there thinking — I need to know where you're going. I need to know what you'll do when the ground moves. I need to know what you do when the old model stops working.
But our industry has trained people to lead with the past. We've built a world that values experience over talent. Certifications over mindset. Safety over innovation. And too many people in our world open their mouth and describe a profession that is far more comfortable explaining where it has been than imagining where it needs to go.
Scaffolding became shelter
Here is the uncomfortable truth hiding behind that story. ITSM was built to help organisations deal with change. Yet one of the least comfortable truths in our profession is that parts of ITSM have become very good at resisting change itself.
That should bother us. Because while the world was moving, too much of our profession was taking comfort in being able to explain itself to itself. We built frameworks. We built certifications. We built governance language. We built metrics. We built maturity models. And somewhere along the way, a lot of that stopped being scaffolding and started becoming shelter.
Now let me be clear. I am not anti framework. That would be a ridiculous thing for someone in my job to say — a bit like a dentist announcing he has concerns about teeth. Frameworks have value. Process has value. Discipline has value. But once a tool becomes a comfort blanket, it stops helping you move and starts helping you hide.
Too many IT professionals do not just use frameworks as tools. They use them as psychological safety. Safety from ambiguity. Safety from challenge. Safety from having to design something genuinely new. And sometimes, if we are honest, safety from having to explain value in language the business actually cares about.
Forty slides, then she closed the laptop
Imagine you're a new CFO. Six weeks into the job. Someone sends you the monthly service report. Forty slides. You open it with genuine goodwill — you actually want to understand what's going on.
By slide four you have encountered the words taxonomy, triage cadence, escalation matrix, operating rhythm, categorisation hygiene and service assurance posture.
By slide twelve you have learned that queue health is amber, deflection is trending positive, and assignment velocity is within tolerance.
By slide twenty you have closed the laptop.
Not because she is not intelligent. Because nothing in those forty slides told her whether the business is easier to work with this month than it was last month. Whether people are less frustrated. Whether technology is helping or hurting. Whether the organisation is more capable or less.
The report was technically rigorous. It was operationally precise. And it communicated almost nothing of value to the person reading it.
That is the language problem. ITSM language was designed to talk to itself. Built for internal legibility. For the room that already knows the vocabulary. The problem is we keep using it outside that room.
It is a bit like explaining the Highway Code on a date. Technically accurate. Completely wrong room.
And the date — in this analogy — is the CFO, the CEO, the board, the business leader sitting across the table trying to understand whether IT is an asset or an overhead. We walk in with our framework fluency and our governance vocabulary and we describe our machinery with enormous precision. And they walk out thinking: I still don't know if this is working.
98% SLA. And a spreadsheet called "things IT can't fix"
If language reveals what we value, metrics expose it. Let me tell you what a lot of service reviews actually look like.
You walk into the room. There is a dashboard. The dashboard is largely green. SLA attainment, ninety-eight percent. Ticket volume, down. Queue health, stable. First contact resolution, trending positive. Assignment velocity, within tolerance. Everyone nods. Someone says "good quarter."
And then you walk out of the building, and you talk to an actual employee. They tell you the system they rely on most has been half-broken for six weeks. That they've stopped raising tickets because nothing seems to happen. That they've built workarounds. That their team has a shared document called "things IT can't fix" — and they update it regularly.
That is the metric problem. Not that the numbers are wrong. The numbers are probably accurate. The problem is that the numbers are measuring the wrong thing entirely.
Most service metrics were not designed to answer the question "is life better for the people we support?" They were designed to answer a different question: "can we prove we are doing our jobs?"
That is a fundamentally different question. It produces fundamentally different behaviour. It is the organisational equivalent of a doctor who never actually speaks to patients but has immaculate paperwork. Technically compliant. Operationally present. Clinically useless.
Many of those measures actively reward the wrong things. They reward movement over meaning. Local efficiency over end-to-end flow. Visible activity over invisible improvement. Which is how you get service organisations that are permanently busy, permanently reporting, permanently proving their own effort — and still not convincingly improving the lived experience of the people they support.
That is not transformation. That is a very tidy form of self-preservation.
A brilliantly organised description of yesterday
Too much of service management is still a brilliantly organised description of yesterday.
I was talking to a service director recently — smart person, good organisation — and they showed me their end of year report with genuine pride. Forty pages. Every incident logged. Every queue analysed. Every SLA trend charted back eighteen months. Genuinely impressive document.
And I asked them one question. If I wanted to understand whether your organisation is easier to work with today than it was a year ago — is the answer in here?
Long pause. The honest answer was no. Not really.
That is the rear-view mirror problem. We have built extraordinary capability to describe what happened. We have invested far less in understanding what is actually changing — and whether we are ahead of it or behind it.
Because the world has moved. AI has changed what is possible. Automation has changed what is scalable. Design thinking has changed what customers expect. And software is changing the nature of service itself.
The question now is not just whether we can manage work efficiently. It is whether we can design systems that sense earlier, adapt faster, and create more value with less friction.
Left of what, exactly?
For years, the dominant answer in our world was shift left. The logic is seductive in its simplicity. Over here on the right — expensive. Humans. Tier one, two, three. Time. Cost. Escalation. Over here on the left — cheaper. Faster. Self-service. Automation. AI doing the work before a human ever needs to touch it.
Push everything left. Automate more. Deflect more. Keep humans away from demand. Drive the cost down.
Lazy criticism is easy, so let me be fair: shift left was not foolish. In a labour-heavy, process-centric, queue-driven world, it was a sensible optimisation. The problem is what happened next. We took a useful optimisation and turned it into doctrine. And once something becomes doctrine, people stop asking whether it is still the right answer.
Shift left was designed to solve one problem: cost. How do we handle more demand with less human labour? That is a perfectly legitimate question. But it is not the same question as: how do we design a service experience that actually works for the people using it?
Those are different questions. They produce very different answers.
Shift left optimised for labour efficiency. And in doing so, it quietly deprioritised something else. The actual human experience of using the service. Which is how you end up with self-service portals that nobody uses. Knowledge articles written for the system rather than the person. Chatbots that confidently misunderstand you at remarkable speed. Deflection metrics that go up while satisfaction metrics go sideways.
Shift right: experience architecture
What replaces shift left is not another workflow diagram. It is an experience architecture. Four modes. Not tiers. Modes.
Self heal by default. The problem resolves itself before the user even knows it existed. AI operating within policy. Invisible. Frictionless. The best service experience is the one nobody notices.
Guided self-help. The user needs to do something, but they're not alone. AI and the user working together to clarify intent and find resolution. Not a FAQ page. An intelligent conversation.
Assisted resolution. Human and AI together. The human validates, steers, exercises judgement. The AI handles the administration. This is where complex or sensitive demand lives — not because we can't automate it, but because a human in the loop adds something the automation cannot.
White glove moments. Intentionally human. Fully human. Not because we ran out of automation. Because the situation demands it. Because restoring confidence, exercising real judgement, showing genuine accountability — that is not a cost to be minimised. That is the value.
Not human as fallback. Human as differentiator.
Underneath all of this, there is something the old shift left model never had. A service sensor layer. Signals from users. Signals from systems. Signals from the business itself. Not waiting for a ticket to tell you something went wrong. Sensing, interpreting, deciding, changing. Signal to insight to decision to change.
Because here is the brutal truth about tickets. By the time a ticket appears, the experience has already failed. The ticket is not the centre of the universe. In many cases it is evidence that the service design broke down somewhere upstream. We have spent twenty years optimising what happens after the ticket arrives. The next-generation service organisation optimises to stop the ticket being needed in the first place.
It's not the waiting. It's the uncertainty.
One of the biggest mistakes organisations make is assuming that customers experience service rationally. They do not.
People say they want faster service. Often what they really want is certainty. They say they want immediate response. Often what they really want is confidence that someone competent is in control.
If my flight is delayed by seventy minutes but I know it is delayed by seventy minutes, I can replan my day. I can make a call. Get a coffee. Adjust. If the board just says delayed, that is mental torture. Because I have lost control.
The same applies in service. A lot of what customers describe as poor support is actually the emotional cost of uncertainty, not just elapsed time. Badly designed uncertainty is one of the hidden failures in modern service. Unclear ownership. Unclear progress. Unclear timescales. Unclear language. Unclear confidence.
Clarity is part of the service. Confidence is part of the service. Reducing ambiguity is part of the service. That is not soft. That is operationally intelligent.
Habit dressed up as governance
I know what some people will be thinking. That's all very well for startups. Fine for digital natives. Fine if you have no legacy, no regulation and no complexity. I do not buy that. But let me be fair about why people say it. Because the concern is legitimate even if the conclusion is wrong.
Regulated industries carry real consequences. A bank that gets its change management wrong doesn't just have unhappy users. It has regulators, fines, systemic risk. I understand that. The stakes are different and pretending otherwise would be naive.
But here is what I've noticed. When you sit down with a large enterprise and ask them to walk you through why a particular process works the way it does — why it takes six months to change something that should take six weeks, why there are fourteen sign-offs on a decision that three people actually care about — something interesting happens.
They explain it by pointing at the regulator. The regulator requires this. Compliance demands it. We have no choice. Sometimes that is true. But quite often, if you actually go and look — if you read the regulation rather than the inherited interpretation of the regulation — the regulator didn't require that specific thing at all.
What the regulator required was an outcome. Control. Auditability. Evidence of due diligence. What the organisation built was a procedure. And then a procedure to govern the procedure. And then a committee to review the procedure that governs the procedure. At some point, nobody could quite remember why it was built that way.
That is comfort bureaucracy. Not compliance. Not regulation. Not genuine risk management. An organisation so thoroughly wrapped in its own protective procedures that it has become slower, more expensive and less capable — not because the regulator demanded it, but because the organisation got used to it.
From certainty performer to uncertainty expert
The next-generation service organisation is not just a tooling architecture or an operating model. It is a leadership model. And one of the problems in our industry is that too many people are rewarded for sounding certain in a world that now punishes certainty.
You know this person. They walk in with absolute confidence. The posture of someone who has never once been troubled by a question they couldn't answer. They speak in complete, fully-formed sentences. No hesitation. No qualification. No visible awareness that the world outside the room has changed significantly since they last looked.
They have a view on everything. The strategy. The roadmap. The framework. And the thing is — they're not stupid. They're often genuinely experienced. But if you ask them something they haven't prepared for — something genuinely new, ambiguous, outside the model they've been running for the last decade — they answer it anyway. With the same confidence. The same complete sentences. The same posture. Because the performance of certainty has become the job.
That is the certainty performer.
In a stable world — a world where the model held, where last year's answer was probably still right this year — that person looked like expertise. We are not in that world any more. In this world, the certainty performer is quietly dangerous. Not because they're dishonest. But because their confidence is contagious. And a room full of people performing certainty is a room that has stopped asking whether any of it is still true.
The leaders who matter next look quite different. They don't walk in with all the answers. The first thing you notice is that they're comfortable not having them. They ask questions that sound almost too simple. Why do we do it this way? What would happen if we stopped? Who actually benefits from this process — us or the customer? Has anyone asked the people we support?
Five rounds of review. Nothing left worth saying
Let me describe a meeting I suspect most of you have been in. Someone comes in with an idea. A genuinely interesting idea. Something with an edge to it. Something that might actually change something.
And the process begins.
- Review 01 — Good, but consider the risk implications.
- Review 02 — Aligned with the governance framework?
- Review 03 — Language might land badly with compliance.
- Review 04 — Can we make it more inclusive?
- Review 05 — What if we soften the close?
By the fifth review, what you have left is something that nobody objects to. Which sounds like success. It isn't. Because something that nobody objects to is not the same as something that works. It is something that has been sanded so smooth, reviewed so many times, made so thoroughly safe — that it has lost the one thing that made it worth doing in the first place. The idea that made someone sit up.
Rory Sutherland — the behavioural economist who I think understands organisations better than most management consultants — argues that conventional logic applied to creative and human problems consistently produces the wrong answer. Not a bad answer. The wrong one. Because conventional logic optimises for what is defensible. And what is defensible is almost never what is distinctive.
Our industry has been optimising for defensible for thirty years.
And I say that with some affection, because I understand why. When your job is managing risk, managing change, managing complexity — defensible feels responsible. It feels like leadership. But there is a difference between being defensible and being right. And there is a profound difference between a framework designed to provoke better thinking and a framework designed to survive a governance committee.
Too much of what ITSM has produced falls into the second category. Not because the people were untalented. But because the process consistently rewarded the version of an idea that everyone could live with rather than the version that might actually change something. That is not maturity. That is creative dilution.
Service organisations that look almost identical to each other. Language that sounds almost identical. Metrics that are almost identical. Strategies that are so thoroughly consensus-proofed they could have been written by any organisation in any sector at almost any point in the last decade. Safe. Aligned. Forgettable.
At some point, leadership has to be willing to place a bet. To back something before every guardian of the old model feels comfortable with it. To accept that genuinely new thinking will always make someone in the room uneasy — and that is not a reason to stop. It might actually be a sign you're onto something.
The next-generation service organisation, by design
If I pull all of that together, what does the next-generation service organisation actually look like?
It speaks the language of the business. Not operationally accurate language dressed up in governance vocabulary. Commercially useful language. The kind that makes a CFO keep reading past slide four.
It designs for experience, not just efficiency. It uses shift right thinking to place self-healing, guided help, assisted resolution and genuinely human moments where they create the most value. Not as a cost decision. As a design decision.
It treats humans as the value add. Not as the default buffer for poor service design. Not as middleware absorbing complexity that should never have existed. The place where trust, judgement, empathy and real accountability live.
It builds software-defined services underneath all of that. Signals, telemetry, policy, agents and knowledge working together as an adaptive system — one that senses problems before tickets appear and changes before customers notice.
It reduces badly designed uncertainty. Treats clarity, confidence and expectation design as part of the service itself. Not a nice extra. Not a soft consideration. An operational discipline.
And it builds a culture of uncertainty experts. People who can learn faster than the environment changes. Who apply their rigour to the question rather than the answer. Who have made peace with not knowing — and are genuinely curious about finding out.
That is the next-generation service organisation. Not a function obsessed with looking busy. A function designed to be intelligent. Not defending its relevance through framework fluency. Earning it by making service more meaningful to the business.
Preserving itself. Or redesigning itself.
That leaves us with a choice.
We can keep treating frameworks as identity. We can keep using language that excludes rather than connects. We can keep measuring activity and calling it value. We can keep pushing everything left as though cost containment is still the whole game. We can keep rewarding certainty performers and wondering why adaptation feels so hard.
Or we can do something more ambitious. We can build software-defined services. We can design service experiences deliberately. We can reduce friction by default. We can design out uncertainty where it adds no value. We can reserve human brilliance for the moments that actually matter. And we can finally describe service in a language the business understands.
If ITSM wants to remain relevant, that is the work now. Not preserving itself. Redesigning itself.