IT service management has evolved significantly over the years, but the fundamentals of great support remain rooted in people, collaboration, and trust. As AI and automation reshape how services are delivered, organisations need to think carefully about how they preserve the human element while building services that work across teams and providers.
Humans of Support is our interview series where we put the spotlight on the people who have been there and done that in the world of support and IT service management.
In this episode, we speak to Michelle Major-Goldsmith, a globally recognised service management thought leader with nearly 30 years of industry experience. An ITIL ambassador, co-author, and passionate advocate for lifelong learning, Michelle shares her perspective on applying ITIL in practice, keeping service management knowledge relevant, building trust across service providers, and navigating the opportunities and challenges of AI.
We also explore how support has changed across three decades and why knowledge management remains one of the most underrated areas in ITSM.
Here’s the full interview with Michelle below.
You’ve worked in IT service management in both the UK and Australia. What differences have you seen in how IT services are delivered and valued across the two?
The gap between the UK and Australia has closed, and in some areas, it may have even flipped. Service integration is now the linchpin that holds everything together.
Michelle Major-Goldsmith, Global SIAM & Service Integration Authority
I actually got my job in Australia through a connection between IT Service Management Forum Australia and the IT Service Management Forum in the UK. That bridge between the two has really mattered to me.
I left the UK nearly 15 years ago, but I never really left. I go to the ITSMF Australia conference most years, and for the last five or six years, I’ve gone back to the ITSMF UK conference as well. I still work with people there, so I get to see both sides and notice how they’ve shifted and changed.
When I first arrived in Australia, people used to say that Australia was 10 years behind. I don’t think that’s true anymore. The gap has closed, and in some places, it may have even flipped.
The UK has a longer history of large-scale, multi-provider arrangements, which means there’s a depth of experience and a lot of lessons that have already been learned. Australia, on the other hand, has a smaller market but bigger distances, so people tend to wear more hats. You often see specialist teams that have learned to collaborate effectively and deal with more complex responsibilities.
What’s striking to me in both places now is how much everything depends on service integration. Whether it’s cybersecurity, AI, cloud, resilience, or experience management, none of it sits neatly with one team or one provider. These things cut across everything, so integration has become the linchpin that holds it all together.
I see organisations in both countries waking up to that. There’s an interesting observation by Melvin Conway, made back in 1968 in How Do Committees Invent?, that organisations design systems that mirror their own communication structures. It became known as Conway’s Law.
I think the same is true of services. Your customers experience your relationships. If your service providers don’t talk to each other, your customer will feel that gap.
In terms of what’s the same, I’d say it’s the people. The best services I’ve ever seen come from teams that stop worrying about whose logo is on the badge and start working as one team. That’s true in both countries.
As an ITIL Ambassador, what do you think practitioners most often get wrong about applying ITIL in the real world?
ITIL is a framework, not a rigid methodology. Process should be used where risk demands it, while principles give people room to think.
This is a very common question. Lots of people know about ITIL, and many have been using it for years. Paul Wilkinson, a well-known industry leader in service management, talks about what he calls the “shiny new thing” and how our industry keeps finding new ways of reinventing frameworks and approaches.
One of my personal favourites is his ABC of ICT, which is about attitude, behaviour, and culture. I think that’s hugely relevant when we’re talking about service management frameworks like ITIL.
We’ve been saying the same things for decades, and yet we still hear stories about service improvement projects using ITIL that fail. That should really worry us.
I recently read a book about leadership called Leadership Without Answers by Ronald Heifetz. He talks about technical problems, which experts can fix, and adaptive challenges, which are more difficult to address. I think that’s where we come unstuck when we focus on things like ITIL.
We keep thinking that service improvement is a technical problem. We think it’s about new tools and new processes, but we also have to adapt. One thing we need to get better at is bringing about changes in behaviour.
Best practices like ITIL work better when we have the right attitudes, behaviours, and culture. Too often, leaders still see service management as a process thing that belongs to the IT team, rather than an organisational theme that’s about creating value. If leaders don’t get that right, even great frameworks like ITIL won’t stick.
We also need to be clear that ITIL isn’t a methodology. I often hear people say, “The ITIL book said that I have to do this and that.” I can pretty much tell you what’s on the pages of those books because I’ve read them so many times, and they don’t say that.
ITIL is a framework. It’s a starting point that gives us guidance, not a one-size-fits-all solution. Context, people, and collaboration are what give it meaning. That’s why I love the ITIL guiding principles. They’re enduring.
The real skill is knowing the balance. When do you genuinely need a process and a policy because consistency and risk management matter? And when do you need principles, guardrails, and good human discretion?
My mantra would always be “process where the risk demands it, principles where people need room to think. ” The skill is knowing which is which.
You’ve spent years shaping the industry through SIAM, ITIL, and service management both as a professional and a thought leader. As a keynote speaker, where do your ideas come from, and how do you keep your thinking fresh?
My ideas come from conversations, listening, and reading. Staying curious and being willing to be wrong helps me challenge what I think I know.
One thing I always say to people is that there are always cleverer people around you. Honestly, that freshness comes from conversations, and I read a lot as well.
I’m not a technologist, and I never have been. I’ve always been drawn to the human side of service management: relationships, trust, and those moments when things go wrong and people either pull together or pull apart.
I learn a lot by listening to practitioners in workshops, people I meet at conferences, and the questions I get asked afterwards. Those conversations after a keynote are often better than anything I said on stage. They’re thought-provoking and help me understand things differently.
Stories are another important source of inspiration for me. I’d rather explain something through a real moment, like a pilot landing on the Hudson or a global outage that stopped the world, than through a framework diagram. I love ITIL, but I think storytelling is a better way to explain things. People remember how something made them feel.
I rarely put much text on my presentation slides. I’d much rather show an image and tell a story. I also love gamifying things, using props, and bringing in fun elements. For an upcoming conference in the UK, Scopism Service North, I’m going to use LEGO bricks to explain SIAM and composable concepts.
I think it’s important to keep our ideas fresh, help people understand things better, and bring them back to the basics through tangible examples.
Another of my mantras is that staying fresh means remaining curious and being willing to be wrong. I’ve been working on international standards, where you sit around a table with people from different cultures, countries, and backgrounds. In that context, your assumptions get tested very quickly.
On a personal level, I’m also doing a PhD on complexity and leadership decision-making. I completed my master’s about 30 years ago, when university and academia were very different. Coming back to it has been a huge culture shift, a real learning experience, and a humbling one. It makes me question things I thought I knew, which I think is really important.
I’m working more with academics and getting closer to different industries. I’m using that as an opportunity to build practical skills, not just technical ones, but also the ability to reach across industries and professions and learn to think differently.
The Service Integration and Management Body of Knowledge is continually evolving. How do you decide what needs to change, and what principles should stay?
The principles stay, but the context changes. Listening to practitioners helps us evolve the guidance without rewriting the fundamentals every time.
I work with two other chief architects, Simon Dorst in Australia and Claire Agutter, the director of Scopism in the UK, which owns the SIAM body of knowledge.
How we keep things up to date and decide what needs to change comes down to listening to the community. The body of knowledge was never written by one person in one room. It’s grown through hundreds of practitioners sharing what works for them and what doesn’t. It’s built in layers.
The foundation and professional books provide the core. That’s the common ground everyone needs if they want to do SIAM. We also have a glossary that helps us establish a shared language, which is equally important.
In the latest iteration, we have the SIAM compendiums. They go deeper into specific areas such as trust, skills, experience management, AI, and automation.
That layered approach allows us to respond to new thinking without having to rewrite the fundamentals every single time.
As architects, Claire, Simon, and I oversee the Content Council, which guides what gets developed and how everything fits together.
What changes is usually the context. It might be new ways of working, new regulations, new technology, or different kinds of service providers. When we see practitioners trying to solve a problem that the existing guidance doesn’t cover, we know that’s a signal that there’s something we could use to enhance SIAM. That’s where the compendiums come in.
The principles stay, but the context changes.
Things like collaboration, trust, clear accountability, and the impartiality of a service integrator are fundamental to SIAM, whether we’re working with internal or external organisations. Providers need to follow shared ways of working and work towards the same outcome.
Language matters because it shapes behaviour, but the context needs to be adaptive. What industry am I in? Is it a large organisation? Where is the business focus? Those are the things that need to change depending on the environment.
Another thing I’m really proud of working on over the last few years is the international standard ISO/IEC 20000-14, which provides guidance on applying service management standards in the SIAM ecosystem.
That was a big moment. It told the world that SIAM isn’t just a fad; it’s a recognised way of working. For me, that’s important because standards and guidance need to keep evolving so they remain relevant to the global industry we’re part of.
With years of experience comes a tacit knowledge that's usually difficult to record. What’s something you know really well that you wish more people in the industry understood?
You can't contract your way to trust. Contracts matter, but collaboration, trust, and understanding complexity are what help service providers work effectively together.
One thing that has really excited me, and that I don’t think I’ve paid enough attention to before, is the importance of trust.
In a SIAM ecosystem, we have contracts, of course, and they guide how we work. But if we want to get the best out of people, you can’t contract your way to trust.
I’ve seen organisations spend months defining contracts, looking at service levels, and concentrating on penalty clauses, but almost no time thinking about how people are actually going to work together. Then they’re surprised when things don’t work.
Trust isn’t a soft concept. It’s what makes everything else more effective.
When people trust each other, they share information early, admit mistakes, and pick up the phone before things go wrong rather than after. When trust is missing, everything slows down and every conversation becomes a negotiation.
Stephen Covey’s book The Speed of Trust makes an interesting point. When trust is low, everything takes longer and costs more. He calls it a “trust tax,” which I think is brilliant. When trust is high, you get a trust dividend.
I see that trust tax in multi-provider environments. Low trust is probably the most expensive line item that nobody budgets for because they don’t recognise it.
Trust is built in small moments: keeping your word, giving someone credit when they’ve done a good job, not throwing them under the bus, and how you behave in a service review meeting.
Leaders are particularly important because they set the tone. If leaders talk about “us and them,” the teams will too.
Another area I think is largely misunderstood is complexity. Dave Snowden, who developed the Cynefin framework, talks about complexity, and we often misunderstand the fact that we’re working in complex environments, not just complicated ones.
Leaders don’t always recognise the difference, and that’s a real challenge. They often make decisions without context, but context is everything.
If you don’t understand the environment you’re working in and adapt the way you make decisions accordingly, you’re almost certainly not going to make those decisions well.
We need to think carefully about complexity and how we manage decision-making in those contexts. And we need to think just as carefully about trust and how we build it, because it’s incredibly important.
Across 2006, 2016, and 2026, three decades, how has support changed at its core?
In 2006, being human was simply part of the job. In 2026, with AI and increasingly complex service ecosystems, we have to deliberately design the human element back into support.
Gosh, that makes me feel really old!
Back in 2006, I was in the UK and had long since finished one of my favourite jobs: being a service desk manager. I worked for RAC and the British School of Motoring, and our service desk supported the staff, not the motorists.
We spoke to people in offices and roadside mechanics who needed their systems to work so they could get people back on the road after a breakdown.
Being human wasn’t a strategy back then. It was just how you did the job. People didn’t really talk about the human element. You picked up the phone, helped somebody, and that was how it worked.
Moving forward to 2016, support had gone digital and become multi-provider. Lots of organisations were delivering services, and people really struggled to join everything up. I think that’s when the SIAM body of knowledge came into being.
But 2016 wasn’t the invention of SIAM. It was the point at which we codified it and gave it a common language. Many organisations had been using SIAM principles for years, but there wasn’t a shared language behind them.
Now, in 2026, we talk about IT and support as an ecosystem. AI is answering lots of questions, automation is fixing things before people even notice, and services might involve dozens of service providers that the customer never actually sees or speaks to.
That’s a massive evolution.
But the real change at its core is that, in 2006, being human was a given. In 2026, it’s almost having to be a choice.
I’m seeing a renewed drive to put people first. It’s almost a backlash to AI, with people asking, “Hold on, where did that human element go?”
I think it’s encouraging that we’re having that conversation, but it has to be deliberate. We have to design the human element back into support because, when we’re dealing with AI, it won’t happen unless we actually think about it.
AI: boon or bane?
AI is positive if we're intentional, but we risk automating the training ground for tomorrow's experts. If we're lazy and don't really think about the impacts, it's not a great thing.
It’s an interesting question, isn’t it? I don’t think there’s a straightforward answer. I think AI is doing good things, but it’s also creating challenges.
I’m not an AI expert, and I’m wary of anybody who claims to have it all figured out. What worries me isn’t the technology itself; it’s how we’re going about it.
Many organisations I see or read about seem to have no AI strategy, no clear purpose, and little or no training for their people. They’re going into it blindly, deploying tools and hoping for the best because they see everybody else doing it.
For me, that’s not transformation. That’s a fear of missing out, which I think is really scary.
AI is only as good as the knowledge, data, and decisions behind it. If your knowledge is messy, your AI is going to be messy. It’s just going to be messy faster, which isn’t great.
We have a real opportunity to take away repetitive work so people can focus on conversations that genuinely need a human. That’s a plus; it’s a boon.
But the risk is that we forget the human altogether and automate empathy out of the experience. I’m certainly seeing situations where nobody is quite sure who’s accountable for what the AI did. That’s a scary conversation, particularly in a multi-provider environment, where accountability becomes very real very quickly.
There’s also something important to consider about IT support and the service desk. Most of us started our journey there. It’s where we learned our craft.
When I worked on a service desk, thousands of everyday calls taught me how things worked and how people behaved under pressure. They taught me how to stay calm.
If AI takes away every easy ticket, where will tomorrow’s experts come from? I think we run the risk of automating the training ground, and we’re not talking about it nearly enough.
I’d like to see more discussion around that. AI can be positive if we’re intentional about how we use it, but I don’t think it’s a great thing if we’re lazy and don’t think about the impacts.
What’s one ITSM trend today that’s genuinely underrated?
AI runs on knowledge, not just data. Organisations need structured, current, trustworthy knowledge and people who know how to question AI's answers.
I’m going to be quite boring and say knowledge management because it’s so important. I know it’s not new, and I know it’s not exciting, but that’s exactly why it’s underrated.
Everybody’s talking about AI, but AI runs on knowledge. Most organisations still have very little direction on how they manage what they know.
If we go back to basics, there’s the DIKW model used in ITIL: data, information, knowledge, and wisdom.
Data isn’t knowledge. A pile of tickets is not knowledge. Knowledge is what you understand when data has given you context and meaning. And wisdom is knowing what to do with it.
I don’t think that distinction is well understood in many organisations. If we don’t understand the difference, we’ll feed our AI data and expect to get wisdom back. That’s a huge mess.
Two things matter now.
First, people need to learn how to use AI well: how to ask good questions and how to challenge what comes back.
Second, we need to learn how to build knowledge for AI. It needs to be structured, current, trustworthy, and actually owned by somebody.
There’s also the question of tacit knowledge. People often know more than they can tell. When experienced people leave an organisation, that knowledge walks out of the door. It’s knowledge that AI will never find on its own.
We need to recognise that and think about how we’re going to share knowledge across the whole ecosystem of service providers. Quite often, we work with providers whose people we may never even have met.
Get that right, and everything else gets easier. Get your knowledge right, and even your AI will get better.
