Last week I argued that business alerts belong to the business even when the cause underneath them is technical, and I offered a way to settle it: ask whether they care that it’s down. If they don’t, recovery is explicitly best-effort. If they do, they own the alert and the delivery team owes a recovery SLA in return. Make both options legible and let them pick, because undecided always resolves to IT by default.
That works. I’ve used it, and it wins the argument in the room.
It also doesn’t scale, and I’d be selling you something if I pretended otherwise. It works once, on one alert. Next quarter there’s a new journey, a new threshold, a new process owner, a new third-party dependency — and you are back at the start of the same conversation, making the same case from scratch. Win it forty times and you haven’t changed anything; you’ve just become the person who keeps having that meeting.
So this post is about the thing underneath: why the default keeps reasserting itself, and what actually changes it.
Being right is not a mechanism
Here’s the part that took me longest to accept. The last time I made this case properly, I made it well. The logic was sound, the examples were real, I had a chart showing the degradation trend. And it went nowhere — a flat “that’s technical, I don’t want to be alerted about it”, and that was the end of it.
I spent a while assuming I’d argued it badly. I hadn’t. I’d argued it into a structure that had no reason to agree. Nothing in how that organisation was arranged made accepting the alert better for the person I was asking than declining it. Accepting meant being woken up, being answerable for a number, and inheriting a problem whose cause sat in someone else’s department. Declining meant carrying on exactly as before, at no cost, and IT would keep watching what it could watch.
Given that trade, declining is rational. It isn’t obstruction and it isn’t laziness — it’s the correct response to the incentives in front of them. Which is the uncomfortable conclusion: if declining is free, a better argument won’t help, because the argument was never what was stopping them.
Ownership follows accountability, not knowledge
The version of this argument I used to make went: the process owner should own the outcome signal because only they know what “working” means. Engineers can measure latency; only the business can say that fifteen seconds is too long.
That’s true, and it is not enough — because knowing something is not the same as being answerable for it. Knowledge tells you who’s qualified to own the signal. It says nothing about who will, and people don’t take on accountability because they’re the best-informed candidate. They take it on when it’s already theirs.
So the real lever isn’t information, it’s accountability, and it doesn’t sit with either party in the argument. It sits above both: someone has to establish that the business is answerable for its own process outcomes, not just IT for uptime. Until that’s true, “you should own this alert” is a favour you’re asking for. After it’s true, the alert is just how they discharge something they’re already on the hook for — and you don’t have to ask at all.
This is the same lesson a design authority without the bureaucracy taught me, one seam over. That only started working when leadership actually stopped non-compliant work. Not because anyone loves governance, but because until then compliance was optional, and optional means “when I have time”, which means never. Culture change needs teeth, and teeth means consequences that exist whether or not people agree with you.
Teeth don’t always mean a pager, mind. For the alert-shaped signals it’s a rota and a recovery SLA; for the ones that are management information rather than alerts, it’s a named reviewer, a standing slot in the diary, and a question that actually gets asked when the number moves. Different instrument, same test — does anything happen if it’s ignored?
The same shape, one seam further out
If the shape feels familiar, it should. We’ve solved this exact problem before, and recently.
Dev used to throw software over a wall to ops. Dev was measured on shipping, ops on stability, and each side’s success was the other’s problem — so ops resisted releases and dev resented the resistance, and both were behaving sensibly given what they were judged on. The fix wasn’t a better release process or a smarter deployment tool. It was cultural: shared ownership of the outcome, with the people who built the thing on the hook for running it.
The business/IT seam is the same problem one step further out. Same handoff, same asymmetry, same “that’s their job” reflex, same rational-but-collectively-terrible incentives on both sides. And the same answer: the ownership has to straddle the seam rather than sit on one side of it.
I’m deliberately not coining a name for this. The analogy is useful because it shows the shape of the fix is known and has worked at scale — not because the business/IT seam needs its own portmanteau and a conference track. If anything, the lesson from DevOps is how much of the value got lost the moment it became a job title instead of a change in who was accountable for what.
What it runs on
Accountability alone will produce a process owner who agrees they should watch their outcomes and genuinely cannot tell you what to watch. That’s not obstruction either; that’s a vocabulary problem. Asking someone to define a healthy state for a journey they only know in fragments — their bit, the bit they get complaints about — will produce either silence or a number they made up.
Which is the people problem again, and it’s the mechanism this whole thing runs on. Shared context is what lets a business colleague and an engineer describe the same journey in the same terms, and without it “own your outcome signal” is an instruction nobody can execute. In practice this is the least glamorous and most useful work available: sit with the process owner, walk the journey end to end, and write down together where it can silently fail. The signal tends to fall out of that conversation on its own.
It also has a side effect worth the effort by itself. A business that can describe its own process end to end is a business you can draw a boundary for at design time, instead of encoding a guess and finding out later.
The bit I don’t like
Here’s the honest turn, and it’s not the ending I wanted when I started thinking about this.
This one isn’t won by architects. Every lever that actually moves it — what people are answerable for, what happens when they aren’t, whose objectives include a customer outcome — sits with leadership. I can diagnose it precisely. I can show the trend. I can put both options on the table and make declining feel like the choice it is. I cannot make the business accountable for its own processes, and pretending I can is how you end up doing the same doomed presentation every quarter and calling it advocacy.
What is genuinely ours is narrower and still worth doing: make the gap impossible to not see. Name it out loud in writing. Say which journeys have no owner and therefore no definition of working. Say what defaulting to IT costs, in the specific terms of the specific journey that broke. Put the chart in front of people. Refuse to quietly absorb the ambiguity as though it were a technical requirement, because absorbing it is what makes it invisible, and invisible problems don’t get resourced.
That’s the same move as everywhere else on this blog: I can’t make the decision, but I can make sure it’s a decision someone made rather than a default nobody noticed. It’s less satisfying than a fix. It’s also the only part of this that’s reliably in your gift.
The dashboard was never the problem. The dashboard was doing exactly what it was told by the only people who were asked.