Why we will not take your pager permanently

It comes up in most support conversations, usually near the end and usually framed as an obvious next step: could you just run it for us, permanently?

The answer is no, and it costs us revenue to say so, so it is worth explaining properly rather than leaving it as a policy.

The feedback loop is the point

A team that carries the pager for its own software writes different software. Not better in the abstract — better in a specific, observable way. They add the log line that would have shortened last month's incident. They fix the alert that fires spuriously at 3am, because they were the one it woke. They resist the clever solution that is hard to diagnose, because they will be the one diagnosing it.

None of that happens by instruction. It happens because the consequences of a decision reach the person who made it, reliably and personally.

Break that loop and reliability decays quietly. Not dramatically — the outsourced operations team is competent, incidents get handled, the dashboard stays green. What degrades is the rate at which the underlying causes get fixed, because the people who could fix them no longer feel them, and the people who feel them cannot fix them.

Eighteen months later the system has accumulated a set of known-fragile areas that everyone works around and nobody addresses.

What we do instead

We carry it during delivery. Our software, our pager, from the first deployment.

We carry it through stabilisation. Typically eight to twelve weeks after go-live, jointly with your team, while the incident rate settles and the runbooks get corrected by contact with reality.

Then we hand it over, and we rehearse the handover first. Your team takes the pager while we are still on the call, for a full rotation, with us watching and not intervening unless asked. Then they take it for real.

Then we stay reachable. Support contracts, response times, escalation. We answer the phone. We are not the first line, and that is deliberate.

The measure that matters

We track how many escalations arrive in the first quarter after a handover. The target is zero, and we usually get close.

A high number is not a sign that the client's team is weak. It is a sign that we documented badly, or that we built something more clever than the problem required. It is our failure, measured after we have left, which is roughly the only way to measure it honestly.

The exceptions

There are two.

Where an organisation genuinely has no engineering function and no intention of building one — a small firm with a single business-critical application — permanent operations is the honest answer, and we will say so and help you find someone who does it well.

And where the system is a specialist component with a genuinely rare operating skill, we will carry it longer while your team builds the capability, with a dated plan for the transfer.

Neither is the common case. The common case is an organisation with capable engineers who have been told that operations is somebody else's job, and the most useful thing we can do is give it back to them properly.

Our last invoice should be the last one you need to pay us. That is not modesty; it is the only version of this work that leaves you better off.