Today's episode is another my favorite tip episode where I go back to interviews from the past and I dig out the thing that was my favorite tip, like the thing that I got out of the interview that really impacted or resonated with me. Today's extract is from my chat with Darren Murph, which was one of my favorite
interviews of twenty twenty. So if you haven't come across Darren, Darren is Gitlab's head of Remote and that is really his title, And if you have never heard of GitLab, it's the world's largest all remote company, with over thirteen hundred team members in over sixty seven countries with no company owned offices. Darren has spent his career leading remote teams and chatting remote transformations, and also authored gitlabs Remote Playbook.
Darren also holds a Guinness World Record as the planet's most prolific professional blogger, having published ten million words My Goodness, And in this extract of my chat with Darren, we talk about his four step process for making virtual meetings dramatically more effective, given that pretty much all the meetings that he's a part of are virtual. So let's head on over to Darren. Now, you mentioned the idea of
synchronous versus asynchronous communication. And I know you've spoken about what companies that truly want to do remote work well need to do is replace the default of synchronous communication. Can you explain what you mean by that, like how companies do default to synchronous communication and what are the steps that a company needs to take to not do that because it's so well entranced into most company cultures.
Yeah, to better understand this, you really have to go all the way back to grade school if you think about it. Early on. In our classical education, children are contained within four walls in a roof. We are conditioned from birth to operate in a synchronous manner in what is essentially an office for children. We are taught no other way, and so it's quite unusual to move projects forward or to build relationships when you aren't in the same place at the same time. You may hear things like, oh,
but I prefer synchronicity. I prefer to be together, And most of that is because people don't have a solid baseline of how this could work well in any other fashion. So synchronicity is the default for a lot of people. They feel like reaching out and having conversations with people or tapping someone on the shoulder. It feels very productive. It makes you feel like you're contributing meaningfully to the organization. But in truth, these types of meetings and ad hoc
interruptions are massively disruptive to the bottom line. They're massively disruptive to people's mental health. It's very difficult to get into a state of flow and make meaningful progress on any line of work if you're continuously being interrupted. There is a reason that Google is a machine and not a person, because if someone just essentially taps you as Google all day, you're going to get tired of answering
those queries at some point. So it's a fundamentally more inclusive way to communicate your knowledge and to scale your knowledge by writing it down once so that it can be interpreted and used a limitless amount of times. But it takes a culture that is understanding of that. And indeed, if you look at the get lab onboarding process, we lay out guides that explain exactly how to adopt a self service mentality. We even have a handbook guide on how to use the handbook. We have another guide on
how to search the Handbook. We are very prescriptive and articulate about the information infrastructure that we have set up. We essentially see the handbook as yet another product or tool. And so if you were coming into any company, you would expect an onboarding to get used to a key tool to do work, and we see the handbook as a key tool to do work.
That's really cool. I want to talk a little bit more about meetings, and obviously at git lab you default to documentation instead of meetings, which I think is such a key like such a key point for listeners who are thinking how do we truly go remote to really think about because we are so conditioned to defaulting to meetings,
it's the easiest thing to do. And I want to know when you do have meetings at get lab, what are the different rules that you have in place, Because I know there are some rules and guidelines for having meetings at get lab. I imagine that it is quite a significant thing if you're in to a meeting it get lab, given it's not the default. Is that fair to say?
It is fair to say, and there is some context you need to understand here. It is easier for us to get away with this at get lab because people self select into get lab. You opt into get lab even in the interview process. You know what you're getting into. Everyone can read our handbook before they even apply here, and so people come here because they want to work this way. It is their default. And so we have a like minded group of people that want to have
a bias towards a synchronous. In fact, bias towards a synchronous is one of the sub values of our diversity, inclusion and belonging value because it allows for a more inclusive course of voices to contribute to a project. So there's a five step process that, of course we have documented on questioning every meeting. The first is what is the outcome I am trying to achieve that has led me to a desire to schedule a meeting. You need
to write that down and articulate that. Number two is can the desired outcome be broken down and the smaller tasks? If you can break things down to more incremental pieces, it's more likely that you can accomplish each individual element of that through an asynchronous means. Number three is can the desired outcome be achieved or work towards by dogfooding
and using a get lab issue or merge request. Now, this is where it's important for me to point out that all of get lab uses get lab the product to collaborate. It is the heartbeat of our asynchronous workflow. So if you don't have a tool like this, you will need one. It is extremely hard to lean fully into a synchronous using a hodgepodge of phone calls, carrier pigeons, and email. You're going to need a tool at the heart of it. The fourth one is am I trying
to gather consensus. If you are consensus gathering can be done asynchronously. Anyone can open up a get lab issue or a mural board or a Figma board and gather input and consensus, and then you can save the meeting until the decision making needs to curve. And even that decision making, which is step five, we ask people to consider can the decision be made asynchronous LEA And if it cannot, then we default to a synchronous meeting, but
we will reserve that for the very end. And then if we have to have a meeting, we make it quite difficult for this to happen. Every meeting has to have an agenda attached to the calendar invite, so that temporal documentation takes place live during the meeting, and then the meeting organizer is responsible for transcribing and contextualizing any takeaways from that meeting into the get lab handbook so that the most amount of people can benefit from the
knowledge that was gained in that meeting. It takes a cultural mindset company wide for this to actually work and be meaningful, but our people fundamentally believe that synchronous time is very precious and we would rather reserve that for informal communication, for coffee chats, for team wide triviasians and scavenger hunts, things that help us build bonds as a team,
then just another work meeting. Now, of course we still have work meetings, but if we're rigorous enough to cut our meetings down by even fifty percent, most people listening to this would think, Wow, if I could have fifty percent fewer meetings, I think my zoom fatigue would go away.
So we're not trying to eliminate meetings. We're just trying to have a thorough process so that you question it, because if you're going to have to write down the takeaway anyway, we would love for you to start by writing it down instead of doing double work with a meeting first and then writing it down.
That is it for today's show. If you want to listen to the full episode, I link to that in the show notes, so you might want to check that out. And if you are enjoying how I work, I would be so deeply grateful if you just take five seconds out of your date to leave a review in Apple Podcasts. It might be a star rating or a few words, and by doing so, it helps other people find the show and it also brings a huge smile to my face. So thank you to the hundreds of people that have
left reviews. It is so deeply appreciated. So that is it for today's show and I will see you next time.