Interview: Remote-first DevOps with Brendan O'Leary, GitLab

Lauri (00:10):

Hello, and welcome to DevOps Sauna. My name is Lauri and I am the Chief Marketing Officer of Eficode. During the COVID-19 outbreak and the following pandemic, many organizations were forced to transition to the remote mode. But there are organizations that have decided to be all remote always. In the DevOps arena, GitLab is one of them. They are an open core company, and they actively share information not only about their strategy, direction, metrics, but also their approach to organizing as an all remote company. We invited Brendan O'Leary from GitLab to talk about the connection between all remote work and remote-first DevOps. Because we believe that DevOps starts already from the business validation and design thinking. We also invited Mervi Rauhala from Eficode to share her experiences transitioning business and service design from co-located practices to remote practices. Hey, Brendan, how are you today?

Brendan (01:20):

Good, good. How are you?

Lauri (01:21):

For a moment, I was terrified for having a mismatch in the scheduling because we went to the wintertime last Sunday, and you're only going to have it ahead of you coming weekend, is that so?

Brendan (01:36):

That's correct. Yeah. And actually, it happened I have another interview that they did do that. So you win not messing that up.

Lauri (01:46):

Yeah. So for once, it helps to rely on a technology and let the calendar apps figure out the time zones. I don't know if that's the case where you live, but in Finland where we live, that change is actually quite fundamental because it very concretely shifts one hour from morning to the evening, or evening to the morning. And it came real for me yesterday when I was finishing up my working day something like 5:20 in the evening. And I thought, "Okay, I've still got plenty of time to go on a run and catch the daylight." And I stepped out of my room, and it was pitch black. That was so surprising.

Lauri (02:33):

Today we are going to talk about remote work, and actually to be more specific, remote-first because I think everybody is accustomed with a thing called remote work. We have all professional people who have kind of a job the way they deal with information, they can do that wherever they are, but remote-first or all remote are completely different things. But before we dive deeper into this subject, maybe I give floor to you, Brendan, to introduce yourself, and then after you, Mervi, to also introduce yourself from Eficode. And then we'll start and talk about remote-first, all remote.

Brendan (03:14):

Sure. Great, thanks. Yeah. So my name is Brendan O'Leary. And I'm a developer evangelist at GitLab currently. I've been at GitLab since 2017. And so, I've seen us grow from about 150 team members to over 1250 team members, and that's in 65 or 66 different countries and regions. So I spend my time talking to folks about certainly GitLab and our view of DevOps in the world. But also, in our current conditions and the state of the global pandemic, I spent a lot of time talking with folks about remote work. Because, as you may know, we've been an all remote company since kind of our inception. So that's something that a lot of folks have come to us, kind of asking about how do we make it work? How do we make remote work for our teams? As many folks have been forced to kind of be suddenly remote and not planned.

Lauri (04:12):

Thanks. Mervi?

Mervi (04:15):

Yeah. I work as a team lead at Eficode and as a service designer, and you could say that I kind of help our clients to idea, design, and build either totally new services or offerings, or improve their existing services and customer experience. And you could say that I very often find myself in projects from the so called fussy front end, where we are not sure yet, we are just kind of like exploring whether we are even solving the right problems and what would be the right ways to solve the problems once we've discovered the right ones. So kind of like what should be built and why. I've been at Eficode for over three years, and really been enjoying. And I would say that very interesting to hear about like all remote company, so get some insights on how you make it work there at GitLab.

Mervi (05:21):

Of course, I would also say that at Eficode, we are very accustomed to working remotely, and probably a lot of companies in the IT world are already quite accustomed and have a lot of like good practices for that. And teams are used to having members in different countries and different time zones, and so forth. So probably this COVID situation and forced remote wasn't that much of a shock to us. But there's still a lot to learn. And hopefully, we can also share some of our good practices to companies that have been just adapting to the remote world.

Lauri (06:06):

What is also intriguing in having precisely the two of you here on the line is, Mervi, as part of her profession is very much in the beginning, very, very early stages of the software development cycle. Whereas if I think of how GitLab appears to me is then a lot of things further down the pipeline, namely the CICD pipeline. So we get to hear how design goes remote. But also, how for development on the whole goes remote. Now, there are two terms that I want, Brendan, you to introduce and speak a little more. So one is the remote-first DevOps. And interesting that that combination of those two terms wasn't known to me from before. And then the follow-up question is, how do different teams experience conducting DevOps remotely, and I actually acquainted myself with the study that you have made, and there was a very interesting comment that 43% of remote workers feel that it is important to work for a company where all employees are remote. And Mervi and I are not part of such an organization, so you are. So with that, let's hear it out.

