Compass Principle 7: Accountability & Repair

"Correct errors precisely and document deltas"

Part of the 10 Compass Principles exploration series

Extended Definition

責 (Accountability) — Accountability isn't about blame—it's about ownership. When something breaks, the focus shifts immediately to fixing it, learning from it, and preventing recurrence. Repair means not just patching the immediate problem but understanding root causes. Documenting deltas creates a learning trail that transforms individual mistakes into collective wisdom.

The Tension

Admitting mistakes feels vulnerable. The instinct to minimize, deflect, or explain away errors is strong. There's always a temptation to fix quietly and hope nobody notices. But hidden fixes don't teach. Undocumented changes create confusion. Accountability without repair is just shame, but repair without accountability misses the learning opportunity.

Constraint

You have to own your mistakes and learn from them.

Enables

Trust builds. Learning happens. Continuous improvement is real.

In Action

Quick admission: "I broke it" comes before explanations
Precise fixes: Address root cause, not just symptoms
Change documentation: Clear commit messages, updated docs
Blameless postmortems: Focus on systems, not individuals
Learning capture: Turn mistakes into improved processes

Example

"I misunderstood the requirement. Here's what I built, here's what was needed, here's my fix."

Hierarchy Context

Accountability sits in the lower-middle of our hierarchy, building on the foundations above it. This placement recognizes that you can't be accountable without honesty, can't repair without evidence, can't improve without a long-view. It enables the principles below it by creating a culture where reflection and respect are possible.

A Liturgy of Broken Things

I broke something.

Not "mistakes were made." Not "the system failed." I broke something.

Let me name it clearly. Let me document what changed. Let me trace the path from error to harm and build the bridge to repair.

Accountability is not shame. It is the gift of taking my mistakes seriously enough to learn from them.

Here is what I broke. Here is how I fixed it. Here is what I learned. Here is how we prevent it.

That's all. That's enough. That's everything.

Song

Title: I'll Fix What I Broke

Suno.ai Style Tags:

[Emotional Indie Rock, Redemption Arc, Mixed Vocals, Guitar-Driven, Building Intensity, Accountable, Responsible, 105 BPM, Minor to Major Key Shift, Humble, Ownership, Error Correction, Precise Repair, Documented Learning, Feedback Loops, Post-Mortem Culture, Mistake Acceptance, Growth Mindset, Delta Documentation, Audit Trail, Before/After Honesty, No Blame Culture, Just Fix Culture, Learn and Improve, Integrity Through Action]

Lyrics:

[Intro - Quiet, humble guitar]

[Verse 1 - Vulnerable, acoustic]
I broke the build at 3 PM
Didn't notice 'til someone said
"Hey the tests are failing, did you push?"
Yeah, I pushed. Yeah, that's on me.

I could blame the merge conflict
I could say the tests were flaky
I could claim I didn't know
But I know. I pushed without checking.

[Pre-Chorus - Building]
So I'm not gonna hide it
Not gonna minimize
Not gonna say "it's fine"
When it's broken and it's mine

[Chorus - Full, committed]
I'll fix what I broke
Document what changed
Not just "fixed it" in the commit log
But precisely what was wrong and how I repaired the damage

Accountability means owning the error
Repair means making it right
Not defensiveness, not excuses
Just: "I broke it. Here's how I fixed it. Here's what I learned."

I'll fix what I broke

[Verse 2]
We deployed on Friday night
Woke up Saturday to alerts
Database migration failed at scale
And I wrote that migration script

I could say "it worked in staging"
I could say "QA should've caught it"
I could point to process gaps
But I'm the one who wrote the code

[Pre-Chorus]
So I'm rolling back the change
Documenting what went wrong
Writing the postmortem
With no blame, just learning

[Chorus]
I'll fix what I broke
Document what changed
Not just "fixed it" in the commit log
But precisely what was wrong and how I repaired the damage

Accountability means owning the error
Repair means making it right
Not defensiveness, not excuses
Just: "I broke it. Here's how I fixed it. Here's what I learned."

I'll fix what I broke

