Aydin Mirzaee, Fellow.app   02:44

Darren, welcome to the show. 

Darren Murph, GitLab  02:46

Hey, thanks. 

Aydin Mirzaee, Fellow.app   02:47

Yeah, it’s really good to see you again. You know, we’ve done I remember, in the beginning of the pandemic, we did a session with you and it was just so good that I said, we have to have you back on the podcast.

Darren Murph, GitLab  03:01

I appreciate it. That’s high praise. And you’ve had some pretty amazing folks on the podcast, shout out to yo bet remote. So happy to be amongst the crowd on the show.

Aydin Mirzaee, Fellow.app   03:11

Yeah, definitely. So I mean, there’s a lot that we’re gonna talk about today. But I thought a really great way to kick this off, is to ask you about something that is highly unusual when I first read it, and I’m like, wow, that’s actually really cool. So you have the Guinness World Record as the planet’s most prolific professional blogger. Yeah. What a title.

Darren Murph, GitLab  03:34

That’s accurate. It is surreal. The plaque is on my wall. Yeah. So the crazy story there is I was Managing Editor at Engadget. It’s a consumer technology publication. It was really the golden era of tech blogging. I started writing about tech the year before the original iPhone came out. So as you can imagine, once the iPhone came out, that was the sea change, like every day, nology became culture, culture became technology, there was a lot to write about. I fell into my niece, that was my superpower distilling information, writing it down really quickly. But also in guys, it was one of the earliest all remote teams, we have people scattered all over the world. And we were very, very efficient working as a distributed team. And what’s interesting looking back on that is I didn’t really consider it unusual at the time, it was just the way work was done. It was only later that I realized, oh, office centric minds don’t really do a lot of the things that you have to do as a remote team. So to capture the record, I wrote and published an article every two hours, 24/7 365 for four consecutive years. That’s what it averaged out to, so when the record was bestowed was about four years into my tenure 17,000 or so articles, 6 million words. It’s up to the 25 30,000 range now, well past 10 million words, and the record still stands. So happy happy to say that.

Aydin Mirzaee , Fellow.app   05:03

Wow. And it still stands. That is incredible. I guess you were just publishing a lot very quickly versus you weren’t staying up every night for four years?

Darren Murph, GitLab  05:13

Yes, that’s correct. So there were some intense bursts. And I actually want to back up and say, it’s really hard to get a Guinness World Record. So when I actually applied for this record, I had to be persuaded by a calling to apply for this, I just kept blowing him off. And he said, Listen, either you’re going to apply for it while I’d stand over your shoulder and watch you do it. Or I’m going to apply for it and forge your name. But I’m convinced that you’ve written more than anyone else in the world. And I absolutely want to see this thing for. So to get us to reach back out to me and said, Hey, this seems like an interesting record. We’re going to put a team of people on it to scour the internet to try to disprove your claim. And they spent six months trying to do it. And they required all of this back end data from our CMS to make sure that every article was authentic, and how many words were on each article, and that it was a human and not a machine and all of this stuff. And six months later, they finally said, Yeah, you’ve done it. But I will say there were some late nights, I did sleep less. In my younger years, I don’t think I could pull it off again. But also, there was just an incredible amount of efficiency in our team, our tools were perfected to work as a remote team, we had engineers that worked on some of those tools that if they could save one click, they would spend weeks to get one click faster. Because in the blogging game, speed was everything quality, of course, but once you had quality speed was the next metric. So beating our competitors by even one or two seconds was a big deal on Google. 

Aydin Mirzaee, Fellow.app   06:46

Wow, what a story. Yeah. And what an honor to actually meet the person with the record. I can say that I actually know who, who he is. That’s amazing. So Darren, there’s a lot to talk about. You obviously talked about  Engadget, and you’ve been at many other companies in leadership roles. And obviously today you’re head of remote at GitLab. So you’ve had a lot of leaders, a lot of bosses, and you know, being at Engadget, you probably interviewed many of them. And so I guess one of the questions I had is from like all the people that you’ve kind of come across either reporting to them directly, or just coming across them, has there been someone who’s been most memorable, whether whether that was like in a very positive way, or something very negative, who’s the most memorable boss you’ve come across?

Darren Murph, GitLab  07:33

