The risk of async islands of excellence
The most logical place to start an async-first shift, is your immediate team. But if the organisation doesn't eventually follow along, it'll be tough to sustain the change.
- External organisational forces can overwhelm a team that has a very different way of working from the rest of the company.
- Async-first and synchronous ways of working need different skills and different mindsets. Very few people can switch between them. This makes rotations and inter-departmental collaboration hard.
- If you don't have an organisational default way of working, people will always have to recalibrate themselves based on the team they work in. This makes it tough to gain fluency, where the way of working becomes second nature.
If you look back at all the advice on this site, you’ll notice that I recommend a part-guerrilla, part-advocate approach to change. As a guerrilla, you identify a group you can influence. For most of you, this is the team you work with. You can be opportunistic with this group and introduce async-first processes and ways of working wherever they make sense. As an advocate, you can use your successes from these experiments to justify a shift for the rest of the organisation.
It makes sense to start small. That’s the essence of agility, isn’t it? But in large organisations, it’s tough for a small team to cling to its own subculture for too long. It’s not impossible to have an ‘async island of excellence’! It’s just hard.
I want to use this post to reflect on the challenges your async-first team could face. Some of these thoughts build on two previous posts.
Forces for and against change
Some months back we referred to the four-forces model for change. It describes the tension between the push and pull for change versus the inertia and anxieties against it. In the last few weeks, I’ve been expanding this model to think about teams within large companies.
The model you see above isn’t unique to async-first ways of working. The same forces apply to any other change you introduce in a team. I think of the forces across three categories.
1. The change agent
The change agent refers to any external influence that precipitates a shift in the team. This could be a combination of various things. Here are a few examples that come to mind.
An external consultant.
Technology or collaboration trends.
Performance objectives.
Market or compliance needs.
New ideas from books, conferences, or other learning experiences.
2. Internal forces
These are the forces that either catalyse or stall change within a team. The team could desire the change because:
they see that their current approaches don’t work;
and/ or they see better alternatives to the status quo.
On the other hand, the team could pushback against the change for multiple reasons. We’ve discussed some of these reasons earlier.
Theory induced blindness stops people from seeing flaws in their favourite tools for thinking.
Loss aversion stops people from adopting fresh approaches, for fear of losing something they already have.
Temporary, unaccounted-for productivity dips may cause teams to lose faith in the change.
Since we can’t foresee the future, we discount the problems we may face several months later. We avoid change and focus on the most immediate issues on hand.
Teams gain internal momentum for change when their desire for it overpowers their pushback against it.
3. External forces
In my experience, these are the forces that have a disproportionate impact on a team’s ability to sustain change. Here are some examples of such organisational factors.
Delivery pressures: When you have tough deadlines and unrealistic go-live plans, it’ll drive a chaotic work environment for the team. An async-first work culture aims to calm down the team atmosphere through protocols and thoughtful communication. It’s almost impossible to manage chaos asynchronously. In such situations, teams will sink back into a sync-first way of work.
Partner inertia. Many companies work with partners. It may not be possible to insulate your own work processes from those of the partners, especially if the power dynamic is in their favour. For example, if your partner is a client and they skew towards being synchronous, then your team will struggle to maintain an async-first approach.
Misaligned leadership. This website has a section dedicated to the role of leadership in an async-first culture. When leaders at any level don’t model async-first behaviours, they influence people who look up to them. Depending on how powerful the leaders in question are, it can make the async-first teams seem like rogue subcultures in the company.
Ineffective management. Remote and asynchronous work needs a fresh approach to management. We’ve discussed several of the shifts earlier. For example, you need an outcomes focus over an inputs focus. Managers need to relinquish their positional authority. A good way to do this is by making processes and documentation clear. You should be able to respond with a link. Counter-intuitively, you need to care personally for your team and know enough about their work to challenge them directly. If managers don’t adapt, the async-first shift doesn’t stick.
Org culture. Any team exists within an organisational culture. It’s impossible to preserve a subculture that’s different from the way the rest of the organisation. Such teams stick out like sore thumbs. It’s tough to rotate people in and out of these groups. Hiring into these teams can be a challenge as well. Inter-departmental collaboration can become a nightmare. All systems have a state of equilibrium. Organisations are systems as well. They will always gravitate back to that equilibrium. An oddball team can resist only for so long.
Poor tools. I mention this last only because it seems like a trivial topic, but it isn’t. Thankfully, most companies in knowledge work have decent collaboration tools. Sometimes however, there are gaps in tool capabilities that can slow teams down. For example, if a team decides to pair-program and there’s no specialised software for it, the practice can be cumbersome. A handbook first culture is central to asynchronous work, but what if you have no tools to create one? Introducing new tools to just one team in a large company is an arduous task. You need to watch out for approvals, compliance, integration with systems and whatnot. While all these processes are important, they also represent corporate red tape, especially in larger companies. It can be months or years before a team gets the tools they’re happy with. Many teams will lose all motivation for change by then.
I’ve enumerated all these forces because I want to illustrate how async-first teams will find the odds against them if the rest of the company doesn’t also appreciate and adopt this new way of working. If the forces against change are stronger than the forces for it, the change will be difficult to sustain.
Async and sync are different sports with similar equipment
As I write this post, there’s a T20 cricket world cup going on. For those who don’t know about the sport, don’t worry, I don’t intend to get very technical about it. The equipment of the sport is straightforward. There’s a leather ball. And there’s a bat. Bat hits the ball and you get runs. The team with more runs at the end of the game wins. Simple.
Except, not that simple. Cricket has three different flavours.
On one end of the spectrum, you have test cricket. We play that game across five days!
In the middle you have one-day cricket, or ODI. As the name suggests, we play it across an entire day.
And then you have T20. It’s a short, fast-paced game that lasts an evening or an afternoon.
You win each of these formats almost the same way. The team with more runs on the board wins. Of course there are nuances and technicalities, but that’s beside the point I want to make. Although all these formats use the same equipment and the goals are similar, they are very different sports. Let’s compare the formats at the two extremes - T20 and test cricket. Here are some examples of the differences.
Dimension | Test cricket | T20 cricket |
---|---|---|
Clothing | White | Coloured |
Time of play | Full day | Afternoons or evenings |
Mindset | Cautious, slow, technical | Risk taking, fast, “hell for leather” approach |
Techniques | Classical and by the book | Innovative and audacious |
Rules | No field restrictions Unforced errors don’t cost many runs |
Different phases of the game have different restrictions Unforced errors can be very costly |
Preferred players | Fit, but experienced | Young, muscular and athletic |
If those differences make sense to you, then it’ll also make sense that in modern times there are very few players who play both formats well. Those who do, are a rare, dying breed of geniuses. Most of the world’s players are specialists only in one format. You can’t play T20 cricket with the skills and mindset of test cricket or vice versa.
Analogously, sync and async-first ways of working are also two different sports with the same goal, same equipment but different techniques, different skills and a different mindset. The defaults for both games are different and so are the defaults for both ways of working.
Just like you don’t expect a T20 specialist to play test cricket (or vice versa), you can’t expect people to switch between different modes of working. I mention this because organisations will inevitably want some people to work across teams. You may rotate people. You’ll definitely hire new people.
What happens when an async-first player now has to work with a mostly synchronous team? What about the reverse?
How do you hire people so their work habits are complementary to those of the team?
If you share the hiring pool with the rest of your company, how will you interview for the characteristics your team needs to maintain an async-first culture?
The bigger the organisation, the tougher these questions get. Organisations eventually need to be decisive about what their default way of working is. They need to decide which sport they’re playing. Multiple defaults lead to unlimited confusion.
Don’t stop your system from getting better
Most coaches will be familiar with the conscious competence model or the four stages of competence.
Let me describe the model so the rest of my argument makes sense. The four stages of competence go a bit like this.
Unconscious incompetence. You don’t know what you don’t know. Neither the deficit in skill nor the utility of the skill in question is obvious to you. You need a stimulus that’ll kick-start your learning.
Conscious incompetence. You know what you don’t know. You understand the need for a specific skill and you know you don’t have it. But you still don’t know how to execute.
Conscious competence. You know what you know. You’ve learned the skill and can perform it when you concentrate and follow the steps consciously.
Unconscious competence. You don’t know what you know. You’ve had so much practice with the skill that it’s now second nature. In fact, you don’t even stop to think about it when you execute.
Adapting to a new way of working also goes through roughly the same process. You achieve a state of nirvana when everyone on the team follows the team’s practices without having to think too much about them.
But what if someone has to switch between two different ways of working frequently? They’ll always have to recalibrate themselves to the norms of the team you’re working with. Most of the time they’ll switch between unconscious and conscious incompetence. With some difficulty they may get to conscious competence, but it’s almost impossible for them to make a way of working their second nature.
So this is where the rub is, and this is where I come full circle. Part-guerilla, part-advocate of course! Teams are the smallest unit to drive change with, so start there by all means. However, as you play the guerilla, don’t forget to play the advocate. A single team can be a nursery to develop an async-first way of working. However, if that shift has to last, you must spread the seeds wide. At some point, the entire company has to join the party.
Async islands of excellence can be unsustainable in the long run. Being async-first has tremendous benefits. But without enough organisational momentum, you can erode those benefits as quickly as you experience them.