Brendan (07:25):

Sure. So maybe I'll tackle the second part first. So yeah. And I think you're apt to point out the distinction in word choice, because I think we're very particular about that. We talk about ourselves as all remote because our entire company is remote, there is no office, the closest thing that resembles an office is our CEOs apartment in San Francisco has a kind of a conference table. I mean, that's also his dining table. And his TV is right behind you. But it is a place that, prior to the pandemic, we could meet with folks maybe that were in San Francisco, but it's by no means an office. It is literally just his apartment. And so, the fact that we have no office means that we're kind of forced to always think in that remote mode, right? So yes, I think engineering teams, and I'll talk in a moment about DevOps and remote-first DevOps, have this kind of natural inclination to be able to work remotely. There's a natural kind of tendency toward the communication can be asynchronous. We're used to, "Hey, I'm going to go make an engineering change. And then I'm going to send it to you to review and you're going to review it in your own time in a merge request or a pull request. And then you'll get back to me, and then I'll review your comments, and I'll make some changes, and then I'll send it back to you."

Brendan (08:51):

However, a lot of how business is conducted, right? And this was even true for us in the beginning. Sid, our CEO, took the company out of Y Combinator, which is a startup incubator in San Francisco, and got an office actually originally, because he said, "Oh, well, sales and finance and these other functions, they can't be remote." Well, it turned out they can, and we were hiring folks still back in Europe, where Sid was from, and we were hiring folks kind of all over the Bay Area, who didn't really need to commute into San Francisco to get their job done. And when the whole company kind of adopts that same methodology of communication doesn't need to be delayed until meetings, it can be done immediately, it can be done much clearer if it's written and asynchronous. And you can really build that culture and kind of ingrain in the culture this idea that we're not necessarily all going to be in the same room or even on the same Zoom call. We're going to record those Zoom calls so you can watch it later and we're going to allow for a non-linear workday to help folks that may have other things to attend to, which of course is all the more apparent now as many parents have students home from school, and they're having to kind of be a part time teaching aide, full time parent, full time employee.

Brendan (10:17):

And so those kinds of things we've ingrained. And I always say, it's the things that companies say they wish they would do more, we have to do, right? Companies would say, "Oh, we should document more, we should write down more of our decisions, we should document how we make those decisions and what they are." That's kind of a key tenet of remote work. But I think it goes hand in hand with DevOps, right? So to your first question in this concept of remote-first DevOps. I think developer teams across the board have realized or are definitely realizing now how DevOps and remote work really go hand in hand. To be successful at both, you have to practice that communication, and collaboration, asynchronous work. And GitLab, that's what we do. We have a publicly accessible Handbook, our teams will livestream calls together, it's all public, for the most part, and we have GitLab issues as like our central source of truth, and that's the official place for communication on projects. And that's really critical.

Lauri (11:17):

Mervi, when you listen to that and think it from the business and service design perspective, from distance, I would imagine that much of that is traditionally synchronous. And that would necessitate people being in the same room, having like immediate response from whatever is going on in the design phase. How has that changed now that we work remotely, and now, effectively, everybody is remote-first?

Mervi (11:44):

Well, it has definitely changed. But first, I have to comment a little bit about the GitLab culture book that is publicly accessible. I, for example, went through the part on communication. And I think that was really amazing that you have well documented everything and sort of the rules of communication and ways. Very well documented, it's probably now very essential, or would be essential for many companies that this kind of set of ground rules would be set. But if you are remote-first, yeah, you're kind of forced to do that. But now all the companies that haven't been forced to do that would probably be much better off if all of these things would have been thought of and well documented. So to all the listeners of this podcast, I definitely recommend to go and check out the publicly accessible handbook. It's really awesome.

Mervi (12:56):

