--- name: tiered-huddle-board description: "A cascading structure of standing huddles — what each tier reviews, and the concrete condition that escalates something to the tier above — honestly flagging any tier nobody's actually named to run yet. Use when: Issues genuinely need to move from the floor to leadership on a real cadence, and you want a checkable escalation condition instead of an ad hoc judgment call each time. You want to catch a tier with nobody actually running it before it matters, not after a real issue sits unescalated. You want each tier to add something the tier below it doesn't already show — trends and exceptions, not the same numbers copied upward. Not for: There's genuinely only one level of review — a two-tier minimum is enforced because a single tier isn't tiered; if that's really all you have, a KPI tree or an escalation matrix fits better. You don't have real people to name as owners yet — that's fine, the board will honestly show the gap; don't invent a name to make it look complete." --- # Tiered huddle board A cascading structure of standing huddles — what each tier reviews, and the concrete condition that escalates something to the tier above — honestly flagging any tier nobody's actually named to run yet. Family: Daily management · Format: .xlsx · Domain: core ## What it is A tiered huddle board answers, for each level of a standing-meeting cascade, three questions: what does this tier actually review, who runs it, and what concrete condition sends something up to the tier above? Describe each tier — its name, cadence, attendees, and what it watches — and a real ladder gets drafted: each tier above reviewing patterns surfaced from the tier below it, never the same content just repeated at a bigger scale. Who specifically runs each huddle is never guessed — every tier starts unassigned until you name a real person. ## When to use it Use it when: - Issues genuinely need to move from the floor to leadership on a real cadence, and you want a checkable escalation condition instead of an ad hoc judgment call each time. - You want to catch a tier with nobody actually running it before it matters, not after a real issue sits unescalated. - You want each tier to add something the tier below it doesn't already show — trends and exceptions, not the same numbers copied upward. Not when: - There's genuinely only one level of review — a two-tier minimum is enforced because a single tier isn't tiered; if that's really all you have, a KPI tree or an escalation matrix fits better. - You don't have real people to name as owners yet — that's fine, the board will honestly show the gap; don't invent a name to make it look complete. ## How to fill it in - **tiers** — Drafted from each tier's name, cadence, attendees, and a rough note on what it watches — assign a real, named owner to each tier afterward. - **narrative** — Drafted from the ladder actually built. ## What good looks like The example below is a warehouse fulfillment operation's own three-tier cascade — a pick/pack huddle twice a shift, an ops huddle once a day, and site leadership three times a week. Two of three tiers have a named owner; the middle tier is honestly left unassigned rather than padded with a placeholder name. Full worked example, on-screen and as a downloadable .xlsx: https://www.katafacts.com/katas/tiered-huddle-board ## Common mistakes - **Every tier reviewing the same content, just at a bigger meeting.** — The entire value of tiering is that each level up sees patterns and exceptions the tier below surfaced — if the content doesn't change, the extra meeting is pure overhead with no leverage. - **Writing an escalation condition like 'if it's taking too long' or 'when it becomes a problem.'** — An unchecked condition can't actually be checked — a real ladder needs a concrete trigger, or nobody can tell when something should have moved up and didn't. - **Naming a placeholder owner just to make every tier look assigned.** — A tier with a fake owner is worse than an honestly unassigned one — it hides exactly the gap the coverage check exists to surface. ## What it connects to Upstream: - **Escalation matrix** (`escalation-matrix`) — A tier's escalation condition often traces to the same severity/trigger thinking an escalation matrix already made explicit for a specific process. - **Key performance indicator (KPI) tree** (`kpi-tree`) — What a given tier reviews is frequently a subset of an existing KPI tree's driver metrics, scoped to that tier's altitude. ## Where AI helps Judgement — stays with you: - Deciding who's actually the right owner to run a given tier's huddle - Deciding whether a drafted escalation condition is realistic given how the organisation actually works Analysis — AI helps: - Drafting each tier's review categories and a concrete escalation condition from a rough description of what it watches - Drafting the narrative from the ladder actually built Drudgery — automated: - Counting how many tiers have a named owner - Identifying which tiers are still unassigned - Exporting to xlsx in the house format --- Tiered huddle board 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/tiered-huddle-board.