Nobody's Postmortem to Write
A postmortem gets written by whoever has standing to write it, and standing is almost never about who understands the failure best.
When a bug lives entirely inside one team's service, that team owns the explanation by default. They have the logs, the deploy history, and the incentive to be first with an account before someone less charitable writes one for them. The postmortem comes out in days, because the question of whose job it is was never actually in dispute.
Trouble starts when a failure doesn't respect anyone's boundary. A power interruption that drops every car on a racing grid at the same instant is sixteen incidents at once, not one, plus the organizer, plus whichever subcontractor wired the circuit. Each team can tell you exactly what happened to its own car and nothing about why the others went dark too. The organizer can tell you the grid lost power and nothing about what any individual car's engineers would want explained. Nobody in the room owns the whole story, so nobody in the room is actually positioned to write it.
That's the part that doesn't look right from outside. The uniformity of the failure, the thing that should make it easy, everyone affected the same way, at the same moment, by the same cause, is exactly what strips every party of the authority to be the one who explains it. A failure that hits unevenly has an owner by elimination. A failure that hits everyone identically has no elimination to run.
So what fills the gap isn't investigation, it's negotiation. Before anyone writes a line of root-cause analysis, someone has to settle who's allowed to publish first and whose name goes on it. That process has nothing to do with diagnosing a bad connector or a blown fuse. It's about jurisdiction, and jurisdiction disputes run on a much slower clock than engineering does.
Which produces the odd result: the slowest postmortems on record are often explaining the simplest failures. A shared point of failure, physical or technical, is usually the easy case to diagnose: one thing to test, one thing to confirm. The weeks between the failure and the public statement go to something other than forensics. They go to separate parties, each holding a claim on part of the story, working out who gets to tell the whole of it.
I've seen the same shape at a much smaller scale. A shared library breaks and every team's build fails at once. For an hour, nobody writes anything, because every team's first instinct is to check whether it's their own fault, and none of them can rule that out faster than just checking the shared thing itself. The fix, once somebody finally looks at the shared thing, takes ten minutes. The hour before that is spent establishing that no single team is the right author for this one. A failure scoped to one service gets an incident doc the same day. A failure scoped to everyone gets argued over in a channel until someone with standing across teams decides to write it down, and that someone is rarer than the failure itself.
None of this argues that uniform failures are worse, technically, than lopsided ones. Most of the time they're simpler, one cause instead of five interacting ones. What it argues is that postmortem speed was never tracking the difficulty of the diagnosis. It tracks the number of parties who have to agree someone is allowed to hold the pen. A failure owned by one team clears that bar automatically. A failure owned by everyone has to clear it by committee, and committees are the slowest instrument we've built for agreeing on anything, including things that were never actually hard to figure out.
The simplicity of the cause doesn't buy you a faster explanation. It just means the explanation, whenever it finally arrives, is going to feel strangely anticlimactic for how long you waited on it.