Yeah, Tim Stevens, by far he was my boss at Engadget. And that was an interesting time, Engadget almost fell apart, we had almost the entire team left to go from another publication, there were only a handful of us left. And we decided that we were going to rebuild it, essentially build it from the ashes. And Tim was in lockstep with me on that vision. And we had to hire and recruit and train and write and run the business, we had to do all the things like suddenly we were a startup all over again. And so being with a manager through that trial by fire was certainly from a crystallizing moment. The magical thing about him is that he was such an empower-er. He recognized my strong suits, he recognized my flaws. He recognized how to steer me in the right direction and focus energy in a positive way. But didn’t micromanage. Got out of the way, let me make some mistakes. He pointed them out to me with grace, and was always always there to connect dots in my career and be a mentor, but also expand my network by leveraging his network. I just appreciate him so deeply for that. And I have tried to internalize many of those things as I become a manager.  Yeah, that that makes a lot of sense. So how long did it take for him to get to know you at that level to be able to, you know, recognize where to focus your energy? Like, did he just get it right off the bat? Or was it something that got better over time? It definitely got better over time, I would say six to nine months, there was an obvious inbuilt trust between Tim and I. And what’s fascinating about that is our personalities are actually very different. Tim is very introspective, calm and quiet, very still. I’m generally much more charismatic and bombastic and just want to get out there and get after it. And so we’re different people. But I think when you couple those things, what we realized is that we complemented each other very well. That has been critical for me as I’ve grown as a leader, where I look for my weak spots, I look for the spots where I don’t necessarily have an innate passion. And I will try to hire Phil for that. So I will actively try to build a team around me that specifically does things that I don’t like, better than me and That’s easy to say. But as you look around the world of managers, it’s not very easy to practice because it requires a certain amount of vulnerability and transparency, that I’m not great at everything. Some things that I don’t actually want to be great at. But I would rather hire someone that’s great at that, and then unblock them as fast as possible to make the sum greater than the parts.

Aydin Mirzaee, Fellow.app   10:21

Yeah, that’s really interesting. And if you don’t mind me digging a bit further, what is something that you have realized that, you know, you might not be great at and that you’ve hired for in the past?

Darren Murph, GitLab  10:34

Long term, project choreography, anything requiring a Gantt chart, so if we’re trying to wrap our heads around this massive six to nine month project, where you’re going to need to coordinate dozens potentially, of people with with with a very syncopated list of due dates, where things have to happen for another gate to open, and then another gate to open? I’m great at putting together the vision of that, and what the outcome can be in some of those early first iterations. But I would much rather give it to someone who is in the weeds, and they thrive on making sure each one of those gates gets lifted at the right time, and that people are plugged in in exactly the right moment. And where I thrive is being able to live in that visionary world, coupled with someone that’s very tactical, and can make sure things get done. 

Aydin Mirzaee, Fellow.app   11:27

And how long would you say it took you to figure out that that, you know, that was, you know, that was the right way to play it and the right type of person to have to surround you? 

Darren Murph, GitLab  11:39

Ten years, forever, forever. I mean, when I was at Engadget, to some degree, it was necessary for all of us to be a jack of all trades. So what I found myself doing was being an individual contributor in many very important things, because I knew how to do it, and I was capable of doing these things. But I didn’t love it. So sometimes I would do it. But it would, it would be at the expense of a lot of energy. Because when you’re doing something that you’re not necessarily called to do, or you’re, you’re not in your zone, even if you have the intelligence to do it, and you can do it, it’s much more draining, it’s much less life giving. So a lot of that was necessity. But it did take me a long time to realize what might be a better use of time, is to train someone up and give them all of the information but hire someone that specifically wants to do that. And it’s not an energy vampire for them. And then just empower them to do it their way, teach them all that you know, and then empower them to do it their way. And now being at GitLab What has really crystallized for me here is that we work in draft, we work in public, and we have a low level of shame. So you see people sharing very early ideas early and often and asking for input and feedback. And that allows people to grab hold of an idea early and run with it in their strong suit. That has been a game changer for me, where you don’t really have to wonder, is this someone strong suit if you share an idea early enough that they can contribute their specific feedback early? 

Aydin Mirzaee, Fellow.app   13:22

Wow. So what’s interesting about that, and what I want to emphasize, is that it is usually I mean, you said it took a decade. And you know, what’s interesting is like, you know, if I feel if we do this podcast, 10 years from now, you’ll probably have even more to add, because it’s the sort of thing that you just like, the more you’re in your career, the more you realize almost you what are the things that are the most fulfilling, and it might not be obvious, and you might not have necessarily spent time on this other thing that you don’t even know about yet that might be even more fulfilling. And so so that’s really interesting. But I did want to dig in on this, this concept of ideas in public. So how does that work practically? As an example, is there something that recently you have a story to tell about?

Darren Murph, GitLab  14:09

