ServiceNow as a Philosophy

I've been working with ServiceNow for more years than I'd like to admit.

Configured it, integrated it, debugged it at 2am, argued with it in ways I'm not proud of. Migrated CMDB data so wrong it was almost impressive. Written discovery probes for systems that technically shouldn't exist but definitely do.

Somewhere in all of that, I stopped thinking of ITSM as a tool category and started thinking of it as a way of deciding how work should move through an organization.

What ITSM actually says

ITIL, the framework under most ITSM setups, is really making one claim: work that flows through clear processes and documented handoffs produces better outcomes than work that flows through favors and tribal knowledge.

That's not really about technology. The technology is almost incidental — you could run a version of ITIL on index cards if you had the patience for it.

It's a claim about organizational design. An organization that runs on documented process, something anyone new can pick up, scales. One that runs on a handful of people who've "been here long enough" doesn't, or scales only at a painful cost.

The resistance to process

Every organization I've worked in has people who resist ITSM on principle. They call it bureaucracy, red tape, an obstacle dressed up as a queue.

Usually these are good people, often very good at their jobs, and their complaint isn't wrong. Formal process does add friction. A change request that needs approvals and a test plan is slower than calling the sysadmin you know and asking him to just push it.

Right up until it isn't. The informal path is fast until you need to know who changed what and when, and the sysadmin you knew has left the company. It's fast until an 11pm Friday change causes a Saturday morning outage and nobody can reconstruct what happened.

The process isn't the obstacle. It's the organization's memory.

Discovery as a way of knowing

My favorite part of ServiceNow, and the part I've spent the most hours on, is discovery — an automated probe that goes out across the network and comes back with an answer to one question: what's actually running, and how is it connected?

That sounds technical. It's also, in a small way, about honesty.

What do you actually know about your infrastructure? Not what's documented, not what was deployed eighteen months ago, not what someone mentioned in a handover meeting once. What's running right now.

The first time most organizations run an honest discovery scan, they're surprised. Systems nobody remembers building. Connections that shouldn't exist. Servers still running software that was supposed to be decommissioned two years ago.

The CMDB is the attempt to keep an accurate answer to that question over time, and keeping it accurate is a constant discipline, because reality always drifts away from the records. I spent months pushing our discovery completion rate from 50% to 85%. The last 15% were the hardest systems to probe — usually for a reason.

Workflows as a shared language

Here's what I've come to believe: a well-designed workflow is a form of communication, not just paperwork.

A change request template that asks for the what, the why, the rollback plan, and the test procedure isn't documentation for its own sake. It forces the person making the change to actually think through those questions before they act.

A good incident process works the same way for outages — it's a shared vocabulary that lets someone who wasn't in the room understand what happened and what was tried.

This is also why copying someone else's ServiceNow setup rarely works. Those workflows encode decisions specific to that organization: what matters to them, who needs to sign off, what information they actually need. The tool is generic. The implementation shouldn't be.

What I've taken from it

A few things from this work have stuck with me well beyond ServiceNow:

Write down the informal stuff. You lose some speed. You gain the ability to find out what happened later.

Measure what matters. Discovery completion rate, change success rate, mean time to restore — imperfect numbers, but better than a gut feeling. What you measure tends to get better.

Keep the documentation honest. A CMDB that doesn't match reality is worse than no CMDB, because it creates false confidence. Better to know it's wrong than to act like it's right.

Watch the handoffs. Most incidents I've traced back weren't caused by one person's mistake — they happened in the gap between teams, or shifts, or systems.

None of this is really unique to ServiceNow. It's just where I learned it.