Incidents I've worked on over more than 20 years usually ended when service came back. People returned to whatever they'd been doing. Sometimes somebody got yelled at.
At one organization, IT sometimes didn't learn about a major incident until 6 a.m., when the business called. The same failures kept returning because we hadn't built a working root-cause capability. We'd restore service, then treat restoration as completion.
The next stage wasn't as mature as it looked. A post-incident review ran through recent outages and assigned names to look into them. There wasn't a mechanism to follow the work through. The names created the appearance of accountability while the same problems continued to recur.
Requiring a root cause analysis document created the possibility of a serious postmortem, but it also created a fork.
A punishment RCA builds a case around fault. Who made the mistake? Who approved the change? Who failed to catch it?
A resilience RCA reconstructs the failure. What conditions allowed it? Why did one problem spread? Why did recovery take as long as it did? What has to change before the next incident?
The resilience fork isn't safe just because the review was blameless. The report can be technically strong, written without blame, and full of individual names.
Everyone in the review may understand the context. They've heard the explanations and watched the timeline take shape. They know why each person acted and what information was available at the time.
The next reader wasn't in the room. They don't have any of that. They have the document.
With a report full of individual names, you're one bad day and one reader away from having a punishment RCA again.
The report has to survive its next reader
GitHub's report on its August 17 incident shows what a technically serious public account can look like.
The incident lasted 7 hours and 47 minutes. At its peak, web and API error rates reached approximately 20 percent. The report traces the failure from an Istio sidecar reaching its concurrency limit, through an autoscaling policy that watched the wrong limit, to four HAProxy nodes exhausting their flow capacity. It explains how optimistic retries worsened the load and how a client retry bug amplified Copilot token traffic.
The report also records the mitigations and five areas of follow-up work.
GitHub gives the reader enough information to reconstruct the failure. It doesn't identify the people who configured the policy, wrote the retry logic, operated the load balancers, or chose each mitigation.
A mature report preserves the timeline, system state, communications, available information, decisions, technical failures, recovery actions, and work required to prevent recurrence. A function, team, or decision role can be identified where it helps explain the sequence. The people working the incident don't need to become the index for understanding it.
Personal accountability still exists behind the report. Corrective work needs named owners, dates, and evidence of closure. That's the job of the internal action tracker and management process.
The shared report explains the failure. The operating process makes sure the work gets done. If those functions aren't kept separate, an internal accountability record can travel as a public list of people connected to mistakes.
Exposure follows the org chart
From entry-level technical roles through VP positions, I've watched employees look up the org chart. They'll watch what leaders do with bad news because they know exposure can travel down.
At that same organization, change accountability had become detached from implementation. Someone could make a technical change and go home while an application owner remained accountable for availability without the technical depth to diagnose what had broken. When the application failed, escalation traveled back up the management chain looking for someone who could resolve it.
Authority, implementation, and accountability weren't sitting in the same place.
That's why names in an incident report aren't neutral. A timeline that identifies the implementer can direct scrutiny toward the lowest visible person even when the operating system allowed the change, failed to detect the condition, and placed accountability somewhere else.
Removing those names changes where the exposure lands.
When I distribute the report, my name is the one tied to the event. I'm saying that this happened under my leadership, this is the factual sequence, and this is how I plan to be responsible.
That costs something. I don't have to accept that exposure. I could leave individual names in the timeline and let the document direct pressure downward. The final stage of the progression requires me to choose otherwise.
Getting there requires a leader who takes blame and spreads praise.
You can't get there without enough technical aptitude to keep the investigation from stopping at the first human action.
Someone changed a configuration. Why didn't the controls prevent that change from producing this result?
Someone approved it. What evidence was available, and what didn't the approval process test?
Someone missed a warning. Why wasn't it visible, actionable, and connected to an owner?
Someone chose the wrong mitigation. What couldn't they see when they made that choice?
If I stop at the first human action, I get a clean disciplinary story and leave the operating condition intact.
The process must work without me
At that same organization, I eventually replaced a 110-person, biweekly incident forum with a 10-person weekly process.
We'd review priority-one and priority-two incidents. Each problem received management ownership. A designated RCA team reconstructed the failure. Reports were due within defined service levels. Recommendations carried follow-up accountability.
Named ownership lived in the management process rather than in a list of people appearing in the incident timeline.
The review rebuild sat inside a wider change that replaced tribal escalation with cross-functional incident management, named service ownership, and peer-level troubleshooting across infrastructure, database, application, and operations teams. Across that work, major incidents fell 60 percent year over year.
I couldn't build that through a recurring meeting alone. I had to define the report structure, evidence standard, review cadence, ownership model, and expectations for follow-through. I couldn't leave report quality to instinct, so I coached reports until the timeline adequately covered people, process, and tools. I had to build enough trust across teams and reporting lines for people to explain what happened without calculating how each sentence might later be used against them.
Showing up well in the room was only the visible act of leadership. The durable work was teaching the organization how to produce the same quality of review when I wasn't there.
The template determines what gets preserved.
The standard separates facts from judgments and technical causality from personal attribution.
Training teaches people how to reconstruct a timeline. If they can't distinguish the triggering action from the conditions that allowed the failure to spread, they haven't found the cause yet.
Coaching continues until the team doesn't need the leader driving every sentence.
The review process catches speculation, missing evidence, unnecessary names, and corrective actions that don't address the mechanism.
This is the architecture of leadership.
Architecture is foresight. I've got to understand how the report will be read and acted on when I'm no longer in the room to chaperone its meaning.
I won't know every future reader, and one may arrive looking for someone to blame. If changing the audience is enough to turn the report into a weapon, the leadership never made it into the architecture.