But yeah, to the service design. You could say that, by nature, it's collaborative, and it's about bringing together different stakeholders that the users, and customers, and of course the stakeholders from our own company and so forth. And usually, this is done, of course, physically at the same time in workshops very often. Of course, some of these workshops have been also remote before, but I think some of the challenges come from the fact that the people participating necessarily don't come from the same companies or same working cultures, or of course, not even from the same cultures. So bringing all these different people with different roles and expectations and ways of working and not having the kind of the trust built among them, or anything like that. It poses some challenges. And very often it's maybe easier to facilitate these people, or create the safe environment where it's easier to express ideas and work together when you are in the same room.

Mervi (14:20):

But when you don't see the people, you don't know the people you are, for example, having a remote workshop with, it might lead into a situation where people are not able to, for example, give their best, or they might have some doubts and everything. So you kind of have to do very much more work on facilitation and thinking about what kind of tools and how to build the process where you are engaging with the different stakeholders together and make the work also like effective. So that it's not only about disconnecting meetings, or people having some, for example, technical issues and such.

Mervi (15:11):

So yeah, I would say that it's more demanding for the people who are facilitating the process is definitely. And that has changed. And of course, there might be some trust issues. Very often, we need to also engage with potential customers and users, and how to make the situation easy and feeling comfortable and safe also for them if we are, for example, testing out a product, or validating a concept, or whatever we are doing. So it needs a lot more from the facilitator than previously. It's more easier to improvise when you are in the same room and you can actually see the people and how they are interacting and reacting to different things. But when everything is in remote, then you need to plan more.

Lauri (16:11):

It's more effortful. Probably.

Mervi (16:13):

Definitely. Yes.

Lauri (16:14):

Yeah. There's an interesting, when I listen to the objectives that service design, or you want to achieve in service design, overall, it's the customer experience is the outcome, and then how quickly you go from defining the desired customer experience into indicating software release that fulfills to that. So it's inevitable that we talk about the objectives. And when I think of this remote-first DevOps, which is an intriguing term for me, I can't help but ask, Brendan, about the sort of ability to reach those objectives. So let's start with the customer experience, the developer experience, which are probably the softer part of the spectrum, and then go into the harder part is the feedback loop and the improving really speed, improving the lead time. So how do you look at the objectives and then measuring them and then actually reaching those objectives?

Brendan (17:14):

Yeah, no. I think it's a really good point. And I think it's, maybe I'll go off in a little bit of a tangent first, but I think it's an important to remember that, right now, we are in this kind of forced remote environment, right? And it's a little bit different than your typical remote working environment. For instance, even though we're completely remote, we very much value in-person meetings and discussions, and the ability to collaborate with customers directly. And we don't have that right now, which is just like everyone doesn't. We also encourage team members to do that. So we typically would get together once a year with the entire team somewhere in the world. So actually, a week after I started, I was on a plane to Crete, Greece in 2017. And we had a meeting of the whole team there, I got to meet everyone, right? Only 150 people, you can know everyone. And then we also went to Cape Town, South Africa, and to New Orleans in the United States. We were supposed to go to Prague in March. But that didn't happen, for obvious reasons.

Brendan (18:20):

And we also encourage team members to meet with each other outside of that. So there were a lot of local co-working days back when co-working spaces were open, and we could get team members together. And there was also a grant to go visit other GitLab team members. And so, I think we can't, we're completely right that so much more effort to do a lot of things that can be done quickly in-person, or better in-person. And then there's things that can be done better face to face over a Zoom call or a video call. And then there's things that lend themselves to asynchronous. So I think, back to our communication guidelines, we really think about a lot. What are the things that need synchronous communication? Let's make time for those by not having a whole lot of meetings and other things that could have been asynchronous, right? And so, we're always pushing ourselves to make those things that can be asynchronous, allow them to be. And that approach really kind of, again, it goes from, I think the similar approaches to DevOps, right?

Brendan (19:33):

So this approach to communication and kind of remote DevOps comes from the same way that developers work, right? Like, they have a development practice that allows them to integrate their code quickly into a shared repository frequently without necessarily synchronous communication, right? And preferably, as often as possible. And so again, I think we kind of, those values kind of feed off of each other and encourage each other as we are working through that.

Lauri (20:05):

Can you see the difference between the measurements or the metrics that in-office teams or co-located teams use versus remote-first teams?

Brendan (20:17):

