DevOps And Service Management Need Each Other. Here’s Why

For many in our world, DevOps lives in that mysterious “other department” where people speak in acronyms you’ve never heard and push out updates at 3 a.m.

But DevOps isn’t just for “the programmers” or “the ops people.” It’s not even just a set of tools. If you strip it to its core, it’s a cultural movement that’s been reshaping how technology teams work together for more than a decade. And while it’s done a lot of good, it’s also introduced its own set of headaches (as any philosophy taken too far usually does).

Let’s try our hand at a DevOps 101, told from the perspective of (and tailored specifically to) someone who’s been living in the Service Management trenches. 

And yes, we’ve looked at this before, but from the other side; in my earlier piece, Putting the Ops into DevOps, we talked about bringing an operational mindset into development. This time, we’re flipping it: what DevOps looks like from the service desk outward, and why it matters more than you think.

DevOps in plain English

Obviously, DevOps is a portmanteau of development and operations. That barely scratches the surface though. It started in the late 2000s as a reaction to the traditional “wall” between software developers (who wrote the code) and operations teams (who deployed and maintained it).

Back then, dev teams would work in long cycles, toss a “finished” product over the wall, and ops teams would have to figure out how to run it in production. This would, of course, result in exasperated finger-pointing, delayed releases, brittle systems, and bad vibes all around.

DevOps said, “What if we stopped treating each other like different planets? What if we worked together, continuously, so software could be built, tested, deployed, and improved faster… and with fewer disasters?”

It’s part process, part philosophy, and part culture shift. And while it’s spawned a whole ecosystem of tools, the tools are secondary. The real value is on the people side – which is where the CALMS framework comes in.

The CALMS framework (and why culture comes first)

The CALMS framework is one of the easiest ways through which to wrap your head around DevOps. It’s a quick map of the big ideas:

• Culture – Building trust, collaboration, and shared responsibility between dev, ops, QA, and yes, Service Management.

• Automation – Using tooling to reduce repetitive work and speed up delivery.

• Lean – Adopting Lean principles: eliminating waste, improving flow, and delivering value quickly.

• Measurement – Tracking meaningful metrics to guide improvement (think MTTR, deployment frequency, change failure rate).

• Sharing – Encouraging transparency, open communication, and knowledge exchange.

A lot of people think DevOps starts with tools (“What CI/CD platform should we use?” or “How do we automate deployments?”) but CALMS makes it pretty clear: culture comes first. Without the right cultural foundation, all the automation in the world just lets you make the same mistakes faster.

For Service Management folks, culture is where the door swings open. You’ve already got experience in the messy, human side of tech work: navigating between teams, translating “tech-speak” for customers, and keeping a service running smoothly when the unexpected happens. That’s pure gold in a DevOps setting, because the whole point is to break down those old silos where everyone just tosses work over the wall.

In a healthy DevOps culture, you don’t wait for “handoff” to talk to each other. You’re in the conversation from the start, whether it’s about a new feature, an infrastructure change, or a process tweak. That early input means you can flag potential service hiccups before they become customer headaches, and that dev and ops teams get to hear about user pain points in real time.

Automation, Lean, Measurement, and Sharing are all important, but they’re kind of like pieces of a puzzle. Culture is the table you’re building the puzzle on top of; if it’s solid, you have a strong foundation, and it works. If it’s wobbly, the pieces might fall and scatter.

So, when you hear “DevOps culture,” think of a space where it’s normal for service desk folks, developers, and sysadmins to solve problems together, trade ideas, and share the wins. 

It’s not that everyone’s doing the same job – instead, everyone’s respecting what each role brings to the table and making sure those strengths actually meet in the same room (virtual or otherwise) before the code ships.

You can be part of the DevOps team (and likely should be).

The promise (and the pitfalls)

When DevOps works well, it really does feel like magic!

• Faster releases mean features get to customers when they still actually want them.
  
  

• Fewer nasty surprises in production means you’re not waking up to a “P1” alert because the new login screen only works on Tuesdays.
  
  

• Happier customers because they get what they need without the drama.
  
  

• Less of the “us vs. them” mindset between teams – you stop hearing “Those devs broke it” or “Ops is blocking us again” and start hearing “We fixed it together.”

That’s the dream. And it’s achievable.

But somewhere along the way, DevOps became an annoying buzzword in a lot of organizations. Leadership latched onto the faster releases part like it was the entire point, and “move fast” quietly morphed into “ship constantly,” with little thought given to what that pace does to quality, documentation, or Change Enablement. 