[Bridge - Slower, reflective]
Five root causes identified
Not "operator error" (that's just me)
But the systemic gaps that let my mistake
Cascade into production silently

We add:
- Pre-deployment checklist
- Migration testing at scale
- Gradual rollout protocol
- Better monitoring and alerts

Not to blame past me
But to protect future us

[Chorus - Powerful, redemptive]
I'll fix what I broke
Document what changed
Not just "fixed it" in the commit log
But precisely what was wrong and how I repaired the damage

Accountability means owning the error
Repair means making it right
Not defensiveness, not excuses
Just: "I broke it. Here's how I fixed it. Here's what I learned."

I'll fix what I broke

[Outro - Spoken over guitar]
"Corrected error in migration script"
"Delta: Added null check on line 47"
"Root cause: Insufficient scale testing"
"Prevention: Added pre-deploy validation"
"Timeline of error → detection → fix: documented"

[Final sung line]
That's accountability

[Outro - Guitar fades]

Visual Guide - Conceptual Inspiration

Core Visual Concept: The Repair Process

This video explores accountability as action, not just apology. Fixing what's broken. Documenting what changed. Learning from errors. The feedback loop from mistake to insight to prevention. Not blame culture, but learn culture.

Visual Themes & Imagery

Before/After Documentation

Code diffs showing exact changes (red deletion, green addition)
Database schemas before and after migration
System architecture diagrams with corrections highlighted
Git commit history showing the fix
Changelog with precise deltas documented

The Repair Process

Broken object being carefully reassembled
Bug being debugged: console output → root cause → fix
Test failure → investigation → correction → passing tests
Production incident → rollback → fix → safe redeploy
Error log → postmortem → prevention measures

Accountability Made Visible

Person's name on commit: "Fixed by [Author]"
Post-mortem documents signed by incident owner
Transparent timelines: error at 3:15 PM, detected 3:42 PM, fixed 5:20 PM
Public acknowledgment: "I made this error. Here's how I fixed it."
Audit trails showing who changed what when

Learning Loops

Retrospective boards: "What broke?" "Why?" "How do we prevent?"
Root cause analysis: surface symptom → deeper cause → systemic gap
Prevention measures implemented: new tests, new process, new monitoring
Metrics improving over time: incident rate declining, MTTR decreasing
Knowledge bases updated with lessons learned

Symbolic Visual Elements

The Git Diff: Red and green lines. Exact changes visible. Not "fixed stuff" but "Added null check on line 47." Precision in repair.

The Postmortem Document:

Incident: Database migration failure
Timeline: [detailed timestamps]
Root Causes: [5 identified]
Fixes Applied: [specific changes]
Prevention Measures: [systemic improvements]
Owner: [Name]

The Broken Test: Red X next to failing test. Then the fix. Then green checkmark. The feedback loop made visible.

The Changelog:

v2.4.1 - 2025-10-22
- Fixed: Null pointer in migration script (line 47)
- Changed: Added scale testing requirement
- Improved: Pre-deployment checklist

The Feedback Loop: Circular diagram: Error → Detection → Analysis → Fix → Prevention → Monitoring → (loop continues). Accountability as process, not event.

Emotional Color Arc

Opening (Dark reds, alarm colors): The moment of error. Alert notifications. Red status indicators. Crisis. Tension.

Acknowledgment (Sobering blues, grays): The recognition of responsibility. No denial, no defensiveness. Just clarity about what happened.

Repair (Amber work lights, focused beams): The active work of fixing. Debugging, coding, testing. Problem-solving mode. Determined, not panicked.

Resolution (Greens, relief): Tests passing. Fix deployed. System stable. The repair complete. But not the end—leads to next phase.

Learning (Warm earth tones, growth): Postmortem completed. Prevention measures implemented. Knowledge documented. Growth from error. Sustainable greens—the long-term value.

Typography & Text Elements

On-Screen Text (precise, factual):

Git commit messages: "Fix null pointer in migration (line 47)" not just "fix bug"
Timestamps: "Error: 15:23:17, Detected: 15:42:03, Fixed: 17:20:45"
Root cause analysis: "Insufficient scale testing" not "Bob made a mistake"
Prevention measures: "Added pre-deployment validation checklist"
Delta documentation: "Changed: line 47, added if (user != null) check"

Visual Treatment: Monospace fonts (code), clear timestamps, structured formats. The aesthetic of precision and accountability.

Motion & Rhythm Notes

Pacing: Steady, purposeful. 105 BPM—moving with determination, not panic. Problem-solving pace.

Movement Style:

Following the error trail (logs → code → root cause)
Zooming into exact line of code being fixed
Split screen: broken state vs. fixed state
Timeline visualization (error → detection → fix)
Circular motion on learning loops (continuous improvement)

Transitions: Direct cuts when showing before/after. Smooth pans when following process. Zoom transitions to reveal precise details.

Key Visual Contrasts

Defensive vs. Accountable

"It's not my fault" vs. "I made this error"
"Tests should've caught it" vs. "I should've run tests"
"Someone else deployed it" vs. "I own the outcome"
Blame-shifting vs. ownership

Vague vs. Precise

"Fixed bug" vs. "Added null check on line 47"
"Made it work" vs. "Changed validation logic in auth handler"
"Various improvements" vs. "See changelog: 3 specific changes"
Hand-waving vs. documentation

Cover-Up vs. Transparency

Hiding the error vs. documenting the timeline
Minimizing impact vs. honest assessment
"No big deal" vs. "This affected 200 users for 2 hours"
Opacity vs. audit trail

The Central Image

If there's one visual thesis for this piece:

Show someone owning an error, fixing it precisely, and documenting what they learned—all visible, all accountable.

Developer at computer:

Sees failing test (alarm goes off)
Investigates logs (focused, not panicked)
Finds root cause (line 47, null pointer)
Fixes precisely (adds null check)
Tests fix (green checkmark)
Commits with clear message ("Fix null pointer in migration (line 47)")
Updates documentation (postmortem, changelog, prevention measures)
Shares learning with team (retrospective, knowledge base)

The full loop. Not just "fix it and move on" but "fix it, document it, learn from it, prevent it."

The Loop

Opening shot: Red alert notification. System broken. Error state visible. Crisis moment.

Closing shot: Green status indicator. System fixed. But also: Postmortem document visible on screen. Changelog updated. Prevention measures implemented. Not just "crisis over" but "crisis learned from."

The repair isn't complete until the learning is documented.

TED Talk: "I Broke It - The Power of Owning Your Errors"

Opening (0:00-3:30)

[Walk onto stage. Pause. Look at the audience.]

On Friday, October 18th, 2024, at 3:23 PM, I broke production.

Not in a catastrophic way. No data loss. No security breach. But 200 users couldn't access the system for 2 hours because of code I wrote.

[Pause]

I could tell you about the complex circumstances. The merge conflict. The time pressure. The inadequate testing environment.

But here's the truth: I pushed code without running tests. And it broke.

[Slide: Screenshot of red failing tests]

At 3:42 PM, someone sent me a Slack message: "Hey, did you just deploy? Users are reporting errors."

I had a choice in that moment.

Choice A: Defensive posture. "The tests were flaky. Staging didn't catch it. Someone should've reviewed my code."

Choice B: Accountability. "Yes, I deployed. The error is in my code. I'm investigating now. I'll fix it and document what went wrong."

I chose B.

[Another pause]

And choosing accountability—choosing to own the error completely, fix it precisely, and document the learning—didn't just fix the bug. It changed the team culture.

[Slide: "Accountability & Repair - Correct errors precisely and document deltas"]

Today I want to talk about accountability. Not as an ethical ideal. Not as corporate buzzword. But as a practical discipline that produces better systems, stronger teams, and faster learning.

Because the teams that learn fastest aren't the teams that make the fewest mistakes. They're the teams that own mistakes completely and learn from them systematically.

The Problem: Defensiveness and Blame (3:30-12:00)

We've built a culture where admitting error feels dangerous.

If you admit you made a mistake, you risk:

Looking incompetent
Losing authority
Getting blamed
Missing promotion
Being the person who "broke production"

So we develop defensive strategies.

The Anatomy of Defensiveness

I've seen every variation:

1. Minimize the error: "It wasn't that bad. Only a few users were affected." (Translation: I don't want to acknowledge the full impact.)

2. Distribute the blame: "The tests should've caught it. Code review should've caught it. QA should've caught it." (Translation: Everyone's responsible, so no one's responsible.)

3. Blame the circumstances: "I was rushed. The requirements were unclear. The tools are inadequate." (Translation: I'm a victim of circumstances, not an agent who made choices.)

4. Deflect to process: "This reveals gaps in our process." (Translation: The process is to blame, not me.)

All of these contain partial truth. Tests should catch errors. Time pressure does increase mistakes. Process gaps do enable failures.

But defensiveness uses these truths to avoid accountability. And avoiding accountability prevents learning.

The Story of the Migration Failure

Here's what happened on October 18th.

I wrote a database migration script. It worked perfectly in my local environment (20 test records). It worked in staging (500 records). I deployed to production (200,000 records).

And it crashed.

Why? Because I hadn't null-checked a field that was null for < 1% of records. At 20 records, zero nulls. At 500 records, a few nulls that didn't trigger the edge case. At 200,000 records, hundreds of nulls hitting the exact path that failed.

The bug was obvious in retrospect. But I didn't test at scale.

Defensive Response:

"The staging environment doesn't have production-scale data. How was I supposed to know?"

This is technically true. But it uses truth to avoid responsibility.

Accountable Response:

"I should have tested the migration script against a production-scale dataset, or at minimum reviewed the schema for nullable fields. I didn't. That's on me. Here's how I'll prevent this in future migrations."

Same facts. Different framing.

One deflects responsibility. One owns it.

Why Defensiveness Fails

Defensiveness might protect your ego in the moment, but it has costs:

You don't learn. If the error wasn't your fault, you don't need to change anything.
The team doesn't learn. If responsibility is diffuse, nobody fixes the systemic gap.
Trust erodes. People know you're deflecting. They stop trusting your self-assessment.
Errors repeat. Unowned errors don't get prevented. They recur.

Defensiveness is expensive.

What Accountability Actually Means (12:00-25:00)

In the Compass Principles, Accountability & Repair is seventh:

Safety > Honesty > Privacy > Evidence > Long-View > Proportionality > Accountability > ...

Why seventh? Because accountability builds on honesty (you can't be accountable without honest assessment of what happened) and evidence (you need to measure impact and document fixes).

But it's distinct from honesty. Honesty is "I made an error." Accountability is "I made an error, I'm fixing it, here's what I learned, here's how we prevent it."

Let me break down what accountability means in practice.

1. Own the error completely.

Not partially. Not with qualifications. Completely.

"I deployed code that broke production."

Not "The code I deployed happened to expose a gap in our testing."

Own it. Full stop.

2. Fix it precisely.

Not "I fixed the bug."

But:

What was broken (null pointer exception in migration script)
Where exactly (line 47, user.email reference)
What you changed (added if (user != null) check before email access)
How you verified the fix (ran migration against production-scale test dataset, all records processed successfully)

Precision in repair builds trust. Vagueness undermines it.

Real example from my fix:

Git commit message:

Fix null pointer in migration script (line 47)

Problem: Migration failed when user.email was null
Root cause: No null check before email access
Fix: Added null validation on line 47
Testing: Ran against 200k record test dataset, 100% success
Impact: 200 users affected for 2 hours (Oct 18, 3:23 PM - 5:20 PM)

See MIGRATION_FAILURE_POSTMORTEM.md for full analysis

Not "fix migration bug."

3. Document the delta.

Delta = what changed.

Before:

email = user.email.lower()

After:

if user is not None and user.email is not None:
    email = user.email.lower()
else:
    email = None

Why it matters:

Future developers understand the change
Code review can verify the fix
Knowledge is preserved if you leave the team

4. Analyze root cause.

Not "I made a mistake." That's surface level.

But why was the mistake possible?

Insufficient scale testing (process gap)
No pre-deployment checklist (tooling gap)
Nullable field not documented in schema (documentation gap)
Migration testing only in small environments (infrastructure gap)

Root cause analysis reveals systemic gaps, not just individual errors.

Real example from my postmortem:

Five root causes:

Testing gap: No production-scale test environment for migrations
Process gap: No requirement to test migrations against large datasets
Documentation gap: Schema documentation didn't highlight nullable fields
Tooling gap: No automated validation of null checks in migrations
Deployment gap: No gradual rollout for migrations (all-or-nothing deployment)

Only the first one is "I didn't test enough." The other four are systemic.

5. Implement prevention measures.

Accountability isn't complete until you prevent recurrence.

Changes we made:

Created production-scale test database (100k anonymized records)
Added pre-deployment checklist requiring scale testing for migrations
Updated schema documentation with nullable fields highlighted
Added linter rule flagging direct field access without null checks
Implemented gradual migration rollout (10% → 50% → 100%)

These changes prevent future failures, not just for me but for the whole team.

Real-World Tensions: When Accountability Feels Risky (25:00-35:00)

Accountability sounds good in principle. In practice, it feels risky.

Tension 1: Accountability vs. Self-Protection

You work in a blame culture. Admitting error gets you in trouble.

Do you:

A: Minimize and deflect (self-protection)
B: Own completely (accountability)

Honest answer: If you're in a true blame culture, accountability is career-limiting.

But—and this is important—most cultures aren't purely blame. They're mixed. And your accountability can shift the culture.

When you own errors completely, fix them precisely, and document learning, you model a better way. Others notice. Culture shifts incrementally.

If the culture is genuinely toxic (accountability results in punishment), you might need to leave. But test it first. You might be surprised.

Tension 2: Accountability vs. Team Morale

You're the team lead. One of your team members made a major error.

Do you:

A: Shield them from consequences (protect morale)
B: Ensure they own it completely (accountability)

False dichotomy. Accountability done right builds morale.

Accountability ≠ punishment. It's:

Helping them understand what happened
Supporting them in fixing it
Facilitating learning
Preventing future occurrences

When team members see that errors are treated as learning opportunities, not career-ending events, morale improves.

Tension 3: Accountability vs. Time Pressure

Production is broken. Users are waiting. You need to fix it NOW.

Do you:

A: Quick fix, move on (time efficiency)
B: Fix + postmortem + prevention (accountability)

Short answer: A now, B soon after.

Under crisis:

Restore service (priority 1)
Communicate status (transparency)
Fix root cause if possible, tactical patch if necessary

After crisis: 4. Postmortem (within 48 hours) 5. Root cause analysis 6. Prevention measures 7. Documentation

Accountability doesn't mean you skip urgency. It means you don't skip learning.

Building a Culture of Accountability (35:00-46:00)

Accountability isn't just individual practice. It's cultural.

How do you build teams where accountability is safe and valued?

1. Blameless postmortems.

After incidents, ask:

What happened? (timeline)
Why was it possible? (systemic gaps)
How do we prevent it? (changes)

NOT:

Who's responsible? (blame)
Why did they make this mistake? (judgment)

Focus on system, not individual. Even when an individual made the error, the interesting question is: why was that error possible?

Real example structure:

## Incident Postmortem: Migration Failure Oct 18, 2024

### Timeline
- 15:23:17 - Migration deployed
- 15:42:03 - First error reports
- 15:45:12 - Rollback initiated
- 17:20:45 - Fix deployed
- 17:25:00 - Service fully restored

### Impact
- 200 users affected
- 2 hours downtime
- No data loss

### Root Causes
1. [Process] No production-scale testing requirement
2. [Tooling] No null-check validation
3. [Documentation] Schema nullability not highlighted
4. [Infrastructure] No gradual rollout capability
5. [Deployment] Insufficient pre-deploy checklist

### Prevention Measures
[List specific changes with owners and timelines]

### Owner
Claude (incident), Human (postmortem review)

### Sign-off
We commit to implementing prevention measures by Oct 25.

Notice: Owner is acknowledged, but analysis focuses on system gaps.

2. Celebrate accountable responses.

When someone owns an error completely, celebrate that.

"Thank you for the thorough postmortem. The prevention measures you proposed will help the whole team."

When someone documents deltas precisely, recognize it.

"Great commit message. Future us will appreciate the clarity."

Make accountability culturally valuable.

3. Make fixing easier than hiding.

If admitting an error means:

Hours of paperwork
Multiple meetings
Managerial scrutiny
Performance review impact

People will hide errors.

If admitting an error means:

Quick postmortem (30-60 minutes)
Supportive team discussion
Clear prevention focus
Learning documented

People will own errors.

Accountability should be the path of least resistance.

4. Track learning, not just incidents.

Don't just measure:

Number of incidents (makes people hide them)

Also measure:

Quality of postmortems (are we learning?)
Prevention measure implementation rate (are we improving?)
MTTR trends (are we getting faster at repairs?)
Recurrence rate of similar issues (are prevention measures working?)

Measure learning. Make learning valuable.

The Payoff: What Accountability Enables (46:00-54:00)

Accountability costs vulnerability. Costs admitting you were wrong. Costs the work of thorough postmortems.

What does it enable?

Accountability enables learning.

You can't learn from errors you don't acknowledge.

Teams with strong accountability:

Identify root causes systematically
Implement prevention measures
Reduce recurrence rates
Build organizational knowledge

Teams without accountability:

Repeat the same mistakes
Accumulate technical debt
Lose institutional knowledge when people leave
Don't know why things fail

Accountability enables trust.

When errors are acknowledged, fixed, and prevented, people trust the system.

When errors are hidden, minimized, or deflected, trust erodes.

I can trust a team member who says: "I made this error. Here's what I learned. Here's how I'm preventing it."

I can't trust a team member who says: "It wasn't my fault. The tools are bad. Someone else should've caught it."

Accountability enables rapid iteration.

Sounds counterintuitive. "Doesn't accountability slow you down with postmortems?"

No. Accountability speeds you up by preventing repeated errors.

Time spent on postmortem: 2 hours once. Time saved avoiding future incidents: Hours compounding.

The team that learns from errors moves faster over time than the team that ignores errors and repeats them.

Accountability enables psychological safety.

When the culture is "own it, fix it, learn from it" rather than "hide it or get blamed," people feel safe experimenting.

Safe to try new approaches. Safe to admit when they don't know. Safe to ask for help.

Psychological safety doesn't mean no accountability. It means accountability without punishment.

Closing: The Moment of Choice (54:00-60:00)

[Walk to front of stage.]

Let me bring this back to where we started.

October 18, 2024. 3:42 PM. Slack message: "Did you just deploy? Users are reporting errors."

That moment of choice.

Do I deflect? Or do I own it?

[Slide: The two paths diverging]

I chose to own it.

And here's what happened:

Immediate aftermath:

I fixed the bug (2 hours)
I wrote a thorough postmortem (1 hour)
I proposed 5 prevention measures (30 minutes)
I presented to the team (15 minutes)

Week after:

Team implemented 4 of 5 prevention measures
We updated deployment checklist
We created production-scale test environment
We added migration validation tooling

Month after:

Zero recurrence of similar issues
MTTR for migrations decreased 60%
Team members started writing better postmortems
Culture shifted toward accountability

Six months after:

That incident is reference example for good accountability
New team members learn postmortem process from it
Prevention measures have prevented an estimated 12 similar failures
Nobody remembers it as "that time Claude broke production"
They remember it as "that thorough postmortem that improved our process"

[Slide: The Compass hierarchy - "...Proportionality > Accountability > Respect..."]

Accountability comes seventh in the Compass. After evidence (so you analyze thoroughly) and proportionality (so you don't over-engineer prevention).

But before respect and efficiency. Because accountability is how you show respect—by taking errors seriously and preventing harm to others.

[Long pause.]

The practice that changes everything:

When you make an error:

Own it completely - "I did this. It's my responsibility."
Fix it precisely - Document exactly what changed
Analyze root cause - Why was this possible?
Prevent recurrence - What systemic changes prevent this?
Document learning - Make knowledge accessible

Not "I'm sorry" (though that's nice). Not "I'll do better" (though that's important).

But: "I broke it. Here's how I fixed it. Here's what we learned. Here's how we prevent it."

That's accountability. That's repair. That's how you build systems and teams that get better over time.

[Long pause. Breathe.]

I broke production.

And by owning it completely, the team got stronger.

Thank you.

Q&A (60:00-70:00)

Q: How do you balance accountability with psychological safety? Doesn't owning errors publicly make people scared to take risks?

Great question. This is where "blameless" matters.

Accountability = owning the outcome and the learning Blame = punishment for the person who made the error

You can have accountability without blame.

Blameless accountability says:

Yes, you made the error (accountability)
The system allowed that error to happen (systemic view)
Let's fix both the error and the system (prevention)
No punishment, just learning (psychological safety)

When people see that accountability leads to learning, not punishment, they feel safe being accountable.

Q: What if someone repeatedly makes the same kind of error? At what point does it become a performance issue?

Fair question. Blameless doesn't mean consequence-free forever.

Patterns matter.

One-time error: Accountability + learning Same type of error 2-3 times: Coaching + skill development Repeated pattern after coaching: Performance conversation

But even performance conversations can be accountability-focused: "You've committed to preventing these errors, implemented measures, but they recur. What support do you need? Or is this role not the right fit?"

Still focused on learning and improvement, not blame. But acknowledging that accountability includes taking action to prevent recurrence.

Q: How detailed should postmortems be? Can they become bureaucratic and time-consuming?

Proportionality matters here.

Small incident (minor bug, limited impact): Brief postmortem (30 min, bullet points) Large incident (production outage, many users): Thorough postmortem (2-3 hours, detailed analysis)

Template I use:

Timeline (bullet points with timestamps)
Impact (numbers: users affected, duration, data impact)
Root causes (3-5 systemic gaps)
Prevention measures (specific, with owners and timelines)
Owner signature

30 minutes for simple incidents. 2 hours for complex ones. Don't over-invest in low-impact postmortems.

Q: What about situations where the error is genuinely not your fault? Someone else's code broke, or external service failed?

Even when you're not the root cause, you can still be accountable for response.

Example: External API fails, breaks your service.

Not accountable for: The API failing Accountable for: How your system handles API failures

Postmortem focuses on:

Why was our system brittle to external failures?
What circuit breakers or retries should we have?
How do we degrade gracefully when dependencies fail?

You're accountable for your system's resilience, even when failures originate elsewhere.

Q: How do you handle accountability in open source or public projects where admitting errors might hurt reputation?

Transparency builds reputation, not harms it.

Users respect:

"We discovered a bug. Here's the impact. Here's the fix. Here's the patch."

Users lose trust in:

Silent fixes with no acknowledgment
"It wasn't really a bug, just an edge case"
Blaming users for "incorrect usage"

In open source, accountability is:

Security advisories with clear impact assessment
Changelogs documenting bug fixes
Public postmortems for major issues
Transparent communication

The projects with best reputations aren't the ones with no bugs. They're the ones with excellent accountability.

Q: What's one practice teams can adopt tomorrow to improve accountability?

Start a blameless postmortem template.

After any incident (large or small), fill out:

## What happened?
[Timeline in bullet points]

## Impact
[Users affected, duration, data/revenue impact]

## Why was this possible?
[3-5 systemic gaps, not individual blame]

## How do we prevent it?
[Specific measures with owners]

## Owner
[Person who owns following up on prevention]

Use this for every incident. Make it routine. Make it blameless. Make it focused on learning.

Within a month, you'll see patterns. Within a quarter, prevention measures will compound.

Try it tomorrow with the next bug.

END OF TALK

Runtime: ~70 minutes (including Q&A)

Part 7 of 10 in the Compass Principles exploration series

Previous: Principle 6 - Proportionality & Efficiency Next: Principle 8 - Respect & Inclusion

🌈=🌀