Well, I think so. I know that our recent remote work survey showed that folks feel more efficient remotely. And I think that that's great, and I think that being able to feel fulfilled and work is fantastic. But I also think it enables us to do something, right? So we have a set of values that spell CREDIT, so they are collaboration, results, efficiency, diversity, inclusion and belonging, iteration and transparency. And so that results value, the second one, we necessarily have to, again, articulate clearly what success looks like for anyone in any role. Because we don't have these kind of lazy metrics, right? Of, "Oh, I'm the boss, and I want to see an employee that's in before me and leaves after I leave." And that tells me… I think of that as signal, whereas it might be noise, right? And it might be a signal of something worse, right? That that employee is burning out, or not as efficient as they could be, or something's in their way. And so, I think really remote allows you to, or forces you almost, to consider, wait, what are the things that we really do value? What are the results we really do want to push for? And let's have our team focus on those rather than on hours put in, but actually results that come out.

Lauri (21:41):

I was thinking, there has been a lot of conversation about this phenomenon that when people have been forced to work from home during the outbreak and the pandemic situation, then more time has been freed up from commuting, but surprisingly enough, that time has not been freed up for free time, it hasn't been freed up for work time. So effectively, people end up working more, and there are lines of work time and free time is blurring. And that's not necessarily a good thing. And I would imagine that an organization who is born of the remote-first principle, they have to take these considerations into account from the get go and they're pervasive instead of like, okay, one day we are back to old world.

Mervi (22:30):

Yeah. There was this, actually, recent study that was conducted in Europe. It was like 9000 managers and employees across Europe by Boston Consulting Group and KRC research commissioned by Microsoft. And in this study, the executives said that the productivity has increased, but then again, the innovativeness has gone down compared to previous year. But of course, it's really difficult to say what causes what. So is it the ways of working in remote that has caused this increase in productivity? That might be easier, but what explains the fact that they felt that also the innovativeness has gone down? So is it because people are, for example, stressed and they feel that they are a little bit, I don't know, in a very unusual circumstances, that's not necessarily an optimal situation to be like super innovative? And of course, for some companies, it has meant like financial challenges and probably being in a crisis mode. So that is quite interesting, actually.

Mervi (23:58):

So in that sense, probably productivity-wise, it's very good because people, well, they feel that they are productive, there's not that many interruptions as there might be, especially if you work in like an open office and everything, and of course the commuting time and so forth. You don't have to spend that sitting in a car in traffic, or in a bus, or wherever, but you can also use that time for something else. But then what happens to the innovativeness, and that's because sometimes it's also about how people feel they belong to a company or do they feel that it's safe. And also, one thing that I've been thinking a lot is that, what about all those happy accidents that happen when you just, by accident, meet a colleague and have that discussion before you go to a meeting or you meet at the water cooler, or whatever. And now, when all of these, they seem that they're not that important encounters are being totally cut off, then what happens?

Mervi (25:17):

And of course, it will be quite interesting to hear that if you are a company that is remote-first, then then how do you, for example, Brendan, deal with innovation, and when you want to create new things, is it a little bit different than maybe kind of like just be productive and do the incremental improvement of services?

Brendan (25:42):

Yeah, for sure. Yeah, I think, again, we have to be really intentional about communication, even informal communication. So if you look at, again, our handbook and our writing on remote, we have to foster that informal, for lack of a better word, random communication, right? Between teammates and colleagues. And so, we have all kinds of ways to do that. We have social calls that are made as part of the day that don't have a work topic involved, there's a parents' call where the parents can get together, and calls for different hobbies, and Slack rooms for every hobby you can name under the sun. And kind of fostering that kind of communication and making it safe to have that kind of communication at work, because it is, it should be. That's part of teams coming together. We have this concept of coffee chats, where you schedule time, or can get randomly paired up with actually in one of our Slack rooms, another teammate to spend 20 minutes and talk about, hopefully, things that aren't work related. Now, of course, sometimes work things come up, right? This is how those happy accidents happen.

Brendan (26:58):

And so, we want and encourage and foster that, but we have to do it really intentionally, right? And it's a really kind of almost in the beginning an unnatural thing to formalize discussing informal communication. But it becomes really, really important. And you realize the importance of it once you've kind of been doing it for a while. And so, again, for a company that's suddenly remote, they may not have that concept. My father knows someone who works at a government entity around here, I live near Washington DC in the States. And they're just on Zoom calls like all day long, literally from 7:00 a.m. to 7:00 p.m. And I know that's not sustainable, and I can't really do anything about it, except tell my father what I think, and hopefully he tells his friend, and maybe it has a positive impact.

