Why you may find it tough to introduce asynchronous work in your organisation
A few years back, I was making the case for remote work to a variety of stakeholders; almost ad nauseam. While the hypothesis in my head presented a clear set of benefits, it was a far cry from the status quo. To make the case real, we needed a tipping point - a critical mass of “experiments” to prove the model’s viability. The Covid-19 pandemic provided more than just an experiment. Within the space of months, the world of work had flipped on its head. The model wasn’t a hypothesis anymore. It was real.
There’s a part of me that’s happy; almost smug about this transition. On the other hand, there’s a part of me that believes we have some ways to go before we declare success. You see, for many of us, remote work was never a compromise or a sub-optimal option. It was a way to do deep work, find the balance between work and life, and find flexibility in when and how we work. I think of it as a better way to work in the information age. Yet, if you look closely, most firms have taken their old ways of working, plastered Zoom, Teams, Google Workspace and Slack all over it and declared victory.
If you’re like me and enjoy the notion of flow and deep work, our days are still suboptimal. With calendars that still look like a dog’s breakfast and a work day punctuated with dings from chat clients and avoidable video calls, “flow” is a state many of us achieve as an exception and not as the rule. To me, the solution is an asynchronous-first work culture.
It’s a simple concept and yet incredibly hard to put into practice. I’ve been part of large, multinational, services firms for most of my career and have worked with even larger clients as a consultant. While getting your team to adopt this approach will have its own challenges, you might also encounter organisational hurdles. Over the last couple of years, I’ve developed a theory about why larger firms struggle to adopt an asynchronous work culture. Being aware of these struggles will help you, the change agent, prepare to deal with them. So let’s get right in.
The decline of email
I’ve had a love-hate relationship with email. On one hand, when I was (note the past tense) a Linux geek, I loved all the deep conversations we’d have on mailing lists. When I joined Thoughtworks several years back, I walked into a culture of global communities. Our mailing lists were rich with layered discussion. People would post well formed, structured thoughts and the nature of email allowed for debates, evolution of thoughts and problem solving in a manner that almost feels mythical today. This communication behaviour continued until the mid-2010s. And then came a tipping point that’s led to a plummeting lack of depth for peer-to-peer communication.
Microsoft bought Slack in 2011. 2013 was the year Slack came into being. 2016 was the year WhatsApp became ‘absolutely free’. Microsoft came up with Teams in 2017. These developments forced Google to build Chat in 2017 as well. Zoom, Fuze and Blue Jeans made on-demand video communications easier. Relatively speaking, it just became too much effort to “write anything up” at any level of detail. Remember, writing is the fundamental practice for remote work. As we relegated email to being a tool people took pride in not looking at, the practice of writing fell by the wayside.
Signal-to-noise ratio
Putting together an enterprise communication toolset is a complex exercise. On one hand, you want to maintain a complementary ecosystem of products. On the other, you need to comply with the regulatory constraints of your industry. Adding to this complexity, you need to cater to the changing needs and demands of your workforce. To top it all, you need tools that also help you collaborate with your partner organisations or teams. When you try to cover so many bases, a Frankenstein communication stack is inevitable. Several tools do the same thing, with little or no variation. Sometimes effective tools succumb to the ineffective ones, not because they’re bad, but because they’re less popular (for a variety of reasons). Very often, the tools that die are the tools that need deliberate thought.
Take email, for example. Many organisations suffer from contradictory thinking with email. There’s no firm that doesn’t have email. Back in the day, Andrew McAfee said, "Email is freeform, multimedia (especially with attachments), WYSIWYG, easy to learn and use, platform independent, social, and friendly to mouse clickers and keyboard shortcutters alike." Heck, email is the OG of collaboration tools.
It’s not surprising then that all official communication comes on email. To this day, if you have to leave an audit trail for communication, email is what you’d call a sensible default. And that’s not a bad thing. Except… email is also where you get a lot of other noise from the workplace. From events, to announcements, to news about a coworker’s promotion, from birthday wishes, to surveys and, of course, the cookies that Sameer brought into the office - it’s all on email. The bigger the organisation, the more the noise. When the signal-to-noise ratio goes below a certain threshold, people lose faith in the tool. Anti-incumbency applied to email and today it’s become the casualty of the instant-messaging revolution.
Visibility bias
There’s always been a bias in the workplace for people who are extroverted and highly visible. For example, there’s data to show that extraversion brings a clear advantage in compensation. It’s no secret that the more visible you are, the more chances you have at being successful at work. Before the pandemic and even today, several publications speak of a “proximity bias”. Here’s how Forbes defines it.
If most of your colleagues are working remotely, now the proximity bias transforms into what I like to call a “visibility bias”. If you’re not making yourself visible with regular chat messages or in meetings, are you really working? So people bite the bullet. There’s a cost to productivity, deep work and overall job satisfaction of course, but you might make the trade-off for long-term career goals.
Calendar density equals importance?
In March 2020, when the pandemic was raging and everyone was working from home, it wasn’t uncommon for people to wear “back-to-back meetings” or a day of “eight hours of meetings, straight” as badges of honour. It was odd for sure, but many of us were transitioning from a fully synchronous office to a 100% distributed model with very little time to consider the change. Of course, we had heaps of meetings! The trouble is, bad habits are sticky.
Victor Hugo once said, "Nothing is more powerful than an idea whose time has come.". I’d add a corollary to that - it’s also hard to stop a bad idea whose time has come. Over the last couple of years, the idea of using the density of one’s calendar as a measure of one’s importance has taken quite an unhealthy root. And yet, it should be clear that if one brags about back-to-back meetings, they misunderstand productivity. Question is - how does one part with that meaningless badge of honour?
Working with partners
Most organisations don’t work by themselves - they have partners. It’s hard enough to change your own behaviours and then to take your entire team along. When you add a partner to that collaboration puzzle, things can get pretty messed up. Part of it is down to the power asymmetry that exists between partners. If you’re working asynchronously and you’re the client in the relationship, it’s likely that you’ll convince your service provider to adopt similar methods. That doesn’t mean that the services team working with you will actually follow suit. Depending on the size of the team, how opinionated they are and how entrenched they are in their existing ways of working, your mileage can vary.
Let’s flip the relationship. If you’re a service provider and you decide to adopt mostly asynchronous work, it may not be easy to convince a client to adopt this way of working. Especially if they prefer being mostly synchronous. The power asymmetry will work against you now. Of course, nothing’s impossible, but the path of least resistance is always easier. As human beings, we’re fine tuned to conform and be part of a collective. If that means giving up an effective way of working for an ineffective one, sometimes we’ll do so.
Bullshit jobs
David Graeber’s book “Bullshit jobs” is a text you’ll either love or hate. The intrepid reader can either pick up his book or check out the excellent New Yorker essay on Graeber’s proposed theory. Graeber defines “bullshit” jobs as “useless jobs that no one wants to talk about.” In fact, he makes a distinction between “shit jobs” and “bullshit jobs”.
I’ll leave examples to your imagination and curiosity; lest I offend someone, but I’m pretty sure that you can find jobs in your company that fit these descriptions. These are the original five categories from Graeber’s book.
From my experience, I’d like to add three other categories to Graeber’s list.
I guess the bigger the organisation you work for, the bigger your grin will be as you read through these descriptions. If many of these jobs seem familiar and heaven forbid some of these jobs exist in the groups you work in, you’ll realise none of them include hands-on, creative work. Unlike the typical developer, tester or designer who needs quiet time, these jobs benefit from visibility either through constant presence in meetings or through high frequency byte sized communication through the workday. Don’t get me wrong - most people in bullshit jobs are probably highly conscientious, smart, individuals. They just need to be in different jobs. Truth be told, I’ve done some of these jobs myself! Yet, the more the proliferation of these roles in your team and organisation, the tougher it is to adopt asynchronous work.
Last, the Cassandra curse
In Greek mythology, princess Cassandra of Troy has a special gift. She can foretell the future. That gift, however, comes with a curse from the god Apollo. No one ever believes her. Before you feel sorry for Cassandra and I’m not saying you shouldn’t; remember some of it is her own doing. As Shankar Vedantam breaks down on his podcast, she has a few quirks. She:
speaks in cryptic language;
doesn't have any formal authority;
is too far ahead of everyone else;
and asks too much of the people she warns.
Synchronous work has a long history, starting with the industrial revolution. When the agile manifesto came about, it challenged much of the status quo but not the status quo of synchrony. It led to the proliferation of open-plan offices and as more and more people misinterpreted the manifesto to be a criticism for documentation, written communication on projects suffered. To this day it’s not unusual to find technologists who prefer to talk than to write. Quiz them and they’ll point you straight to the manifesto. Which is strikingly simple to consume and has a two-decade legacy at this point.
Compare that to any advocacy for asynchronous work. We haven’t yet put out anything that has, for lack of a better term; the virality of the agile manifesto. Sure there’s GitLab, Basecamp, even the venerable HBR and Forbes, but we’re all battling the endowment effect. When we own anything (in this case, an existing way of working); forgoing it will feel like a loss. As humans, we are loss averse. So how do any of us asynchronous work advocates compare to Cassandra?
If you plan to be an evangelist for asynchronous work, you can see how you may feel a bit like Cassandra.
In this article, I walked you through some reasons that may stop you from introducing asynchronous work in your team or organisation. Here’s a quick summary.
The decline of email and the rise of video conferencing and chat tools has led to a decline in structured, written communication. Some of this is also because of the poor signal-to-noise ratio on email.
The status quo at work creates a visibility bias, which leads people to attend more meetings than they have to. Over time, people equate calendar density to their importance at the workplace.
Partners can derail your work practices even if your entire team is bought in to work asynchronously. Power asymmetry between partners and our tendency to choose the path of least resistance can come in your way.
Wherever there are bullshit jobs, there are meetings and high-frequency communication. The more of these roles you have in your teams and organisations, the tougher it’ll be to adopt asynchronous work.
And last, all evangelists for a new way of working suffer from the Cassandra curse. Change is hard, especially if the incumbent way of working has a deeply entrenched, easy to comprehend legacy.
While you may see some odds against you, remember that introducing a new way of working is similar to introducing a new product into a market. The four forces model you see above has inspiration for how you can precipitate the change in your teams. In the first article of this series, we discussed why the old way of working needs to change. In future articles, I’ll lay out a playbook to make asynchronous work real - especially for software development teams.