Change implies risk, inability to change implies certain death.
“Nobody moves, nobody gets hurt” used to be a joke agenda for a
safety meeting… It turned into the fundamental structure used to
…I have worked for tens of companies that use ITIL/ITSM models and
all of them are were miserable and unhappy workplaces.
When I have worked in companies that don’t use ITIL (and there are a
few) I found they were a great places to work where real business
value was being created and delivered.
ITIL = misery + unhappiness.
Some years ago I took a step back and made a conscious
decision to avoid working for companies that asked for ITIL,
ITSM, PRINCE2 and TOGAF experience…
…and my work happiness improved enormously.
It’s about happiness.
I know people keep saying
“If you follow and use ITIL correctly it works perfect!”
Umm, isn’t the giant swath of failure evidence that ITIL doesn’t work?
This is just the No True Scotsman fallacy to defend ITIL.
According to most of you, if you use ITIL and your IT sucks, you are not
using ITIL properly.
There are a ton of people wanting to manage by spreadsheet, that
just haven’t paid their dues in Engineering…Yet they outnumber the
They increase the administrative workload on Engineers simply by
going through continuous status updates in multiple tools.
Been through this so many times, PMP/Prince2/ITIL/ITSM outnumber
engineering staff by two or three to one and then complain when the
technical work falls behind schedule.
In my 20+ years as a victim of corporate IT and ITIL, I
was disheartened and demotivated by the consistent
bad implementations of ITIL.
I blame the ITIL methodology for making it so simple
ITIL gets implemented absent common sense, far too
More importantly, ITIL destroys potential outcomes
by preventing change.
The ultimate outcome of ITIL is that it creates incentives to
Over years, this creates flawed business flow and IT becomes a
cost centre instead of a profit centre.
I’m happy to accept ITIL is good on paper, it certainly isn’t in real
The overwhelming bureaucracy actively encourages technical-
debt inducing shortcuts, sub-optimal solutions and dangerous
reuse and overuse of existing assets.
These become too big to fail which only feeds the need to
massively overprotect these brittle system with their myriad
integrations into everything else.
I think the major difference between ITIL and DevOps really comes down
to the approach to failure.
ITIL introduces a world of pain to minimise its possibility whilst probably
increasing it in the long run and having a high number of unpleasant
DevOps has tolerance built-in by design and consequently, a high
number of positive benefits.
…The most dangerous misunderstanding is that
systems that encourage a lot of work in process and
ticketed handoffs are somehow less risky and
therefore better for “stable, mission critical”
…we had a great team, great morale and more importantly great
results – That has all been thoroughly beaten out of our once
upbeat teams and many have left as a result.
DevOps is a reaction to the poisonous effluent of ITIL abound in
If your team sucks, no matter what framework you apply the
results will likely be sub-par.
Enterprise culture is watching the world race away if it thinks ITIL
is the answer.