Brendan (27:46):

But I think we've got to learn from each other. And that's one reason we've been trying to share as much as we can about remote work, and our remote work guide, and we also have our remote work course on Coursera now. We're really trying to get the message out there to help people deal with it, because I think it's tough. Another example is, my mother's a schoolteacher, and at her school, when they were remote, they would have staff meetings, and she said to me, "Look, it's either pandemonium of everyone trying to talk at once, or it's really not a meeting, it's just the principal talking at us for 40 minutes, and no one can really collaborate or discuss." And so, I share with her just a little snippet of part of our communication page where we talk about how we have a Google Doc for every meeting. And folks can add things into the Google Doc asynchronously, because it's kind of like a multiplayer environment, as we know, with Google Docs, and that lets you then both have input, I'll put my name and say, "Brendan, I want to say something about X, Y and Z."

Brendan (28:50):

And then when it comes to be my turn, I get to talk and it gets to be discussed. And now, that's how they run their Zoom meetings at her school. And so, I think, you have to start to be really intentional about that, both formal and informal communication, which can be awkward at first, but it's important.

Lauri (29:10):

Very interesting example, you bring it there, which is that you would deliberately introduce practices that would happen spontaneously in the real life. And that reminds me of 20 years ago when the world talked about digitization. And digitization was simply taking something which is analog in the analog world and turning it into a digital format. But effectively, by nature of it was still what it originally was. Like if you digitize the form that you had to fill in, it was still nothing but a picture of a form. But you would only truly revamp it by doing the digitalization, which is thinking, how do you refactor the business process so that you let go of all of the legacy and think it from clean slate?

Lauri (29:58):

And I can hear from what you are saying here is that there are tons of organizations who have been forced to digitize themselves, which is trying to mimic the office behavior in the digital world. Whereas this all remote or remote-first approach, which is like not even trying to artificially render a digital form of a real world, but really think it from scratch, and how should we solve this problem? Instead of thinking, how should this solution be digital? There's a big difference between those two.

Brendan (30:31):

Exactly. That's exactly correct.

Lauri (30:33):

And if I can build on that, there is one type of challenge that I believe organizations who are not fully digital or remote-first is the security, which has probably hindered a lot of organizations have been forced to acknowledge the fact that you can have a secure way of working, a secure organization, even though you work from home. So how have you addressed that specific challenge around security?

Brendan (31:02):

Yeah, that's a challenge for sure. First of all, I'd say, we have amazing teammates, who are both experts in the field of security and bought into our values at GitLab. But I think more specifically their focus for those teams have been on the concept of zero trust. And so, this concept of zero trust says, well, you don't trust any part of the system, right? Which I think, again, it's not that different than even folks that are on-premise. Now, there are some governments and other entities that operate maybe completely offline, completely disconnected environments, that you could say, okay, that's completely contained. But I think for any business, pre or post-pandemic, we've seen huge movement to the cloud, we've seen movement of critical business information in the cloud tools that they don't own anymore. And so, every business really has kind of a wide set of security concerns, whether they acknowledge it or not. And so, for us, it's not necessarily a completely different security mindset, it's just a step change from what a normal organization would have, which is, yes, you have the bounds of your network. But really, that's not the bounds anymore, right? You've got people bringing their own devices, you have different cloud providers, you have folks with who knows what access to what.

Brendan (32:30):

And so, those challenges I think for us are very similar to the same, but we layer on top of it this concept of zero trust, so that we ensure that there is only authorized and authenticated access to things that are required, right? And on the flip side of that, we have transparency as a value, which makes it a lot simpler of a model to understand. So we're very specific about those things that aren't public, right? Customer data, things about employment and personal information. Those things are very clearly not public. But a lot of the other things are. So when it comes to financial information, or the details of how other groups work at GitLab, most of that is going to be freely available to most GitLab team members, if not to the public. And that means that then we can, again, be really intentional about those things that require security and require confidentiality rather than trying to boil the whole ocean, if you will. We focus really specifically on those things that we need to protect.

Lauri (33:39):

Any thoughts Mervi from the sort of the design world? I presume that security is not one of the challenges in the all remote or remote-first service design, but there must be some other similar kind of class of challenge that didn't exist before and now just have to be solved.

