The Weekly Huddle and the Ticket of the Week

Wednesday, 09:15, at Acme. Four technicians are standing by the whiteboard with coffee, and Jonas has ticket 6183 on the screen. The finance scanner would scan to the shared folder from every workstation except one. It had been doing this, on and off, for a month. He walks through it in order. He starts with what the requester said, what he checked first, and the two things that did not help. Then comes the line in the scanner's log that finally pointed at a certificate the one workstation did not trust. And the three-minute fix once he knew. Ines says, "I had one like that in the spring and swapped the scanner." Priya says, "There is a second one of those workstations in payroll." Fourteen minutes later everyone sits down knowing something they did not know at 09:14. There is a new known error on the list with Ines's spring ticket linked to it. Payroll's scanner has a ticket before payroll knows it has a problem. The queue did not notice the desk was gone.

The alternative, which most desks run instead, is a weekly meeting of forty-five minutes. Each person says what they are working on and everyone else waits for their turn. It is not a bad meeting. It is a meeting about the queue, and the queue is already on the screen. Nobody at a status meeting has ever learned how to fix a scanner.

The huddle is fifteen minutes, standing, once a week at a fixed time. The desk hears one solved ticket in enough detail to solve the next one like it. The desk glances at the known-error list and names next week's presenter. The ticket of the week is that one ticket: not the biggest or the most dramatic, but the one that taught the person who solved it something. This article is part of our Team Knowledge Sharing series. The huddle is the spoken half of it, the one rhythm where knowledge moves by someone saying it out loud. The writing-down follows the same afternoon.

It starts with why fifteen minutes and why standing. Then comes the ticket of the week, how to walk through it and how to choose it. Next are the known-error review, the rotating presenter, and what the huddle is not. Then it covers running it in a bad week and remotely, and what has to come out of it. A short war story and the huddle agenda to copy finish the article.

Why Fifteen Minutes, Standing

The shape is the constraint, and the constraint is the point. Fifteen minutes is below the length at which the queue objects, which means the huddle can happen every week including the bad ones. A thing that happens every week beats a better thing that happens when there is time. Standing stops it drifting, because people who are standing finish; people who are sitting with a coffee and a comfortable chair discover a second topic. Same day, same time, same spot, so nobody has to decide whether to hold it. The decision was made once, and the calendar makes it again every Wednesday.

The huddle is the only recurring meeting a small desk needs, and I would defend that against most organisation charts. The queue is the status meeting; it shows who holds what, and reading it takes less time than hearing it. The weekly queue hygiene is a routine, not a meeting. The monthly numbers go to a manager on a page. What none of those does is move what one technician learned on Tuesday into the heads of the other three, and that is the one job the huddle has. Do not give it a second job. The second job is how fifteen minutes becomes forty.

Do not sit down. Not for the interesting one, not because the room has chairs, not because it is only four of you. The first week the desk sits, the huddle runs twenty-five minutes and everyone agrees it was useful. The fourth week it is a meeting, with the agenda item "any other business". And "any other business" is where meetings go to grow. Stand, finish, and if the ticket of the week genuinely needs forty minutes, book forty minutes for the two people who need them, after the huddle, sitting down.

The Ticket of the Week

The presenter walks the path, not the answer, because the answer is in the ticket's note and the path is what teaches. The format is fixed and takes five to seven minutes. Start with what the requester said, in their words, and what the presenter checked first and why. Then comes what did not help, including the wrong turns, because the wrong turns are where the rest of the desk would also have gone. Next come the clue, the exact line or symptom that changed the diagnosis, and the fix. Finish with the one thing the presenter would do first if the same ticket arrived tomorrow. That last line is the whole value compressed into a sentence, and it is the line that goes into the knowledge base that afternoon.

