The instinct in some quarters is to ditch ITSM entirely, or to let the ITSM team operate in a separate orbit from DevOps practitioners. According to several practitioners and analysts, that would be a serious mistake.

“DevOps aims to deliver high-quality software to the business faster and in shorter cycles. However, it still does not eliminate the need for controls.”

Krishna Mohan Reddy, VP and Deputy Global Head of Cognitive Business Operations, Tata Consultancy Services

ITSM and DevOps are often described as the yin and yang of modern IT operations—contrasting viewpoints that, when integrated thoughtfully into a single operating model, can be highly complementary.

“Maintaining the proper balance between ITSM and DevOps helps organizations scale, grow, and become more organized. Both in harmony will increase efficiency and reduce the blame-game within the organization.”

Sachin Agarwal, DevOps Engineer and Solution Architect, Mantra Labs

As organizations work toward that harmony, here are three key pitfalls to avoid.

Mistake 1: Letting Tribal Preconceptions Block Progress

Both camps carry baggage. DevOps and Agile practitioners often automatically discount input from colleagues with ITIL certifications, viewing process-heavy frameworks as the enemy of speed. Meanwhile, traditional operations and development teams can view DevOps practitioners as undisciplined “cowboys” who ignore governance at their peril.

“You need to compromise. A lot of the new, young practitioners in DevOps and Agile will pretty much automatically discount opinions coming from people who have got ITIL certifications. And vice versa—a lot of traditional operations and development teams will look at the people in DevOps and Agile and think they’re all cowboys. But they all have something to learn from each other.”

Andi Mann, Chief Technology Advocate, Splunk

For DevOps practitioners specifically, it is worth recognizing that ITSM controls—service requests, change management, structured incident and problem tracking—do not inherently slow teams down. Done well, they provide exactly the visibility and structure that enable sustainable speed.

“In IT, just like in science, if it isn’t seen, measured, and reproducible, it doesn’t really count. ITSM is actually the perfect complement to DevOps because it aids in the visibility, measurement and reproducibility of key DevOps processes.”

Troy Vetter, COO, Coda Global

The practical takeaway: create cross-functional forums where ITSM and DevOps practitioners design processes together rather than having either side impose its assumptions on the other.

Mistake 2: Ignoring the Change Management Problem

If there is one single flashpoint where DevOps and ITSM consistently clash, it is change management. Traditional Change Advisory Boards (CABs) were designed for a world of infrequent, high-risk releases evaluated in scheduled weekly or bi-weekly meetings. Continuous delivery pipelines can push dozens—or hundreds—of changes per day. Those two realities are fundamentally incompatible without deliberate redesign.

“Change management has often been where DevOps and ITSM collide. The stereotypical Change Advisory Board must radically revise its approach to be in sync with the enormous amount of change that DevOps can produce in a day.”

Roy Atkinson, Service Management Analyst, HDI

The good news is that the ITSM community has been actively rethinking change management for CI/CD environments. The emerging model shifts change management from a gate at the end of a delivery pipeline to a continuous, embedded practice woven throughout the development lifecycle.

“There is some excellent recent thinking in the ITSM world about how change management can serve its intended purpose without being a roadblock—by acting as an enabler of change and being involved all along the way, rather than a bolt-on quality check at the end of the line before the production environment.”

Roy Atkinson, HDI

Practical approaches organizations are adopting include pre-approving standard changes that have been tested in the pipeline, automating change record creation from CI/CD tooling, and restructuring the CAB into a lighter, asynchronous review process for high-risk changes only.

Mistake 3: Maintaining Separate, Disconnected Toolchains

Even when both ITSM and DevOps teams are willing to collaborate, organizational goodwill can be undermined by incompatible tooling. When developers track work in one system and the ITSM team tracks incidents and requests in a completely separate platform, handoffs become manual, error-prone, and slow.

“You might have a tool that developers use for tracking bugs or product backlog and then there’s a completely separate IT service management tool. So what you end up doing is forcing developers to use some process that’s outside of their norm in order to address issues.”

Donna Knapp, Curriculum Development Manager, ITSM Academy; author, DevOps Institute’s ITSM for DevOps course

A significant part of DevOps resistance to ITSM has historically been driven by monolithic, manually-operated ticketing systems that added friction without adding value. Modern ITSM tooling has evolved considerably, but only delivers value if it is properly integrated with the DevOps pipeline.

“Self-service requests, automation flows and IT orchestration are now our front door to actions, and IT service management can and should be happening in the background, automagically created, maintained and measured by our DevOps tools.”

Troy Vetter, COO, Coda Global

Bridging the toolchain gap typically means one of three approaches: integrating existing tools via APIs so that events in the CI/CD pipeline automatically create or update ITSM records; adopting a platform that spans both use cases; or establishing a shared data layer that both toolchains write to and read from. The right choice depends on existing investment and team size, but any of the three is preferable to maintaining two siloed systems.

Bringing It Together

DevOps and ITSM emerged from different problems, but they share the same ultimate goal: reliable, high-quality IT services delivered as fast as the business needs them. Organizations that treat integration as a cultural and process challenge—not just a tooling decision—are far more likely to get both disciplines working in concert.

• Encourage cross-functional empathy. Create shared forums, rotating roles, or joint post-incident reviews so both camps understand each other’s constraints.
• Redesign change management from the inside out. Embed change controls into the pipeline rather than appending them at the end.
• Invest in toolchain integration. Automate the handoffs between development, operations, and service management systems to eliminate manual overhead.

The collision between DevOps and ITSM is real, but it is not inevitable. With deliberate design and a willingness to compromise on both sides, the two can operate as a unified, high-performing system.

Original reporting by devops.com. Quotes and attribution preserved from the source article.