Build a mindset for change
Change always comes up against the inertia of the status quo. To help precipitate the change, you need to get your team to buy into it. Here are four ideas to achieve that buy-in.
- Align your team to the value you’re hoping to achieve out of working asynchronously. Asynchronous work is still just a means to an end.
- Visualise the change on a spectrum of synchronousness - 100% asynchronous on the left and 100% synchronous on the right. Empower your team to think of ways to “shift left”.
- Institute a Ulysses pact. The one I recommend comes from Basecamp, “Meetings as the last resort - not the first option.” It’ll help your team be thoughtful about how synchronous you really need to be.
- The choice of a synchronous or asynchronous collaboration rests on a fine balance of values. F2F interactions are a special kind of synchrony.
Over the last few articles, we’ve discussed the value of asynchronous work to a remote and distributed agile team. If by any chance that made you too enthusiastic, we’ve discussed some of the reasons your organisation or your team may resist this shift. In this relatively shorter article, I’d like to share with you four ideas that may help you prime both your broader organisation and your team for the change. We’re not yet at the level of an implementation checklist and a playbook for individual practices will follow in due course, but for the time being, consider this as a framework to help align your team. Enough said. Let’s get right into it.
Focus on value
Like anything else we do in agile software development, the notion of “value” is at the centre of this shift to asynchronous work as well. Let’s get one thing straight - asynchronous work is not the goal. It’s a means to an end: an end that wholly synchronous ways of working cannot achieve. At the risk of repeating myself, let’s look at a summary of benefits.
| Benefit | How does asynchronous work help? |
|---|---|
| Better work-life balance | When people don’t have to work synchronously with each other, they can choose the work hours that work best for them. That way they get to give their life the time it deserves. |
| Higher inclusion | You don’t have to worry about where someone is located or their timezone. Introverts and non-native English speakers can use the safety of tools and writing to communicate freely. Flexible hours allow people with various personal situations to become part of your team. |
| Improved onboarding and knowledge sharing | A discipline to communicate clearly in writing reduces FOMO on teams. Regular writing and curation also helps build up referenceable team knowledge that you can use for knowledge sharing and onboarding. |
| Communication practices that support scale | Everyone cannot be in every meeting. People read faster(200-400 wpm) than they can listen (140-160 wpm). People don’t remember every piece of information they encounter. Writing allows your team to share information at scale. It’s referenceable and fast to consume. |
| Time for deep work | When you don’t have unnecessary meetings on your calendar, you can now free up large chunks of time to get deep, complex work done without interruptions. |
| A culture that defaults to action | Whenever we face a choice between waiting to be perfect and being wrong at speed, we choose the latter. The focus is on getting things done. If something’s wrong, we choose to refactor and adapt. |
The first step in introducing change on your team will be to align on these elements of value. The more of these benefits the team cares about, more they’ll be open to change.
Visualise change on a spectrum
One trap I’ve seen myself fall into, even when I’m consulting professionally, is making binary judgements. You may identify with this tendency - something is either perfect or rotten. There’s nothing in between those two extremes. As we embark on any journey of change, I think it’s important to acknowledge that we may never be perfect. This is life in perpetual beta - you and your team will get better with time. Asynchronous work that’s judgemental and unkind somehow belies its central intentions - to build flexible, inclusive teams that value deep work.
Spectrum of synchronousness by James Stanier
So the key to plotting this change is to think of it as a spectrum. Thankfully, James Stanier did all the hard work for us defining this spectrum in his book “Effective Remote Work”. I’ve just flipped the direction of his spectrum. You see, agile teams value the approach of “shifting left” when testing. The idea is to catch defects earlier in the development process. It can confuse teams to shift left for one thing and right for another; so I prefer this direction of the spectrum.
The image is self explanatory - as you go from right to left; you go from a fully synchronous medium to a fully asynchronous medium. And just as you don’t want to run an entire project just on a wiki, you don’t want to communicate only on video calls all the time. Communication methods on the right side of the spectrum are the ones I characterise as “temptation comms”. They are easy in the short term, but they have fewer long term benefits. As you traverse left, communications get tougher in the short term, but have longer term benefits - the kind we’ve discussed earlier. I call them “investment comms”
To quote Stanier with a slight modification;
“To fully embrace remote work, we need to shift our mindset and habits (on) the spectrum. Instead of choosing the convenient option, we need to choose to communicate in a way that enables an equal level of contribution from anyone, regardless of where they are in the world.
…
That’s the habit that you need to promote within yourself and with your colleagues. Every time you communicate, can you purposefully shift further along the spectrum?”
Using the spectrum as a reference will help your team co-own the change as you integrate asynchronous ways of working into your software development process. Coupled with the benefits you’re looking to achieve, this gives you a sense of direction.
Make a Ulysses pact
There’s a story in Greek mythology about the Sirens - a band of women singers sitting somewhere out on the sea. No sailor could resist the temptation of getting close to the Siren’s rocks once they’d heard them singing. Of course, rocks and old wooden ships were never a fortunate combination - so the next thing to happen was a shipwreck.
Ulysses wanted to listen to the Sirens, but didn’t want to be shipwrecked. So he made a plan. He stuffed his sailors’ ears with wax and asked them to bind him to the mast as they approached the Sirens. Easy did it - not only did Ulysses enjoy the show, his sailors also steered the ship to safety.
A Ulysses pact is a term used to describe commitment strategies. By binding himself to the mast, Ulysses prevented self-destruction. He also removed the tempting cues for his crew, but we’ll come to cues in a later post. In a similar way, you need to consider what the Ulysses pact for your team is. The pact I recommend is to institute a simple principle everyone can hold each other accountable to.
“Meetings as the last resort - not the first option.” - David Heinemeier Hansson, Basecamp
The biggest obstacle to asynchronous work is meetings, which by definition are synchronous. By agreeing to this basic pact, you can help the team think consciously about the meetings that are absolutely necessary.
Appreciate the balance
The choice of collaboration patterns rests on a fine balance.
All said and done, you can’t be a zealot. Imagine a system in perfect balance. On one end, you have asynchronous collaboration with a certain value that it brings. On the other, you have synchronous interactions and their value. As we’ve discussed with the spectrum of synchronousness, this isn’t a zero-sum game. You choose a certain interaction by assessing the value you’re looking to get out of it. My argument for asynchronous agile stems from the fact that most teams are too far on the right of the spectrum. That doesn’t mean I see no value in being on the right sometimes!
There are a few trade-offs you make when you decide the nature of your interaction.
Thoughtfulness vs. speed. Writing up a document is slower than brainstorming on Zoom. Waiting for people to think things through and comment on your document slows things down even further. Including people with flexible hours may not optimise for speed. This is classic System 1 vs System 2 in action. In return for slowing things down, you optimise for thoughtfulness instead.
Depth vs. breadth. A side effect of speed is that you cover more ground in a short period. Taking that metaphor further, it’s easier to cover several miles in an hour than it is to dig a few feet in the same time. Similarly, synchronous interactions allow you to cover a wide range of topics in a short time, but if you want depth, you’ll need to be more asynchronous.
Productivity vs. connectedness. Even the most ardent advocate of asynchronous work will tell you that while it’s more productive to have time for yourself, it can get isolating after a while. You don’t need to kid yourself. We’re all human and we want contact with our friends and colleagues from time to time. Synchronous interactions offer that connectedness.
The future vs. the moment. Last, there’s the value that James Stanier calls “permanence”. With the focus on writing things up, asynchronous work helps you create assets and artefacts for the future - be it for reference-ability or for onboarding. Synchronous work, on the other hand, is all about the present moment. If you need an instant solution or urgent help, you’ll need to be synchronous!
Anyone who’s watched The Karate Kid can’t forget the lovable Mr Miyagi. There’s a quote of his from the movie, that I love.
“Lesson not just karate only. Lesson for whole life! Whole life have a balance, everything be better.”
“If you want to go fast, go alone. If you want to go far, go together.” - African proverb
Without buy-in from your team, any change you try to introduce won’t go very far. So I urge you to spend time working with your team to identify the value you’ll get from being more asynchronous. Any change that looks too daunting, won’t go too far either. Think of small steps and quick wins to get you started. Commitment strategies will help and so will a pragmatic, balanced approach.
Whatever you do, don’t be a hard-nosed zealot. Instead, take a part-advocate, part-guerilla approach. Be an advocate to make your case with bosses and co-workers. This’ll help you garner the support you need. Be a guerrilla to change the things you have influence over. Every little win will help you justify subsequent experiments.
And most importantly, be ready to move from the whiteboard to the trenches. A successful async-first team doesn’t need hand-waving leaders. You’ll be valuable to your team when you can get into the details and help your colleagues out when necessary. Showing them how to execute a practice in an asynchronous fashion. Create an environment conducive for change. Be a role model with your own way of working.
This article brings us to a logical point where we can start thinking about ways and means to be more asynchronous on distributed, agile teams. In upcoming articles, we’ll address various communication and collaboration practices on your team, so you can pick the improvements you want to make.