Walk through the ticket itself, on the screen, rather than from memory, and the walk-through is honest. The ticket's history shows when the first reply went out and when the ticket was reassigned. It shows how long the wrong turn actually took and what the note said at each step. The presenter reads it rather than reconstructs it. If you run QuerySolv, the complete event history on the ticket is already the timeline, so the presenter scrolls it and talks. In any tool, bring the ticket up rather than a summary of it. Memory smooths the path into something cleverer than it was. The ticket remembers the forty minutes spent on the wrong workstation, and the forty minutes is what the desk needs to hear about.

Questions are allowed and short, and the right ones are the ones that make the ticket general. "What did the log say exactly?" "Would that happen on the other site?" "Is that the same as the one Ines had in the spring?" The third kind of question is the most valuable thing a huddle produces. It is the moment two tickets that were solved separately turn out to be one problem. One problem with two tickets is a known-error candidate. The lead's job during the ticket of the week is to ask that question when nobody else does, and otherwise to be quiet.

Include the mistake. A presenter who shows only the clean path has told the desk what the answer was, which the note already does. A presenter who says "I spent forty minutes on the workstation's network settings because the symptom looked like a network problem, and it was never the network" has told the desk where not to spend forty minutes, which no note ever does. The huddle has to be a place where saying "I went the wrong way for most of an hour" costs nothing and earns a nod. The first time the lead presents their own wrong turn, that becomes the culture. It does not become the culture any other way.

Choosing It Without a Committee

The ticket of the week is nominated by whoever solved something that surprised them, which is the whole selection process most weeks. "I did one on Thursday that I want to show" is the nomination, and it arrives in the team chat or on the whiteboard any time before Wednesday. Surprise is the right test, because a ticket that surprised an experienced technician will surprise the rest of the desk. A ticket that surprised the newest technician is one the rest of the desk has forgotten was ever surprising, which is its own kind of useful. Both get presented. Neither needs approving.

When nobody nominates, the lead picks, and picks by the numbers rather than by instinct. The ticket with the most reassignments that week is a ticket that three people could not solve and one could, which is the definition of knowledge that has not spread. The ticket with the longest time to fix is a ticket with a long path, and long paths teach. The ticket that was reopened is a candidate too, handled with care. A reopen presented as "here is what the requester saw that we did not" is a lesson. Presented as "here is who closed it too early", it is a punishment. The second kind empties the room of volunteers for a year. The reopen as a coaching conversation, with its minimum sample before anyone reads a number, belongs to Feedback and the Ticket Review. The huddle borrows only the lesson.

Do not choose the biggest ticket by default. The outage that took the whole desk a day is a tempting ticket of the week and usually a poor one. Everyone was there, everyone already knows the path, and it has an incident review of its own. The best tickets of the week are small, odd, and solved by one person on a Tuesday afternoon when nobody else was looking. Those are the ones that otherwise stay in one head.

The Known-Error Review

Three minutes, with the list on the screen, three questions per item, and no discussion of cause. A known error is a recurring symptom the desk can recognise on sight and get round with a tested workaround while the permanent fix waits. The list of them is the desk's memory of what keeps happening. For each one the huddle asks: how many tickets linked to it this week, is the workaround still working, and is there news on the fix. A known error with no tickets for a month is a candidate to retire. One whose workaround failed on Monday is flagged and its owner takes it away. One with news gets the news in one sentence. Three minutes, and the list is current for another week.

The huddle looks at the list; it does not manage it. The owner of each known error, the recognition test, the workaround and the business case for the fix are all the business of Known Errors and Workarounds. The deeper weekly hour where repeats are hunted and fixes chased is Problem Management in an Hour a Week. The huddle's job is smaller and more frequent: to make sure every technician has seen the current list in the last seven days. That way, when the symptom arrives on Thursday it is recognised rather than rediscovered. A list nobody has looked at since it was written is a list of things the desk used to know.