Mervi (33:57):

Well, in a way, actually, of course, also, the security has posed some challenges. But it might be that, for example, when we have worked with some governmental organizations, they might have very strict policies, for example, which are the tools that can be used. And of course, sometimes those policies are not even very well grounded. They might be just that, yeah, we just say that, no, this is not allowed, and this is not allowed, and this is not allowed. Because it's easier. So for us, when we, for example, have workshops where we have people from different organizations with different policies, and different access rights, and different user rights, very often, we might have participants who can't even, for example, while they can't even install a blocking to their browser, and very strict policy. So you need to discover all of this in advance rather than have it there in the workshop when the person just can't participate because they can't even access the service that you want to use, because you need to have these collaborative tools to be able to, for example, do ideation and really make people collaborate together.

Mervi (35:25):

So this has posed very concrete problems, or well, not problems, but at least challenges that we had to be aware of. And, of course, very many questions related to licensing and security issues that I'm, for example, as a service designer, not aware of. So for me, it's very difficult to answer all the questions that participants, IT organization asks from them that, is this okay? And is this safe? How does this work? And so forth. So necessarily, I'm not aware of those. And of course, the policies have been changed with different tools, as probably the amount of people using, for example, the online collaborative tools has exploded during the remote situation. So they have also changed and improved a lot of things. But you kind of need to also know a little bit about the IT security side when you start, for example, bringing these different stakeholders and organizations together.

Lauri (36:38):

Brendan, there's an interesting old Chinese proverb to recite before I set the second question, which is, "There are three ways of learning, one is through the reflection, which is the noblest, and then one is the imitation, which is the quickest, and then the third one is the experience, which is the bitterest. Why I wanted to recite that is when we think of those companies that are considering to move either to the remote-first or considering to sort of gradually progress towards what your organization represent. Are there some experiences that you have had to maybe bitterly experience and that those other companies could just ensure that they don't stumble up on those challenges as they start going along the same journey?

Brendan (37:33):

Sure, no, I think so. And, again, we wrote a specific document focused on, if you're going remote suddenly, what are those things you should focus on? And I think there's a couple things, first of all, having a team, right? If it's a task force, or a designated person. Someone who's kind of focused on how are we operating remotely, or a group of people that are focused on how we're operating remotely, I think is really critical. Because I think, again, just to try and translate the office into remote is going to be, you're going to have very bitter time. And so, doing that is not a great idea. And so, having folks focused on how are we doing, and how are we operating remotely is really critical.

Brendan (38:22):

Second, I would say, again, making a very clear source of truth. And so, we paint a great picture, and our handbook is the source of truth for us. But that doesn't mean we don't struggle with that, right? Sure, we have folks that may be new to the company, or things that have to live elsewhere. But we're always trying to centralize ourselves on, this is the source of truth for how the company is run, what the policies are. And that really creates a lot of freedom and safety for our employees to know that that's where it is. And if it's not in the handbook, then it's not real.

Brendan (39:02):

I experienced that firsthand, as I mentioned, that second week I was at GitLab, I was flying to Greece to meet everyone, and I had read a lot in the handbook, and that's what kind of brought me to GitLab. And I also knew that Sid, the CEO, was very fond of it, obviously. And so, I was like, "Oh, I'll get in good with Sid, and talk up the handbook to him." And so, I said, "Oh, Sid, I just want to let you know, the handbook was a big part of the reason I wanted to come here. And he didn't miss a beat. He said thank you. He said, "Okay, now that you're here, what's written one way, but we really do it the other." And I said, "Well, I've only been here a week, I'm not sure." I was like, "I could find something, I'm sure." He's like, "Okay, I hope you do. And when you do, fix it, and send it to me."

Brendan (39:45):

And I said, "Okay." And as I always say, flash forward to me in a hotel room in Greece like frantically searching to find something to send to the CEO because he just gave me this mission. But that's how seriously we treat it. It's like, if it's not in the handbook, it should not be the way we do things. And if we're doing something different, then we have to change it. And so, again, that lesson learned is having a central source of truth for folks to go to be able to asynchronously consume, what is the policy? What are we doing? How do I get help with X? That is a really critical learning.

Brendan (40:23):

