What IT Service Management Taught Me About Relationships

I have spent twenty-five years working in and around IT service management. Google. IBM. PwC. Barclays. ServiceNow. Companies whose entire operations depend on their ability to keep vast, complex, interconnected systems running reliably.

Somewhere in my thirties, I started noticing that the frameworks these organisations use to run their infrastructure were dramatically more sophisticated than anything I or anyone I knew was using to run their personal life.

This is the observation that eventually became one of the most surprising chapters in *Relationships Modernised.

The framework enterprises actually use

Most organisations that take their operations seriously use a framework called IT Service Management, or ITSM. The specific classifications vary but the core is consistent across every implementation I have worked with.

ITSM breaks down operational activity into seven distinct categories, each with its own specific process for handling. When you understand these seven, you have a much clearer picture of what is actually happening in any relationship at any given moment, and what specific response the situation calls for.

• Incidents are unexpected disruptions to normal operations. Something broke. Something is not working as expected. Something needs immediate attention to be restored to functioning. The response to an incident is to acknowledge it, address it, and get things back to working order.
• Major incidents are incidents severe enough to require escalation, dedicated resources, and structured response. Not everything that goes wrong is a major incident. Treating minor issues as major incidents produces its own dysfunction.
• Service requests are ordinary, routine asks. Someone needs something. It is not an incident because nothing is broken. It is a normal transaction that requires a response.
• Knowledge is the accumulated organisational wisdom. What have we learned? What are the standard operating procedures? What has been documented so that we do not have to reinvent it every time?
• Changes are proposed significant modifications to how things work. Changes require review, approval, and structured implementation. Changes that bypass this process — that just happen — are one of the most reliable sources of dysfunction.
• Assets are the resources you are responsible for. What do you own? What is your infrastructure? What are the boundaries of what you are managing?
• Problems are underlying structural issues that produce repeated incidents. If the same incident keeps occurring, you do not have an incident problem — you have a Problem problem, and the response is different.

How this applies to relationships

The reason this framework applies so precisely to relationships is that most relational dysfunction is actually a misclassification error. People treat incidents as problems, or problems as incidents, or changes as service requests, and the mismatch produces the specific difficulty that neither party can quite untangle.

Consider some examples.

The incident that keeps recurring. A partner keeps arriving late. Each individual lateness is an incident — annoying, requiring acknowledgement, addressable in the moment. But if it keeps happening, it is not actually an incident. It is a Problem — an underlying pattern that requires structural attention, not repeated apologies. Treating repeated lateness as a series of incidents is one of the most common ways couples get stuck.

The knowledge that never got documented. A couple has an implicit agreement about how holidays with family work. Neither of them has ever discussed it explicitly. Both operate from slightly different understandings of what was agreed. When the agreement breaks down, they cannot resolve the dispute — because there was no Knowledge base to consult. Documenting shared agreements, formally or informally, prevents most of the friction that unclear expectations produce.

The change that was implemented without approval. A partner decides to take on significantly more work responsibility. It affects their availability, their energy, and the household routines. But they did not treat it as a Change requiring negotiation — they treated it as their personal decision. The relationship absorbs the impact without ever having agreed to it. This is one of the most common sources of relational resentment.

The service request treated as an incident. A partner asks for something ordinary. Help with a task. Emotional support during a stressful week. The other partner responds as if a crisis is occurring, dramatising the ordinary request into something bigger than it was. The service request never gets fulfilled because it was reclassified into an incident that could not be resolved.

The Knowledge base

Of the seven ITSM categories, the one I have found most transformative in my own relationships is Knowledge.

In every important relationship I am part of, there are now explicit documented agreements. Not legal contracts. Not signed documents. Just written summaries of what we have agreed together, that either of us can refer back to when uncertainty arises.

What is our approach to money? What is our approach to family obligations? What is our approach to communication when one of us is under stress? What is our approach to social media? What are our non-negotiables, and what is open to renegotiation?

These agreements do not eliminate difficulty. They eliminate the specific difficulty of two people trying to reconstruct, in a moment of tension, what they had agreed months earlier when they were calmer. That specific difficulty has been responsible for more damage in more relationships than almost any other source.

Why professional frameworks apply to personal life

The reason I keep applying professional frameworks to personal relationships — and the reason I have made this the central intellectual move of *Relationships Modernised — is that they were developed by people who took the subject matter seriously.

ITSM exists because organisations decided that keeping their infrastructure running was important enough to warrant deliberate, structured, professional frameworks. Change management exists because organisations decided that navigating transformation was important enough to warrant the same.

The inherited script for personal relationships operates as if these domains — running the day-to-day operational health of the most important connections in your life, navigating the transformations that every long-term relationship must navigate — do not require frameworks. That they should just happen naturally. That love is enough.

Love is not enough. Love is what makes the work worth doing. But the work itself requires the same quality of frameworks that any consequential domain requires.

That is the argument the book is making, and ITSM is one of the chapters where the argument becomes most concrete.

From Relationships Modernised: Lead Your Relationships in the Digital Age. Follow for more.