Introduction
I work on the product team that focuses on young people -facing products. That includes the digital services we build ourselves and the off-the-shelf products like Zoom and Teams. Our team has about twenty people and we’ve never all been in the same meeting at the same time. We work asynchronously, which for us means being in-sync about the important things; the outcomes of the work, and not being tied to less important things like having to all work at the same time and in the same way.
We don’t have all the answers. We’re still learning how to make this work for everyone, but three of our priorities are how we learn and share knowledge more effectively, how we give people the freedom to work in ways that are best for them, and how we quickly respond to changes and new problems.
Learning, and integrating learning into the organisation Our team (in fact, I think, everyone who works for any modern knowledge work organisation) has two jobs; learn, and integrate that learning into the organisation. This should be the goal for all modern knowledge workers who are creating new knowledge. If that knowledge stays in the head of one person it can’t be utilised effectively by the organisation. So having effective ways of sharing information is an essential aspect of async working.
Meetings are not that. They aren’t effective ways of sharing information. They are left over from a time before the internet when organisations didn’t have any other means of telling people stuff. Meetings and calls have their place, but they serve a social purpose rather than an information sharing one. They can help people feel connected, help with team cohesion, etc., so I’m not saying we need to never have meetings, but we need to clear on what purpose they serve. Meetings aren’t even great for discussion because they favour quick thinkers and don’t allow for equal input from slower reflective thinkers. And in any discussion it’s usually the loudest most persuasive voice that wins.
Writing and drawing instead of always talking and listening are under-utilised asynchronous tools for thinking and communicating. More asynchronous working gives us more opportunities for everyone to contribute and learn. It gives us time to be considered and reflective, deliberate and thoughtful. It prioritises depth of thinking and writing over the speed of thinking and talking.
Communicating, and pulling information when it works for you
Async communication work best when everyone gets to contribute at a time that works for them along with all the other work they’re doing, has time to develop their thoughts on the subject, and learn from what others think. Compare this to joining a video call with no agenda or preparation, and being expected to think effectively and make good decisions. It’s no wonder that so many meetings end with an action to arrange another meeting.
We still have way too meetings, but most of our discussions take place in Word documents. The body of the document contains what we’re talking about, and the discussion takes place in comments, and once something is agreed it’s written into the document. When someone sends an email the information in it is limited to those the email was sent to. That’s what email is good for; passing a fixed piece of information that doesn’t really require any discussion to a fixed group of people. But if we want people to contribute, to build on the information and improve it, and to learn as they do it, then putting the same information in a shared document and working on it together gives us better quality decisions and longer-lasting information which is available to anyone and for as far into the future as needed, which is hardly ever the case with meetings, calls and emails.
The challenge with communication is to create ‘pull’ systems where the information is available when someone needs it, and not ‘push’ systems which send information to people when they’re working on something else and so causing distraction and information-overload. All those products which send a notification email every time an update is made, or show how many chat messages you haven’t viewed yet are bad for really effective asynchronous working because they push themselves to you and demand your attention now regardless or whether you’re in the flow with something else.
Even though we write lots of documents, I’m always keen to guard against assuming that they have all the information in them. So I’m big on encouraging questions. When someone asks a question they are coming from a particular context which affects the answer they need and means the right information might not be in the document. When I reply to question, even if the answer could have been a single sentence, I’ll often try to explain about the background, why the decision was made, what implications or unknowns we’re aware of, all because keeping that information in my head doesn’t help anyone else learn. I’m sure some people find that really annoying and just want the short answer but we all have to make sacrifices for the goal of learning.
Working together, in small lightweight temporary teams within teams
Asynchronous working allows for different ways for teams to organise themselves and their work. We want to be synchronised around outcomes; what we want to achieve and when, but we want to try to remove as many dependencies as we can so that we’re able to respond to change without any drastic impact on the project.The 20-person strong team I’m part of is a cross-functional team, which means it’s made up of people with different skill sets, and is focused the one big project we’re working on. But sometimes something new comes up. A new problem to solve, something we didn’t know about before. It might be considered part of the project we’re working on, or it might not. We don’t want to distract everyone on the team, so we get together a small lightweight temporary project teams made up of people from within the larger team and outside of it to focus on solving the new problem.
One of those times was when we wanted to make it easier for young people using Microsoft Teams to ask for help. So we set up one of these lightweight temporary teams made up of someone from our safeguarding team, a designer, a developer and me. We started a Word doc, all added to it to get to a good enough understanding of the problem to solve, what constraints we faced, and what solutions could look like. We settled on the solution being an app that would live in Teams and have its own button in the Teams menu so that if someone had any questions they could click that button and the app would open and provide them with ways of getting help. So, even though our colleague from the safeguarding team had never worked this way before the rest of us were familiar enough to help her contribute effectively and we were able to design a solution within about 48 hours of picking up the work, and alongside other work we were doing. If we weren’t working asynchronously it have taken us longer than that to find time when everyone was available to have meeting to talk about the work before even doing any work.
Amy Edmondson, professor at Harvard, calls this way of working ‘Teaming’. She describes it as “teamwork on the fly. It involves coordinating and collaborating without the benefit of stable team structures,” It’s a skill that enables groups of people who aren’t part of a formal team and don’t have a history of working together to work effectively together for a short period of time. I think the asynchronous mindset of not having to be doing the same thing at the same time as someone else helps with adopting this way of working because it has a low overhead for organising people. All it takes is a document and writing clearly what we’re thinking about to get started.
Asynchronous teaming also has an interesting side-effect. The people who work in those teams, they spread knowledge from one temporary team to another, which helps to increase learning for everyone. It creates a network of knowledge transfer. It uses Stanford professor Mark Granovetter’s idea about the strength of weak ties. Where we talk about how not being in offices means we miss out of those informal coffee-break chats, creating a these network where everyone talks to people that they wouldn’t have if they only worked within formalised team boundaries means people, maybe it can help.
Asynchronous working at its best leads to a learning culture where two things are true: One, people know stuff that is beneficial for them to know, that isn’t necessarily part of their formal job title, and they don’t know how they came to know it. And two, learning and knowledge sharing are regarded as an implicitly beneficial activity as much as the producing of outputs of work. We’re still working on achieving both of those, but if you’re interested in trying asynchronous working I’d say the three things to try out are:
- Make writing and drawing the default ways to communicate before meetings (not as well as).
- Focus on sharing knowledge and learning rather than coordinating people and work.
- Pick a small problem and get a group of people who wouldn’t normally work together to solve it.
Resources
SVCO blog post: How to share ideas when you don’t share a space