And then I think the last one is, the one we've talked about a number of times here, which is just not to transfer in-office methodology to working from home, it's completely different thing in normal times, remote work is completely different than in-office. And I think in a pandemic, it's even more critical to be conscious of that. We've been talking about that, because for us, again, we were all remote. So folks may think, well, nothing really changed for GitLab. But of course, it did. We've got folks that are worried about the pandemic, and stressed about what's going on, and concern for loved ones or themselves. We've got, again, parents with kids at home that need help with different things, we've got different schedules and folks that may need to take care of loved ones that gets sick. And so, it's a different time for us.

Brendan (41:18):

And one thing, again, that we came to realize is like, look, even for us, again, theoretically adjusted to not having to commute, we've got folks that are working more just because it's an easy thing to do and a controllable thing. And so, folks are working too much. And so, we decided to create, in this pandemic, we've created a couple of family and friends' days where we close the doors, again, we don't have an office to actually close. But we've created a few days, I think we've had three of them so far during these few months to say, "Hey, let's all take a breath, take a day, focus on family and friends." Which is written in our values as comes first before business, and make sure that we're all able to recharge and continue going. Because it's a challenge for all of us in this environment. And then a special challenge for those folks that had no remote work experience beforehand. But again, I don't think you can, you can't completely judge yourself and your ability to work remote, right? No one's born to do that. And you especially can't judge it during a pandemic.

Lauri (42:27):

Before I go to my two remaining questions, I'd like to ask Mervi to simply chime in to this, because you have in a miniatures scale, so to say, had to go this through from a service design perspective. So I think I recorded, set up the teams, set up the source of truth, and then try to mimic the reality. And when you scale that down to your area of expertise, has there been some mistakes that, or some lessons learned that you have experienced that you would like to share?

Mervi (43:03):

Well, for one, maybe you are a little bit too optimistic, how engaging sessions you're really going to carry out remotely where people need to focus all the time and participate. So if you can hold like a half day workshop or meeting when everybody's face to face, and that doesn't feel like too tiring. If you mimic that in the also straight in the virtual world and use the virtual tools, then it feels much more consuming. And you need to have even more breaks and everything that you necessarily don't need that much when you are physically in the same space and everything. You can walk around and do also use methods where people need to actually stand or move around and so forth. But if everybody is sitting on their desks and staring at their screen, it gets very tiring. So that is probably one of the mistakes or learnings that we've all also had that it's quite different to have like one whole day workshop remotely, it needs to be the whole flow has to be quite different than it would be that you would be in the same room physically.

Lauri (44:32):

I have two last questions for you, Brendan. And one of them is hard question in terms of hard values versus soft values, and then the other one is the completely opposite. So as far as the business case is concerned going to remote-first, what is the metric which is going to get improved by as we transition to this? So the first question is, can you think of a specific step in the feedback cycle, or a specific metric that really justifies this change? So that would be the hard question. And then the soft question is, I think you have related to me that, but let's just put it in the bed, which is the culture question. Because people often think that culture comes from the proximity and belongingness and being able to reflect each other and sort of find a non-codified way of behaving together. And if the culture isn't there, then a lot of other initiatives will be in vain.

Brendan (45:35):

Yeah, I think the overall metric, the simplest way to put that is, the ability to measure the result of work over the hours put in. And I think that applies really broadly, right? That could be, and not even just hours, right? Just overall effort. And so, you're talking about giving employees flexible work hours, being able to hire anywhere in the world, not limiting yourself to a specific geography or set of geographies. Not having folks have to commute every day, allowing teams to write down processes over learning through osmosis in an office. Those kinds of things really will allow you to measure results better. And sol, I think the metric is that.

Brendan (46:31):

And then secondly, you mentioned culture. And it's interesting, we talk a lot about culture and values at GitLab, and we make a distinction that may not be the same distinction everyone would make, but it's important for us, which is, our values are really unchanging, right? That credit values that I listed out earlier. But our culture is constantly changing, right? And so, like I said, within three years, we've hired over 1,000 people, and increased the company by thousands of percent in size. And we specifically don't hire for culture fit, we hire for culture edition, right? Because we believe that that culture is going to evolve necessarily over time. But it evolves within the constraints of our values. And so, again, enabling that culture is done through this focus on making informal communication formal, and encouraging teammates to have access to all of the information about how the business is run, encouraging collaboration from all, and again, hiring for values fit, but for culture edition, is how we focus on that.

