Human Skills 029: Fully Asynchronous Teams
Human Skills 029: Fully Asynchronous Teams
with Amy Phillips
Amy Phillips has an incredibly varied background in management, having led QA teams, developers, and SREs. And we talked some about those experiences, the challenges of different ways you might take over a team, and what how to think about balancing a team as you hire.
But those weren't the meat of this interview. What make's Amy's experience unique in folks I have spoken with so far, and what we spent the majority of our team talking about, is managing people in the globally distributed, remote and asynchronous company that is Gitlab.
Truly working asynchronously is something many companies aspired to when forced to go remote during the COVID pandemic, but few actually succeeded at. GitLab has been that way from the beginning. So we dove deep into how it works at GitLab, how an asynchronous approach makes some things easier and others harder, what the 'A B C's of async look like, and how time horizons shift when you account for asynchronicity *and* global distribution.
How is working at GitLab different from most other companies?
I think people who join GitLab come in and it's globally distributed, and we're remote first. But the thing that seems to surprise people is it's async.
So it's not that you are on Zoom calls with people from across the world or Zoom calls with people in other cities in your time zone. It is first and foremost, things are written down and then secondly, spoken.
There's some benefits, there's some challenges, there's some stuff that's just different. And I think it's the single thing, it's interesting when we onboard people because you actually have to be very, very deliberate on teaching people "here is how we communicate."
I think in a normal office environment, you have to teach people a level of professionalism, and you learn that through your career, but they'll reach a point where people know how to go to a meeting, and they know how to talk to their peers.
When you join GitLab, because it is asynchronous and it's not so common, you do end up almost needing to... sort of walk people through like, here is what this looks like.
There's a few really fundamental things. I think we are very, very lucky. I think through the pandemic, we saw lots of companies having to suddenly go remote. And I think in lots of cases, they perhaps tried to go async and it didn't always work out. I think at GitLab because it has been like that from day one, we are lucky. there's lots of things just built into our culture that's like, that make this stuff work.
For example, everything is going to be written down. And it should be written down in a place that other people can discover it. At GitLab, we're using GitLab, so it's GitLab issues. But there are other ways of doing that. But I think it's not email. Crucially, it's not a private email thread that nobody else can ever discover ever again. Because the real benefit of async, and the thing that justifies the cost of async, is the fact that you almost get your documentation for free.
So you wrote down that discussion, and you wrote down that decision, and hopefully you added all the context about why you made that decision. And then six months, 12 months, or however many years in the future, it's just there. And the next time when somebody says, "why does this thing work in this way," you hopefully just have the information right immediately there.
Starting from the fundamentals, what are the 'A B C's of how you work professionally in an async environment?
I think the things that are most difficult is unlike in, say, an office environment or a here's a meeting and calendar invite and a link that you can join, what can feel quite difficult is how do I get to that person? How do I reach that person?
So you do end up having to do some sort of onboarding and training to help people navigate that. Here are your teammates. That always happens. But... this is our process. You will receive notifications in this way. When people want something from you, this is what that will look like. So again, at GitLab, you usually get a ping within a GitLab issue or a merge request, or you will be assigned to a merge request to review it. Your notifications will appear within the product. So it's helping people understand where they will find those things and helping them understand "here's where your work is living."
You actually do need to go and find your work. Otherwise you'll just sit at your desk all day and you may not be in a time zone with other people. So if you don't go and engage in the conversation, it may not come to you.
So it's helping people actually find a way to sort of firstly connect with the team, and then know what the norms are for team communication. How do you indicate that you are working on something? How do you indicate that you are seeking feedback or this is a very sketchy, like, you know, super early thinking and you're looking for other... you sort of have different types of communication. So how do people indicate that to other people?
And for others, often, just like titling of an issue or the certain labels we use. It's not complicated. It's just helping people understand what the norms look like.
Then the next challenge of GitLab is if you get asynchronous really right, the problem you have a bit later, once you've got hooked into all these workflows and people suddenly realize who you are and what value that is, you get what we call the fire hose of information. So suddenly you're connected to everything.
And then you have a new problem, which is, how do you possibly keep up with all of this stuff? So you may get like... there's all kinds of interesting discussions or projects. You may be asked for your input into all kinds of different things. And then there's all other things that you may just stumble across that are also interesting to you.
So there's always this like secondary workflow thing where you have to find a way to put some process in place. And this tends to be a little bit individual. I think different people have different ways of working that work for them.
And I think I found that my way of working will usually work for six months or maybe 12 months. And then you reach like a breaking point and you're like, oh no, too much information, I need to revisit and sort of recategorize so I can stay on top of things.
But how do you make sure you are seeing and responding to the right things and spending your time wisely, even though there is like an infinite amount of other interesting things. It's kind of like if you imagine in an office, if you could eavesdrop on every meeting taking place all the time. Fascinating stuff, but you can't keep up.
Given there still need to be some synchronous meetings, what do those look like in an async culture?
Yeah. Oh yeah, definitely. So this one is really interesting because I have previously worked in teams in sort of more office-based environments, which as I look back now, I'm like, some of this stuff, if we'd have had that, we would have just avoided certain problems. So the basic one is just every meeting has an agenda. That's just standard. If there's no agenda, there's no meeting. And then the meeting, so I like the...
There's lots of benefits, I think, to asynchronous work. But the one I particularly like is the fact it's a lot more inclusive. So it isn't just the loudest person speaking, or it isn't just the fastest thinker getting to drive the conversation.
We are varying degrees of good, but when we get it right, we're brilliant at having an agenda written up in advance. That should be editable by everybody... everybody is not a "I'm coming to present to you." It's asynchronous discussion.
So the general thing that normally happens is the topics are added onto the agenda. People will add discussion points and questions and answers to the agenda ahead of the meeting. I always found that quite interesting because in some ways, some meetings almost conclude before they even begin.
But it works for time zones. So the agenda will be up, and it will have topics in. And maybe the meeting is taking place my morning tomorrow. But there are people working in other countries who actually are going to have an entire work day between that.
So they can actually join into the agenda. They can add to the agenda, even though they won't be physically in the meeting. And that's OK. Somebody else will verbalize their points, or we'll share something.
But the general idea is that the meeting is a discussion. And it is a document that's accessible by everybody. And it has the minutes. Unless it's genuinely a private meeting, that's fine. But for a team discussion or project updates and discussions, then that's the idea.
The meeting is not really intended to be the first time you heard about something, because we are asynchronous. So we're quite good on the culture of if somebody comes up and, "oh, I've got this idea, I've been thinking about all of these things," okay, where is this written down?
So there was a kind of normalization of, you wrote down the first version, and then we discussed it. And again, I think that really helps the people like myself who like to read something or hear something, think about it, and then have an answer. So you kind of get that thinking time.
Are there other rules around meetings, or what should and shouldn't be a meeting?
I think one rule that we have which I mean I think it actually like blew my mind when I first heard it is we don't present. Because people can read.
So if you're gonna give them a slide deck, give them the slide deck and then have a discussion meeting. So we have quite a lot of meetings where you'll prepare slide decks. They're a little bit more texty than, like a flashy conference slide deck, for example, but all the information is gathered on a slide deck, shared in advance, and then there'll be a meeting, which is just questions.
And that's really nice, because it means if people don't have questions or they don't want to go to another meeting, they don't have to. But if they do have questions or they want to discuss things, they also have a place they can go to. So that works really well. And I think it really cuts down on the number of meetings and the length of meetings.
How is management different in an asynchronous environment?
That's a good question. It's reasonably similar. So yes, I still have synchronous one-to-ones with everyone. I think that's really important. And you have very different type of conversations one-to-one. And I think that's when you really can check in and see how people are doing.
But I think there are a few things that are interesting. I have found that in many ways, it's easier to give people good feedback, because their work is so much more visible.
So if previously, in an office where you know this person's having trouble communicating with that person, it's all a bit hearsay. It's all, "well, they said this and I said this and they're not listening to me." And it's really hard because a lot of those things take place in a closed meeting room. It's very hard to get to the real bottom of, like, where is the problem? So I find those things can sometimes take a lot longer to resolve.
One of the great things about being mostly asynchronous is a lot of those things are visible. So you may not see the full problem. It may still have happened sort of synchronously, but if you get feedback that, you know, I'm finding this person difficult to work with for these reasons, you usually have a decent sense from the work you can see of okay I could see how that could come about.
So I think in that case, it's a little bit easier to gather those examples and give feedback that's actually a bit more specific. I've definitely had cases in offices where you, oh, make sure you give that person the feedback on their communication. You're like, I don't have any examples. And it just doesn't land at all.
Whereas I think one thing that's good when you have asynchronous is f you did get something like that, if you were going to give the feedback, if it did feel valid, you could probably get together some of your own examples where you can literally walk through, "you wrote this sentence, and how do you think that makes people feel?"
And quite often, I think it's a, not everyone's got English as their first language. So often, it's just a simple translation. When you say this word, actually for some people, it sounds more like this word. So you can go into, I think you can give slightly more useful feedback just because you have that visibility.
How do time horizons change in an asynchronous environment?
They absolutely change. It's interesting because it goes both ways. So one I think that can feel frustrating, so I'll start with that one, particularly if you come from more of a synchronous environment, is the sort of things where you would previously have, “let's get a group together and we'll just quickly discuss this thing and it'll be all done and dusted one hour, off we go."
So for example, say like a retrospective. Lots of teams, every few weeks, get together for an hour. I've worked in places where we've done 15 minute retrospectives once a week, really quick and everybody just drops in their ideas and you're done.
Take that asynchronous, but also crucially globally distributed.. and that is the key thing that changes it because if you write something, you really need to give at least 24 hours before you make the firm decision. Because otherwise, you've not allowed everybody to really take part.
But also, it may not have been everybody's top priority. So that's probably your minimum. So if I open up a retrospective, if we do our retrospective, it's asynchronous. We use a GitLab issue, and it sort of has the sort of usual information, like here were the goals we went in with, here is the outcome, here's what we achieved. Here was a rough timeline of events, and then some fairly standard retrospective questions.
I would usually give my team one or probably two weeks to respond. And then we summarize everyone's comments, draw some conclusion, set some actions. You've probably got another few days to get everybody to really agree to some actions, and then you're done. So we do them less often and they take longer.
But the actual actions we get are very high quality because the benefit we have is that it wasn't, you know, 9 a.m. on Tuesday and this person wasn't feeling that well and this person hadn't slept well because they had childcare issues last night. And you just got what top of mind on Tuesday at 9 a.m.
Because people have that longer time, they're actually able to think about it and be a bit more thoughtful and respond to each other. So sometimes people will add their comment, someone else will add a comment the next day and that will trigger a different discussion.
So it feels like we get a more useful retrospective, but the overall end to end that you're going to need three weeks to get through your retrospective is a real shift compared to what many people are used to.