When people can identify themselves in all their interactions with each other, it reflects a high psychological safety. But just like a failing test can be invaluable in coding, you need the test of “anonymous contributions allowed” to test if your psychological safety is indeed as high as you’d like it to be.

Writing the book about “async-first” collaboration doesn’t mean that I’m immune to the status quo. I screwed up on my own rules recently, by taking a “sync-first” approach instead. And boy, did that hurt!

The “CEO test” is when you ask yourself “Would I do that to my CEO?”. That can often help you spot behavioural anti-patterns you must correct, when interacting with your coworkers.

Group chat can be both a helpful tool and a distraction in the workplace. While suitable for quick exchanges and simple information sharing, it falls short for more important discussions and tasks.

To invite diverse views in an open discussion, psychological safety is essential. In this article I want to tell you how anonymity can help create that safety.

The agile manifesto claims that the best way of communicating in a team, is face-to-face. Does that claim hold up to scrutiny? 21 years after the manifesto came to life, have technology, the nature of our projects and our ways of organising and working taught us something different? I explore all these questions and more.

Communication is a big part of an exec’s role. In fact, many people would argue that if an exec isn’t communicating, what are they doing? In today’s post I want to demystify asynchronous company communication for the executive. If you’re leading a department, or your own company, think of this as your guide to effective internal communication.

To move away from the office mindset, then we’ll need to unlearn a few unhealthy habits we’ve picked up over the years. In this post, I want to share four of these habits. Benign as they may seem, they are pernicious obstacles in your path to being an async-first team or organisation. Let’s explore each of them and the problems they create. As we do so, I’ll outline a few alternatives to these behaviour

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.

Sometimes we give a free pass to any activity that seems collaborative. Before you know it, you’ve built half a dozen gate checks to deliver a single user story. Each of those “collaborative” gate-checks doesn’t just create interruptions and context switches. It also leaves an attention residue - your mind continues to think about the interruption even when you’ve switched to the task on hand. In this article we examine the ad-hoc “huddle” through a series of questions, so we can find out how much we really need them.

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.

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.

In the previous post, we discussed how written communication is the number one superpower when working asynchronously. In this post, I’m adding three more superpowers to the list. Think of these as a quartet of abilities that will help you and your team to supercharge your individual and collective effectiveness.

1. Distraction blocking

2. Reading and comprehension

3. Working independently

There’s no asynchronous work without written communication. It has several benefits over just verbal communication and even over audio and video. This post articulates those benefits and shares some resources you can use to build this remote working superpower.