Working with people
Meetings and demos
Open with the purpose, show the user path, and leave with a decision, an owner and a date.
Verbal communication fails the same way writing fails: burying the point, drowning people in slides and treating the meeting as a story instead of a decision forum. A good meeting has a purpose in the invite, a time-boxed opener and a closing sentence people can search for later.
Concept
BLUF still applies out loud. The first minute answers why you are in the room. See bottom line up front.
The big idea
A meeting is expensive shared time. Spend it on the thing that will not move in a doc: a live disagreement, a demo of a path, a decision with a face on it. Everything else can be a pre-read.
The analogy is a courtroom, not a campfire. You are not telling the history of the case; you are asking for a verdict. The analogy breaks for true workshops, where the point is to think together — and even those need an agenda and an output.
Walking through it
Before. Send a pre-read when the topic is non-trivial: the decision request, the demo script, or the three options. People who read it ask better questions. People who do not still have the BLUF in the invite.
Open with the purpose. "We're here to pick a migration strategy; I'll take 5 minutes, then we decide." Time-box yourself. If you need feedback, say what kind: "challenge the approach" vs "rubber-stamp so we can start Monday."
Demos. Show the user path, not the architecture diagram first. State what works and what does not ("happy path works; error states are stubs"). Have a backup: recorded video, screenshots, or a staging URL. Live demos fail; plan for it.
Slides. One idea per slide. Prefer a diagram or a table over paragraphs. You are the narrative; slides are anchors. If someone can understand the deck without you, the meeting might have been a doc.
During discussion. Take notes on decisions, owners and dates in the shared doc in the meeting. End by restating: "Decided X; Y owns it by Friday; we revisit if load test fails." That sentence is the artifact people will search for later.
This is how project execution stays coherent across time zones: the meeting produces a written decision, not a vibe that someone was "aligned."
Common mistakes
- Meeting as workshop with no agenda. An hour of talk and no owner.
- Architecture first in a demo. Stakeholders came to see the user path.
- Decision amnesia. You chose X; it lived only in the room. Write it before people stand up.
Check yourself
- What should the last sentence of a decision meeting contain?
The decision, the owner, the date and the revisit trigger.
- Your live demo breaks. What did you prepare?
A recording, screenshots or a staging URL — and a one-line statement of what works and what does not.
Key takeaways
- Invite and opener state the purpose and the decision you need.
- Demos show the user path and have a backup.
- Close with a written decision, owner and date.
Further learning
Back to the map: written and verbal communication.
Related
Written and verbal communication
Lead with the point, write for skimmers, and adjust depth for engineers, PMs and executives.
Bottom line up front
Put the decision, ask or outcome in the first sentence. Context comes after.
Driving projects to launch
Kickoffs, status, dependencies, unblocking, launch checklists, and a finish decision-makers recognize as shipped.