The ticket of the week feeds the list directly, and that is the connection to watch for. When Ines says "I had one like that", the lead writes "scanner certificate: Jonas 6183, Ines spring ticket" on the board. By the afternoon there is a known-error record with two tickets linked and a recognition test taken from Jonas's walk-through. The huddle is where the desk notices a pattern. The record is where the pattern is kept. Without the huddle the two tickets stay two tickets for ever, solved twice, forgotten twice.

The Rotating Presenter

The presenter rotates, and the rotation is written down, because a huddle where the same two senior people present every week is a lecture series. Next week's presenter is named in the last minute of this week's huddle, in order round the desk, with the rule that anyone may swap but nobody may skip. The newest technician presents in their second month, with a ticket they solved alone. It is the single most useful thing that happens in their first quarter. To walk the path aloud they must understand it, and the preparation does more than the presentation. This is the teach-back from Cross-Training Rhythms That Survive a Busy Month in its natural home. A learner who has just reached "alone" on a system should present their first solo ticket on it here.

The rotation is also how the hero's knowledge leaves the hero's head one ticket at a time. The senior technician who holds the desk together is, under the rotation, presenting every fourth or fifth week. Each presentation is five minutes of what they know moving into four other heads, with a note written the same afternoon. In a year that is ten or eleven tickets, with their paths, from the one person who never had time to write a runbook. It is not a substitute for the runbook. It is how the runbook gets its first draft without the hero noticing they are writing one.

The lead does not present, except to show a wrong turn, and does not run the huddle beyond keeping the time and asking the general question. A huddle run by the lead becomes a briefing, and a briefing is a status meeting with one speaker. The presenter runs it. The lead stands at the back, watches the clock, and at fourteen minutes says "who's next week?" (Then stops talking, which is the hard part.)

What the Huddle Is Not

The huddle is not a status meeting, and the test is simple: if anyone says what they are working on, it has become one. The queue already shows who holds what. A round of "I've got the printer thing and two access requests" tells the desk nothing it could not read in less time. It uses up the minutes that were meant for the scanner. The urge is strong, because status rounds feel like coordination, and coordination feels like management. They are the feeling of work without the work. Fifteen minutes of status is how a desk arrives at Friday knowing exactly what everyone was doing and nothing about how any of it was done.

It is not the backlog review, the planning meeting, the performance review, or the place to complain about requesters. Each of those has somewhere else to live, and each will try to move in. The table shows what each impostor looks like when it arrives, so it can be recognised and sent home.

The one question that decides whether a huddle was a huddle is "did anyone learn how to fix something?" If the answer is yes, it worked, however awkward the presenter was. If the answer is no, something else was held in its slot, and next week the slot goes back to the scanner. A desk that asks that question out loud at the end, once or twice, finds that the impostors stop arriving.

Running It in a Bad Week, and Remotely

The bad-week rule is the same as for every rhythm in this series: the huddle moves within the week and never out of it. In a truly bad week it shrinks to the ticket alone, five minutes, no known-error review, standing by whoever's desk is nearest. A five-minute huddle on a bad Wednesday keeps the habit. A cancelled one teaches the desk that the huddle is the first thing to go. The desk learns that lesson permanently after about three repetitions. The only thing that cancels a huddle outright is a live major incident. That huddle happens on Thursday with the incident as the ticket of the week, which is the one time the biggest ticket is also the right one.

Remotely, the standing rule becomes the no-other-windows rule, and it is harder to keep. Cameras on, the presenter sharing the ticket itself rather than slides about it, and the rest of the desk with the queue closed for fifteen minutes. That is the remote equivalent of not sitting down. A remote huddle where three people are also triaging is a recording nobody is watching. Keep it to fifteen, keep it to the ticket, and ask the general question yourself. The side comments that produce "I had one like that" in a room do not happen on a call unless someone invites them.

What Has to Come Out of It

