Fixing an unmanaged post-mortem action backlog

WHAT THIS TESTS Whether you can diagnose why action items rot and redesign the process so improvements actually ship, balancing reliability work against feature pressure.

A GOOD ANSWER COVERS The backlog grows because reviews optimize for thoroughness, emitting many small, low-leverage, often ownerless items that live in a separate list nobody prioritizes against real work. Fix the generation side first: push each review to identify the few systemic fixes that would prevent classes of incidents, not every conceivable tweak, ranking by risk reduced versus cost. Then fix the lifecycle: every item must have an owner, a due date, and a priority, and must enter the team's normal backlog so it competes for sprint capacity rather than sitting in limbo. Make follow-through visible by tracking completion rate and aging as metrics leadership sees. Consider a standing reliability budget so high-priority items get guaranteed capacity.

COMMON WRONG ANSWERS Just telling teams to do better. Generating even more items. Keeping action items in a separate tracker disconnected from planning.

LIKELY FOLLOW-UPS How do you decide which items earn engineering time over features? Who enforces ownership and dates? What metric signals the process is healthy?

ONE CONCRETE EXAMPLE A team's reviews averaged 12 action items each, mostly trivial, and 80 percent went stale. You change the standard to at most three items per review, each a systemic fix with an owner, date, and priority, filed directly as backlog tickets that compete in sprint planning. You add a monthly report on action-item completion and age. Within a quarter, far fewer items are created, the stale rate drops sharply, and the systemic fixes that actually prevent repeat incidents get shipped.