Service Management Leadership Podcast · 2026-08-31 · 6 min
Key moments - from our scoring
Substance score
22 / 100
Five dimensions, 20 points each
Jeffrey Tefertiller draws a parallel between aviation safety and IT service management, arguing that the riskiest moments occur during transitions rather than steady state. Just as planes experience their most critical phases during takeoff and landing, technology services face greatest risk when new services are introduced, changes are made, or systems are decommissioned. While running services benefit from autopilot-like automation and monitoring, the handoff and transition points are where organizations struggle most. Tefertiller shares a concrete example from his consulting work at a Big Four accounting firm where one team marked a server as retired in the CMDB and asset management database, but failed to actually shut it down. When the infrastructure build team reused the IP address for a new server, both machines fought over the same address, causing an outage. This story illustrates how decommissioning errors - often more common than organizations realize - create operational risk. The episode targets IT leaders and service managers struggling with incidents during transitions, emphasizing the need for better change management processes, CMDB accuracy, and cross-team coordination.
The safest phases are when the plane is parked on the ground and when it is in cruise at altitude; the riskiest phases are takeoff and landing, which parallels IT service transitions.
The operations team marked a server as retired in the CMDB and asset management database but failed to actually shut it down, so when the build team reused the IP address from Infoblox for a new server, both machines competed for the same address and caused an outage.
Introducing new services, making changes to existing services, and decommissioning services are the three moments that open organizations up to the greatest heartaches and risk.
By improving handoff processes between teams, maintaining accurate and current CMDB and asset management databases, and focusing on strong decommissioning procedures rather than only optimizing steady-state design and change management.
Our reviewer’s read on each dimension, with quotes from the episode.
The episode's sole substantive claim is that decommissioning is an underappreciated risk phase, which is a mildly non-obvious point for ITSM practitioners but is padded heavily with an extended flight analogy and throat-clearing that fills most of the six minutes.
I have seen more outages due to poor decommissioning than I can count.
it's when we introduce new services or make changes to those services, or when we decommission that we open ourselves up for the most heartaches
The airplane takeoff/landing analogy for IT change risk is a well-worn metaphor in service management circles, and the decommissioning angle, while slightly less common, is not explored with any fresh framework or contrarian argument.
This airplane analogy is very similar with our technology services. When services are up and running, the technology runs smoothly.
It's easy to talk about making sure our change management is really strong.
This is a solo-host monologue with no guest at all; the host references consulting experience at an unnamed Big Four firm but provides no credentials or demonstrated depth beyond a single anecdote.
Almost every organization that I've been a part of, which is a lot because of consulting, they struggle with decommissioning.
The episode earns its only meaningful specificity points from one concrete story that names a real tool (Infoblox), a real system (CMDB/AMDB), and a clear failure mechanism (IP address conflict between old and new servers); everything else is abstract.
the build team grabs that IP address from Infoblox and they put it on a new server. These two servers, the old and the new, are fighting over one IP address, causing an outage.
They pulled the item out of the CMDB and asset management database by pulled out of. They set the status to retired yet the server was still going, still running in the data center.
This is an uninterrupted solo monologue with no guest, no questions, no follow-ups, and no intellectual tension of any kind; there is no interview craft to evaluate.
I hope you have an awesome, awesome rest of your day.
Computed from the transcript - who did the talking, and the words that came up most.
In this episode, Jeffrey discusses why it is important to worry about the take-off and landing of our technology services Email Jeffrey with any questions or feedback (jtefertiller@servicemanagement.us) Each week, Jeffrey will be sharing his knowledge on Service Delivery (Mondays) and Service Management (Thursdays). Jeffrey is the founder of Service Management Leadership, an IT consulting firm specializing in Service Management, Asset Management, CIO Advisory, and Business Continuity services. The firm's website is Jeffrey has been in the industry for over 30 years and brings a practical perspective to the discussions. He is an accomplished author with seven acclaimed books in the subject area and a popular YouTube channel with approximately 2,000 videos on various topics. Also, please follow the Service Management Leadership LinkedIn page
Transcribed and scored by The B2B Podcast Index.
Speaker A: Foreign.
Speaker B: Welcome to the Service Management Leadership Podcast with Jeffrey Teifer Tiller.
Speaker A: Welcome to the Service Management Leadership Podcast. I am thankful to have you join
Speaker C: us for this episode. I don't travel as much as I used to for work. I kind of liked it. Some people hate is what it is. But if you get on airplanes often,
Speaker A: you know that the safest time during your flight is either when you're parked
Speaker C: on the ground, of course you're safe, or in midair. Most issues arise either at takeoff or when you're landing during midair.
Speaker A: The plane has these great features like
Speaker C: autopilot that help ensure a smooth flight.
Speaker A: Yes, you may have some turbulence, yes,
Speaker C: you may have a little bit of bumps, but they have.
Speaker A: These planes are full of technology, including autopilot, to make sure your flight is
Speaker C: going the right direction, the right speed, that everything's good.
Speaker A: But it's the takeoff in the landing that has the most risk. This airplane analogy is very similar with our technology services. When services are up and running, the technology runs smoothly. We have redundancy.
Speaker C: We have so much to monitor to
Speaker A: make sure that everything is great. However, it's when we introduce new services or make changes to those services, or
Speaker C: when we decommission that we open ourselves up for the most heartaches, especially for leadership. Yes, it's easy to talk about
Speaker A: designing those services.
Speaker C: It's easy to talk about making sure
Speaker A: our change management is really strong.
Speaker C: But oftentimes we forget about how decommissioning errors open our organization, uh, up for risk.
Speaker A: Almost every organization that I've been a
Speaker C: part of, which is a lot because
Speaker A: of consulting, they struggle with decommissioning. Either they think something's decommissioned and it's not, or something is decommissioned too early.
Speaker C: It's not smooth, not like we would like our airplane landing to be.
Speaker A: I have seen more outages due to poor decommissioning than I can count.
Speaker C: And let me give you a story back.
Speaker A: When I was at this very large
Speaker C: big four accounting consulting firm, there was a an organization that was dedicated to
Speaker A: building new servers, that sort of thing. And then there was one organization department
Speaker C: that was dedicated to operating and maintaining infrastructure. Well, the group that is responsible for operating and maintaining, they said they decommissioned. So they pulled the item out of the CMDB and asset management database by pulled out of. They set the status to retired yet the server was still going, still running in the data center. They just messed up on the timing. However, the build team grabs that IP address from Infoblox and they put it
Speaker A: on a new server. These two servers, the old and the
Speaker C: new, are fighting over one IP address, causing an outage. And it's this is a simple story, very true story, but it's one that happens often in different ways throughout every organization.
Speaker A: So if your organization is
Speaker C: having more
Speaker A: outages, more incidents, even more just missed handoffs, look at your takeoff in your landing and think, how can we do this better?
Speaker C: How can we have great handoffs, one
Speaker A: team to another, as well as keeping
Speaker C: our CMDB and our AMDB asset management database up to date and current so that these handoffs are a lot smoother.
Speaker A: My name is Jeffrey Tefertiller and I
Speaker C: thank you for joining us today. Hopefully you like the story and the analogy. Uh, and I hope you have an
Speaker A: awesome, awesome rest of your day.
Speaker C: Goodbye. Sa.
Other episodes covering the same guests and topics, from across The B2B Podcast Index.
Stop Buying Trucking Tech Emotionally: The Better Way to Choose Software with Nate JohnsonBehind The Freight · on Change management86 / 100
When You’re VP of CLM, with Sofya Mikhelson of Fairview Health ServicesMeeting of the Minds · on Change management86 / 100
50% of your job needs to be finance transformation: Anders Liu-LindbergFP&A Today · on Change management84 / 100
The Identity Threat: Why AI Adoption Is a Human Challenge, Not a Technology ProblemDisambiguation · on Change management80 / 100
6 M&As Later: What this CPO has Learned (Nichole Viviani, Chief People, Culture & Change Officer at Global Payments)The Modern People Leader: Forward-Thinking HR · on Change management80 / 100
#299 What It Takes to Become CFO by 33 Audrey Lagresle CFO, Automobile En DirectGrowCFO Show · on Change management78 / 100
Service Management Leadership - Sticky Metrics39 / 100Service Management Leadership - Ted Williams Mindset42 / 100Service Management Leadership - OCM35 / 100Service Management Leadership - Define What Good Looks Like42 / 100Service Management Leadership - Anchoring Conversations