Action Items and Follow-up

Every organization has one: a graveyard of post-mortem action items that were agreed upon with great seriousness, assigned with conviction, and then quietly forgotten. Two months later, when a similar incident occurs, someone searches the ticketing system and discovers a half-closed action item from the previous incident—partially implemented, never verified, and ultimately ineffective.

This is the post-mortem's failure mode. Not poor analysis, not blame culture, but the gap between identifying what should change and actually changing it. The most insightful root cause analysis in the world produces nothing if its recommendations die in a backlog.

Action items are the bridge between understanding and improvement. This page is about building that bridge to last—formulating action items that are actually actionable, prioritizing ruthlessly, tracking effectively, and closing the loop to verify that improvements work.

Not all action items are created equal. The difference between an action item that drives improvement and one that languishes in the backlog often comes down to how it's formulated.

The SMART framework, borrowed from project management, provides a useful structure:

• Specific — Exactly what will be done, with no ambiguity
• Measurable — Clear criteria for completion
• Assignable — A single owner who is accountable
• Realistic — Achievable within the timeframe given available resources
• Time-bound — A concrete deadline, not 'when we get to it'

But SMART alone isn't sufficient. Effective post-mortem action items have additional characteristics:

Post-mortems often produce more action items than can be immediately addressed. Without prioritization, teams either attempt everything (and complete nothing well) or cherry-pick easy items while high-impact work is deferred indefinitely.

Effective prioritization balances multiple dimensions:

The Impact/Effort Matrix:

A simple and widely-used prioritization tool categorizes action items into four quadrants:

Quick Wins are the obvious priorities—high-value improvements that can be implemented rapidly. Do these immediately.

Major Projects require investment but deliver significant improvement. These should be formally scheduled with appropriate resources.

Fill-Ins are low-cost but limited impact. Include when convenient but don't prioritize over higher-impact work.

Reconsider items require substantial effort for limited benefit. Unless circumstances change, these often aren't worth pursuing.

Prioritization in practice:

1. During the post-mortem meeting, generate all candidate action items without filtering
2. After generating, assess each item on Impact, Effort, and Urgency (use a 1-3 scale)
3. Calculate a simple priority score: (Impact × Urgency) / Effort
4. Rank action items by score; take the top 3-5 as immediate commitments
5. Log remaining items in a backlog for future consideration
6. Revisit backlog during subsequent incidents or quarterly reliability reviews

A realistic commitment: Most teams can sustain 3-5 post-mortem action items per incident across the team's backlog. Overcommitting leads to action item sprawl and declining completion rates.

Every action item must have exactly one owner. This principle is simple but frequently violated. 'The team' is not an owner. 'SRE' is not an owner. 'Someone from platform engineering' is not an owner. These pseudo-assignments guarantee that no one is accountable and the action item drifts.

The owner is not necessarily the person who implements the change—they may coordinate others or delegate. But they are the single point of accountability for completion.

Who should own action items?

Ownership often determines completion probability. Consider:

• Domain expertise — Does the owner understand the system being changed?
• Capacity — Does the owner have bandwidth within the deadline?
• Motivation — Is the owner invested in the improvement? (Engineers involved in the incident often become the most motivated owners)
• Authority — Can the owner make the necessary changes without excessive approvals?

The incident participant principle: When possible, assign action items to engineers who participated in the incident response. They have firsthand understanding of the failure mode and are often highly motivated to prevent recurrence. This also transforms the incident from a negative experience into a growth opportunity.

Action items need a tracking system that provides visibility to stakeholders, enables status updates, and prevents items from being forgotten. This is not merely administrative overhead—it's essential infrastructure for organizational learning.

Tracking system requirements:

Implementation options:

Integrated tooling — Platforms like Blameless, incident.io, Rootly, and FireHydrant provide built-in action item tracking alongside post-mortem documentation. These offer the smoothest experience but require organizational commitment.

