Helpful tools for technical teams to collaborate without meetings
The first week of March was Expel’s quarterly Week Without Meetings (or WWOM — you can read about it here). It’s an experiment we ran in 2020 that’s become a quarterly event we all look forward to. We ask everyone to cancel every internal meeting possible and encourage our team to use these weeks to work on projects they’ve had to put to the side, do something for their professional development, and take time to focus on their well-being.
The goal: be more intentional about the meetings we do schedule afterwards. Does that conversation really need a meeting? Or can we connect asynchronously over Slack or work together in a Google doc?
As CTO, I find these weeks incredibly valuable. Even if I still have a few important conversations scheduled during my WWOM, removing all of our recurring meetings is a huge reprieve and allows for deep thought work time, catching up with other humans (yay), and a general change of pace.
This past WWOM, as my team carried on working together without jumping on Zoom, I reflected on the tools and tricks we now use to reduce the burden of meetings on an ongoing basis while still communicating and collaborating across our team and org. Hopefully there’s something here that can help with your team’s “meeting mojo,” as we like to call it, and create more time and space for your people and the work that excites them.
Disclaimer: While Expel is a customer of several of the vendors I’ll list here, we’re in no way sponsored or being asked to write about them. These are genuinely tools I’d want to use wherever I’m working.
Asynchronous feedback and collaboration
One of the challenges with meetings, besides scheduling, is the imposition of asking people to bring their A game at a time you choose, or at a time that fits into most people’s schedules. This is especially important when you’re seeking collaboration — whether discussing feedback or brainstorming. I find those two types of asks carry a heavy cognitive load.
If you’re a morning person like me, your preference is likely to do that kind of work in the AM. If you aren’t like me, you may prefer the late afternoon, which is when I’m desperately in need of another coffee. Either way, the timing of specific types of meetings can have an impact on the capabilities people bring to the table. I’ve found that offering asynchronous collaboration instead is an effective way to involve everyone you need at their own ideal time.
To that end, Google docs are a great tool for async feedback and brainstorming. I know, truly novel, right? This probably isn’t a surprise to many. But I want to talk about a common mistake I see made when collaborating on content. Project owners often don’t anticipate that, with so many messages and docs swirling around, those coming into a shared doc may have forgotten the initial ask or may not recall the role they play in the ask. Are they bringing a customer perspective, editing for grammar, or thinking about how other teams will react?
I’ve found the easiest way to help with this is to start the doc with what you expect or need from reviewers and a reminder of how the content will be used. Here’s a screenshot of a Google doc where I did just this:
These details help each reviewer know where and how to focus their time and energy so they can provide the most useful feedback and prevent duplicative efforts.
Asynchronous feedback and socialization
The video tool Loom is one of my new favorite tools to combat meetings. Our team’s using it in two ways. The first is perhaps more obvious — it’s a great way to asynchronously socialize a concept, provide training, or present on a new topic.
For example, our Principal Data Scientist Elisabeth Weber recorded two Loom videos called “Learn to Rank,” explaining how we use ranking at Expel. These videos can be watched by our team as they see fit at a good time for each of them to consume the concept. Loom also has metrics on how many people watched a video, and those watching can see comments left by previous viewers. This becomes really powerful when you present a concept that connects dots across multiple teams.
The second way we’ve started to use Loom is for asynchronous feedback on presentation talk tracks. As someone who regularly has to present ideas to diverse audiences, I’m constantly seeking feedback from different parts of the company to make sure I have a concise, complete, and compelling message while also avoiding any “gotchas” I may have missed.
Loom is an amazing tool to use in the draft phase of presentation building. Recording talk tracks with slides and getting feedback from colleagues who can record their responses has been invaluable for building impactful presentations that get the right message across. Below is a screenshot of the most recent video I recorded — all of those talk bubbles are what we would call constructive feedback, and those emojis are what some would call trolling. Suffice it to say, I saved a lot of time by getting this feedback, deleting this presentation, and starting over 🙂
Socializing research outcomes
When completing research, you can often be left wondering, “How do I start moving this through the larger org outside of my (research) team?” There are different factors for success (note to self: this could be a whole blog series, especially on what not to do from personal experience…), but one of them is generating awareness and interest among other teams.
Researchers know that doing the research is only half of the work — the other half is communicating, recommunicating, and moving the findings through your org. At Expel, we love Jupyter Notebooks for this. Specifically, structuring Notebooks to socialize completed research has helped us more easily translate that research into product features.
We usually use slides in combination with a Notebook. Slides help us set the stage for why we did the research, remind everyone of our goals, discuss solutions and potential impacts, gotchas, etc. We then make the associated Notebook available for engineers or other internal researchers to play with the concepts in more depth.
To successfully use Notebooks to socialize research, consider the following:
- Notebooks should be optimized for the reader to understand, not for the developer. This means you might have to violate the DRY (Do not Repeat Yourself) principals (oh em gee…)
- Notebooks should be optimized for the reader to understand, not for porting to production. This means you might not have loops collapsed on one line (oh em gee again…)
- Code should be well documented. Yes – prototypers, it’s possible to have more than one comment per 100 lines of code 🙂
- Markdown cells should exist around code cells. The text in these cells isn’t about the implementation of the code in the cell below (that’s what comments are for). It’s telling a story for the reader at a higher level, helping think about the cell relative to the research objective.
Our weeks without meetings are meant to shock the system and make us more intentional about our meeting choices. It’s often the pause we need to rethink our meeting mojo and figure out how we can reduce the time and energy burden of meetings on ourselves and our teams going forward. That’s where the tools I’ve discussed come into play.
If you’ve read this far, hopefully you’ve found one tip or tool you can carry forward into your day-to-day to reduce the meeting burden on yourself or your team. Have other tools that help you minimize meetings while still communicating and collaborating effectively? We’d love to hear about them — drop us a note!