Read the last five postmortems your team wrote. Count how many times a manager's decision shows up as a contributing factor.
I'll guess zero.
The deploy went out at 4:45 on a Friday. The on-call engineer missed an alert. The config change skipped review. All true. All written down. All attributed to the people closest to the keyboard.
What's missing? The person who set the Friday deadline. The person who left the team one engineer short for three months. The person who said "we'll fix the alerting next quarter" two quarters ago.
Usually, the person who made those calls is the one reading the postmortem.
Blameless Has a Blind Spot
Most engineering teams say they run blameless postmortems. Good. The idea is sound.
John Allspaw laid it out in 2012 when he wrote about blameless postmortems at Etsy. Engineers involved in an outage should be able to give "a detailed account" of what they did, what they saw, what they expected, and what they assumed... "without fear of punishment or retribution."
His reasoning is blunt. An engineer who expects a reprimand has every reason to hold back the details. And without the details, he wrote, the lack of understanding "all but guarantees" the incident will repeat.
Google's SRE book makes the same point. Its chapter on postmortem culture says a blameless postmortem "assumes everyone involved in an incident had good intentions and did the right thing with the information they had." It also makes the point plainly: you don't fix people, you fix the systems and processes around them.
Here's the problem. Most teams read "blameless" as "don't blame the engineer." They stop there. Everyone still picks over the engineer's actions in forensic detail. The leader's decisions never enter the room.
This isn't blameless. It's one-sided.
Real Talk Starts at the Top
Claude Silver, Chief Heart Officer at VaynerX, said something on our podcast I keep coming back to. She talked about how every person on a team arrives at work after two or three hours of their own life... the sick dog, the school lunches, the row with a spouse. Then she asked how you, as the leader, share your own vulnerability with your team.
Her answer was about being more human. Take the armour off. Relate to people. Remember you were once a junior too.
Taking the armour off is a leadership job. You go first. Your team watches what happens to you before they risk it themselves.
A postmortem is the most practical place I know to do it. It's written down. It's shared. It's about real events with real costs. If you put your own decision in the timeline, everyone sees it. If you leave it out, everyone sees the gap.
Your Decisions Are in the Causal Chain
Richard Cook, an anaesthesiologist and safety researcher, wrote a short paper called How Complex Systems Fail. Every engineering leader should read it. It takes ten minutes.
Two of his points matter here.
First, catastrophe "requires multiple failures." No single fault is enough. Small failures line up and only the combination produces the outage.
Second, he says attributing an accident to a single "root cause" is "fundamentally wrong." He argues the hunt for one cause reflects "the social, cultural need to blame specific, localized forces," not a technical understanding of failure.
Now look at the small failures in your last outage. Some live in code. Some live in config. And some live in a planning meeting, a hiring freeze, or a roadmap where alerting work kept slipping to the next quarter.
Those decisions belong to you. They are as much a part of the causal chain as the bad config file. Leaving them out doesn't make the postmortem kinder. It makes it wrong.
What Your Team Learns When You Leave Yourself Out
Ron Westrum, a sociologist who studied safety in aviation and healthcare, sorted organisations into three types based on how information flows. DORA, the research programme behind the State of DevOps reports, summarises his model:
- Pathological cultures punish messengers. Failure leads to scapegoating.
- Bureaucratic cultures neglect messengers. Failure leads to "justice."
- Generative cultures train messengers. Failure leads to inquiry.
DORA's research found a high-trust, generative culture predicts software delivery and organisational performance.
Here's what I'd ask you. When your postmortems examine engineers and skip leaders, which of those three types does your team see?
They see inquiry for them and immunity for you. It reads as bureaucratic at best. The messengers learn to report the bugs and stay quiet about the deadlines. You get honest accounts of the last ten minutes before the outage and nothing about the last ten weeks.
Amy Edmondson saw a version of this in hospitals. Her 1996 study, Learning from Mistakes is Easier Said Than Done, looked at patient care teams in two hospitals and found systematic differences between teams in how often errors happened and in how likely teams were to catch them and learn from them.
I'm not sure about this part: the popular retelling of Edmondson's study says the better-led units reported more errors because people felt safe to report them, not because they made more. I've seen this summary many times, but I couldn't access the full paper to confirm the exact figures, so treat it as the commonly cited version rather than something I've checked line by line.
How to Put Your Name in the Postmortem
None of this needs a new process. It needs you to change what you write.
1. Add a "Decisions Upstream" section
Every postmortem template has a timeline. Most start when the first alert fires. Extend it backwards. Add a section for decisions made weeks or months before the incident which shaped the conditions for it.
Deadlines. Staffing. Deferred work. Risk accepted in a planning meeting. Write who made each decision and what they knew at the time. Use the same blameless tone you'd use for an engineer.
2. Write your own entry first
Don't wait for someone to raise it. They won't. Nobody wants to be the junior engineer who says, "The real problem was the VP's launch date."
So you say it. "I set the release for Friday because of the customer demo. I knew the alerting gaps were open. I judged the risk acceptable. It wasn't."
Four sentences. Your team will remember them longer than any all-hands speech about psychological safety.
3. Hold your entries to the same standard
Google's SRE chapter talks about the value of "senior management's active participation in the review." Participation means more than reading and nodding. It means your decisions get the same questions an engineer's actions get. What did you know? What did you assume? What would have changed your mind?
4. Turn your entries into action items with your name on them
If staffing was a factor, the action item is yours. If the roadmap kept bumping reliability work, the action item is yours. Track them in the same place as the engineering fixes. Close them on the same timeline.
An action item assigned to the leader proves you meant it.
5. Reward the first person who names a leadership factor
Google's SRE book describes an engineer whose change took down a service for four minutes. He rolled it back fast. He got two peer bonuses and a round of applause at TGIF from the founders and thousands of staff.
The lesson for you: the first time someone on your team names a leadership decision in a postmortem, thank them in public. Then do it again the next time. You're training the messengers.
What Changes When You Go First
Here's what changes when the leader writes themselves into the incident record. The postmortems get longer. They also get better.
Engineers start including context they used to leave out. "I didn't escalate because the last two escalations got pushed back." "I skipped the load test because the environment had been broken for a month." This is the detail Allspaw said you need. People offer it once they've watched you offer yours.
Postmortems stop being about the last ten minutes and start being about the system... which includes you.
And here's the part most leaders miss. Your team already knows about the Friday deadline. They already know about the hiring freeze. Leaving it out of the document doesn't hide it. It tells them the document isn't honest.
This ties straight back to the research behind Step It Up HR: 99.5% of the people we surveyed said they'd had one or more types of bad boss. Few of those bosses set out to be bad. Most of them stood behind the armour and let their teams take the hits for decisions made upstairs.
If you want real talk from your engineers, give them a leader who talks real first.
I wrote about a related idea in Culture Isn't Perks. It's How Fast Bad News Reaches You. Postmortems are where bad news gets written down. Make sure your own bad news makes it onto the page.
Your Move
Pull up the last postmortem your team wrote. Read the timeline. Ask yourself one question.
Which decision of mine belongs in here?
Then add it. Today. Tell your team you did. Watch what they write next time.