Personal user manuals are a way for distributed workers to broadcast information about themselves to their colleagues. While they aren’t without their pitfalls, they can be an effective way to achieve some personal and team objectives.

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.

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.

Distributed agile software development projects rely too much on synchronous communication. This not only leaves too little time for deep work, it also leads to burnout, less diverse teams and knowledge and information sharing practices that don’t scale.

Asynchronous work has the potential to transform distributed agile so it’s fun, sustainable, inclusive and scalable.