Why an agenda, if everyone knows the topic
A topic and an agenda are different things. The topic answers “what about”; the agenda answers “what we must come away with”. A meeting without the second answer ends with “well, we talked it through” and a new meeting in the calendar.
An agenda does three jobs. It filters out the wrong people: seeing the items, someone realises there's nothing there for them, and that saves them an hour. It sets a boundary: when an adjacent topic surfaces, there's something to point at to bring the conversation back. And it forces preparation — not of the participants, but of the author: if you can't write the agenda in five minutes, the meeting probably isn't needed.
If every item could be closed with a message in a channel, send the message. A meeting earns its place where positions have to collide, where a decision is needed despite disagreement, or where the thing under discussion would fork into ten threads in writing.
The shape of an agenda item
An agenda item isn't a topic — it's a question with an expected outcome. Good wording answers: what we're discussing, what has to come out of it, how long it takes.
1. Budget
2. Timelines
3. Any other business
1. Approve the phase-two estimate — decision, 15 min
2. Pick a release date from two options — decision, 10 min
3. Integration risks — information, 5 min
“Budget” doesn't say what to do with it: approve, discuss, or hear a status. People arrive with different expectations and spend the first ten minutes working out why they're there. In the second version every item has a verb (“approve”, “pick”), a type of outcome and a duration — and it's visible at a glance that the third item needs no decision, so nobody should get stuck on it.
Three types of outcome
- Decision. A choice has to be made between options. Requires someone in the room with the authority to make it — otherwise the item is doomed.
- Information. Everyone needs to learn the same thing at the same time. The likeliest candidate for replacement by a message.
- Working through. Something nobody understands in full has to be understood together. The only type that transfers badly to writing.
Six formats for different calls
The skeleton depends on the type of meeting: a status call and an incident review have different logics of time. Pick a format and take the agenda.
The goal is synchronisation, not discussion. The main risk is that it swells into an hour of planning. Hold the timing hard and push anything contested into a separate meeting.
# Status: [area], [date] 1. Closed since last time — information, 5 min 2. In progress and where it's stuck — information, 8 min 3. What's blocking and whose help is needed — decision, 5 min 4. What moves to a separate meeting — decision, 2 min Not discussed here: how to solve the task. Only the fact of the block and its owner.
The goal is a plan everyone agrees with. The commonest error is starting from tasks rather than constraints. Fix the frame first, then fill it.
# Planning: [period], [date] 1. Constraints: time, people, budget — information, 10 min 2. What must be in, and why — decision, 15 min 3. What doesn't make it, and what happens to it — decision, 15 min 4. Risks and the points where the plan breaks — working through, 15 min 5. Owner for each block — decision, 5 min Before the meeting: the candidate list has been circulated.
The goal is to change the process, not to vent. A retro without “what we change and who owns it” turns into a ritual: the same complaints recur every time.
# Retro: [iteration], [date] 1. Checking what we changed last retro — information, 5 min 2. What worked, and why — information, 10 min 3. What got in the way: facts, not judgements of people — working through, 15 min 4. What we change in the process — decision, 10 min 5. One experiment before the next retro: who, what, success criterion — decision, 5 min Rule: no more than one process change per iteration. Otherwise you can't tell which one worked.
The goal is comparable data on a candidate. A free-form conversation is more pleasant, but two candidates assessed that way cannot be compared with each other.
# Interview: [role], [candidate], [date] 1. Context: the role and how the work is set up — information, 5 min 2. Walk through a real case from the candidate's experience — working through, 20 min 3. A practical task matching the role — working through, 20 min 4. Candidate's questions — information, 10 min 5. Next step and when we respond — decision, 5 min The same blocks for every candidate for the role — otherwise the comparison turns into an argument about impressions.
The goal is to find out whether there's a problem you solve, and who on the client's side can say yes. Demoing the product before that is a waste of both sides' time.
# Meeting: [company], [date] 1. How the process works today — information, 10 min 2. Where it breaks and what that costs — working through, 10 min 3. What they've already tried and why it didn't fit — information, 5 min 4. What a solution looks like from their side — working through, 10 min 5. Who's involved in the decision and the next step — decision, 5 min Demo the product only after item 2, and only the part that addresses the breakage they named.
The goal is to reconstruct the sequence of events and find the cause in the process, not the person. The moment the conversation turns to blame, facts stop surfacing.
# Incident review: [what happened], [date] 1. Timeline by the minute: what, and when — information, 15 min 2. What we saw and when we understood it — working through, 10 min 3. Why we didn't notice sooner — working through, 10 min 4. What fixes the cause rather than the symptom — decision, 10 min 5. Owners and dates — decision, 5 min Replace wording about people (“didn't check”) with wording about the process (“there was no check at this step”).
Timing: why the total is always more
A working rule: the items should add up to roughly 80% of the meeting. The rest goes on getting into context at the start and pinning down agreements at the end — those fifteen minutes exist whether or not you planned them.
If the items don't fit, the extra one shouldn't be compressed but moved out. A compressed item still takes its time; it simply eats the next one — and what you end up discussing is not what mattered most, but whatever came earlier in the list.
Agenda checklist
What to do about “any other business”
“Any other business” at the end of an agenda is where everything nobody dared schedule separately collects. It almost always eats more time than allowed for, because what ends up there are the most contested questions: they weren't put on the plan precisely because there's no agreement on them.
The working replacement is a running list of topics that surfaced but aren't on the agenda. At the end you go down it in one pass — each topic gets an owner and lands either in the next agenda or in writing. Discussing it on the spot means letting the accidental displace the planned.
Whisperer helps from the other end: it compares the transcript against the agenda and shows which items were never closed and where time went over. That doesn't replace preparation, but it quickly cures the habit of listing things you never get to.