Yeah, absolutely. The GitLab platform was built by a remote team for remote teams. So to give you some context, GitLab is a DevOps platform. We have 1300 people in more than 65 countries with no company owned offices ever. So it was designed from the ground up to leverage the benefits of a remote team, instead of it being this thorn in your side or this challenge to overcome. A lot of transitioning companies are recognized. They’re having that reckoning right now. So that’s the organizational design concept. So GitLab, the platform enables us to do collaboration across the entire company. Our legal team uses that our comms team uses that our marketing team uses that we centralize all of that information in one central hallway, one central heartbeat where all work happens. So it’s transparent by default, after this podcast, I could go peek around and GitLab and within 10 seconds tell you what any one of the companies working on without having to interrupt them or bother them or call a meeting. That is the beauty of transparency. But the critical part here is that visibility and transparency in work has a direct link to belonging. As a member of this company, I feel like I belong, because the work and the workflows are transparent. So it’s critical for leaders to empower their employees to work in a transparent way on a transparent cloud platform. But that’s only 50% of the equation. The other 50% is culture. So in GitLab, we have a values page that is incredibly comprehensive and robust. We have six core values. But what’s more important is the substantiating values, the sub values underneath all of those, and I mentioned a few of these earlier, no ego, we explicitly work with no ego, short toes, no one can step on anyone’s toes it GitLab because we all have short toes. So this empowers people and design to chime in on things we’re doing in HR onboarding, for example. The other thing we say is everything is in draft. So we share things early and often. And one of our key values is iteration. This is the hardest value to learn, but the most impactful if you truly embrace it. So we say if you share a piece of work or an idea, just a sliver of an idea out in a public Slack channel or in a GitLab issue, where you can ask others for input and feedback, and you have a little bit of embarrassment in doing it, then you’re exactly on the right track. If you’re embarrassed about how infantile that first idea is, you’re doing exactly right. Conversely, if you spend three or six months, packaging up this idea into the perfect final polished product, and only then do you share it with someone, even if it is right, it’s going to be frowned upon. Because what if it wasn’t, you want to give people the chance to give you input early, so that if you’re off course, it’s only going to be one or two degrees, it’s really easy to fix. If you hold something in a silo for six months, and then ask for feedback. What if it’s 40 or 50, or 60 degrees off, then it becomes a one way door not a two way door very hard to reverse, it’s very hard to undo, you end up having to do an entire new project just to offset the old one. But it requires a culture of acceptability and a psychologically safe atmosphere where you can share things without fear of retribution or worrying that someone is going to say you didn’t think all of this through. That’s exactly the point. It’s exactly the point. Of course, I didn’t think all of this through, I wanted to share it very early so that people smarter than me can make it better while they still had a chance.

Aydin Mirzaee, Fellow.app   17:58

Yeah, there’s so many interesting things that you said, this concept of, and I feel like these things go hand in hand, right. So this concept of short toes, that means that people can, you know, obviously have ideas for even different parts of the company, and they’re not worried about, you know, stepping on someone’s toes, but also just by pre framing it and telling people that we want you to feel embarrassed almost, with the nascent sea of your ideas that would obviously encourage people to to contribute more. So I guess one of the questions is, so there’s that kind of encouragement for people to put out ideas. How do you, I guess, advise people on the receiving end? So if you’re on the other end, and there’s all these ideas being generated? Is there ever a situation where it feels like, well, we have all these ideas, but we don’t execute on enough of them?

Darren Murph, GitLab  18:56

Yeah. So the counterpart to enabling everyone to contribute proposals is that you have to respect the concept of a DRI being a directly responsible individual. This is the counterbalance, you can’t have one without the other. So every major or even minor project at GitLab has a DRI, if we’re incubating on an idea, and it becomes obvious that we want to move this forward by even a day or two. Let’s keep exploring this. Before we do it. We assign a d-ri a single person who is the ultimately responsible individual for that. And the beauty of that is the d-ri doesn’t owe anyone an explanation. So a recent example here is our CMO was working with a third party agency on a brand messaging video, and instead of getting it all done in a back corner, we share the earliest possible draft of it with the entire company. We shared the link to the video, we opened up a GitLab issue for input and feedback. We said Hey everyone, watch this video, we’re going to timebox the feedback. You have a week, put all of your thoughts in here. By the way, none of this required a meeting all of this was done asynchronously so you empower 1300 people to give input at a time that works for them while spending zero minutes on meetings, which is the other superpower when you really embrace a synchronous, but then at the end of that week, the CMO is the directly responsible individual. So it’s possible that there’s so much input, the CMO can’t even read it all. And it’s and no one who is contributing feedback feels like they’re owed a response. That’s the only way it works both ways. Otherwise, you’re directly responsible individual will be so underwater and so overwhelmed by having to comment back on every possible comment that they would never actually get any things done. But here’s the beauty of doing that. Let’s say that we move forward on this project, there was a comment that was delivered, and maybe we just got a discount buried somewhere. And it doesn’t exactly go like we want it to go. So then we say, all right, what can we learn from this? How can we iterate on it and make it better? Someone who left that comment could say, Ah, I actually anticipated this happening, you can go see this comment here, time stamped and everything, because it was documented and in and delivered in a transparent way. Now our next iteration, we have a shortcut. It’s like, Oh, this person already knew this was going to happen. Now this person needs to be a key collaborator in the future iteration. So we would pull that comment out, we would start a new discussion. And that would be the foundation of what the next iteration would be. So that’s why it’s important to allow people to contribute even if you don’t act on it immediately. Because it can still be useful information in a future iteration.

