Daily management huddle

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.

Where, when, how long, how many — and the two limits

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.

The standing 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.

The rolling record — one line per huddle

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.

What was raised, who has it, what happened

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.

Is the huddle still working? (computed)

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.

What the record says

Drafted from the record actually kept, and grounded only in what it computes.

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.

• 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.