Summary

A good way to assess your behaviour towards your colleagues, is to ask yourself if you’d behave the same way with someone in a position of power. For example, your CEO. You’ll realise that we normalise many dysfunctions that we should weed out of our ways of working. I discuss a few behaviours that are not-OK in an async-first environment.

1. Ignoring written communication.

2. Asking people for walk-throughs of content you can read yourself.

3. Being trigger-happy with meetings.

4. Not communicating proactively about tasks you’re responsible for.

Async-first, is about challenging the status quo. No matter how common these behaviours are in your company, you mustn’t normalise them.

When teams think about a transition to an async-first way of working, I often hear objections. Some objections are valid. People want to protect the value of the practices they follow, even when they work async-first. Fair enough. That’s why I wrote “The Async-First Playbook”. Others want to transition in tiny steps — no quarrel with that. In fact, that’s what I recommend! So I created the async-first method stack. But what gets my goat, is when we normalise dysfunctions.

Often there are some behaviours that we take in our stride, even though they are unprofessional and insensitive. These aren’t just barriers to working async-first, they’re also barriers to fostering a respectful team and company environment. A good way to ask ourselves if certain behaviour is OK, is to ask, “Would I do that to my CEO?”.

If the answer to that is a “Hell, no!”, then we must ask ourselves why we’d do that to any other colleague. We mustn’t normalise the problem. In the words of Dan Heath, let’s problematise the normal.

Is it ok to ignore written communication?

There are many problems with email. I’ll be the first to admit that. But if your company pays for an email service, is it acceptable to give the excuse of, “Oh, I didn’t read the email”? Let me put it this way. If your CEO wrote an email to you and asked you to do something, would you ignore it? It’s likely that even if you have a mountain of other unread emails, you’ll rush to respond to the boss’s note. So why would you ignore your colleagues?

I empathise with the problem of “too much email”. There’s a company’s responsibility to set up mailing lists and email infrastructure in a manner that doesn’t create spam. There’s also the individual’s responsibility to ensure we communicate effectively. Little things matter. For example, who do you add to the “To” and “Cc” fields? Far too often, we add everyone who might be vaguely interested in the topic, to such communication. Unsurprisingly, most people find such communication irrelevant. So they ignore it. Once a group of people gets into the habit of ignoring written communication, it’s a slippery slope from that point on.

So yes, we must all get better at targeting our messages to the right people and no one else. We must get better at writing as well. But for us all who receive emails from colleagues, please don’t ignore them! Especially if our name is in the “To” field. Set up your mailbox and filters to prioritise such emails. Respect the response time commitments for each communication channel for your team, department or company. If you won’t ghost your boss, why ghost your co-workers?

Is it ok to ask for a meeting to read what you can read yourself?

There’s no asynchronous work without writing. If you can’t build the discipline of written communication, then you might as well not try to work async. Simple as that. The corollary to this, of course, is that there’s no asynchronous work without reading. If no one reads, what’s the point of writing?

In meeting-happy teams and companies, it’s common practice to create a slideument - i.e. a document created in presentation software - and then “present” it to a bunch of people. I can’t say it any other way, folks - there’s no reason you must read to literate people. Yet, in such places, people expect that if you put together an artefact, you’ll also set up a meeting to “walk through” it. This is a colossal waste of time and synchronisation effort. It’s far more to share a document and to expect people to read and comment on it by a certain date. You can then synthesise comments and either move to the next step asynchronously or meet if you must make a contentious decision.

But of course, some people expect the grand tradition of the “walk-through”. Let’s put that to the CEO test as well. If your CEO, boss, or paying client, sent you a document to read and comment on, what would you do? Most people who expect you to pamper them with a “walk-through”, will drop everything they do and read the doc! So why would we not accord the same respect to our colleagues?

Part of the barrier to reading is that people are too busy. Reading and commenting on a document takes effort. It’s a thoughtful exercise. It doesn’t happen in breaks between meetings. Therefore, setting aside time on your calendar for deep work is important. Asynchronous work will bring several efficiencies to your team’s work, but not if you don’t recognise communication as a bona fide part of your work. When you set aside time for deliberate communication through reading and writing, you’ll be more likely to reap the benefits of going async-first. 

Is it ok to be trigger-happy with meetings?

One reason we have so many meetings is that it’s bloody straightforward to set them. Think about it. A few clicks on your calendar app, and there you have it. Sure, you’ll have to play Calendar Tetris, but it’s easier than writing a document, right? Wrong.

Just because you have easy access to your coworkers’ time, doesn’t mean you stop respecting it. Would you be so blasé when booking your CEO’s time? You’d give it some thought, wouldn’t you? You’d probably write something up, sweat the prep and be sure that you need the meeting. If that’s a good thing to do with your CEO, then hey, it’s also a good thing to do with your colleagues. 

I’m not suggesting that we should not have easy access to each other on our teams. Indeed, the point of having a team is that we should be able to rely on each other. That said, being able to rely on each other shouldn’t be at the expense of our need for deep work and flow. An async-first mindset embraces the need for synchronous collaboration while balancing it with a team’s need for a shared reality, and for time to solve fun and complex problems.

Is it ok to ignore deadlines?

Imagine this situation. A colleague promised to finish a piece of work by a certain date. You have the task sitting on your task board, in the “In progress” lane. The deadline passes by, but the card doesn’t move. You nudge your colleague to check about the status of this work. They shrug their shoulders and give you some variant of “Oh, I haven’t been able to finish that yet.”

Would you do that if your CEO gave you something to do? If not, I’m sorry - such behaviour is downright unprofessional. When people routinely don’t follow up on their commitments, it leads to process overload. You need meetings for status updates and project manager types have to needle their teams with reminder after reminder. What you get for a lack of professionalism, is communication churn. 

This is not a problem that takes rocket science to solve. All it takes is proactive communication from every individual on a team. If you’re responsible for a task, then you must communicate about it. It’s not uncommon for us to push a deadline. That happens. But you can’t do that after a deadline has passed. We always know ahead of time, if we won’t finish a piece of work before its due date. So let the team know about this. Don’t spring them a surprise at the eleventh hour. Make the task board the nerve centre for communication. One of the simplest tests for an async-first team is to check the “In progress” lane of their task board. If that lane represents the actual status of what the team is up to, then you’re on the right track. If there are unrepresented tasks or status updates, then your team lacks transparency. Without transparency, you’ll erode trust and without trust, you’ll create a heavy process and micro-management. Is that what you’d prefer?

At the core of the async-first mindset, is the conviction that a calm, inclusive and thoughtful environment yields better results at work. But we can’t reap these benefits without questioning dysfunctions in the way we work. Some of these dysfunctions have been around for so long, that they almost feel normal. Then again, if you’ve chosen to go async-first, you’ve chosen to challenge the status quo. While you’re at it, why not put some dysfunctions to the CEO test?