Tool 4 of 32 · a day
Recurrence Ledger
Counts the problems that keep coming back, because a returning problem means a symptom is being treated while a cause survives underneath.
During Reality, from three to six months of the company's own records.
What it is for
To count the problems that keep coming back, from meeting notes, the issue tracker, and repo history, so a series of reasonable-looking patches becomes a single pattern.
The failure it catches
Healthy teams' problems die. Sick teams' problems return with mutations, because symptoms get patched while causes persist. Individually, every patch decision looks reasonable, which is why the pattern is missed without counting.
Why it works
Counting recurrences turns a stack of defensible one-off fixes into a number about the company. A cause hiding under symptoms only becomes visible once the returns are on one page.
How to run it
- Pull three to six months of meeting notes, the issue tracker, and the repo history.
- List every topic that keeps appearing in meetings without an executed resolution.
- List tickets that were closed and came back, in the same or a mutated shape, within about a month.
- Rank modules or areas by how many fixes and hotfixes they have absorbed.
- Pick one recurring calculation and check whether it gives different answers in different weeks.
- Report every finding as a number about the company, never as a finding about a person.
How to read the result
A topic in three or more consecutive meetings without resolution points at decisions not landing. One small area absorbing a large share of all hotfixes, more than about 30 percent of hotfixes in less than about 10 percent of the work, points at a buried root cause. Same inputs, different conclusions, points at definition or data rot. Those percentage cutoffs are our judgment, not proven science. A single recurrence proves nothing; the pattern is the finding.
How to run it well
- Let the records referee the accounts. Where they agree you have solid ground. Where they differ you have found something worth understanding.
- Never use a single recurrence as proof.
Where it breaks
- A company in the middle of a legitimate migration will over-count.
- If there are no notes to pull, that absence is itself a finding about how information travels, but reconstructing from chat is noisier.
- A single recurrence proves nothing.
What would prove it wrong
A team with high recurrence counts that ships fine and whose estimates converge would break the link between recurrence and a cause surviving underneath.
What we watch
Whether high recurrence later matches a buried root on the trace, or whether busy teams with lots of returning topics still settle work and converge.
Ask yourself
- Which problems have come back more than once in the last few months?
- Is there a meeting topic that appears again and again without a decision that stuck?
- Is there a part of the product or the operation that absorbs a large share of the emergency fixes?
- Does the same calculation ever give different answers in different weeks?