Silent meetings can better leverage the ideas, perspectives, and insights of your team. They’ll not just help improve your meetings, you’ll also see better ideas and solutions emerge.

Recurring meetings are usually meetings looking for an agenda. Not the other way around. You’ll do well to delete most of them.

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.

If you reduce unnecessary meetings, you can use the time savings to build relationships with your team mates.

To ensure that the meetings you actually have are productive, here are a few simple things you can do.

Compose your thought but schedule the message to go out when you expect the recipient(s) to be at work.

Block out focus time on your calendar so people know exactly when you are available.

Don’t pressure people or get pressured into responding to an email the moment they/you see it.

Set up your default status in a way that everyone knows you use the platform in an asynchronous manner.

Plan your week in advance, ration the distractions and use an app blocker to reap all the benefits of async work.

Think retro as a process that has two parts - take inputs asynchronously and run it synchronously.

If all you want to share is a “yesterday, today, blockers” update, you don’t need a standup meeting.

Imagine calling someone on the phone, going hello! then putting them on hold!

If you have an established product, then you’re probably less concerned about big release plans. Instead, your priority will be to enhance your product regularly. For such situations, I’m a big fan of Ryan Singer’s “Shape up” approach.

Advocate for a pair programming pattern where two developers act as each other’s accountability partners.

Create smaller decentralised pods inside the team to devolve responsibilities. Pods operate autonomously and make their own decisions.

To make remote pairing work, the tools involved play a big role. Make sue you have specialised tools that serve the purpose.

Take a break by going solo on simple coding activities that won’t benefit from the intense code review of pair programming.

Use the flexibility of remote work to work out your “pairing” hours. Get into the practice of writing good commit messages and pass on the baton.

Queue up candidate stories for the next sprint, about a week in advance. Let the devs take a look at them and ask questions.