The one idea
A meeting exists to produce something that could not be produced by writing: a decision, an alignment, or a conversation with real back-and-forth.
If the output is "everyone now knows X", that was an email. If it is "we heard five status updates", that was a document. Meetings are the most expensive communication channel there is — multiply the length by the number of people — and they are the default only because nobody stops to ask.
So the question before every meeting is: what decision comes out of this? If you cannot answer, either find the answer or cancel.
Only meet when people need to talk to each other. Write it down afterwards.
Every meeting has a stated purpose, a decision to reach, the smallest useful group, and notes with owners and dates within a day.
A meeting is synchronous, so its cost scales with attendance and it blocks everyone's schedule. Use it only where the back-and-forth latency of writing would be worse than that cost.
Before: earn the hour
| Question | If the answer is no |
|---|---|
| What decision comes out of this? | Send a document instead |
| Who must be there to make that decision? | Cut the rest to optional |
| What must people read first? | Expect the first 20 minutes to be catch-up |
| How long does it genuinely need? | Do not book 60 minutes out of habit |
The agenda. Not topics — questions. "Reporting cut-over" tells nobody what to prepare. "Decide: 28 Oct or 4 Nov for the reporting cut-over" tells everyone exactly what to think about on the way in, and makes it obvious when you are done.
Subject: Thu 11:00, 30 min — decide reporting cut-over date
To decide: cut-over on 28 Oct or 4 Nov.
Pre-read (5 min, attached): vendor availability and the two risk profiles.
Needed: Rekha (decides), Sanjay (vendor constraints), me (release plan). Anyone else optional — I'll send notes.
The pre-read. Attach it and say how long it takes. "Five minutes" gets read; an unlabelled attachment does not. And say what you will do if it is not read: "I'll assume you've read it and start from the decision" is a legitimate thing to write, and it works.
The invitation itself. Making people optional is a kindness that costs you nothing and buys you enormous goodwill. Most people are in meetings they should not be in, and cannot say so.
During: contributing without dread
Not speaking in meetings is not a personality trait. It is almost always one of three fixable problems: you do not know when to enter, you are trying to formulate something perfect, or you think your point is too obvious.
Speak in the first ten minutes. Anything — a question, agreeing with someone and saying why. The longer you go silent, the higher the bar you set for yourself, until by minute forty you would need something brilliant to justify breaking the silence. Enter early and cheaply, and the rest is easy.
Have one prepared line. Read the agenda and decide before you walk in what you will say. One sentence. Then you are never scanning for an opening under pressure.
Use an entry phrase. "Can I add something on that?" "Quick question before we move on." "Building on what Sanjay said —". These are not filler; they are signals that stop other people talking, and in a group that is the actual mechanism by which turns are taken.
Asking a question without looking foolish
The question you are afraid to ask is being silently asked by two other people. This is not encouragement, it is nearly always literally true.
The trick is to make it a request for confirmation rather than an admission of ignorance. Both are honest. One is easier to say.
| Instead of | Say |
|---|---|
| "Sorry, what's DSO?" | "Can I check I've got DSO right — days sales outstanding?" |
| "I don't understand" | "Can you give me an example of what that looks like in practice?" |
| "What are we deciding?" | "Just so I'm clear — the decision today is X, is that right?" |
That last one is enormously valuable and almost nobody asks it. Half the time the room discovers it does not agree on what it is deciding.
Disagreeing in a meeting
Disagree with the idea, out loud, once, and then let it go. In public, keep it short — the full four-move version from the previous lesson is for private conversations and for things that genuinely need a decision now.
"I'd push back on that. If we go with the 28th, the vendor's engineer is on leave that week, so we'd have no support during the window. Is that a risk we're comfortable with?"
One objection, one reason, one question back. Not a speech. If it needs a speech, it needs a separate meeting, and saying that out loud — "this is bigger than the time we have; can we take it offline?" — makes you look senior, not evasive.
Taking notes while participating
You cannot transcribe and think at the same time. Do not try.
Capture only four things, in a running list:
- D — decisions
- A — actions, with a name and a date
- Q — open questions
- ? — anything you did not understand and must look up
That is it. Everything else is recoverable or worthless. If something is said that requires a decision and none is made, write it under Q and raise it before the meeting ends: "Before we close — we didn't decide the compliance question. Do we need to?"
Video call specifics
Things that are genuinely different on a call, and that people get wrong:
- There is a delay. Half a second is enough to make normal interruption impossible. Leave a beat after someone finishes. If you and someone else start together, one of you should stop immediately and say "go ahead" — the deadlock is the awkward part, not the collision.
- Nobody can see you nodding. In person, agreement is visible. On a call it is invisible, so say "agreed" and "makes sense" out loud. Silence reads as absence.
- Use the chat for things that do not need the floor. A link, a number, a correction, "+1 to Sanjay". This is the single most underused feature of video calls.
- Raise-hand exists and works. In both Meet and Teams. It is far better than waiting for a gap that never comes, and it is not childish.
- Mute by default in groups over four, and unmute before you start talking. Everyone has lost a sentence to this.
- Learn to share a window, not your whole screen. Google and Microsoft both document how; the difference is that your notifications, your inbox and your other tabs stay private.
- Camera on if others have theirs on, unless there is a reason. And if you need it off, say why once — "camera off, bad connection today" — so it is not read as disengagement.
After: the notes are the meeting
An unrecorded decision did not happen. In three weeks, four people will remember it four ways, and the loudest memory wins.
Send notes within a day. Short. Decisions and actions, not narrative.
Subject: Notes — reporting cut-over (decided: 28 Oct)
Decision: cut-over 28 October, 22:00–02:00. We accepted the vendor support gap because delaying to 4 Nov clashes with month-end close.
Actions
- Sanjay — confirm the window with the vendor — Fri 12 Sep
- Sana — update the release plan and tell QA — Mon 15 Sep
- Rekha — brief the regional leads — Wed 17 Sep
Open: whether old reports stay available 30 days. Rekha checking with compliance by 19 Sep.
Corrections welcome by tomorrow — otherwise I'll take this as agreed.
Note the small thing that does the most work: the decision includes the reason. In four months someone will ask why the 28th, and this line answers it without anyone having to remember.
Running a meeting that produces something
1 of 7Write the decision as a question before you book anything. "Decide: X or Y." If you cannot write it, cancel and send a document instead.
Try this
Your manager asks you to "set up a meeting to discuss the customer complaints issue". Write the invitation.
Your challenge
Level 3 · IndependentTake the next meeting you attend that you do not run. Without changing anything about how it is run, do these four things:
- Before it starts, write down what you think the decision is.
- Speak in the first ten minutes.
- Keep the D / A / Q / ? list.
- Within an hour of it ending, send the group your notes — decisions, actions with owners and dates, open questions. Frame it as "my notes, corrections welcome", not as a criticism of anyone.
You have succeeded when at least one person replies with a correction. That reply is the proof that the meeting's participants did not agree on what happened — which is the thing your notes just fixed.
Do this three times and you will be the person asked to take notes at everything. That sounds like a punishment. It is not: the person who writes the notes decides what the meeting decided, and that is quiet, real influence.
What people usually get wrong
- Booking a meeting to share information. That is a document. The meeting is for the conversation that follows the document.
- An agenda of topics rather than questions. "Budget" prepares nobody. "Decide: approve the ₹40L or defer to Q4" prepares everyone.
- Inviting everyone to be safe. Every extra person makes the discussion slower and the decision less likely. Optional is a real setting; use it.
- Sixty minutes by default. Most decisions need twenty-five. Work expands to fill whatever you booked.
- Ending with "great discussion". If no action was named, nothing will happen, and the next meeting starts from zero.
- Notes as narrative. "We discussed the pros and cons of both dates" is useless. "Decided 28 Oct because 4 Nov clashes with close" is not.
- Waiting for a gap to speak. In a group of six there is no gap. Use an entry phrase or raise your hand.
- Sending notes three days later. Memories have already diverged and yours no longer has authority.
How someone experienced does it
Experienced people do the meeting before the meeting. For anything genuinely contentious, they have already spoken to the two or three people who matter, one at a time, so the objections are known and the meeting is a confirmation rather than a discovery. This sounds political. It is mostly just kind — nobody enjoys being surprised in front of an audience, and people say more honest things one to one.
They also treat their own calendar as a budget. Declining a meeting with "I don't think I'm needed for this one — send me the notes and grab me if something comes up" is completely normal and almost never refused. Freshers believe every invitation is a summons. It is a request, and the person who sent it usually invited you out of caution.
The rarest skill is stopping a meeting that has stopped working. "We've been on this fifteen minutes and we're going in circles. Are we missing information, or is this a decision Rekha needs to make on her own?" Almost nobody says this, and it saves more time than any other sentence in this lesson.
When not to use this
Meet, rather than write, when:
- The topic is emotional or personal. Feedback, bad news, conflict, anything about someone's performance. Writing strips tone and the reader supplies the worst one available.
- You genuinely do not know the shape of the problem. Exploratory thinking works badly in writing because the useful move is the interruption.
- Trust is not established. A new client or a new team needs faces before they need efficiency.
And avoid meeting when the real reason is that you want to be seen, or that someone senior asked for one and nobody checked whether it was needed.
Why the quiet person in the meeting is often right
Groups converge fast. Once two or three people express a view, the cost of saying something different rises sharply — not because anyone punishes it, but because you now have to explain why everyone else is wrong rather than merely offering a thought.
Two practical consequences if you run meetings. Speak your own view last, if you have any authority in the room, because whatever you say first becomes the thing others are arguing against. And ask named quiet people direct questions, because a general "any concerns?" reliably returns silence — silence which everyone then reads as agreement.
If you are the quiet person: your discomfort with a plan usually contains real information, even before you can articulate why. "I can't put my finger on it, but I'm uneasy about the 28th — can I think about it and come back today?" is a completely legitimate contribution, and far better than saying nothing and being right in December.
Prove it
One set of notes from a real meeting, sent to the real participants within a day of it happening. Decisions with reasons, actions with owners and dates, open questions.
Then keep the reply that corrects you. Every correction is a place where the meeting thought it had agreed something and had not — and finding those is precisely what this skill is for.
Keep learning this
Paste this into any AI assistant. It turns the assistant into a tutor that tests you instead of just answering you.
Act as an experienced practitioner who is good at teaching. I have just learned running or contributing to a work meeting effectively. Assume I am intelligent but relatively new to this — treat me as intermediate level. Work through this in order, and wait for my reply at each step: 1. Ask me 5 questions that test whether I actually understood running or contributing to a work meeting effectively. Do not reveal the answers yet. 2. After I answer, tell me which parts I got right, which I got wrong, and which I only half-understand. Explain only what I misunderstood — do not re-teach what I already know. 3. Give me one practical challenge based on something I could genuinely encounter at work or in daily life. Do not solve it for me. 4. Evaluate my solution the way an experienced person would judge it, including what a professional would have done differently. 5. Tell me what to learn next, and why that comes next. 6. Give me trustworthy sources for deeper study — prefer official documentation, primary research or standards bodies over blogs and videos. Rules for you: no buzzwords. No motivational filler. Say "I'm not certain" when you are not certain, and tell me which parts of your answer I should verify myself. Clearly separate facts from your recommendations and your opinions.
Become independent at this
Use this when you want a path from where you are to actually good, with checkpoints you can test yourself against.
I want to become independently capable at making meetings produce decisions — not permanently dependent on AI, tutorials or step-by-step guides. Design a progression for me with five stages: Beginner, Guided practice, Independent practice, Real-world application, Professional level. For each stage tell me: - what I must know - what I must be able to do without help - the mistakes people make at this stage - one practical challenge - one real project that would prove I reached this stage - one way I can test myself honestly Then tell me the signals that I am ready to move to the next stage, and the signals that I have skipped ahead too early. Keep the theory to the minimum I actually need. Focus on ability I can transfer to situations you and I have not discussed.