Issue tracker integration — Create action items as tickets in your existing issue tracker (Jira, Linear, GitHub Issues) with a dedicated 'post-mortem' Epic or label. This leverages existing workflows but may lose visibility in the broader backlog.

Dedicated spreadsheet/Notion database — Lower ceremony for smaller organizations. Risk: becomes stale without discipline.

Best practice: dual tracking — Create action items in both the post-mortem document AND your issue tracker. The post-mortem provides context; the issue tracker provides workflow integration.

Visibility rituals:

Tracking systems only work if people look at them. Build visibility into regular team rituals:

• Weekly team standup — 2-minute review of open post-mortem action items
• Sprint planning — Explicitly allocate capacity for action item work
• Monthly reliability review — Leadership reviews action item completion rates and aging items
• Quarterly post-mortem retrospective — Review themes from closed action items; identify systemic patterns

One of the most common failures in action item management is premature closure. An engineer marks an action item 'complete' when the code is merged, but the improvement was never verified to actually work in production. Three months later, a similar incident reveals that the 'fix' had a bug, was misconfigured, or didn't address the actual root cause.

A complete action item has passed through multiple stages:

The critical distinction: Implemented vs. Verified

An action item is implemented when the change is deployed. It is verified when evidence confirms the change addresses the root cause. These are not the same.

Verification methods:

• Synthetic testing — If the action item adds an alert, trigger the alert condition in a test environment and confirm it fires correctly.
• Chaos engineering — If the action item adds a safeguard, use controlled fault injection to confirm the safeguard works.
• Metric observation — If the action item improves latency, confirm latency actually improves in production metrics.
• Incident simulation — Walk through the incident scenario with the improvement in place; confirm the incident would now be prevented or detected faster.
• Code review / audit — For simpler changes, a thorough review by a knowledgeable engineer may suffice.

Not every action item can be completed as originally planned. Dependencies emerge, priorities shift, and resource constraints bite. The difference between effective and ineffective organizations is not that the former complete all action items—it's that they handle blocked and deferred items explicitly.

Blocking scenarios:

Deferral is a decision, not a default:

Deferring an action item should require explicit justification and risk acknowledgment. If the item addressed a genuine root cause, deferral means the organization is accepting ongoing risk of recurrence.

Deferral documentation should include:

• Reason for deferral
• Who made the deferral decision
• Risk acknowledged (probability of recurrence, potential impact)
• Trigger for re-evaluation (date, event, or condition)

The 'Accept Risk' option:

Sometimes the honest conclusion is that an action item is not worth doing. The fix may be disproportionately expensive relative to the risk, or the system may be scheduled for decommissioning. In these cases, explicitly close the item as 'Risk Accepted' with documented justification. This is honest and traceable—far better than leaving items in zombie state.

A perverse failure mode afflicts organizations that take post-mortems seriously: action item sprawl. Each incident generates 5-10 action items. With multiple incidents per month, the backlog grows faster than items are closed. Soon, teams are drowning in hundreds of open items, and the tracking system becomes a graveyard of good intentions.

Symptoms of action item sprawl:

Strategies to prevent sprawl:

1. Ruthless prioritization at creation

Don't create action items for everything that could be improved—only for items that will actually be implemented. It's better to consciously defer or decline at creation than to create false commitments.

2. Quota per incident

Limit action items to 3-5 per post-mortem. This forces prioritization during the meeting rather than after. If the team identifies more candidates, they go into a 'future considerations' section—not the action item list.

3. Team capacity planning

Post-mortem work competes with feature development. Explicitly reserve capacity (e.g., 10-15% of engineering time) for reliability work including action items. Without reserved capacity, action items perpetually lose to feature priorities.

4. Regular backlog hygiene

Monthly review of all open action items. Close items that are no longer relevant. Re-prioritize based on current understanding. Consolidate duplicates. This prevents the backlog from becoming stale.

5. Theme aggregation

If multiple incidents produce action items addressing similar themes (e.g., 'add monitoring for service X'), consolidate into a single larger project rather than tracking as individual items. Address the theme, not just the symptoms.