How To Run a Successful Asynchronous Team

Asynchronous dev teams perform best. We’ve all heard this statement at some point, but what does “asynchronous team” actually mean, and what does it take to run one successfully? We asked Brendan O’Leary, senior developer evangelist at GitLab, what his thoughts were.

Brendan has been working at GitLab, a fully remote company with 1,300 employees and zero offices, for the past three years. He believes a lot of the best practices around working remotely are things that, as teams, we always say we want to do, but never do because we end up using our office as a crutch to fall back on.

Brendan shared 5 best practices to help make successful asynchronous teams: 

1 - Write things down

Brendan: You want to write down everything: processes, decisions, etc. Having those things written down lets people consume things asynchronously. But it also allows for a lot of other things — it allows you to iterate, and you can train people a lot easier because now everything is written down.

2 - More transparency

Brendan: The more transparency you can have with people, the more you can make things public or public to the company versus having the need to obtain access, the better. In an asynchronous world it can be hard to know what you don’t know, so if there’s not a reason to hide a process from someone, you shouldn’t.

As an example: I’m not in the finance team, but I need to understand how our finance team handles something with expense reimbursements. I don’t have to go ask someone, because I can read about it first, then ask any questions after, which is hugely efficient.

3 - Documents open to everyone for editing or suggesting changes

Brendan: Instead of making a top down traditional hierarchy, our documents are open to anyone if there’s no sensitive information. And it helps us with synchronous communication, like synchronous meetings, where we have a Google doc that everyone can access. There’s no agenda in it, and anyone can add things to the agenda or add questions, and now it’s really easy to run the meeting and it’s really easy for someone who wasn’t in the meeting to catch up, because now there’s this an asynchronous way to understand how the meeting flowed. 

We also record every meeting, which is very helpful for catching people up. We can’t have a meeting with everyone because some people are asleep while other people are working as we have 1,300 people in 65+ different countries and at least 1 person in every timezone that exists.

4 - Have a DRI (Directly Responsible Individual)

Brendan: This is my first all-remote job where the whole company works remotely, but I’ve worked in remote teams through most of my career, where I am in an office with a remote team elsewhere.

Before GitLab you would have a delay in any decision that involved folks that are in the US, Europe and Asia. It then takes around two or three days to make a decision because you’re communicating one thing at a time and the people in Asia wake up and answer then the people in the US wake up and they answer.

At GitLab we have a concept that is really helpful called DRI (Directly Responsible Individual). For any decision that has to be made, there’s a very clear, directly responsible individual who makes the decision in the end. There is likely lots of input from lots of different people, and we encourage that, but in the end we know that every decision has a DRI, so if there is ambiguity in who the DRI is, we’ll have a meeting to make sure that is the first thing we figure out. 

Once you have a DRI, that person in empowered to make the decision without having to reach consensus, which can be hard to impossible across the world, and they’re especially empowered to make that decision if it’s what we call a two-way door decision — if it’s a decision that once made could easily be changed and it’s 100 percent of the time more efficient to just make the decision and start walking forward as the worst case is that you have to go back and make the other decision.

If it’s a one-way door decision — we make this decision and there’s no going back — that might make people more careful with considerations, and that’s the decision that goes slower. 

5 - Communicate about how you communicate

Brendan: What I’ve just said you could easily get from anyone who works at GitLab, because we’re very clear about all this, and words have strong meanings. The word DRI is one everyone signs up for and understands eventually, and we’ve written all this down.

We even formalize informal communication. In our communication handbook, which is public to the world, much less to the whole company, there’s a section on informal communication that formalizes informal communication, because the thing that you don’t get asynchronously is the watercooler, coffee chat thing. So we formalize that and we have a thing called coffee chats where part of our routine is having meetings with people where we don’t talk about work.

We have a large company with 1,300 people around the world, so you do have people in other departments that you want to talk to about a work thing, and so you’ll have the apologetic, “let’s have a coffee and meet, but also I want to talk about this work thing.” Though generally, they’re not supposed to be at work, they’re supposed to be about just getting to know people.

Something to think about

Brendan: There is value in synchronous communication, but we use it very sparingly for the things it’s valuable for: human connection and decisions that are super complex and do actually require a bunch of people involved, and I think that’s key.

Doing asynchronous communication well means being very intentional about what is synchronous and what is asynchronous.

Extra Resources:

GitLab’s all remote guide: https://about.gitlab.com/company/culture/all-remote/

GitLab’s handbook https://about.gitlab.com/handbook/