Meetings are toxic, that's one of my favorite articles. So true. I refer this article to a lot of people when I want to reduce the amount of meetings that we have. Don't get me wrong, it's good to meet every once in awhile, but only when it's every-once-in-a-while.
Over the years, I have met many teams that tend to discuss everything in meetings. Rarely do these meetings have an agenda and, even rarer still, does everyone comes with enough insight to get straight to the point. In web development, topics like "Discuss the current deployment process" or "Discuss testing strategies" are black holes that will gulp your team's precious time unless there is asynchronous research and collaboration beforehand.
Don't meet. Write and collaborate.
When I need to discuss something, and I want to avoid a meeting, I write my thoughts in a document, share it with the team, and discuss it via suggestions, edits, and comments.
Here's an example: I wanted to propose changing the way that some code was submitting video files to a transcoding platform but, before creating a ticket, I wanted to discuss the implementation with my colleagues Andrew and Dave. Instead of scheduling a meeting or pinging them via Slack, I wrote the following document in Dropbox Paper:
Next, I invited Andrew and Dave to review it. They made changes to it and left some comments with questions, which led to a discussion:
Once there were no further edits to do and we resolved all comment threads, the meeting was done. But wait, there was no meeting! That is the great thing about this process: not only did the three of us agree on how to implement that change in the code, but we also took our time to think, research, and discuss. Plus now we have written proof that we can reuse for the next step, which in this case meant creating a ticket to work on the solution that we agreed upon.
If we look at the document's change history, we can see a chronology that ends with me creating a ticket at the top:
Silently introducing this process within your team
The best thing about this process is that you don't need to force it. Instead, you can just do it the next time that you want to discuss something. Write down what you would like to discuss with the rest of the team and invite them to collaborate. If you persist with this process for a few weeks, you will end up attending less meetings and getting much more work done. If the team does not come to an agreement while collaborating in a document, then a meeting may help to wrap up what is left, but make it a short meeting, and only after you've gone through this process!
If the team likes the process (this is a cultural change, some will, others won’t), then you could use the following template to describe it:
- Someone from the team writes the goal, the scenario, and then either proposes a solution or brainstorms ideas. I use Dropbox Paper or Google Docs.
- This person then invites the rest of the team to collaborate.
- The team reviews the document, which evolves with edits here and there, reverts, comments, further research, new ideas, etc.
- Once all comment threads have been resolved and there are no further edits, the document is complete. The next step would depend on the original goal.
Give it a go next time and let me know how it goes!
Hero photo by Startup Stock Photos.