incident-call

post-mortem

blame-culture

engineering-leadership

accountability

How to Run a Blameless Post-Mortem in English at Work

ESL English learning: Master blame and responsibility vocabulary for running blameless post-mortems and fostering systems thinking in engineering teams.

Pronunciation Guide: Blame Vocabulary

Several blame-related words have tricky pronunciations. Getting these right signals confidence in formal settings like post-mortem presentations:

culpable /ˈkʌl.pə.bəl/

KUHL-puh-buhl

Saying 'kool-PAH-blay' (Spanish influence)

censure /ˈsen.ʃər/

SEN-shur

Confusing with 'censor' (/ˈsen.sər/)

castigate /ˈkæs.tɪ.ɡeɪt/

KAS-ti-gayt

Saying 'kas-ti-GAYT' (wrong stress)

indict /ɪnˈdaɪt/

in-DYTE

Pronouncing the 'c' as 'in-DIKT'

reproach /rɪˈproʊtʃ/

ri-PROHCH

Saying 're-PROACH' with flat 'o'

Why Blame Language Matters in Incident Reviews

When a production incident occurs, the words you choose shape whether your team learns or shuts down. Engineering culture has evolved to embrace blameless post-mortems—but running one effectively requires specific vocabulary skills. The difference between 'Who broke the deploy?' and 'What conditions allowed this failure?' is not just cultural—it's linguistic.

Many ESL engineers struggle with this distinction because blame vocabulary in English carries subtle gradations. Words like 'culpable,' 'reproach,' and 'censure' all relate to blame, but each signals a different level of severity and formality. Understanding these distinctions helps you navigate post-mortems, 1:1s, and code reviews without accidentally escalating tension.

Cultural Note

In high-performing engineering organizations (Google, Netflix, Etsy), blameless post-mortems are considered essential for psychological safety. The language you use signals whether your team culture is learning-oriented or punishment-oriented.

The Blame Vocabulary Spectrum: From Mild to Severe

English has a rich vocabulary for discussing fault and responsibility. In tech contexts, knowing which words land softly and which land harshly helps you calibrate your message. Here's the spectrum from mild observation to severe accusation:

Term	Severity	Tech Definition	Example in Context
accountable	Neutral	Responsible for outcomes without implying fault	The on-call engineer is accountable for acknowledging alerts within 15 minutes.
culpable	Moderate	Deserving blame for a specific failure	The deploy script was culpable—it lacked rollback logic.
reproach	Moderate	To express disapproval or disappointment	I don't want to reproach anyone; let's focus on the timeline.
censure	High	Formal criticism or official disapproval	The security team issued a censure after the data exposure.
castigate	Severe	To criticize harshly or punish verbally	Castigating engineers for honest mistakes destroys trust.
indict	Severe	To formally accuse (often used metaphorically in tech)	The post-mortem shouldn't indict individuals—it should indict the process.

Notice how 'accountable' stays neutral while 'indict' carries legal-weight severity. In blameless post-mortems, you want to stay in the 'accountable' zone and redirect any 'castigate' energy toward systems, not people.

Scenario 1: Facilitating a Blameless Post-Mortem

You're leading a post-mortem after a 3-hour outage. The root cause was a configuration change pushed without review. Here's how to redirect blame language toward systems thinking:

❌ Blame Language (Avoid)	✅ Systems Language (Use)
Who pushed this change without approval?	What allowed this change to bypass our review process?
Sarah is culpable for missing the alert.	Our alerting coverage had a gap in this failure mode.
The on-call engineer should be censured.	The runbook didn't cover this scenario clearly.
This is inexcusable negligence.	We identified a process gap we can address.
Someone needs to be held responsible.	Let's document the contributing factors.

Facilitation Phrase

When someone uses blame language in a post-mortem, try: 'I hear the frustration. Let's reframe that as a system question—what process allowed this to happen?'

Scenario 2: Discussing Accountability in a 1:1

Your manager wants to discuss an incident where your code caused a bug. Here's vocabulary for taking ownership without self-blame, and for managers discussing accountability without criticism:

'I take ownership of this outcome' — accountable without being defensive
'The code I wrote had a gap in error handling' — specific and factual
'I've identified what I'd do differently' — forward-looking accountability
'What support would help you catch this earlier?' — manager language that helps, not blames
'Let's add this to our testing checklist' — converting blame to process improvement

Avoid phrases like 'It wasn't my fault' (defensive) or 'I'm culpable' (too severe for a 1:1). The goal is honest ownership that enables learning.

Scenario 3: Redirecting Blame in Code Reviews

Code reviews can slip into blame territory, especially when reviewing incident-related fixes. Here's how to keep feedback constructive:

❌ Heard in Blame-y Reviews	✅ Better Engineering English
Why didn't you catch this obvious bug?	This edge case is tricky—should we add a test for it?
This code is indefensible.	I'm concerned about the error handling here. Let's discuss.
You should have known better.	This pattern has bitten us before. Here's a related doc.
Who approved this originally?	What context led to this design choice?

Slack vs. Email Register

In Slack: 'Hey, can we chat about this edge case? I think we can strengthen it.' In a formal doc: 'This section would benefit from additional error handling to address the failure mode identified in INC-4521.'

Grammar Patterns for Blameless Language

Blameless language often uses specific grammatical structures to shift focus from people to systems:

Passive voice to remove the agent: 'The config was deployed without review' (not 'Alex deployed without review')
Subject-as-system: 'The process failed to catch this' (not 'We failed to catch this')
Contributing factors framing: 'Several factors contributed, including...' (distributes cause)
'What' questions over 'Who' questions: 'What allowed this?' vs 'Who did this?'
Conditional past for learning: 'If we had automated this check, the issue would have been caught'

Grammar Tip

Use 'the system' or 'the process' as grammatical subjects when you want to discuss failures without targeting individuals. This is a deliberate linguistic choice, not evasion.

Practice: Test Your Blameless Vocabulary

Multiple choice

Choose the best answer.

In a post-mortem, which phrase best reflects blameless language?

Sarah was culpable for the outage.The deployment pipeline lacked sufficient guardrails.Someone should be censured for this failure.This was inexcusable negligence.

Multiple choice

Choose the best answer.

Which word is most severe on the blame spectrum?

accountablereproachcastigateculpable

Complete the sentence

Type the missing word or phrase.

Complete the sentence with appropriate blameless language: 'The incident wasn't about finding someone to blame—it was about identifying ______ factors.'

Frequently asked questions

How do I say something went wrong without sounding like I'm blaming someone in a post-mortem?

Use systems-focused language: instead of 'Who broke this?' say 'What conditions allowed this failure?' or 'The system allowed this to happen because...' Key phrases are 'contributing factors,' 'gap in our process,' and 'the deployment process lacked guardrails.' This keeps accountability language neutral and directs the team toward process improvement, not personal fault. Practice saying 'We identified a gap in alerting coverage' rather than 'You didn't set up alerts properly.'

What's the difference between 'accountable' and 'culpable' when discussing who caused an incident?

'Accountable' means responsible for explaining and improving; 'culpable' means legally or morally guilty—much harsher. In blameless post-mortems, always use 'accountable' when discussing people: 'The team is accountable for strengthening code review processes' (focuses on systems thinking) versus 'He is culpable for the outage' (assigns personal blame). This vocabulary distinction shapes whether your incident review becomes learning-focused or defensive. In your 1:1 with a manager, say 'I'm accountable for this bug' to show ownership without accepting severe personal judgment.

How do I take responsibility in a 1:1 about an incident without sounding defensive or overly apologetic?

Use ownership language that separates you from the system failure: 'I'm accountable for the code change, and I see now the review process didn't catch it—let's strengthen that together.' Avoid 'It wasn't my fault' (sounds defensive) and 'I'm culpable' (too severe and damages your professional standing). Frame it as accountability for improvement: 'What I could improve is running tests locally before pushing,' which shows learning and systems thinking. This approach keeps the conversation focused on blameless post-mortem principles and prevents misunderstanding with your manager about your capability.

When should I use 'root cause' vs 'contributing factor' in an incident review?

'Root cause' suggests one single, simple answer (which rarely exists in complex systems); 'contributing factors' reflects systems thinking and blameless culture by acknowledging multiple conditions that had to align for failure. Say 'The contributing factors were: the deployment lacked approval guardrails, monitoring was silent, and the runbook wasn't updated' instead of 'The root cause was the engineer's mistake.' In incident review English, this phrasing prevents blame language from creeping in and helps your team focus on what processes to redesign. Most modern blameless post-mortem facilitation now favors 'contributing factors' or 'conditions that allowed this to happen.'

How do I give critical feedback about code in a post-incident code review without sounding like I'm blaming the author?

Redirect from the person to the process: instead of 'You wrote unsafe code' say 'This code pattern bypassed our guardrails—our linter should catch this automatically' or 'This gap shows we need a pre-deployment checklist.' Use accountability language that names the improvement: 'Going forward, we're accountable for running this test before merge,' not 'You should have run the test.' This keeps your code review blameless while still being honest about what needs to improve. Phrases like 'The review process didn't surface this' or 'We're missing a safeguard here' keep the focus on systems thinking rather than individual fault, which helps your engineering team embrace true blameless incident review culture.