Aydin Mirzaee, Fellow.app   21:43

[AD BREAK] Hey there before moving to the next part of the interview, quick interjection to tell you about one of the internet’s best kept secrets, the manager TLDR newsletter. So every two weeks, we read the best content out there, the greatest articles, the advice, the case studies, whatever the latest and greatest is, we summarize it, and we send it to your inbox, we know you don’t have the time to read everything. But because we’re doing the work, we’ll summarize it and send it to your inbox once every two weeks. And the best news is completely free. So go on over to fellow dot app slash newsletter, and sign up today. And with that said, let’s go back to the interview. [AD BREAK ENDS]  Yeah, that yeah, that’s super interesting. And I love this concept of not like people just know that not every comment is going to get a response. And they understand that this person is going to make the decision. And sometimes it might actually be a very unpopular decision and might go against the grain. But I guess, like, it’s nice to have both ends of that show, you did mention this, this one thing that I did want to dig in on is this concept of asynchronous meetings. So I’m curious for you, for example, how many synchronous meetings do you end up having in a given week? Or are like, what kind of meetings would you do synchronously? And what kind would you do? async.

Darren Murph, GitLab  23:06

So there’s before times, and after times, so before COVID, I did very few synchronous meetings. After COVID. Obviously, there’s been a huge spotlight on GitLab being an all remote company in, in large part, guiding the world and making this transition. So there’s been a lot of opportunity to connect with people synchronously to then scale that knowledge in a big way. But even now, I try to keep it to less than half of my day, I just find as a leader that my energy starts dropping precipitously and the quality of work and the quality of my mood goes down. If I commit more than roughly half of my day to synchronous meetings, thankfully, we work in a place where people can be honest about that. And they can block time in a way that they can manage their energy. Yeah,

Aydin Mirzaee, Fellow.app   23:52

So I guess, like, from a tactical perspective, like are their categories, I understand that you would be having a lot of maybe external meetings, but say, for someone who doesn’t have a lot of external meetings, and they’re working internally, and they’re trying to make the decision of should this be a synchronous or asynchronous meeting? Do you have general guidelines around how that works?

Darren Murph, GitLab  24:14

We do. We actually did a three month project. We’re dubbing it Asynch 3.0. It will not surprise you that we have an entire handbook page devoted to it. So anyone listening can dig into all of the details. But we can list the entire company and we ask managers around the company, how are you using async to make your team more effective. And then we collected all of those ideas and we shared them out so that we have this cross team visibility and other leaders. We’re learning from other leaders on how they were using asynchronous workflows in a very unique way. But I want to give you some context to async especially at GitLab. The global conversation on async is generally captured in two ways. One, is it sync versus asynch as if they are mortal enemies. When the other is, people generally look at async as a productivity measure, can we move towards more asynchronous workflows to become more effective and productive. And if you aren’t familiar with the term async, simply it means moving work forward without two or more people needing to be online at the same time. So email is a great term for async. And a phone call where both people have to be on the phone at the same time is an example of synchronous. But what we do at GitLab is that instead of having it tied to productivity or efficiency as a metric, our bias for asynchronous communication is actually a substantial creator of our diversity, inclusion and belonging value. People are when they first hear this, they’re like, What does async have to do with diversity, inclusion and belonging? The reason we put it there is that we want to focus the conversation on the reality that moving work forward without demanding someone to be on the zoom at the same time, is fundamentally more respectful of their time, if you put in the effort to tee up work so that someone else can contribute to it and move it forward without needing to be in your office at

26:14

the same time.

Darren Murph, GitLab  26:16

