I recently finished reading Mark Manson's book The Subtle Art of Not Giving a F*ck. Aside from the great insights that the book provided there was one concept that really got me thinking as it applied to Service Management.
The concept was popularized by Alan Watts and is called the Backwards Law
To paraphrase how Manson interpreted it in his book “The desire for a more positive experience is itself a negative experience. And, paradoxically, the acceptance of one’s negative experience is itself a positive experience.”
If you’ve spent any time in Service Management, especially in improvement initiatives, you’ve likely encountered the paradox that Alan Watts dubbed The Backwards Law. The harder you chase something (certainty, speed, efficiency, “world-class service”), the more elusive it becomes. In fact, the very act of obsessively chasing improvements can create dysfunction.
Sound familiar? Welcome to ITSM’s daily struggle.
The ITSM Paradox: Why Chasing “Better” Can Make Things Worse
Let me break it down.
In ITSM, we often over-engineer. We build massive frameworks, set sky-high SLAs, measure everything that moves, and invest in shiny tools. All in pursuit of “maturity.” But here’s the kicker, the harder we try to “optimize,” the more complexity we create. Instead of solving problems, we introduce new ones: tool fatigue, process gridlock, staff burnout.
It's like trying to force calmness by shouting "EVERYONE RELAX!" and it never works.
Incident Management: The Hero Trap
Take incident management. Many organizations strive to be “incident response rockstars.” Quick resolution becomes the KPI of choice. Dashboards track Mean Time to Resolve (MTTR) down to the second. But when you obsess over resolution speed, you might discourage escalation (no one wants to “miss the SLA”), over-focus on major incidents, and neglect root cause analysis.
The result? A fire-fighting culture where teams are celebrated for solving problems rather than preventing them.
That’s backwards.
CMDB: The More You Want Control…
For me, one of the most infamous examples of Backwards Law in ITSM is the Configuration Management Database (CMDB). Everyone wants one. Every major tool has one. In my experience nearly every IT team has been burned by trying to build a “complete” one.
The more you desire total control and visibility over every CI, relationship, and dependency, the more paralyzed you become. You start with ambition and end up with spreadsheet chaos or a bloated, inaccurate CMDB that nobody trusts.
The organizations that succeed with CMDBs? They accept imperfection. They scope it ruthlessly. They focus on value, not coverage. They embrace uncertainty and manage it, rather than trying to eliminate it.
Change Management: Control vs Flow
In change management, the backwards law shows up when governance becomes obsession. CAB meetings are filled with fear-based language:
Stope me when you have heard these…..
- “We shouldn’t see any issues.”
- “It’ll probably be fine.”
- “No rollback needed. This will work.”
(Yes, real quotes, and cringey ones at that).
The more you try to eliminate all risk, the more rigid and slow your processes become. Eventually, people bypass them entirely. Shadow IT flourishes. Developers go rogue. Ironically, in your quest for control, you lose it.
The better approach? Accept that not all changes are equal. Empower teams. Build trust. Automate what’s low-risk. Reserve rigor for what really matters. Control flows better when you loosen your grip.
Applying the Backwards Law to ITSM Improvement
So how do we use the Backwards Law constructively in ITSM?
Here are 3 real-world ways:
1. Shift from Outcomes to Intentions
Rather than obsessing over “high performance” metrics like SLA adherence or ticket volumes, shift your focus to the intent behind your work, delivering value to the business.
Start by asking:
- “What’s meaningful to our customers?”
- “What would they miss if we stopped doing it?”
- “Where are we over-engineering in the name of ‘improvement’?”
2. Embrace Imperfection
Perfection is not only unattainable, it’s counterproductive. In continual improvement work, don’t wait for the perfect time, tool, or process. Start where you are. Use what you have. Improve what matters most, and accept that some things won’t be fixed right away.
In fact, some of the most effective improvement work starts with admitting, “We don’t have this figured out.”
3. Let Go to Move Forward
This sounds a bit pie in the sky, but it’s practical. If you're clinging too tightly to dashboards, frameworks, or compliance checklists, step back. Ask: “Is this serving us, or are we serving it?”
Letting go might mean:
- Simplifying your service catalog
- Retiring unused metrics
- Killing CAB review items that add no value
- Accepting that your CMDB only needs 20% of the data to be useful
Let go of control for control’s sake and focus on flow.
Final Thought: Watts, Manson, and the Service Desk
If Alan Watts ran a service desk, he might tell us to stop trying so hard to be great at ITSM, and instead focus on being useful, present, and adaptive.
If you want better incident response, build empathy into the process.
If you want better change outcomes, talk about risk honestly.
If you want improvement, stop trying to improve everything all at once.
Or as Manson said: "The key to a good life is not giving a f*ck about more; it’s giving a f*ck about less."
In ITSM, give a f*ck about what matters.
The rest? Let it go.