Every huddle produces at least one written line, that afternoon, or it was a conversation. The presenter writes the ticket of the week up as a short knowledge base article, or promotes their note into one. The "what I would do first next time" line goes at the top. That is the capture habit from the knowledge series, done once a week by whoever presented. The known-error list gets its three answers per item recorded. Any "I had one like that" becomes a link between tickets and a known-error candidate with an owner. Any cross-training outcome the presentation revealed, the thing the presenter clearly knows and nobody else does, goes on the next half hour's calendar. How the written forms fit together and which to write first is in Documentation as the Sharing Medium. The huddle only has to make sure that the writing happens the same day, while the path is still warm.

Keep a huddle log of one line per week: date, presenter, ticket, what was learned, what was written. It takes a minute and it is the proof, at the quarter's end, that knowledge moved. Fifty-two lines, fifty-two tickets whose paths are now in several heads and one knowledge base instead of one head and no base. The log is also how a new technician catches up, by reading a year of tickets of the week in an hour. That is the cheapest induction a desk can offer and the only one that is already written.

A Short War Story: The Forty-Five Minute Meeting at Ashgrove Housing

Ashgrove Housing's five-person desk met every Monday for forty-five minutes, going round the table. Each technician said what they had open and what they expected to close. The meeting was well attended and generally agreed to be useful. Over two months, three of the five technicians separately solved the same tenant-portal sign-in failure. A tenant's account worked on the website and failed in the app because of a stale token the app cached. Each technician spent between one and two hours finding the cause, resetting the token, and writing "fixed, token reset" in the note. None of them mentioned it on a Monday, because the Monday meeting was about what was open, not what had been learned. The fourth occurrence landed with the fourth technician, Marta. She spent most of an afternoon on it before asking aloud whether anyone had seen it. Three people said yes at once. The review counted roughly six hours of rediscovery across four technicians and four tenants locked out of the app for a day each. It also counted two months during which a known error with a two-minute workaround had been an unknown error with a ninety-minute one. The desk replaced the Monday meeting with a fifteen-minute huddle, and the first ticket of the week was Marta's. A meeting where everyone says what they are doing is a meeting where nobody says what they learned.

The Huddle Agenda

The agenda below is the whole huddle on one page, with the minutes marked. It includes the walk-through format for the presenter, the three questions for each known error, and the log line to fill in afterwards. Print it once and pin it where the huddle stands. The presenter brings the ticket, not a summary of it, and the lead brings the known-error list and a pen.

THE WEEKLY HUDDLE — FIFTEEN MINUTES, STANDING
Day and time: ______________   Where: ______________   Lead keeps time

MINUTES 0-1   OPEN
  Presenter this week: ________   Ticket number: ________

MINUTES 1-8   TICKET OF THE WEEK (presenter, ticket on the screen)
  What the requester said, in their words:
  What I checked first, and why:
  What did not help, and how long it took:
  The clue that changed the diagnosis:
  The fix:
  What I would do first if it arrived tomorrow:
  Questions: "What did the log say?"  "Would it happen on the other site?"
             "Is it the same as one somebody else has had?"

MINUTES 8-11  KNOWN-ERROR REVIEW (lead, list on the screen)
  For each known error:
    Tickets linked this week: ___   Workaround still works? [ ] yes [ ] no
    News on the fix: ____________   Action: [ ] none [ ] retire [ ] flag to owner

MINUTES 11-14 PATTERNS AND HANDOFFS
  "I had one like that": tickets ________ and ________  -> candidate known error, owner ________
  Knowledge revealed that only the presenter holds: ____________ -> half hour on ________

MINUTE 14-15  CLOSE
  Next week's presenter: ________   (swap allowed, skip not)
  Written the same afternoon by the presenter: [ ] article or promoted note
                                               [ ] known-error list updated

HUDDLE LOG (one line per week)
  Date ______  Presenter ______  Ticket ______  Learned: ____________  Written: ________

NOT ON THIS AGENDA: what anyone is working on, the oldest tickets, projects, who
closed what, anything about a requester who is not in the room.

Frequently Asked Questions