--- name: daily-huddle description: "The short standing meeting where a team reads its board, surfaces what stopped the work, and leaves with names against problems — plus the handful of numbers that tell you whether the huddle is still working or has quietly become a status meeting. Use when: A team with a board or grid it already marks, that needs the meeting that makes it worth marking. Work with enough repetition that the same kinds of problems recur — that is what makes a queue worth managing. Not for: As a status report to a manager. If the purpose is telling someone what happened rather than deciding what to do, it is a different meeting and it will drive out honest problems. For individual accountability. Nothing in this record should ever reach an appraisal — attendance is counted rather than named for exactly that reason. At a group size where speaking up is expensive. Above roughly fifteen, or with several layers of leadership present, people stop raising the things worth hearing." --- # Daily management huddle The short standing meeting where a team reads its board, surfaces what stopped the work, and leaves with names against problems — plus the handful of numbers that tell you whether the huddle is still working or has quietly become a status meeting. Family: Daily management · Format: .xlsx · Domain: core ## What it is A short, standing, same-time-every-period meeting where a team reads its own board, says out loud what went wrong, and leaves with a named person against each thing worth acting on. Ten to fifteen minutes is typical; the timebox is part of the design, because a meeting that can run long becomes a meeting people prepare for, and a meeting people prepare for stops producing honest problems. The board is not the practice. A grid nobody stands at is wallpaper, and most daily management dies at the huddle rather than on the wall. The single most useful idea in this kata is that a huddle is a queue. Making problems visible raises the rate at which problems arrive into an improvement queue. If the capacity to close them is not designed at the same time, the list grows, time-to-close stretches, the feedback that made raising feel worthwhile disappears, people stop raising things, the board goes quiet, and the quiet is read as success. That failure is self-confirming, and it is the ordinary way these systems die — not in an argument, but in a series of increasingly short, increasingly pleasant meetings. Everything in this kata exists to make that visible early: a cap on how many problems can be open at once, a promise about how fast someone responds, a three-way triage so not everything has to escalate, and a rolling record of what was raised and what was closed. Two consequences are worth stating plainly because they surprise people. More problems being raised is good news, not bad — a team that raises six things a day is not worse than one that raises none, it is safer. And the number of things raised must never become a target, in either direction: it is how you detect whether people still trust the process, and the moment it is managed it stops measuring anything. Influences, paraphrased rather than reproduced: the andon tradition of stopping the line and swarming the problem; Amy Edmondson on why better-led teams report more errors, not fewer; Little's law on why a queue without a limit does not go faster, it stops finishing; and the well-documented practice at Lantech, where a cap of five open problems protects the day's work rather than opening a sixth investigation. ## When to use it Use it when: - A team with a board or grid it already marks, that needs the meeting that makes it worth marking. - Work with enough repetition that the same kinds of problems recur — that is what makes a queue worth managing. - Someone in the room can act, or can reach the person who can, without writing a business case first. - You suspect your existing stand-up has become a status round and want to know whether it still surfaces anything. Not when: - As a status report to a manager. If the purpose is telling someone what happened rather than deciding what to do, it is a different meeting and it will drive out honest problems. - For individual accountability. Nothing in this record should ever reach an appraisal — attendance is counted rather than named for exactly that reason. - At a group size where speaking up is expensive. Above roughly fifteen, or with several layers of leadership present, people stop raising the things worth hearing. - In a system already running at full stretch. A huddle that surfaces problems nobody has capacity to close makes things worse, not better: stabilise first, then raise visibility. - For project coordination or task allocation. Those are real meetings, but they are not this one, and merging them turns the huddle into a to-do list review. ## How to fill it in - **setup** — Fix the boring things first, because they are what decay. Where — at the board, standing, not in a room with a screen. When — same time every period, and hold it when you are busy, because busy is when problems arrive. How long — a timebox you actually enforce, usually ten to fifteen minutes. How many — five to fifteen people; below five there is no team, above fifteen the cost of speaking up gets too high. Then the two limits that do most of the work: a cap on how many problems may be open at once, and a promise about how quickly someone responds to a raised item. Both are commitments about capacity, not aspirations, and both should be uncomfortable to set. - **agenda** — The same blocks, in the same order, every period, so nobody has to remember what happens next. A workable shape: read the board (name every red out loud before explaining any of them), reasons for the reds (one line of fact each, from whoever was closest to the work), triage (each item goes one of three ways — fix it now, watch it another period, or it needs a proper problem-solving cycle), yesterday's promises (anything due or overdue, closed or re-dated out loud with a reason), and a last call for anyone who needs help. Give each block minutes and add them up. The block teams skip is yesterday's promises, and skipping it is precisely how the list stops meaning anything. - **occurrences** — One line per huddle, written straight afterwards in about twenty seconds: the date, how many were there, how long it took, whether anyone actually read the board, and how many items were raised and closed. This line is what makes the health checks possible — a single huddle tells you nothing about whether the practice is alive, and by the time decay is obvious from inside the room it has usually been running for months. - **items** — What was seen, which measure it came from when it came from one, how it was triaged, and a named person. Never a department: an item with no named responder is a complaint rather than a request for help. When it closes, write what actually happened — not "done", but what changed and how you know. The three-way triage is the part that keeps this workable: without an explicit "watch", everything either escalates or gets quietly dropped, and a team that escalates everything drowns. - **health** — Computed for you, and it splits into two groups that often disagree. The meeting numbers — held against expected, average duration, overruns, group size, whether the board was read — say whether the ritual is intact. The queue numbers — raised against closed, how many are open against your cap, the age of the oldest open item, how many blew past your response promise, and the direction the raising is going — say whether it still does anything. When the meeting numbers look good and the queue numbers look bad, believe the queue numbers. Nothing to enter here. - **narrative** — Drafted from the record actually kept, and grounded only in what it computes. ## What good looks like The example below is a customer operations team, and it is deliberately one that looks healthy and is quietly dying. Eleven huddles held out of twelve, averaging under eleven minutes against a fifteen-minute timebox, one overrun, the group never outside its size band — on the meeting numbers alone, a well-run practice. The queue numbers say otherwise: thirty-four things raised, nine closed, and every one of those nine a same-day fix while nothing on the problem-solving pile has ever closed. The oldest open item is fifty-seven days old, all six open items are past the team's own two-day response promise, and six open against a cap of five means nothing new can start. Then read the raising column in date order — six, seven, five, six, four, three, and then one, one, zero, one, zero. That is not a quiet fortnight; it is the predictable result of raising twenty-five more problems than were ever closed. The dangerous part is how it reads from outside: attendance good, duration down, less being raised, nothing overdue being argued about. A manager glancing at it would call the problem solved. A worked example that was obviously broken would be dismissed; this one has to be read carefully to see what is wrong, which is the skill the kata is trying to build. Full worked example, on-screen and as a downloadable .xlsx: https://www.katafacts.com/katas/daily-huddle ## Common mistakes - **Treating fewer problems raised as an improvement** — It is the main way these systems fail, and it always looks like success. A team that raises six things a day is safer than one that raises none. Read the raising rate as a measure of whether people still trust the process, never as a performance number, and never set a target on it in either direction. - **No limit on how many problems can be open at once** — A queue without a cap does not go faster, it stops finishing. Work in progress divided by throughput is how long each item waits, so the cap is the only real lever on time-to-close. Without one the list grows until raising anything feels pointless. - **Counting a workaround as a closed problem** — Patching the symptom keeps the day moving and leaves the cause exactly where it was. A log that records workarounds as fixes is measuring its own decay while reporting progress, and it is why a team can close hundreds of items and face the same problems all year. - **Letting the huddle grow** — Group size is a design constraint, not a preference. A huddle containing several layers of leadership is one where the cost of raising a real problem exceeds the benefit, and people quite rationally stop. Split it and connect the parts rather than letting one meeting swell. - **Skipping it when things are busy** — Busy is when problems arrive. A huddle that gets dropped under pressure is one that has already stopped being how the team works and become something it does when there is time. - **Turning it into a status round** — Once each person reports what they did, the meeting has an audience instead of a purpose, and nobody volunteers a problem to an audience. Read the board, not the people. - **Raising visibility in a system with no slack** — If the team is already at full stretch, surfacing more problems adds a queue nobody can serve, and the result is worse than before because now the failure is documented. Stabilise the work first; the huddle is an amplifier, and amplifying an overloaded system just breaks it faster. - **A measurement system that punishes the practice** — It happens more often than it sounds: time spent in the huddle counted against the team's productivity, or improvement work that has to be justified against utilisation. Check what else your numbers reward before blaming the team for a huddle that will not stick. ## What it connects to Upstream: - **Performance grid** (`performance-grid`) — What the team stands in front of. The grid produces the reds; the huddle is where a red turns into a named person with a date. - **Leader standard work** (`leader-standard-work`) — What the leader does to make the huddle survive: being there, asking real questions, and following up on what they heard. A huddle delegated away signals it does not matter. Downstream: - **Tiered huddle board** (`tiered-huddle-board`) — What to do when an item is genuinely beyond this team: the route upward, what it takes with it, and what has to come back down. - **Escalation matrix** (`escalation-matrix`) — Who an unclosable item goes to, how fast, and what returns. Without this, a huddle either escalates nothing or escalates everything. - **Pareto chart** (`pareto-chart`) — Which of the things raised keep coming back. That, not volume or volume of complaint, is what earns the next problem-solving cycle. - **A3 problem solving** (`a3`) — Where an item triaged as needing a proper cycle actually goes. If nothing on that pile ever closes, the triage has become a way of filing things rather than working them. ## Where AI helps Judgement — stays with you: - Setting a cap on open problems that reflects the team's real capacity rather than its optimism - Deciding whether an item should be fixed now, watched, or worked properly - Judging whether the huddle has become a status round, which needs someone who was in the room - Deciding whether the system has enough slack to survive raising visibility at all Analysis — AI helps: - Reading the meeting numbers against the queue numbers and saying plainly when they disagree - Spotting that the raising rate is falling while the queue is not draining — the signature of a team that has stopped believing raising anything helps - Noticing that everything closing is a same-day fix while the harder pile never moves - Saying when there are too few huddles on record to claim a trend at all Drudgery — automated: - Totting up raised against closed, held against expected, and the age of the oldest open item - Counting overruns, out-of-band group sizes, and items past the response promise - Drafting a first standing agenda with timings that add up to the timebox - Exporting the record to xlsx in the house format --- Daily management huddle 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/daily-huddle.