9. Zero-meeting product development in async teams
9. Zero-meeting product development in async teams
Insights into running a product and engineering team with almost zero meetings and a lot of results
I'm very vocal about async work - it gives me control over my time and acknowledges that work is only a part of life. I'll never give that up.
Our product development team consists of a product marketer, two developers and a designer. They are spread across the world in different time zones.
In the last couple of quarters, we have shipped multiple products fast. We did all that with almost zero meetings related to product development.
I like to call it zero-meeting product development because there are no unnecessary repeating meetings. Contrary to the old school belief, it has improved the speed of our outcomes.
In this blog post, I want to go through the processes we follow. A blog post is too short to cover all the nuances. So I’ll keep this high level.
Zero-meeting product development
While "zero meetings" slightly exaggerate how we work, you only need very few meetings to run a small product development team.
Guiding principles of our meetings
All "meetings" start as a google doc.
If you feel like you need a meeting, start a google document, and write down the problem you are facing and how your teammates can help. Make it easy for others to help by being crisp and concise about your points. Use tables and bullet points wherever possible.
If necessary, create a short loom video running through the document and clearly articulate the ask.
99% of the time, you will find out what you need through this document. Whenever you think there is a lack of clarity, use a Loom video to explain your thoughts.
No standup meetings
In-person standup meetings are the most significant waste of time for async teams. Trust people by default and trust they are doing their best work. Most of the time, developers or product managers don't have updates to share every day. Things get built-in weeks or months rather than days when working on features. It's pointless to get on a daily call and explain what you did yesterday and what you plan to do today.
Instead, use that time at least once weekly to build a good relationship with your team. Get on a call and don't talk about work. Building a solid relationship goes a long way.
Voluntary updates
"No standups" don't necessarily mean no update at all. A responsible remote worker keeps their stakeholders updated about the important milestones they achieve. But this comes voluntarily at their convenience. This can be in the form of a document, a Loom video or even a Slack message.
Trust your team
Reiterating the point above - many teams have too many meetings simply because they don't trust each other. This might be hard if you are a manager used to micromanaging people. Also, this might be a problem if you don't have self-starters in the team. This is why I discuss async work as a function of hiring below.
Updates to leadership
If you are a DRI for a project or your team, you would be responsible for sharing updates up the hierarchy or to the leadership. Your duty would be to collect all the voluntary updates, put together one coherent update and pass it on to the leadership team. As you might have guessed, this can be done by combining Doc + Loom.
If necessary, you can ask your teammates to fill in an update on a specific question - but again, you don't need a meeting for that.
Communication guidelines
I believe a lot of meetings are the results of lousy communication guidelines. Good communication at the core can help you get rid of many meetings.
Using Slack the right way
You don't need to get fancy with the number of tools you use to make async communication work. We have a dedicated channel for the product development team. All questions are threaded, and nobody expects an immediate response to the things you post.
Here is another good thread about the concept of async slack channels.
Don't be lazy
Try not to write single-line replies or messages. Genuinely try to answer a question or address a concern. Read what you have written before you press enter.
Does that answer the question? Would a loom explanation help here? All these questions help you improve the quality of discussions.
Decoupling from traditional processes
We don't have names for the processes we follow. Seeing how little you need to get meaningful work done is impressive.
Sometimes we have 1-week sprints, sometimes 2 or 3 weeks. We work backwards from the desired outcome.
Include engineers in planning as early as possible
Great engineers don't want to be treated as code monkeys. I try to include designers and engineers right from the discovery phase and increase the cadence as we move toward the next steps.
It works wonders. Trust your engineers, treat them with respect, and they will produce their best results. Engineers are the best product owners.
Async is a function of hiring.
Some people love to have face-to-face meetings and in-person standups. Such people cannot be forced to work async. Async work requires a shift in the mindset. You have to think async first. Building a remote team is a function of hiring - you need to hire people who understand the importance of async work. They'd also require good writing skills - and in this age, good Loom skills too.
You also need to hire self-starters and people who can manage themselves.
The meetings we have
1:1s and socials
I still have many weekly meetings - most of them are 1:1 or social. 1:1 are supposed to build a deeper relationship with people you work with - there is no point in doing them async. Set aside time in this meeting to talk about non-work stuff and discuss personal life if both parties are ok with it. That's the only kind of meeting you need to run a robust team.
Kick-off meetings for big projects
Sometimes we have kick-off meetings for large projects - Even these meetings have the purpose of helping people see the bigger vision. We don't discuss feature specifics, but it's more a ritual than a meeting.
Brainstorming meetings
While there are ways to conduct brainstorming async, I prefer to wrap it up and make decisions live. Leaving some space for organic ideas has proved good in my experience. Miro has some good async brainstorming templates that you can get started with.
Caveats
This is not a one size fits all solution. Probably a bigger team cannot follow this framework. This is based on my experience with smaller product development teams. I'd also argue that your team shouldn't be too big in a distributed setup to function effectively. Always split out into smaller squads with small focus areas.
What's the point?
The point of zero-meeting product development is not to eliminate all meetings. The purpose is to realise how less you need. And you require a mindset shift to make this happen. You have to unlearn most things you already know. You have to unlearn things that you have been practising for years. But the effort you put in will result in improved quality of life.
Parting notes
This blog post is too short to dive into the details of how we work. In a future edition, I’ll cover the detailed processes, the document templates we follow, and what a day looks like for me. Stay tunes.
How did you like this edition of No Office Required? I put hours of research into every edition of this Newsletter. Your feedback helps me make this great.
Thanks for reading, and see you soon with another exciting edition!
Sooraj,
You can follow me on Twitter to see more of my ramblings on async work.