Christian Nissen has spent about four decades in IT service management (ITSM), much of it shaping the best practice the rest of the field now works from, including a stint as lead editor of ITIL 4: Drive Stakeholder Value. In his Conversations with Giants interview with Roman Jouravlev, he argues that the industry keeps isolating capabilities it should be integrating, that in doing so it has drifted toward product and let service slide into the background, and that the skills most worth having are older and plainer than anyone entering the field expects.
When a specialism outlives its purpose
Much of the conversation circled a pattern that Mark Smalley sets out in his recent book, Organising XLA for Adaptability. A new capability earns its place by being specialized, given a dedicated team, office, or body of knowledge. As it matures, the cost of keeping it in its own box begins to outrun the benefit, and the sensible move is to integrate it back into the wider organization before that happens.
Christian agreed with the pattern but reframed the pieces. He does not see DevOps, agile, lean, or ITIL as separate entities so much as spotlights that fall on a single organization from time to time, usually because something has been ignored. DevOps emerged, in his telling, when developers adopted agile practices and ran into operations, which had its own way of doing things and slowed delivery. The spotlight fell on operations, and the industry gave it a name. The trouble starts once a capability is isolated so it can be made to work, because walls go up around it, and walls are hard to take down later. His advice is to plan how a specialized team will rejoin the whole at the moment you create it, rather than years later, once coordination costs have climbed.
That instinct to wall things off is, for him, part of a larger problem with complexity. Organizations, markets, and technology are complicated enough already. Hence, guidance intended for use has to be simple, or people cannot hold it in their heads. Telling someone their work is too complex costs nothing, but doing the reduction, taking something tangled and making it simpler, is the harder job, and one he admits he has not always managed. He worked on ITIL v3, which grew into the most complex version of the lot, and he takes the trimming down of the versions that followed as a sign that the industry is heading in the right direction.
Service is part of the product
His sharpest criticism is aimed at the drift toward product and away from service, and he is careful to say the fault lies with the world, not with ITIL. To Christian, a product is only a configuration of resources you put into play, and the situation it is put into is the service. Service, in his view, is part of the product rather than a wrapper around it. Treat the two as separate, and the service contribution shrinks to support, which is how service level agreements end up as support level agreements in all but name, their useful content set by whatever a vendor happened to supply. He is not optimistic that this will reverse soon, because the product is where the fast, easy money sits. However, the ITIL framework itself has moved his way: ITIL (Version 5), released this year, is built around a digital product and service lifecycle rather than the service-only framing of earlier versions.
His service thinking goes back to an initiative he ran after ITIL v3 with Stuart Rance and Peter Brooks, called Taking Service Forward, an attempt to build the underlying architecture for service management that the framework’s owner had never funded. Chasing that architecture led the group to academic work on service that practitioners had ignored for the better part of a century, and what they took from it was that goods can be handed to someone else, while a service is something you have to do together. That co-creational quality became the foundation of the ITIL 4: Drive Stakeholder Value publication Christian went on to lead, and it remains central to how ITIL describes value co-creation today. The architecture itself was never built, and he still doubts anyone will fund it.
Who ends up integrating, and the limits of architecture
If value is co-created across several providers, someone has to hold those providers together, and most of the time, Christian points out, it is the consumer. He used Roman’s own morning as the example: a train to the airport, a flight, a metro, a venue, each bought separately and bound by its own agreement, with the traveler silently stitching them together and leaving a gap between the train and the plane in case the airport ran slow. People are left as integrators whether they want the role or not, and his point is that they usually do not. The best experiences he has had were those in which someone else carried that responsibility, and he is glad to pay for it.
There are two ways to lift the burden. One is to build integration into the infrastructure, the way societies built roads. Hence, the parts speak to each other underneath, though that is a vast, multi-decade investment almost no one has made. The other is to orchestrate it deliberately, and there is a mature body of service integration and management practice for doing exactly that, which, in his experience, is used far less than it warrants.
He is more skeptical about solving the problem with architecture, even though the idea appeals to him. He calls himself a rational person who loves a clean architecture, and twenty years ago, he believed the industry could build generic models it could rely on. He is no longer sure. The difficulty is the one that has dogged configuration management and knowledge management for years: reality changes faster than the records can be updated, and the connections are too many to model perfectly. His tentative conclusion is that people talking to each other may do more good than another diagram of boxes and lines.
Where AI helps service management
Christian is more hopeful about artificial intelligence (AI), and for the same reason. Configuration management has always been weak, he argued, because it was done after the fact, and almost no one wants that job. With software-defined infrastructure, the order flips. The configuration creates the infrastructure, so it becomes something you can trust because it is what was built. AI shifts from being a record of what happened to an actor that helps make and connect things, and he has seen it work, particularly at the network and security layers, where the manual version is hardest.
On the broader question of AI, he comes at it as a long-time believer in technology, having built neural networks on a DOS machine in the 1980s. He uses AI heavily as a student, where he is required to declare how he used it: to work with data, not to do his thinking. The discipline he carries over from information security is to run a real risk analysis before trusting any of it, asking which data is involved, how it could be misused, and how it could be misread. The more widely a technology is shared, he says, the more careful you have to be. His illustration was a bank adviser, biased in ways a customer cannot see. An AI agent in the same seat would be biased too, only differently, and the job is to understand that bias rather than pretend it is gone, or to see ghosts everywhere.
What he’d teach first about service management
What worries him is not the technology itself but what happens to attention around it. Tools have always traded one skill for another, he says: writing cost people the knack of memorizing and retelling stories, and Google, in his own case, cost the ability to find things in a library. The loss he fears now is the capacity to reflect, and he blames it on social media and constant scrolling rather than on AI. As he put it, “I’m more scared about social media than about AI.”
That worry shapes what he would tell anyone entering the field. Start by being who you are, he said, instead of trying to be someone else. Then learn the basics, because the basics last: languages, for the wisdom built into them that you will use long after you have forgotten where it came from, and mathematics and statistics, because the industry talks endlessly about data-driven decisions and then trusts its gut instead. He puts logic and rhetoric alongside those, so that you can make yourself understood. Beyond that, understand a situation before acting on it, which takes longer than reaching for a solution but lets you see whether there is a pattern underneath that you can use again.
Most of all, ask why before what and how, the order Simon Sinek calls the golden circle. When a client asks Christian for help with incident management, his first question is always why: what challenge is being solved, what value is missing, or, the part he finds most interesting, what opportunity it might open. Be empathic, by which he means listening for what people mean and not only what they say, the habit Stephen Covey framed as seeking first to understand and then to be understood. And invest in people as people, not as a means to your end or a network to assemble, but as people worth your time in their own right, because the work you build together is the point of being there at all.
Watch the conversation
Christian’s full conversation is worth watching for the parts not covered here, including how his reading of ancient philosophy reshaped his thinking on contracts, and the managers who taught him to be demanding while creating safety at the same time. The Conversations with Giants series is created by Roman Jouravlev.
Further Reading
https://itsm.tools/it-asset-handoff/
https://itsm.tools/itam-it-asset-management-security-compliance-budgeting/
https://itsm.tools/ai-it-service-desk-context-not-intelligence/
Sophie Danby
Sophie is a freelance ITSM marketing consultant, helping ITSM solution vendors to develop and implement effective marketing strategies.
She covers both traditional areas of marketing (such as advertising, trade shows, and events) and digital marketing (such as video, social media, and email marketing). She is also a trained editor.
