The Dark Side of ITIL: How to Survive as a Human Being
Let me put this first: ITIL, at its core, is a collection of good ideas. It offers a plethora of knowledge helping to reduce chaos, clarify responsibilities, and to deliver better outcomes for any organisation of any size.
And yet, many people working in ITSM environments, especially in Service Desk or operational roles, feel that ITIL is … “not helpful”? It feels like a system that grinds them down. A system that talks about value, but rarely about the humans who are supposed to run it.
This article is an exploration of what happens when ITIL is implemented without humanity – and how to survive that as a sane human being.
Reading and learning ITIL, you will encounter concepts like value co-creation, importance of outcomes, continual improvement, collaboration and transparency. This sounds reasonable and even inspiring.
However as a daily routine, many practitioners experience “The process says no”-situations, metrics that matter more than people, accountability without authority, and being pressured by endless urgency, regardless of actual impact. Somewhere between the book and reality, something goes wrong.
Dark Pattern #1: Process Absolutism
One of the most common pathologies in ITIL environments is process absolutism. This is the belief that, if the process is followed, the result must be correct. In absolutist environments, the process becomes unquestionable. Any deviation is treated as incompetence, insubordination, or risk, regardless of context. You’ve probably heard sentences like:
- “We can’t do that, it’s not in the process.”
- “Yes, it’s stupid, but that’s how ITIL works.”
- “Audit enforces to do it like this.”
Ironically, ITIL explicitly says that practices should be adapted to context. But absolutism turns guidance into dogma.
When thinking is punished, people stop thinking. As a result we get a workforce that is experiencing a loss of professional autonomy. Adding up every little bit of frustration on a daily base will lead to gradual disengagement (“just tell me what to click”).
Dark Pattern #2: Metric Worship
Metrics are supposed to support decision-making, but in many ITIL implementations, they replace it. SLAs, KPIs, CSAT, MTTR – none of these are bad by themselves. The problem starts when numbers become moral judgments. Green = good person, Red = bad person.
Complex socio-technical work is not visible in dashboards. Context eliminated, trade-offs vanished – the human effort behind this becomes imperceivable.
You resolve a ticket quickly but cause a downstream issue? Green metric. You take longer to actually solve the user’s real issue? Red metric.
A constant pressure to optimise numbers instead of outcomes creates a fear-driven behaviour (“don’t touch it, it might break the SLA”), as well as a quiet sense of meaninglessness.
ITIL talks about value. Metric worship talks about achieving numbers.
Dark Pattern #3: Responsibility Without Authority
This one is especially damaging and yet extremely common.
On one side, people are held accountable for resolution times, customer satisfaction and service quality. But on the other side, they have no influence over staffing levels, tool quality, process design and priority conflicts.
You are responsible for outcomes, but not empowered to change the conditions that create those outcomes. This is structural unfairness.
ITIL never recommends this, but too many organisations do it anyway. And it results in chronic stress, defensive behaviour and learned helplessness.
Over time, people stop trying to improve things – not because they don’t care, but because caring hurts too much.
Dark Pattern #4: Dehumanizing Language
Listen closely to how people talk in broken ITIL environments. “Resources”, “Headcount”, “FTE” – these terms are not inherently bad, but they make it easy to forget the real humans behind them. “Ticket volume” has no relation to human needs or capacity.
Language shapes perception. When people are consistently described in abstract, mechanical terms, they start being treated that way. No, it is not malicious. It’s just systemic.
In the end, the result is a culture where exhaustion is normalised, empathy is optional, and burnout is reframed as “lack of resilience”. “I’m fine” becomes part of the job description.
How to Survive as a Human Being
ITIL literature is silent on mental health. Reality is not. Survival does not mean quitting ITIL. It means learning how to exist inside ITIL systems without losing yourself.
1. Use ITIL Language as Self-Defense
ITIL can be used to protect your humanity – if you speak it fluently. For example
+ frame pushback as risk, not emotion.
+ talk about value degradation, not frustration.
+ describe overload as capacity imbalance, not stress.
You’re not lying. You’re translating human reality into organisational language.
2. Separate Process Compliance from Self-Worth
Failing a metric is not a personal failure. Breaking a process does not make you unprofessional. Many people internalise system flaws as personal shortcomings. That’s incredibly damaging.
Learn to say (at least internally): “This is a design issue, not a me issue.” That sentence alone can save your career and mental health.
3. Practice Healthy Pragmatism
Perfect process adherence is rarely optimal. Healthy ITIL practitioners know,
+ when to bend rules to create value
+ when strict compliance actually increases risk
+ when “doing the right thing” means deviating slightly This isn’t rebellion. It’s professional judgment.
4. Decide Where Your Responsibility Ends
You are responsible for your actions – not for fixing an entire system alone.
If your questions and improvement attempts are consistently ignored, blocked, or punished, that’s a signal. It is definitely not a failure on your part.
Sometimes survival means
+ changing roles
+ changing teams
+ changing organisations
Leaving a broken system is not giving up. It’s choosing sustainability.
Reclaiming ITIL from the Dark Side
ITIL works best when treated as, a tool, not a belief system. ITIL provides guidance, not law. Thus it is a way to support humans, not to control them .
The irony is this: The more rigidly ITIL is enforced, the less value it creates. The best ITIL environments I’ve seen have one thing in common: They allow people to think.
So here’s the final thought I’ll leave you with:
If a process requires you to stop thinking in order to follow it, the process is broken – not you. Stay human. Stay sane. Even in your ITIL environment.
Enjoyed this post? Join the conversation by leaving a comment or sharing your thoughts below, we’d love to hear your experiences and perspectives. Don’t forget to explore our upcoming events for more opportunities to learn and connect, and visit the forum to continue the discussion. 
