Go async-first with your team
Use the filters below to find async-first methods that are relevant to your team. For detailed articles, check out the blog.
Delete recurring meetings
Recurring meetings are usually meetings looking for an agenda. Not the other way around. You’ll do well to delete most of them.
Meeting free halves
It’s a good practice to keep at least half the days of your team calendar meeting free. This meeting free half should also sync with your personal calendar.
Plough back savings into team bonding
If you reduce unnecessary meetings, you can use the time savings to build relationships with your team mates.
Meeting hygiene
To ensure that the meetings you actually have are productive, here are a few simple things you can do.
Replace "quick sync" with "async"
Most “quick syncs” can be async. This honours everyone’s need for flow and deep work.
ConveRel quadrants
The ConveRel quadrants are a way for you to triage your meetings and figure out which ones can immediately or eventually be async.
Scheduled emails
Compose your thought but schedule the message to go out when you expect the recipient(s) to be at work.
Block focus time
Block out focus time on your calendar so people know exactly when you are available.
Email signature
Don’t pressure people or get pressured into responding to an email the moment they/you see it.
Chat status
Set up your default status in a way that everyone knows you use the platform in an asynchronous manner.
Distraction blocking
Plan your week in advance, ration the distractions and use an app blocker to reap all the benefits of async work.
Shift left on retros
Think retro as a process that has two parts - take inputs asynchronously and run it synchronously.
Write once, run many
Switch from fragile, redundant, ephemeral conversations to shared, persistent onboarding assets.
Pull requests
Pull requests are a feature that most source control systems provide (GitLab calls it a “merge request (MR)”). This feature allows anyone who wants to contribute code to a project, to package their changes so someone else can review their code before merging it into the codebase.
Business decision records (BDRs)
By documenting every business decision you make for your project, you help your present and future colleagues understand the rationale of why things are a certain way for your team.
Commit messages
Effective commit messages are a way for developers to communicate to each other about the changes they’re making to a codebase. These messages can be useful when fixing issues or when finding the root cause of a bug or even when troubleshooting a broken build.
Architectural decision records (ADRs)
Your architecture will change with time and in the future you may have to investigate why your architecture is a certain way. Architectural decision records (ADRs) help by providing an archaeology of your project.
Meeting minutes
By going async, you’ll limit the number of meetings you have. For the meetings you keep, you must afford your teammates, present and future, the courtesy of a meeting summary; a.k.a meeting minutes.
Demos only when necessary
Let’s be honest. Teams don’t always have something big to showcase every sprint. Without substantive demos, the sprint reviews become a formality and a reporting exercise. Take a pragmatic approach to sprint reviews instead.