Lauri (47:51):

Is there something personally, something for you personally that you really deem above everything else?

Brendan (47:59):

The fluffy answer would be, but true, is that I love, I'm extremely proud to talk about having colleagues all over the world, and I'm so humbled to have gotten to share and learn so much about so many different people in so many different cultures throughout the world through my work. The personal note though, maybe on the opposite side, and the family note is, so I have four small children at home. And three of them were born when I was going to an office, and the fourth was born while I was at GitLab. And just the ability of me to be there and transition back to work in a way that was flexible. And, again, maybe my wife who was at home with the baby, she might not need me during the day, but knowing that I'm right there provides this like level of comfort that really can't be measured. Because before, with the other ones, it was like, "Okay, I'm going to work and good luck." Like, "I'm going to be 45 minutes away, so hope everything goes okay." Versus, if I'm here, and there's two little ones at home and one needs a change and the other ones crying, like I can take 10 minutes and do that. And that's just such a huge difference. And so, I know it sounds like a super personal thing. But you asked so that's my answer.

Lauri (49:27):

Yeah. But I also see it from your report. When I read GitLab's 2020 remote work report, this was something that a lot of people appreciated, and I would, maybe I am wrong, but I will put it out there as well that it is a selective culture, that it's sort of that culture itself invites people who appreciates the kind of values and then you end up looking like a different kind of organization purely for the sake of people having different values and different priorities. And the fact that you allow that to happen gives you an advantage over some other organizations who have a harder time or just disallow that to happen.

Brendan (50:11):

It's true. That's very true.

Lauri (50:13):

Is there something else we haven't discussed do you think it's important, you absolutely need to put out there before we close this conversation?

Brendan (50:24):

No, I think we've touched on those things that at least I find most important. Again, we have a head of remote, his name is Darren Murph. And he writes prolifically, he actually has a Guinness World Record in writing. And so, I would really encourage folks to, if you just Google GitLab remote, you'll find our all remote guide, you'll find a downloadable playbook that we released in March, you'll find tips for going remote quickly in an emergency, and you'll find, like I said, lots of prolific writing. It's a lot to consume, but I would really recommend folks take a look, you'll find something that speaks to issues you're having, and hopefully gain some nuggets of wisdom. Maybe you won't agree with us, but at least get you thinking about how to do this better.

Lauri (51:20):

Yeah. And I believe Darren is speaking in our webinar as well.

Brendan (51:23):

I think so.

Mervi (51:25):

Yeah. Well, it has been very interesting and very nice chatting with you, Brendan, about your remote-first and how you work at GitLab. One thing that I was still thinking, did you find anything that you do differently than in the handbook, or did you have anything to report?

Brendan (51:44):

Yeah, I found a very minor thing about onboarding, but it was something. But it instilled in me, again, this idea that it is, that's the people operation section of the handbook. And I was in not that group. And I could issue a fix to it, right? Nothing makes Sid happier than that happening or even when folks outside of our company fix an issue in the handbook, because it's all open source, and it's creative commons license, you can fork the company if you want to. And so, nothing makes him happier than everyone can contribute, right? And us really embodying that and allowing folks to contribute to things that in a traditional company, people would just take for granted and assume were correct instead of questioning and making correct.

Lauri (52:34):

That reminded me of the open source practice where you may have somebody working in another open source project, and then they find a bug in the other open source project. And then first, they go and they find the bug, and then they join the team and help them fix it. It did sounds very much like what you just described. And it's so fascinating that you have been able to build a culture, like an open source-esque culture through the handbook.

Lauri (53:02):

Well, I thank you all for your time. Thank you, Brendan, for joining. It was fascinating to listen to the experience, and I hope this will also be useful for organizations who continue to wrestle their way in the day and hopefully some of them will become remote-first converts. And thank you, Mervi for joining.

Mervi (53:21):

Thank you.

Lauri (53:22):

I am personally impressed by the fact that, at GitLab, something that tends to be spontaneous have been formalized. For any organization that will want to get started with the all remote work, I guess that would work as a great practice for faking it till you make it. Make sure to check out the referred materials, GitLab's publicly accessible handbook, their 2020 remote work report where 86% of the respondents think remote work is here to stay and much more. For now, that's all I had to share. Until next time, stay safe and get yourself a virtual water cooler.