If you adopt asynchronous work, everyone should be able to work on a schedule that’s convenient to them. But that may not be the case from day one. You must first build your deep-work muscle.

Onboarding is one of the first areas where you’ll see payoff for the effort you spend in writing things up. In this post, let’s explore a few mindset shifts and a few tips and tricks you can use to bring people aboard your team. As you read on, you’ll notice how your handbook and your developer documentation are among the key ingredients to brew the perfect onboarding storm.

Earlier in this series, I mentioned your team will need a handbook. We’ve also discussed the audit trails you should create while in the flow of your work. If you look hard, you’ll notice that the goal still isn’t to create “comprehensive documentation”. The idea is to create enough “sensible documentation” that helps make communication effective. In this post, I want to zoom into a very specific section. This relates to developer documentation.

When you’re in a remote setup, think of your retro not as a meeting, but as a process. That process has two parts - asynchronous and synchronous. How much you do asynchronously is totally up to you and how adept you feel with working this way. This post will tell you how to run effective retros distributed team, with a solid sprinkling of asynchronous methods.

Distributed standups are painful, period. With modern tools there are better ways of getting the value you’d expect from such a meeting. As an individual, you’ll get back a few minutes of your life every day. The bigger benefit? You can share updates continuously, and at your own pace. From a team perspective, you’ll be able to create an audit trail of communication and, of course, plough back the time savings into deep work.

As a team scales, the need for documentation increases in parallel with the cost of not doing it. Daunting as it may seem, a handbook-first approach has many advantages, and will give your team a way to self-govern and self-organise. In this post, I’ll walk you through some ideas about what to include in such a resource and how you can create and maintain it.

Before you start tweaking individual practices on your team from a remote and async-first perspective, you need to zoom out and examine your work and communication protocols. So, in this post I want to share with you a few fundamentals you need in place, so you avoid the hyperactive hive mind.

It’s time to lay out the framework for change. It all starts with values and guidelines. In addition, the team needs to reflect on the work they’re doing. Motivation is no trivial matter. So in this post, we’ll also discuss a few important parameters that your team can use to judge how motivated they are with the work they’re doing and the way they organise. Consider this as a set of sensible defaults to begin your journey of change.

Let’s look at the categories of collaborative tools most software development teams will need. Many of these will seem familiar to you already, and that’s a good thing. You just need to use the tools effectively. I’ve broken down the list into three categories - must haves, good to haves and optional extras.