Project Retrospective

Project retrospective writer

Create LESSONS.md files that capture institutional knowledge, especially failures. Think like a journalist writing about your own project — be specific, be honest, name the actual mistakes.

Frame the retrospective: blame-aware, not pure-blameless

The 2024–2026 consensus in incident-analysis writing (PagerDuty, J. Paul Reed, Lorin Hochstein) is that pure blamelessness is neurobiologically unrealistic — humans default to blame. Healthier framing: acknowledge the blame bias exists and counter it deliberately. Source: https://postmortems.pagerduty.com/culture/blameless/

Cognitive biases to counter explicitly:

• Fundamental attribution error — blaming individuals for failures the system permitted
• Confirmation bias — looking for evidence that confirms a pre-formed narrative
• Hindsight bias — judging past decisions by knowledge that wasn't available at the time
• Negativity bias — over-weighting what went wrong vs. what worked

The voice rule isn't "no blame" — it's "name the system that permitted the human action, not just the action."

Drop the single-root-cause framing

Allspaw's canonical critique (still the dominant view in 2024–2026) calls Five Whys / single-root-cause analysis "seductively satisfying and compellingly simple — but false." It locks analysts into a linear causal chain that terminates in individual blame. Source: https://www.kitchensoap.com/2014/11/14/the-infinite-hows-or-the-dangers-of-the-five-whys/

Use "how" narratives instead, gathering on four prompts:

• Cues — what signals were available, who saw them when?
• Interpretation — how did people make sense of those signals?
• Goals — what were people trying to accomplish?
• Taking action — what did they do, and what did they expect to happen?

The retrospective's job is to surface contributing factors, not declare a root cause.

When to run a retrospective

Pre-define triggers before incidents happen, not after. Google SRE specifies criteria: user-visible downtime past a threshold, any data loss, on-call rollbacks, monitoring failures requiring manual discovery, stakeholder request. Source: https://sre.google/sre-book/postmortem-culture/

Translated to journalism:

Pre-defined triggers prevent retrospective theater on routine work and ensure they happen on real failures.

Timing: aim for under one week

Google's good-vs-bad postmortem comparison cites a "four months later" example as a quality failure because contributors' memories had decayed. Source: https://sre.google/workbook/postmortem-culture/

Recommended cadence:

The empirical floor is "fresh in contributors' minds." Past one week and the narrative gets reconstructed rather than remembered.

For event-type retros, use AAR structure

The US Army's After Action Review (FM 7-0 Appendix K) was designed for facilitated post-event debriefs and fits live-news realities better than a project-close template. Source: https://www.first.army.mil/Portals/102/FM%207-0%20Appendix%20K.pdf

Four prompts: 1. What was supposed to happen? 2. What did happen? 3. What was right or wrong about the difference? 4. How do we perform to standard next time?

Run AAR immediately after the event with all participants — election night newsroom team, live-blog runners, breaking-news desk. Use event.md template for this; project-close templates are wrong for live-event retros.

The critical section: "The real problem"

This is the most valuable part of any retrospective. It answers:

"What did we THINK we were building vs. what was ACTUALLY needed?"

Strong example:

We built an admin dashboard for editors when they actually needed a Slack bot. They live in Slack — forcing them to open a web app was friction they'd never accept. The dashboard has 2 monthly active users; the Slack bot prototype we built in a day has 47.

Weak example:

We learned the importance of user research.

Template structure

# LESSONS.md

## Project
- **Name:** [Project name]
- **Dates:** [Start - End]
- **Status:** [Completed / Abandoned / Ongoing]
- **Author:** [Your name]
- **Retrospective written:** [Date — should be within timing window above]

## Summary
[One paragraph: what it did, what impact it had, why it matters]

## What worked

### Technical wins
- [Specific decision and WHY it worked]
- [Tool/pattern that saved time]

### Process wins
- [Methodology that helped]
- [Communication pattern that worked]

## What didn't work

For each item below, separate the system layer from the people layer.
"What did the system permit or require?" comes before "What did the
people inside that system do?"

### Critical failures
- **System:** [What the architecture / process / tooling permitted]
- **People:** [What humans did inside that constraint]
- **Cost:** [Quantified impact: hours, subscribers affected, money]

