The Route That Buried Bad News (Part B)
The local cost, postmortem question, and decision aid (Route Rebuilder | Episode 1b)
Part B: The Rebuilt Route
👋 Welcome to this week’s edition of Empathy Engine. Every Wednesday, I publish a new article for paid subscribers first, then unlock the full piece for everyone late Thursday morning. Each week, I turn product leadership friction into practical tools, sharper language, and more defensible decisions.
Research Binder: the receipts (citations + source notes) are compiled in a PDF at the bottom of this post.
In Part 1, a visible warning sat in an incident channel for fourteen days while the room assumed someone else owned it. We named that failure an Orphaned Alert and showed how acknowledgment fakes ownership, how reasonable people build the broken route, and why the failure stays invisible from above.
Now: what does that missing route actually cost, and what does the rebuild look like?
The cost of a broken route is easier to see when you trace two paths from the same warning.
The local cost of a broken route
The cost language in this article is local and illustrative. I am describing estimate categories a team can adapt using its own labor rates, timelines, and remediation data. The point is not that every team pays the same amount. The point is that the labor cost of a broken route usually hides inside normal work until someone traces it.
Three local cost categories tend to surface when you trace a broken route backward.
Bystander Burn is the coordination time multiple people spend seeing, monitoring, or briefly investigating an unowned warning.
Investigation Tax is the duplicated effort that appears when the first investigation does not become a documented handoff.
Compounding Rework is the extra cleanup and remediation that accumulates when a known problem sits unresolved while downstream work continues building on top of it.
I have traced this kind of cost through an Azure DevOps board. A work item was marked blocked, comments were added, and the assignee was visible, so the board looked like it had captured the risk. But the person assigned to the work did not own the decision that would unblock it. Over the next week, the item appeared in standup, backlog refinement, a review conversation, and a stakeholder update. Each time it generated questions nobody could close.
The conservative cost: two developers spending roughly three hours each checking the dependency, a delivery lead spending two hours chasing status, a product owner adjusting expectations, and a lead reconstructing who could actually make the decision. Roughly eleven to twelve hours before counting the eventual fix.
Multiply those hours by your team’s loaded rate and the math becomes local, specific, and hard to ignore. A $500 Day 0 fix quietly became a multi-week remediation because the signal had a channel but not a route.
The Day 0 fix would have been boring: name the decision owner, confirm the authority, and set a twenty-four-hour escalation rule. Boring would have been cheaper.
That is why the math should stay local. A team does not need to claim that every minute of delay costs some theatrical number borrowed from a vendor deck. The team only needs to ask what the delay cost here, in this workflow, with these people, this cleanup, and this missed handoff. The route did not save time. It moved the cost to more calendars.
Trace the route, not the person
Ownership language turns dangerous when handled badly. “When did this become someone’s job?” is a useful question when the team is tracing the route. The same question becomes politically unsafe when the team is hunting for a person to blame.
A blameless review does not mean no one is accountable. It means the review inspects system conditions, handoffs, and authority gaps before inferring personal failure. Accountability still matters. But accountability works better when people know what they owned, what authority they had, and where the next move should have gone. The safest postmortem questions are route questions: where did the signal first become visible, what happened between visibility and explicit ownership, and what timer or escalation rule should have moved the signal when ownership remained unclear?
I have facilitated retrospectives that handled the same kind of failure in completely different ways. In the weaker version, the room decides the problem was “communication.” Nobody says “we are blaming someone,” but the questions start orbiting the person closest to the miss. The retro ends with an action item like “communicate sooner,” and everyone nods because nobody wants to argue with a virtue. The weeks afterward reveal the real effect: people become more careful, not more transparent. They bring screenshots, soften risks, and turn updates into little legal exhibits for the defense. That is not learning. That is workplace theater with better bullet points.
The better reviews feel different in the first five minutes. They still ask hard questions, but the questions follow the route: where did the signal appear, where did ownership become assumed, who had authority, and what rule should have moved the warning when authority was unclear? When a team leaves with a named receiver, a return date, and an escalation rule, the next few weeks look different. People have something better than a reminder to be brave. They have a path.
The rebuild: from signal to named owner
Most incident frameworks assume ownership already exists. This one exists to create it.
The rebuilt route does not start with another channel. It starts with a lightweight aid that helps a team move a visible warning into explicit ownership. That is why I am giving away the Incident Triage Decision Aid with this article.
The aid asks four routing questions.
MTTO (time from first visible signal to explicit ownership). Use as a local learning metric, not a personal scorecard. This is the gap the graveyard dashboard was hiding.
Run the Part 1 warning through the aid, and the route becomes visible.
