ITIL, by design, doesn’t close the gap between formal structures and reality. It assumes the gap doesn’t exist, and I’ve seen it with developers in a large bank. For us, it was a “good news” story in the end, but we needed to learn along the way.
The Reality Check: When ITIL Doesn’t Deliver for Developers
When I joined as a Developer Experience (DevRel) consultant at one of Kazakhstan’s largest banks with 700+ engineers, I expected the usual challenges: stakeholder alignment, change resistance, legacy tooling. What I didn’t expect was to watch a mature ITIL 4 implementation – incident management, change enablement, service level management, knowledge management, the works – quietly fail to deliver what it promised. IT service management (ITSM) processes existed, and practices were documented by dedicated practice heads. Tools were in place. And yet deadlines slipped, ownership was perpetually unclear, knowledge lived in people’s heads rather than any system, and delivery happened not predictably, but despite the structure rather than because of it.
The Strengths – and Assumptions – of ITIL 4
ITIL 4 is a genuine improvement over its predecessors. The shift from rigid processes to flexible practices, the focus on value co-creation, and the acknowledgment that service management needs to fit within developer (Agile and DevOps) environments – all of this was needed and largely works. But ITIL still carries an embedded assumption: that the people implementing it share a common understanding of what the services are, who owns what, and how individual work connects to organizational outcomes. It assumes alignment is the baseline, and that process gives it structure.
Why ITIL Struggles in Developer-Led Organizations
In a large bank’s engineering organization in 2026, that assumption doesn’t hold. Here’s what I actually observed:
- Modern developers are rightly expected to be autonomous. Choosing tools, influencing architecture, deciding how work gets done. But autonomy without clear ownership leads to local optimization. Teams deliver their piece and move on. Nobody owns the seams between them.
- Across a workforce of hundreds of engineers, many remote, many working across multiple parallel priorities, the idea that everyone is equally invested in long-term service outcomes is simply not realistic. This isn’t a moral failing; it’s a structural reality of how large technology organizations work today.
- Developer culture, especially in high-performing teams, prizes speed and minimal bureaucratic overhead. ITIL’s change controls, documentation requirements, and formal approval chains don’t feel like enablers to most engineers. They feel like overhead. So, they get worked around not maliciously, but pragmatically.
- As a result, change processes were bypassed, documentation stored in Confluence remained intact, and service levels became targets rather than commitments, a situation aggravated by the fact that Agile sprints were automatically closed after two weeks.
Where ITIL Practices Break Down in Reality
The failure points with developers were consistent and are worth naming:
- Knowledge management existed on paper. In practice, documentation was incomplete, outdated, or simply absent. Onboarding new engineers meant scheduling time with specific people – the ones who happened to remember how things worked. The knowledge management practice was real; the knowledge management system was not.
- Service level management suffered from diffused ownership. When it’s unclear who’s accountable for a service outcome, deadlines become suggestions. Service level agreements (SLAs) existed; confidence in them had eroded. Escalations increased not because things were worse, but because nobody trusted the commitments.
- Continual improvement was consistently reactive rather than proactive. Teams focused on delivery, not reflection. The same failure patterns recurred across improvement cycles because improvement had no anchor – no one owned the problem persistently enough to solve it.
- Change enablement was the most visibly circumvented practice. Fast-moving teams found formal approval processes too slow and simply routed around them. Changes landed in production that weren’t fully visible to anyone. Risk was managed implicitly by individuals rather than explicitly by the system.
The Root Cause: An Organizational Understanding Gap
It took time to resist the easy explanation that this was a discipline problem, or a culture problem, or a training problem. These framings lead to more controls, stricter enforcement, and heavier governance. They make things worse.
The organization had:
- Documented processes
- Defined practices
- Tooling to support workflows.
What it lacked was a shared understanding of how services actually function – real dependencies, actual ownership, and lived workflows. ITIL managed what should happen. It had no mechanism for ensuring people understood what was happening, including developers.
What Worked: Mapping Real Work Instead of Ideal Processes
Rather than introducing more controls, we took a different approach. We ran structured conversations with developers/engineers across teams, not about processes, but about actual delivery. How do features get built? Where do delays happen? How are dependencies managed? Where does confusion come from?
From those conversations, we built what I started calling engineering narratives: end-to-end descriptions of how work actually moves through the system. Not how it was supposed to move. How it did.
What these narratives revealed was illuminating:
- Hidden dependencies that existed in practice but nowhere in any documentation
- Ownership gaps at the boundaries between teams – everyone assumed someone else was responsible
- Repeated failure points that had never been named as systemic issues because they looked different in each incident
- Significant mismatches between documented processes and actual behavior.
We then transformed these narratives into simple, shareable artifacts: visual flows of real delivery, explicit ownership maps, and context around key decisions and trade-offs. These were not process documents. They were representations of operational reality. When we brought these artifacts back to the teams, something shifted.
Conversations that had been about blame or escalation became about understanding. Ownership gaps became visible and discussable. People started agreeing on what was actually happening, and from that shared ground, ITIL practices started working better. Not because the practices had changed. Because people finally shared the same mental model of the system the practices were supposed to govern.
How Shared Understanding Unlocks ITIL’s Value
My conclusion isn’t that ITIL 4 is insufficient. It’s that ITIL is incomplete when applied without a foundation of shared organizational understanding. Call it a “world model,” a “service map,” or just organizational clarity about how things actually work. Whatever its name, it’s the layer that must exist before ITIL practices can function as intended with developers.
Without it:
- Governance becomes symbolic rather than meaningful
- Practices become inconsistent because people are operating on different models of reality
- Outcomes remain unpredictable even when processes are technically followed.
With it, the same practices deliver significantly more. Not because ITIL changed, but because it finally has something real to operate on.
Practical Advice for ITIL in Modern Developer/Engineering Teams
If I were to distill this into practical guidance for anyone running an ITIL “implementation” in a large engineering organization, it would be this: before you adjust a single practice, invest time in understanding how work actually flows through your system. Talk to engineers. Map real dependencies. Name real ownership. Make the informal explicit.
The gap ITIL struggles to bridge in developer-led organizations isn’t a process gap. It’s an understanding gap. And no amount of governance can close it; only honesty about operational reality can.
Askar Aituov
Askar works as a DevRel and ITSM consultant and has led service management initiatives across large-scale engineering organizations in Central Asia and beyond.
