The Anti-Powernoia Practical Implementation Guide

Never heard of Powernoia? Please read this: I need to confess something. For three decades as a CIO and consultant, I implemented IT service management (ITSM) frameworks in dozens of organisations. ITIL, SIAM, VeriSM, DevOps, Agile. I trained hundreds of people. I designed processes. I built service catalogs. I measured everything. I chaired all sorts of meetings and required countless reports.

And I created systems that destroyed people while supposedly delivering “service excellence.”

I genuinely believed I was implementing ITSM best practices. I genuinely thought ITSM metrics would drive improvement. I genuinely trusted that ITSM frameworks would solve problems. I genuinely believed that my years of IT and ITSM experience, along with the title I held, would drive us toward better, safer ways of doing things.

I was wrong about what mattered. I forgot about the people I worked with, our customers, our suppliers and, most importantly, those who worked for me.

ITSM practices are tools. The tools of ITSM are just tools. Powernoia (my belief as the biggest elephant in the room) decides how they’re used.

Powernoia: The Implementation Failure Nobody Talks About

We obsess over:

• Which ITSM framework to use
• How to structure ITSM processes
• What ITSM tools to implement
• Which ITSM metrics to track
• How to measure ITSM maturity

We ignore:

• Who should have decision-making power
• Whether people can speak up safely
• If authority matches accountability
• Whether metrics serve value or control
• Who benefits from the current state
• Whether our future state is truly in a five-year plan.

That second list is where Powernoia lives.

Powernoia is paranoia merged with power. I’ve watched it transform excellent frameworks into weapons:

• Change Management → “We can’t approve this because… risk.” (Translation: We’re afraid to trust you.)
• Incident Management → “Who missed this?” (Translation: Blame someone so leadership stays safe.)
• Problem Management → “It’s a known error.” (Translation: We’d rather workaround than fix the root cause in leadership.)
• Service Level Management → “You missed your SLA.” (Translation: Your failure, our metrics.)

Powernoia: The Aspect That’s Missing From Your ITSM

We implement:

• Ticketing systems
• Monitoring tools
• Change platforms
• CMDB solutions
• Reporting dashboards.

We don’t implement:

• Psychological safety measurement
• Powernoia detection systems
• Authority-accountability alignment checks
• Dignity impact assessments
• Mental health monitoring.

The ITSM Metrics That Actually Matter

Forget your current ITSM key performance indicators (KPIs) for a minute. Try these:

Decision Distance

How many layers are between problem identification and solution authority?

• 0-1 layers = Empowered
• 2-3 layers = Manageable
• 4+ layers = Powernoia

Speak-Up Safety

Can people challenge decisions without career risk?

• Measured via anonymous surveys
• Tracked via “ideas implemented from the frontline”
• Validated by “problems surfaced vs. problems hidden”
• Open via the utilization of visual management techniques (Kanban, value stream mapping (VSM))

Authority-Accountability Alignment

Do people have the power to achieve what they’re responsible for?

• % of decisions requiring escalation
• Time from issue identification to resolution authority
• Bottleneck analysis (who’s blocking what)

Dignity Preservation

Do practices honor or strip people’s dignity?

• Post-implementation surveys not written to source blame
• Turnover rates of high performers
• “Would you recommend working here?” scores

Powernoia Indicators

• Homogeneity of the leadership team
• “Culture fit” rejection rates vs. capability rejections
• Decision transparency scores
• Information hoarding patterns

Try running these alongside your traditional ITSM metrics, and see what you discover.

Powernoia: Real Implementation Examples

Change Management – Before

• Change advisory board (CAB) meets weekly
• All changes require approval
• Board of eight senior leaders
• 60% rejection rate
• “Risk reduction” justification
• Result: Innovation dies, workarounds proliferate

Change Management – After

• Tiered authorization (small changes = local authority)
• CAB for architectural decisions only
• The next team in the value stream can approve the change
• Must justify “no” with specific risk
• Rejected changes get alternative paths
• Result: Speed increases, engagement improves

Incident Management – Before

• Root-cause analysis (RCA) focuses on “who missed what”
• Blameful post-mortems
• Speaking up discouraged
• Same problems recur
• People hide issues
• Result: Anxiety, reduced reporting, worse outcomes

Incident Management – After

• Blameless post-mortems led by senior management that has to fix all of the outcomes
• “What system failed,” not “who failed”
• Psychological safety measured
• Speaking up rewarded
• Result: More problems surfaced, faster fixes, less stress

My Powernoia Call to Action

I need ITSM.tools readers to:

• Share your Powernoia detection methods
• Propose practical anti-Powernoia tools
• Submit before/after implementation stories

What matters most? Dignity. Practices should enable it, not destroy it.

Are you implementing ITSM or implementing Powernoia with ITSM vocabulary?

Written with Claude.ai assistance – transparency matters

Further Reading

How IT Service Management Eliminates SaaS Waste and Boosts Enterprise Efficiency

Reimagining Knowledge Systems in ITSM: Moving From AI-Assisted to AI-Native

Setting the Standard: How Analyst Reports Guide Service Management Progress

From Configuration to Value: How the VMDB Transforms the CMDB into a Value Management Engine

Technicians Hold the Access: Why IT Service Desks Are the New Cybersecurity Target