A programmer once spent half an hour writing a couple of lines of code. When they next visited the client’s office, they were received almost as heroes. They hadn’t seen it coming because they’d been measuring the work by what it cost to produce it rather than by what it was worth to the person using it, i.e. its value. From where they sat, the work was nothing; from where the user sat, it had changed their working day.
That mismatch between producer effort and user value is something Mark Smalley, IT Paradigmologist and author of nine books on digital and service management, has been thinking about throughout his career. In this first episode of Roman Jouravlev’s Conversations with Giants series, Mark covers several ideas that have held up across four decades in IT service management (ITSM): why value is always determined by the recipient, why silos are more human than structural, why thinking precedes doing, and what good use of artificial intelligence (AI) actually looks like in a service management context.
Value Is Determined by the Recipient, Not the Producer
The person (user) in the story was called Nell. She worked in the back office of an accountancy organization, processing survey forms submitted by accountants through a slow, clunky system. For each form, she had to click through several screens to record whether it had been submitted. She asked if anything could be done.
The program Mark wrote allowed her to enter an accountant’s number and press Enter. It took him half an hour. When he next visited, the reception he received caught him entirely off guard, because he’d been measuring the work by what it cost him rather than by what it was worth to Nell.
Price and cost have nothing inherent to do with each other, and assuming they correlate is one of the most consistent errors in IT delivery. A small piece of work can be transformative for the person receiving it. A large, expensive project can change almost nothing from the user’s perspective. ITSM has frameworks, metrics, and processes designed to track delivery, but if those measures are oriented around effort and output rather than user outcomes, they’re measuring the wrong thing. For more on this, Mark has written directly about how to demonstrate the business value of IT, and the question of how to measure IT service desk value is one the ITSM.tools community has explored in depth. Establishing what success looks like from the user’s perspective before delivery begins isn’t optional; it’s the point.
Think It Through Before You Build It
Edsger Dijkstra, the Dutch computer scientist who was highly influential in the 1970s and 1980s, identified computing’s central challenge as “how not to make a mess of it.” Mark finds it still accurate and worth repeating in an era when the tools make it easier than ever to start building before you’ve finished thinking.
The discipline of thinking before committing was enforced by necessity in the punch card era. You wrote your program on paper, had it punched, fed the cards into the machine, and waited until the following day for the results. If it didn’t work, which it usually didn’t, you started again. That enforced pause has been largely removed by faster tools and shorter delivery cycles, and the costs of that tend to arrive downstream rather than upfront.
Speed of execution isn’t evidence of progress. Building the wrong thing fast, or implementing a process without properly understanding the problem it’s meant to solve, creates work that wouldn’t have existed if the thinking had happened first. Getting to first principles before a line of code is written or a process is changed isn’t slow; it’s what makes the work that follows more likely to succeed (and add value).
Don’t Try to Eliminate Silos. Build Better Bridges.
The standard position in service management is that silos are a problem to be solved through restructuring. Mark’s view is that this misunderstands why they exist.
IT teams develop strong identities around what they do and how they do it. That identity is part of what makes specialists effective; it isn’t a symptom of organizational dysfunction. The problem isn’t that the development and operations teams think of themselves as distinct groups. The problem is what happens at the boundaries between them when those boundaries become barriers: knowledge stops crossing over, assumptions go unchecked, and each team optimizes for its own outcomes rather than the shared ones.
Trying to solve that by reorganizing people out of their specialisms in the pursuit of value risks losing both expertise and isolation. The more productive goal is to invest in the connections across those boundaries: shared language, cross-functional relationships, deliberate communication. In ITSM terms, this means designing for collaboration at the interfaces rather than assuming a restructure will produce it.
Mark makes the same observation about professional communities. ITSM events and DevOps events tend to draw completely separate crowds, each reinforcing its own assumptions. The business analysis and project management world is a notable exception, frequently combining its events, and he thinks it’s better for it.
Using AI Well in ITSM
AI tools are increasingly part of how service management teams work and add value, whether that’s drafting communications, analyzing data, building knowledge bases, or supporting decision-making. AI in ITSM can obviously do a great deal, but the question of how to use it effectively is one the industry is still working out. Mark’s framework for that is straightforward and directly applicable.
In the early stage of any problem or project, AI is most useful as a critical voice rather than a generative one. Feed it your assumptions and ask for the counterargument. Ask what you’ve missed, what the risks are, what the case against your approach looks like. LLMs will confirm your thinking if you let them; so, you have to be deliberate about not letting them. Using multiple tools to pressure-test the same output is one practical way to do that.
In the later stage, once you know what you’re trying to say or do, AI can help you work out how to communicate it clearly to a specific audience. There’s a discipline to that prompting. Mark describes four questions he deliberately builds in, and they transfer directly to service management work: What is this actually about, and have I explained it clearly enough? Is it specific and evidence-based, or is it opinion dressed as fact? Why does it matter to this particular user or stakeholder, given their situation? And what do I want them to do or think as a result? Generic prompts produce generic output. Prompts built around those questions produce something more likely to be useful.
The Nell story runs through this, too. If you don’t know who you’re producing something for and what it needs to do for them, the output is aimed at the wrong target. AI doesn’t fix that problem; it amplifies it.
Know Who You’re Working for Before You Start
A consistent thread across everything Mark describes is the discipline of being specific about audience and purpose before anything else. He draws on Seth Godin’s argument that choosing a specific audience and committing to it is both scarier and more effective than designing for everyone. Working for everyone gives you cover when it doesn’t deliver; choosing a specific person with a specific problem makes you accountable, and that accountability tends to produce better outcomes.
In ITSM, this means resisting the instinct to design for the average case or the generic user. The more specific you can be about who you’re serving and what their actual situation is, the more likely the output is to create meaningful value. The Nell story is an example of getting this wrong by omission: Mark hadn’t asked clearly enough who the work was for and what it needed to do for that person. He got lucky. The lesson is about the habit, not the outcome.
Step Back Often Enough to Check You’re Still Solving the Right Problem (and Adding Value)
Mark’s view on this is direct: step out of what you’re currently doing often enough to check whether it’s still the right thing. Not at the end of a project, but regularly, as a practice.
In busy operational environments, the instinct is to keep moving. Reflection feels like stopping, and stopping feels unproductive. But in ITSM, where business needs, the technology landscape, and the people involved are all in constant motion, continuing in the wrong direction is a much more expensive problem than pausing to check. This isn’t a formal review process, though those have their place. It’s about maintaining enough perspective on your own work to evaluate it (and its value) honestly and asking whether the problem you’re solving is still the right one.
The Conversations with Giants series is created by Roman Jouravlev, and you can watch this episode with Mark Smalley here.
The second article in this series is based on a conversation with Paull Wilkinson: https://itsm.tools/itsm-repeating-failure-pattern/
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.