And that’s when the cracks start to show:

• Over-automation without understanding: Automation is great until it isn’t. I’ve seen entire pipelines grind to a halt because of one broken script that nobody on the service desk even knew existed, let alone knew how to fix. Suddenly, you’re in a standstill, and everyone’s learning in real time.
  
  

• Change fatigue: If you’ve ever had to answer “What happened to my button?” for the fourth time in a week, you know this one. Small, unannounced changes sound harmless in theory, but they chip away at trust and make support teams feel like they’re always one step behind.
  
  

• Documentation debt: “We’ll write it later” turns into “We never wrote it at all,” and by the time someone needs the details, the person who knew them has moved on to another project (or another company).
  
  

• Blame still happens: Culture doesn’t change just because the job titles did. Even with DevOps banners flying everywhere, it’s easy to slip back into old habits when things go wrong. The “no blame” ideal sounds great until the pressure’s on.

If you’re nodding along right now, you’re not alone. These pitfalls are more common than most organizations would like to admit, and they’re exactly the points where Service Management can make a massive difference. SM pros are the ones who understand the ripple effects – not just in code, but in customer experience, communication, and the health of the service as a whole.

What Service Management can bring to DevOps

DevOps and Service Management are different shapes – one’s all about rapid iteration and continuous delivery, the other’s about stability, reliability, and keeping the lights on – but when you snap them together, you get a full picture instead of two incomplete ones.

Here’s where SM brings the goods:

• Change Enablement discipline: DevOps moves fast. Sometimes too fast. Service Management can serve as the rearview mirror of this barreling vehicle (and the turn signals, and maybe the seatbelt). SM pros know how to pace changes so they don’t blindside users or bring down critical services. They make sure changes are communicated, understood, and most importantly safe.
  
  

• Incident Management expertise: When something breaks, SM knows exactly how to coordinate the response, get the right people involved, and keep stakeholders informed without sending them into a panic. They do more than just fix the thing; by managing the experience of the fixing.
  
  

• Human centered thinking: DevOps loves the “how”: How do we ship faster? How do we automate this? How do we get the code into production without manual steps? SM loves the “why”: Why are we building this? Why does this matter to the people we serve? Why are we deploying this now, and not next week? Having diverse perspectives in the room keeps teams from building technically beautiful solutions to problems nobody actually has.
  
  

• Service Transition practices: A lot of “production issues” are really “handoff issues.” Dev builds a feature, throws it over to ops, and assumes they’ll figure it out. Service Management is the one saying, “Hold up. Before we unleash this thing, let’s make sure the people running it actually know what it is, how it works, and what could go wrong.” It helps to formalize that hand-off so no one is caught off guard when the first user ticket comes in.

Bringing Service Management into the DevOps conversation early smooths everything out. You can still go fast, but you’re far less likely to end up getting fired because half the company’s systems are down.

A two-way exchange

I want to be very clear that I’m not advocating for Service Management to “fix” DevOps, or for DevOps to “replace” Service Management. Neither side is the savior or the villain. They’re just two disciplines that have been circling each other for years, pretending they don’t need each other, when in reality they’d both be better off swapping a few tricks.

Service Management folks can steal (yes, steal) from DevOps. Automation, measurement, lean thinking – these can streamline ticket workflows, improve service reporting, and cut down on repetitive tasks. Imagine automating the boring, repetitive parts of your incident process so you can spend more time on the gnarly, high-impact stuff.

DevOps teams can borrow from Service Management. Things like customer focus, documentation rigor, and change/incident frameworks aren’t “old-school bureaucracy” – they’re safety nets that keep you from deploying something at 4 p.m. on a Friday that knocks out payroll.

Done right, it’s a feedback loop. SM gets faster, leaner, and more data-driven. DevOps gets steadier, more user-focused, and less likely to set the building on fire. And everyone wins: faster delivery, fewer outages, happier end-users.

The healthiest organizations don’t draw hard lines between “DevOps work” and “Service Management work.” They blur them, on purpose, because they know the real magic happens in the overlap.

Closing thoughts

Look, DevOps and Service Management have the same ultimate goal: delivering value reliably. They just start from different ends of the process.

If you’re in SM, don’t tune out when you hear “DevOps” – lean in. Ask questions. Offer your expertise. Advocate for the cultural side of CALMS. And don’t be afraid to point out when the “move fast” mantra is creating more work (and pain) for customers.

Because when dev, ops, and Service Management pull together, we’re building a healthier, more resilient way of delivering technology, and prioritizing that the people using it actually feel the value.