In many organisations, the hand-off between development and operations feels like a game of pass-the-parcel, except the parcel is full of surprises, and no one wants to be left holding it. For years, when I worked in Ops, we had new projects tossed over the wall with little context and even less collaboration. What followed was usually a laundry list of ongoing issues, patchwork fixes, financial issues and many frustrations on both sides. This is where DevOps in ITSM steps in to fix what’s been broken for decades, disconnection, delays, and dysfunction between two sides of the same delivery team.
Dev vs Ops a Culture Clash
Developers thrive on change. They move fast, build features, and push forward. Operations, meanwhile, must protect the stability of the environment, minimise risk, and keep services up. These aren’t just different goals, they’re often seen as opposites. Devs want movement; Ops want stillness.
But in the world of IT service management, both are essential. The value isn’t delivered when code is committed, it’s delivered when the service works reliably for the customer. And that requires both sides of the house to act in unison.
Why Early Collaboration Isn’t Optional
The traditional model waits until code or IT project is done before thinking about operational readiness. That’s when the scramble begins; forgotten dependencies, overlooked on-going support & maintenance, zero or minimal documentation, license renewal, un-scalable components, and firefighting support teams. The DevOps approach in ITSM changes this by embedding operational thinking from the start. Operations becomes a design partner, not a late-stage gatekeeper.
One of the most powerful shifts is getting both teams to go live together. Not in silos, not in phases, but as a single coordinated release. This approach reduces unplanned costs, shortens delivery timelines, and improves confidence across the board.
Operational Readiness Is Everyone’s Job
DevOps doesn’t mean operations becomes invisible. In fact, it’s the opposite. True integration brings operations into planning discussions, sprint reviews, and architecture decisions. If you’re building a new service, you’re also building the ability to support it and that should be intentional, not an afterthought.
A real-world story in the source material shows this well. A development team couldn’t decide between a fat client or thin client. Enter an operations rep who simply asked, “What happens when the disk fails?” That practical question cut through months of debate and redirected the decision. That’s the power of integrated thinking.
DevOps Is a Service Management Tool
While DevOps often gets framed as a development practice, its principles deeply support ITSM goals. From change enablement to improved release frequency and post-deployment support, the overlap is clear. What matters is that the mindset is applied correctly and not as a quick fix, but as a cultural shift that drives continuous improvement.
🔗 Further Information.