When pointy-haired bosses run out of real arguments for a “return to office”, they turn to disingenuous corporate speak. There are many examples out there, but three of them annoy me the most.

When we leave cultural characteristics open to interpretation, we run the risk of creating toxic cultures. The loudest voices usually undermine diversity. It makes more sense for distributed organisations to do the boring work of defining culture. It isn’t as sexy as a secret sauce, but writing things up fosters a consistent and healthy culture.

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.

I think sending meeting recordings instead of meeting minutes is inefficient and insensitive. You can do much better.

If you’re calling your culture a “secret sauce”, or your “x-factor”, you’re doing little to clarify it. To demonstrate care for culture, means that we must define it clearly, at the level of behaviours. We must move beyond platitudes and poetic expressions.

Wait, what? Write in slides? Well, yes. And I’m sure you’ve seen this yourself. Heck, I’ve done it myself as well. Guilty as charged!

If you’ve normalised this approach to writing and sharing information, then I’m here to tell you that you should write differently. That’s what this post is about.

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

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.

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.