Action Item Quality

SMART actions, durable owners, due dates, prevention controls, and verification evidence.

6 min readSRE PlaybookOperate

SMART Action Items

Every action item must be Specific, Measurable, Achievable, Relevant, and Time-bound. Vague action items do not get done. Specific action items have clear owners, clear outcomes, and clear deadlines.

SMART action item examples


smart_examples:
  bad:
    title: "Improve monitoring"
    problem: "Not specific, not measurable, no deadline"

  good:
    title: "Add connection pool utilization alert to Grafana"
    specific: "Connection pool utilization for user-api service"
    measurable: "Alert fires when utilization > 80% for 5 minutes"
    achievable: "Requires Grafana dashboard and Prometheus query"
    relevant: "Addresses contributing factor: no connection pool monitoring"
    time_bound: "Complete by 2024-02-15"
    owner: "Alice (platform-sre)"
    verification: "Alert fires correctly in staging, confirmed by manual test"

  transformation:
    before: "Fix the deployment process"
    after: "Implement automated rollback in Argo Rollouts that triggers
      when error rate exceeds 5% for 2 minutes, tested in staging,
      complete by 2024-03-01, owned by Bob (platform-sre)"

Durable Ownership

Every action item must have exactly one owner. Not a team — a person. Shared ownership is no ownership. The owner is responsible for completion, not just for tracking progress.

Ownership rules


ownership_rules:
  single_owner: true
  rules:
    - "Owner must be a named individual"
    - "Owner must agree to the due date"
    - "Owner must have authority to complete the action"
    - "If owner changes, update the tracker immediately"

  accountability:
    - "Owner provides weekly status updates"
    - "Overdue items escalated to engineering manager"
    - "Monthly report on completion rate"

  delegation:
    - "Owner can delegate work but retains accountability"
    - "Delegation must be recorded"
    - "Original owner verifies completion"

Realistic Due Dates

Due dates must be realistic. Unrealistic due dates are ignored. Consult with the owner before setting a due date. Account for competing priorities, testing time, and review processes.

Due date guidelines


due_date_guidelines:
  critical_priority:
    description: "Must be done to prevent recurrence"
    sla: "Within 1 week"
    examples:
      - "Add missing alert for connection pool"
      - "Fix security vulnerability"

  high_priority:
    description: "Should be done to improve reliability"
    sla: "Within 2 weeks"
    examples:
      - "Add runbook for common failure"
      - "Implement automated rollback"

  medium_priority:
    description: "Would improve the system"
    sla: "Within 1 month"
    examples:
      - "Add comprehensive monitoring"
      - "Improve documentation"

  low_priority:
    description: "Nice to have"
    sla: "Within 1 quarter"
    examples:
      - "Refactor related code"
      - "Add advanced analytics"

  factors:
    - "Owner's current workload"
    - "Complexity of the action"
    - "Dependencies on other teams"
    - "Testing and review time"
    - "Deployment windows"

Prevention Controls

Focus on prevention, not just detection. Action items should prevent recurrence, not just detect it faster. A detection action is a band-aid. A prevention action is a cure.

Prevention vs detection


prevention_vs_detection:
  detection_actions:
    type: "Detects the problem"
    examples:
      - "Add alert for connection pool usage"
      - "Add monitoring for disk space"
    limitation: "Problem still occurs, just detected sooner"

  prevention_actions:
    type: "Prevents the problem from occurring"
    examples:
      - "Implement connection pool auto-scaling"
      - "Implement disk space auto-cleanup"
    benefit: "Problem does not recur"

  hierarchy:
    level_1: "Eliminate the cause"
    level_2: "Prevent the cause"
    level_3: "Detect and mitigate"
    level_4: "Detect and respond"

  good_action_items:
    - "Implement connection pool auto-scaling (prevents)"
    - "Add circuit breaker for database connections (prevents)"
    - "Implement automated rollback (prevents impact)"

  weak_action_items:
    - "Add monitoring for connection pool (detects only)"
    - "Create runbook for connection pool issues (responds only)"
    - "Schedule regular capacity reviews (detects only)"

Verification Evidence

Every action item must have verification criteria. How will you confirm the action is complete and effective? Without verification, you cannot be sure the fix actually works.

Verification criteria examples


verification_criteria:
  monitoring:
    - "Alert fires correctly in staging"
    - "Alert routes to correct PagerDuty service"
    - "Runbook link is accessible and accurate"

  code:
    - "PR approved and merged to main"
    - "Tests passing in CI"
    - "Deployed to production"
    - "Verified in production with real traffic"

  process:
    - "Documentation updated"
    - "Team trained on new process"
    - "Runbook tested by different engineer"
    - "Game day validates the process"

  infrastructure:
    - "Configuration applied to production"
    - "Verified with test query"
    - "Monitoring confirms expected behavior"
    - "No regression in related metrics"

Anti-Patterns

Anti-Pattern	Problem	Fix
Vague title	Cannot be executed	Make specific and measurable
No owner	No accountability	Assign exactly one person
No due date	No urgency	Set realistic deadline
Team owner	Diffused responsibility	Assign individual owner
Detection only	Does not prevent recurrence	Focus on prevention
No verification	Cannot confirm completion	Add verification criteria

Action item quality determines postmortem value

A postmortem with poor action items produces no improvement. A postmortem with excellent action items prevents future incidents. The quality of your action items determines the value of your postmortem process.

Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.

Stage 6 · Operate

Blameless Postmortems & Learning