When you are looking for a better Remote First culture, you are looking for better meetings. If you go for better meetings, you will also have fewer of them.
“The anthropologists got it wrong when they named our species Homo sapiens (‘wise man’). In any case it’s an arrogant and bigheaded thing to say, wisdom being one of our least evident features. In reality, we are Pan narrans, the storytelling chimpanzee.”
Going for a written culture helps, going for storytelling will help even more.
Almost 15 years ago, I wrote about an experience with the roleplaying game Primetime Adventures. If you are reading German, check it out .
One of the things to take away from Primetime Adventures is that “on screen” nothing happens without reason, all interactions serve the story. And the story is always about conflict: Anything from misunderstandings to misaligned goals, from disagreement about a mission to disagreement about fundamental values, from friendly competition to outright fighting over starved resources.
In the end it does not matter, but screen time is always about the current conflict, because to the Storytelling Chimpanzee this is what it’s about.
This is, at the core, also true about meetings. If they are not about conflict, they are not worth your time.
It does not have to be conflict about the people in the meeting. The meeting does not have to resolve the conflict (but should progress it somewhow). But in every meeting there is some kind of conflict in the background.
Remember: Not all conflict is drama, in fact, most is not.
So when you go for meetings, prepare an Agenda. If you are invited to a meeting without an Agenda, decline it.
What is a good Agenda?
- Make an agenda and make it self-contained.
- It should itemize the things you would like to talk about.
- Each item should have a short summary (“What happened so far”, “Last week on …”) or link to one.
- You should invite the people you need to talk to about the thing, the stakeholders.
Then send the agenda around well in advance, maybe share a link to a shared document. Allow people to change, amend, and comment the agenda. Force them to interact with the document in some way.
Your goal, ultimately, is to either not have a meeting, because all agree.
Or have a meeting, but only about the things you disagree about. Or people have questions about things, which can only be resolved interactively.
So invite people to actually comment. Invite long form, have them write in the text. Sidenotes are horrible to read, and basically are good for +1’s only.
Invite people to agree with you, in the document, or to specify where the disagreement is exactly. Disagreement can take many forms:
- It can be insecurity (“The plan looks good in principle, but I fear that…”).
- It can be misalignment (“You want to do …, but we actually need … on our side.”).
- It can be resource shortage (“You want … from us, but that would require us to …, and we can’t do that in this Quarter.”).
- It can be many other things. It always signals a need to communicate more, about a specific thing.
Use the Agenda and the Agenda Prep to collect agreement. If there is no disagreement, it’s fine to not have the meeting, because the reason to have one just vanished.
If there is disagreement, you now know where, and how, and what specifically is the perceived or real problem. You can spend interactive time exactly on these things, and go over possible reconciliations.
Since this is all in a shared document, y’all can amend the discussion with additional writing and sidenotes as needed. This is automatically also the meeting notes, so make sure they contain whatever the outcomes are y’all collectively agreed to.
Mark up deliverables, deadlines and people responsible. Set a deadline with a followup meeting (which you can then try to kill in advance, too).
One exception are kickoff meetings. They exist to present the project, and project goals, to set the framework and to make sure you are talking to the right people, and all the right people.
They exist also for socializing, specifically to enable people to make the necessary connections. You will be working together, you need to know each other.
So make it short, to the point, and make sure people can connect with each other directly afterwards, on their own. This is important, because kickoffs cannot be killed.
Finding conflict, isolating interesting topics to talk about, also applies to reporting meetings.
Reporting meetings always read a lot of slides with a lot of numbers. Everybody zones out. “Last weeks SLOs for … were met completely, and we improved …” Nobody is interested, skip that.
We all can look at the green in the report in advance. Instead use the reporting meeting to speak about interesting things.
This can be the story of an outage, and what we learned. It can be about the story of an improvement, and how it will prevent a certain class of failure. Or tell the story of how you work, how you improve work, or how you work differently than other companies do, if that is useful.
Sharing stories about practice is much more interesting that reading numbers from a slide that is all green anyway.
Or skip the meeting. If the numbers are all fine and there are no learnings, no interaction is needed.
In general, finding out, in advance, what the meeting should be about, always means finding the conflict, determining its nature, and the stakes. Uneven information, misaligned goals, differences about implementation or scope, resource allocation, whatever. Knowing this, maybe even preparing alternatives, and then either developing or discovering them interactively, or deciding on them collectively helps.
It also automatically prepares the meeting minutes:
The Agenda collects agreement, and preparing the meeting from the residual conflict in the Agenda then makes it simple to have minutes. We have shared documents in 2022, so there is an easy way to make sure all voices are recorded.
Shared documents are also a burden: They are hard to discover, maintain and organize. I am increasingly a supporter of the idea that Google Docs should auto-delete after 3 months.
If you want deliverables, put them elsewhere, anywhere. Heck, even Confluence would be a better location than a Google Drive. In any case, you can create a consolidated version of the current state in a proper document, and then collect or link the path that led to it and attach it as documentation.
You can’t take meeting notes and call them deliverables, though. That won’t work. It never did.
So a discussion with interactive and written elements, is also a documentation evolution process, in which we collectively work on a deliverable: the architecture, documentation and implementation of a process.
In a proper store, and not in shared documents, much less in volatile spoken discussion without any record or recording. We work to distill information, to shape an idea, and to bring it into the world, in a proper deliverable and in code.
Because that is what a company is about: Making agreements on how we work together on a common thing (and building infrastructure to make this easier).
And we have meeting agendas to collect agreement, and to sharpen disagreement, we have interactive meetings to find and ultimately document conflict resolutions, and we then put these back into the deliverable.
This is the heart of asynchronous distributed collaboration.
So if somebody asks you: “What did your org learn to do differently in the last 3 years?” and the answer is unlike the above:
What did you do instead? How did your org evolve?
This started out as a Twitter thread. There have been reactions.
- Florian Haas pointed to a really good writeup about writing of his.
- He also mentions: “Re project kickoffs, never do them without preparing a 5-paragraph brief. Better still, circulate it ahead of the kickoff.”