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.

As team size increases, communication becomes more complex. Small teams will eventually bring in new people. Such is life. Team size aside, you’ll find that complex decisions lend themselves better to the written word. Moreover, there are limits to what people can remember, so it makes sense to commit things to writing. If we’re designing continuously, we’re also communicating about it all the time. In today’s post, I want to share three asynchronous techniques to communicate about design.

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.

Like the pebble trail in the story of Hansel and Gretel, our projects need audit trails for us to keep track of changes, communicate on a daily basis, and to onboard and align people. We discuss the five most important trails in this article. In the context of distributed teams these represent communication and documentation in the flow of 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.