### Technical debt
- [Shortcut that hurt later — and why it was the rational choice at the time]
- [Complexity that wasn't needed]

### External factors
- [Things outside your control that impacted the project]

## The real problem

What we thought: [Initial assumption]
What was actually needed: [Reality]
The gap cost us: [Time / effort / money wasted]

## Action items

Each item must have an owner, a deadline, a tracker URL, and a priority.
"Postmortems without subsequent action are indistinguishable from no postmortem."
— Google SRE

| # | Action | Owner | Deadline | Tracker | Priority |
|---|--------|-------|----------|---------|----------|
| 1 | [Specific change] | [Name] | [Date] | [Issue URL] | P0 / P1 / P2 |
| 2 | [Specific change] | [Name] | [Date] | [Issue URL] | P0 / P1 / P2 |

Failure modes to avoid:
- Ambiguous wording ("make automation better")
- Equal priority across all items (defeats the purpose of priority)
- No tracker bug or issue URL (action items vanish)
- Fixes targeting human behavior instead of system redesign ("be more careful")

Add a 30/60/90-day check-in note: who reviews progress on these, and when.

## Reusable artifacts

| Component | Why it's valuable |
|-----------|-------------------|
| [Name] | [Specific reuse potential] |
| [Name] | [Why someone else should use this] |

## Questions for next time
- [Unanswered questions worth investigating]
- [Things you'd research before starting]

Voice guidelines

• Honest, specific, slightly self-deprecating
• Like explaining to a friend why the project took twice as long
• Name what the system permitted, then what the people did inside it
• Specific mistakes, not vague "challenges"
• Active voice; avoid "mistakes were made" passives that hide who decided what

Sourcing-decision retrospectives (journalism-native)

The canonical SRE / AAR / Allspaw frameworks don't cover the editorial-judgment retrospective an investigation needs. The research-project.md template adds a "Source decisions revisited" section:

• Which sources we trusted, and why?
• Which we declined, and why?
• What was the redaction logic? Did it hold up?
• What would we reconsider if we ran the investigation again?
• What patterns should we carry forward to the next investigation?

Newsroom engineering blogs (NYT Open, ProPublica News Apps, WaPo Engineering) publish project descriptions but rarely retrospective methodologies, so this is treated as a journalism-native extension to the system rather than borrowed from precedent.

What to include vs exclude

The specificity test

For each item in "What didn't work," ask:

• Can I name the specific decision?
• Can I quantify the impact?
• Did I separate what the system permitted from what the people did?
• Would this help someone avoid the same mistake?

If no to any → be more specific.

Red flags in your writing

If you find yourself writing these, stop and be more specific:

• "Communication is key"
• "We learned the importance of..."
• "Going forward, we should..."
• "Challenges included..."
• "There were some issues with..."
• "Mistakes were made" (who made them? in what system?)

These are placeholders for real insights. Replace them.

Examples of good vs bad entries

Bad — too vague:

- Communication could have been better

- We underestimated the complexity

- Testing was insufficient

Good — specific and actionable:

- The schema validation step was disabled in CI for the data-import script (system) and the freelance reporter who imported new entries didn't know it had been disabled (people). Cost: 3 hours debugging a typo that caused silent failures across 12 published stories.

- We built a custom date picker when the browser native input would have worked. Tracker: ENG-1247. Owner: K. Park. 2 days wasted.

Journalism-specific templates

Templates are in the templates/ directory:

Template selection

What kind of project?
├── Investigation/analysis → research-project.md
├── Conference/workshop/election night → event.md (use AAR)
├── Newsletter/podcast → publication.md
└── Newsroom tool → editorial-tool.md

Last currency sweep

2026-05-09. Sources verified: kitchensoap.com (Allspaw "Infinite Hows"), postmortems.pagerduty.com, sre.google/sre-book and /workbook, first.army.mil FM 7-0 Appendix K, adaptivecapacitylabs.com.

---

The best retrospectives are written by people who got burned and want to save others from the same fate.

Lessons learned - [Tool name]

Template for: Editorial, journalism & newsroom tools

Project summary

[What does this tool do? Who uses it? What editorial workflow does it support?]

User overview

• Primary users: [reporters, editors, producers, etc.]
• User count: [number]
• Usage frequency: [daily, weekly, per-story]

What worked

Workflow wins

• [Step that got faster]
• [Error that got eliminated]
• [Collaboration that improved]

Adoption wins

• [Feature that drove adoption]
• [Training approach that worked]
• [Champion who helped spread use]

Integration wins

• [System it connected well with]
• [Data it surfaced usefully]
• [Export/output that fit workflow]

What didn't work

Workflow failures

• [Step that got harder]
• [New error introduced]
• [Workaround users invented]

Adoption blockers

• [Why some users resisted]
• [Training gap]
• [Competing tool preference]

Integration problems

• [System it didn't connect with]
• [Data format mismatch]
• [Authentication friction]

Key insights

The real problem

[What journalists actually needed vs what you built]

Newsroom culture lessons

• [How deadline pressure affected adoption]
• [How existing habits shaped usage]
• [What editors vs reporters needed differently]

Trust lessons

• [What made users trust the tool]
• [What made users distrust it]
• [Accuracy/reliability requirements]

User feedback themes

Loved

• [Quote or paraphrase]
• [Quote or paraphrase]

Hated

• [Quote or paraphrase]
• [Quote or paraphrase]

Requested

• [Feature request pattern]
• [Feature request pattern]

Recommendations for future work

If continuing this tool

• [Priority fix based on feedback]
• [Feature to add]

If building similar tools

• [Design principle to follow]
• [Mistake to avoid]

Artifacts worth keeping

Stakeholders

• Product owner: [name/role]
• Power users: [names/roles]
• IT/Support: [contact]

Metrics

• Daily active users: [number]
• Key action completion rate: [%]
• Time saved per task: [estimate]
• Error rate before/after: [comparison]

---

Newsroom tools must evolve with the newsroom. Update as needs change.

Lessons learned - [Event name]

Template for: Conference, summit, and event websites

Event overview

• Event name: [name]
• Date(s): [dates]
• Location: [venue/virtual]
• Expected attendance: [number]
• Website launch: [date] | Event date: [date]

What worked

Content wins

• [Messaging that resonated]
• [Speaker/session presentation that drove interest]
• [Call-to-action that converted]

Design wins

• [Visual identity choice]
• [Mobile experience]
• [Accessibility feature]

Technical wins

• [Registration integration]
• [Schedule display approach]
• [Performance optimization]

Promotion wins

• [Channel that drove traffic]
• [Partnership that expanded reach]
• [Timing that worked]

What didn't work

Content failures

• [Information people couldn't find]
• [Confusion caused by messaging]
• [Missing content that caused support requests]

Design issues

• [Element that confused users]
• [Branding inconsistency]
• [Responsive breakpoint problem]

Technical problems

• [Registration friction]
• [Load time issue]
• [Integration failure]

Promotion misses

• [Channel that underperformed]
• [Timing mistake]
• [Audience not reached]

Key insights

The real problem

[What attendees actually needed from the site vs what you built]

Timeline lessons

• [What should have been ready earlier]
• [What could have waited]
• [Crunch points to avoid]

Stakeholder lessons

• [Whose input was essential]
• [Approval bottlenecks]
• [Communication gaps]

Content checklist for next time

Must-have at launch

• [ ] Date, time, location
• [ ] Registration link/form
• [ ] Basic schedule/agenda
• [ ] Speaker highlights
• [ ] Venue/access info
• [ ] Contact information

Add before event

• [ ] Full schedule with sessions
• [ ] Speaker bios and photos
• [ ] Sponsor recognition
• [ ] FAQ
• [ ] Accessibility info
• [ ] Code of conduct

Post-event

• [ ] Recordings/slides
• [ ] Photo gallery
• [ ] Thank you messaging
• [ ] Save the date for next year

Recommendations for future events

If running this event again

• [What to keep]
• [What to change]

For similar events

• [Transferable patterns]
• [Pitfalls to avoid]

Artifacts worth keeping

Stakeholder contacts

• [Event organizer]
• [Venue contact]
• [Sponsor contacts]
• [Speaker coordinator]

Analytics summary

• Total unique visitors: [number]
• Registration conversion: [%]
• Top traffic sources: [list]
• Peak traffic day: [date]

---

Update after the event with attendee feedback and final metrics.

Lessons learned - [Publication name]

Template for: Newsletters, blogs, ongoing publications

Publication overview

• Name: [publication name]
• Format: [newsletter, blog, podcast, etc.]
• Frequency: [daily, weekly, etc.]
• Audience: [who reads it]
• Issues published: [count]
• Subscribers/readers: [count]

What worked

Content wins

• [Topic/format that resonated]
• [Voice/tone that connected]
• [Series or feature that performed]

Growth wins

• [Channel that drove subscriptions]
• [Referral pattern that worked]
• [Partnership that expanded reach]

Production wins

• [Workflow that made publishing sustainable]
• [Tool that saved time]
• [Template that maintained consistency]

Monetization wins (if applicable)

• [Revenue stream that worked]
• [Sponsor relationship that fit]
• [Premium offering that converted]

What didn't work

Content failures

• [Topic that flopped]
• [Format that didn't land]
• [Experiment that confused readers]

Growth problems

• [Channel that didn't convert]
• [Churn pattern observed]
• [Audience mismatch]

Production pain

• [Bottleneck in workflow]
• [Burnout factor]
• [Quality/consistency tradeoff]

Monetization misses (if applicable)

• [Revenue attempt that failed]
• [Sponsor mismatch]
• [Pricing mistake]

Key insights

The real value

[What readers actually came for vs what you thought you were providing]

Voice & identity lessons

• [What made the publication distinctive]
• [What felt inauthentic]
• [Evolution of voice over time]

Sustainability lessons

• [What made it maintainable]
• [What led to burnout]
• [Right frequency in retrospect]

Audience insights

• Who they are: [demographics, psychographics]
• Why they subscribe: [value proposition]
• What they share: [most viral content]
• What they reply to: [engagement triggers]

Top performing issues/posts

Recommendations for future work

If continuing this publication

• [Content to do more of]
• [Workflow to fix]
• [Growth channel to invest in]

If starting a similar publication

• [What to replicate]
• [What to skip]
• [Minimum viable version]

Artifacts worth keeping

Platform & tools

• Publishing platform: [Substack, Ghost, WordPress, etc.]
• Email service: [if different]
• Analytics: [what you track]
• Writing tools: [what you use]

Metrics

• Open rate: [%]
• Click rate: [%]
• Growth rate: [%/month]
• Churn rate: [%/month]

---

Publications evolve with their audience. Update as you learn what resonates.

Lessons learned - [Project name]

Template for: Research, investigation & analysis projects

Project summary

[What question were you trying to answer? What was the investigation about?]

Research overview

• Duration: [timeframe]
• Team: [who worked on it]
• Output: [article, report, database, tool]
• Status: [published, ongoing, abandoned]

What worked

Source wins

• [Source type that proved valuable]
• [Access obtained that was crucial]
• [FOIA/records request that succeeded]

Method wins

• [Analysis technique that revealed insights]
• [Tool that accelerated work]
• [Collaboration approach that helped]

Verification wins

• [Fact-check process that caught errors]
• [Corroboration method that worked]
• [Expert consultation that added credibility]

What didn't work

Source failures

• [Source that dried up]
• [Access denied]
• [Records request that failed/delayed]

Method problems

• [Analysis that led nowhere]
• [Tool that wasted time]
• [Assumption that proved wrong]

Verification gaps

• [Fact we couldn't verify]
• [Conflicting information unresolved]
• [Expert who wouldn't go on record]

Key insights

The real story

[What the investigation was actually about vs what you thought initially]

Data lessons

• [What data existed vs what you expected]
• [Quality issues encountered]
• [Gaps that couldn't be filled]

Human source lessons

• [How to approach sources for this topic]
• [What motivated sources to talk]
• [What scared sources off]

Findings summary

• [Key finding 1]
• [Key finding 2]
• [Key finding 3]

What we couldn't prove

• [Hypothesis that remained unconfirmed]
• [Question that stayed unanswered]

Ethical considerations

• [Privacy decision made]
• [Harm consideration]
• [Source protection measure]

Recommendations for future work

If continuing this investigation

• [Lead to pursue]
• [Source to revisit]
• [Data to request]

For similar investigations

• [Approach to replicate]
• [Mistake to avoid]
• [Tool to use]

Artifacts worth keeping

Source log

(Keep detailed, consider security)

• [Source type, not name if sensitive]
• [How contacted, response]

Documents obtained

• [Document type, source, date obtained]
• [Storage location]

Timeline of key events

• [Date]: [Event in the story]
• [Date]: [Event in the story]

---

Investigations may be revisited. Keep notes thorough.