--- name: countermeasure-log description: "What is being done about the causes behind the reds, and whether it held: every entry marked as containment or a permanent fix, with the outcome it was supposed to produce written before it was tried — and a flag on every closure the cause outlived. Use when: A team already surfacing problems — from a grid, a huddle, or anywhere else — that now needs somewhere honest for them to go. You suspect you are fixing the same things repeatedly but cannot prove it. Your action list closes plenty of items and the underlying problems keep returning. Not for: As a general task tracker. This is for causes, not for everything anyone has agreed to do — mixing them buries the few entries that matter. As an input to appraising individuals. The moment it can reach a review, the honest entries stop and the log fills with things that were already safe to say. For a one-off problem nobody expects to see again. Containment, done, no entry needed." --- # Countermeasure log What is being done about the causes behind the reds, and whether it held: every entry marked as containment or a permanent fix, with the outcome it was supposed to produce written before it was tried — and a flag on every closure the cause outlived. Family: Daily management · Format: .xlsx · Domain: core ## What it is A log of what is being done about the causes behind the problems a team keeps hitting, and whether it worked. Every entry names the cause, says whether it is containment or a permanent fix, carries a named person and the outcome it is supposed to produce, and closes only with evidence that something moved and held. Two things make it different from an ordinary action list, and both come from the same uncomfortable finding: in the closest observational study of how people actually handle problems at work, nurses worked around roughly nine in ten of the failures they hit and removed the cause in about one. Everyone was busy, everything got resolved, nothing improved. First, this log therefore separates containment from permanent everywhere and reports what share of closures actually removed a cause. Containment is not failure — it is usually the right first move, and it protects people while the cause is still being understood. It becomes failure only when it is where the work stops. Second, the log records when a cause is seen again after its countermeasure was closed, which means the closure was never real. A team can close forty items a quarter and face the same eight causes all year, and without that check the log reads as a record of relentless progress. Add the date at the huddle the moment a cause reappears; it takes ten seconds and it turns a list of activity into a record of what is actually true. There is also a cap on how many entries may be open at once, because work in progress divided by throughput is how long each item waits — a queue without a limit does not go faster, it stops finishing. Influences, paraphrased rather than reproduced: Tucker and Edmondson on first-order versus second-order problem solving; Spear and Bowen on an improvement being a hypothesis with a predicted outcome rather than a task; and Little's law on why the cap is the only real lever on time-to-close. ## When to use it Use it when: - A team already surfacing problems — from a grid, a huddle, or anywhere else — that now needs somewhere honest for them to go. - You suspect you are fixing the same things repeatedly but cannot prove it. - Your action list closes plenty of items and the underlying problems keep returning. - You want to know whether improvement work is actually changing the system or just absorbing it. Not when: - As a general task tracker. This is for causes, not for everything anyone has agreed to do — mixing them buries the few entries that matter. - As an input to appraising individuals. The moment it can reach a review, the honest entries stop and the log fills with things that were already safe to say. - For a one-off problem nobody expects to see again. Containment, done, no entry needed. - Before anything is surfacing problems at all. A log with nothing in it is not a sign of health; go and build the board and the huddle first. - Where a simple commitment list is genuinely all you need — who agreed to what, by when. That is the daily accountability sheet, and it is a lighter tool. ## How to fill it in - **cap** — Set the number of entries that may be open at once before you add the first one, and set it low enough to be uncomfortable — around five for a single team is a well-worn figure. The cap is the only real lever on how long an item waits, because work in progress divided by throughput is the waiting time. When you are at the cap and something new arrives, contain it and leave it off the log until something closes. That will feel wrong. It is the point: a list that only grows teaches everyone that adding to it achieves nothing. - **entries** — The cause in the same words every time, so recurrence is visible at all — write it once and reuse it exactly. Then whether this is containment or a permanent fix; be honest, because the whole value of the log rests on that one word. A named person, never a department. And the outcome you expect, written before you try it: "same-day replies back above 95% within two weeks", not "improve responsiveness". An action with no predicted outcome can only ever be done or not done — it cannot fail informatively, and an action that cannot fail teaches nobody anything. - **recurrence** — Close an entry only with evidence: what was seen that shows the thing moved, and held. "Done" is not evidence; a date is not evidence. Then keep the entry alive in one respect — if the cause turns up again afterwards, add that date to the entry that claimed to have fixed it. That is the single most valuable habit in this kata, and the cheapest. It costs ten seconds at a huddle and it is the only way anyone finds out that a closure was a hope with a date on it. - **health** — Computed for you. The number that matters most is the share of closures that removed a cause rather than patching it — read it alongside the count of closures the cause outlived, because a high permanent share means nothing if those closures were not real. Also computed: how many are open against your cap, the age of the oldest open entry, how many closed with nothing written in evidence, the median time to close, and the causes that keep coming back. Nothing to enter here. - **narrative** — Drafted from the log actually kept, and grounded only in what it computes. ## What good looks like The example below is the inside sales team from the performance grid, a quarter further on, working the two causes that grid's Pareto surfaced. Nine entries, seven closed, median eight days — from a distance, a team getting things done. Look at what closed. Only two of the seven were permanent fixes, and one of those was closed on a verbal agreement before anything had actually changed, after which the cause turned up twice more. So of seven closures, exactly one removed a cause and kept it dead: a published cover rota with four weeks of figures behind it that survived two absences. Meanwhile the one item that would genuinely stop deals slipping has been open sixty-five days, because it needs someone to change the qualification standard work. That is the ordinary shape of a real log — the easy contained things close in days, and the one that would change the system sits past its date. Full worked example, on-screen and as a downloadable .xlsx: https://www.katafacts.com/katas/countermeasure-log ## Common mistakes - **Counting a workaround as a fix** — It is the main way improvement systems decay while reporting progress. Patching keeps the day moving and leaves the cause exactly where it was. If most of what you close is containment, you are absorbing problems rather than removing them, and the log should say so out loud. - **Closing on the decision rather than on the change** — A sign-off, a verbal agreement or a ticket being marked done are not the thing working. Close when you have seen the number move and stay moved. Everything else is a hope with a date on it, and it shows up later as the same cause reappearing. - **Never recording that a cause came back** — Without it the log cannot tell the difference between a team that fixed eight things and a team that fixed the same thing eight times. The recurrence date is the cheapest entry on the sheet and the one that makes every other number honest. - **No cap on open entries** — A queue without a limit does not go faster, it stops finishing. Items age, people stop trusting the list, and raising anything starts to feel pointless — which is how the board that feeds this log goes quiet. - **Writing the cause differently each time** — One cause split across three wordings is three small bars instead of one obvious one, and the thing actually hurting you stays invisible. Agree the wording once and reuse it exactly. - **An action with no predicted outcome** — Then the only question anyone can ask later is whether it was done. A predicted outcome lets it fail usefully, which is the difference between a task list and a set of experiments. - **Letting it become a list of everything** — This log is for causes worth removing. Fold in every agreed task and the handful of entries that would change the system get lost among the ones that just needed doing. ## What it connects to Upstream: - **Performance grid** (`performance-grid`) — Where the causes come from. The grid's Pareto says which reason keeps repeating; this log is what happens to it next, and whether that worked. - **Daily management huddle** (`daily-huddle`) — Where entries are opened, re-dated and closed out loud — and where a returning cause gets its date added. A log nobody reads at a huddle stops being true within a fortnight. - **Daily accountability sheet** (`daily-accountability-sheet`) — The lighter tool: who committed to what, by when, with no claim about causes. Use that when a commitment list is genuinely all you need; use this when you want to know whether the cause is gone. Downstream: - **A3 problem solving** (`a3`) — Where a cause goes when containment keeps holding and the permanent fix keeps not landing. A repeatedly contained cause is the clearest signal in this catalogue that a structured cycle is overdue. - **Pareto chart** (`pareto-chart`) — For ranking causes across a longer window than this log covers, or across several teams' logs at once. - **Go-see protocol** (`go-see-protocol`) — How the evidence for a closure actually gets gathered. A standard being followed by someone who was not part of the improvement is evidence; a task marked done is not. ## Where AI helps Judgement — stays with you: - Deciding honestly whether something is containment or a permanent fix - Setting a cap that matches what the team can absorb rather than what it hopes to do - Judging whether the evidence offered for a closure would convince someone who was not there - Deciding when a repeatedly contained cause has earned a structured problem-solving cycle Analysis — AI helps: - Reading the permanent share alongside the false closures, since a high share means nothing if those closures were not real - Spotting that the quick closures are all the easy ones while the entry that would change the system ages quietly past its date - Normalising cause wording so one cause stops appearing as three, which is what makes recurrence visible at all - Saying plainly when too little has closed to judge anything yet Drudgery — automated: - Working out which closures the cause outlived - Counting open against the cap, overdue entries, the oldest open age and closures with no evidence - Computing the median time to close and ranking the repeat causes with their cumulative share - Exporting the log to xlsx in the house format --- Countermeasure log is licensed [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/). Attribution: Katafacts (katafacts.com). ## Using this skill Apply this method as part of whatever broader task, instructions, or deliverable you're already working on -- it's a method to use, not a standalone conversation to start. There is no generation tool for this catalogue yet, so draft the artifact's actual content yourself, following the fields above, the same way a person filling this out by hand would. The canonical guide page and a downloadable worked example (.xlsx) are at https://www.katafacts.com/katas/countermeasure-log.