That’s more respectful of them, that enables them to spend that 30 minutes with their family or going for a walk or staying in a state of flow on a piece of work they’re already working on. And if you reframe the conversation around respect, it’s much easier to get by and across the organization. Everyone wants to be respectful of one another. We all want to work in a respectful work environment. So if you take the focus off of productivity, efficiency, and and all of those things, we could debate that for years, and you put it on respect, can we be more respectful of each other, it becomes a lot easier to get it ingrained in your culture.

Aydin Mirzaee, Fellow.app   26:53

Yeah, I love that. And I don’t know exactly when it will be out. But regardless, the remote handbook from GitLab, you all have made it publicly available, and you’re updating it all the time. So whenever you do check it out, you will see the latest version and I think that that’s, that’s amazing. I look forward to reading the 3.0 version. A quick tactical question on that. Do you actually say it’s a recurring meeting, you would actually block off time? But all that means is that that’s almost like the deadline by which that has to be done. But does it also exist in people’s calendars?

Darren Murph, GitLab  27:31

Yeah, absolutely. I mean, there are some recurring instances where we want to keep like standouts is a great example, if you want people to contribute status updates, status updates, meetings are the like the first to go, there are certain meetings that are just more amenable to being a synchronized and status on stand ups are a great example. But for many people, they still want dedicated time to do it asynchronously. So we would encourage people to put a block of time in your calendar some time throughout the week, that works for you to provide your updates asynchronously, because the issue there is if you convert everything to async, but then you don’t actually devote time to contribute asynchronously. It’s tough to actually do it. So then people end up reverting back to the old behavior of Well, let’s just have a meeting. But what you shouldn’t do is just block the time, because the meeting blocks the time. And then you put your inputs in at a time that’s convenient for you. It does require you to be a manager of one that’s a profile that we look for at GitLab and being ruthless about your calendar and being dedicated and devoted to blocking it to make sure that you reserve pockets of energy to get meaningful work done.

Aydin Mirzaee, Fellow.app   28:42

Yeah. I love that. Darren, we’re just coming up on time here. This has been incredible, so many great insights. Always love chatting with you. One question that we ask everybody on this show, which is for all the managers and leaders out there looking to get better at their craft of leading teams? Are there resources, books, tips, or just any parting advice that you would leave them with?

Darren Murph, GitLab  29:07

Yeah, check out all remote dot info that will take you straight into the remote section of the GitLab Handbook, you can download the remote playbook, or out of the office report. We have lots and lots of insights there, all of which will be useful for managers trying to wrap their heads around how to manage and lead in a remote world. I’ll also point you to Coursera where you search for remote team management at Coursera. We’ve ported a lot of our manager training into a Coursera course. It’s totally free to take an optional paid certificate at the end. But it’s totally optional. So dig into that. That’s all of our best knowledge on management. And I’d say on a personal level as you’re managing remote or even co located teams try to see yourself as less of a director and more of an unblocker what you’re really there to do is accept feedback from your direct reports and then unblock them and as fast as you can and let them run as fast as possible. And in a co located space, this might feel a little awkward, but in a remote space, it’s by far the best way to manage, it really sets the tone for empowering your people. And in this remote world, try to deconstruct the old office norms. Don’t just copy and paste what your office dorms were into the virtual world. I look at my family now, and my wife and I were able to adopt a newborn two years ago, I’m a huge advocate for open adoption. And that was made possible largely by the flexibility of a remote role. And I had a manager that fully supported going out to these meetings at two or 3pm, because that’s when the agency was open. And letting me work a more nonlinear workday and more unconventional schedule, so that we could grow our family in an extraordinary way. And the impact on my life and many other lives and generations to come, has been massively impacted by a supportive manager that embraced that flexibility instead of holding it against me. And I look now at 10s of millions of people going remote, if even a small percentage of those think, well, I could use this extra time to foster or adopt, we could solve the orphan crisis overnight. So as a manager, you’re really in the driver’s seat of empowering people, and a society to do things with their time that were not possible before and really empower us to leave a positive mark and a positive legacy on the world. And as a manager, you change hearts and minds one person at a time. So I would say in your next one on one, ask someone, what do you want to do with more time if you’re remote? Now? Really, what do you want to do? Start making a plan, look at the impossibilities of last year, start writing them down. It is a fun time to be a manager when you can empower people to have that much more flexibility. So I’ll leave you with that. And if anybody is interested in adoption and wants to connect with me, you can find me on Twitter at dharma.

Aydin Mirzaee, Fellow.app   31:57

That’s amazing as some great advice and a great place to end it. Thank you, Darren. 

Darren Murph, GitLab  32:03

Thanks, Aydin.