EP 44: Sid Sijbrandij (Founder/CEO, GitLab) - Corporate Transparency, Open Source Philosophy, Remote Work and Global Talent Pools

In the 44th episode GitLab Co-Founder and CEO Sid Sijbrandij discusses the importance of transparency both within a company and publicly and the philosophies of open source and success. Plus why he’s such an advocate for remote work and the troubles with hybrid offices. (0:00) Introducing Sid Sijbrandij (13:43) Corporate Transparency (22:03) Remote work (25:13) Philosophies for success (26:55) Team ops (32:37) Human elements of remote work (36:14) Hybrid work (39:07) Global talent pool (43:10) Measuring productivity (50:08) The shadow program (54:14) Staying in the Bay Area (56:57) Situational leadership (1:00:08) Outro Mixed and edited: Justin Hrabovsky Produced: Andrew Nadeau and Rashad Assir Executive Producer: Josh Machiz Music: Griff Lawson 🎙 Listen to the show Apple Podcasts: https://podcasts.apple.com/us/podcast/three-cartoon-avatars/id1606770839 Spotify: https://open.spotify.com/show/5WqBqDb4br3LlyVrdqOYYb?si=3076e6c1b5c94d63&nd=1 Google Podcasts: https://podcasts.google.com/feed/aHR0cHM6Ly9mZWVkcy5zaW1wbGVjYXN0LmNvbS9zb0hJZkhWbg Follow on Socials 📸 Instagram - https://instagram.com/cartoonavatars 🐦 Twitter - https://twitter.com/cartoonavatars 🎬 Clips on TikTok - https://www.tiktok.com/@cartoonavatars About the Show A Saturday morning podcast hosted by Logan Bartlett (Partner and Managing Director at Redpoint Ventures) covering the tech news with his friends and other people with industry expertise. Executive Producer: Rashad Assir Producer: Leah Clapper Mixing and editing: Justin Hrabovsky Check out Unsupervised Learning, Redpoint's AI Podcast: https://www.youtube.com/@UCUl-s_Vp-Kkk_XVyDylNwLA 🎥 Subscribe on YouTube: https://www.youtube.com/channel/UCugS0jD5IAdoqzjaNYzns7w?sub_confirmation=1 Follow on Socials 📸 Instagram - https://www.instagram.com/theloganbartlettshow 📱 X - https://twitter.com/loganbartshow 🎬 Clips on TikTok - https://www.tiktok.com/@theloganbartlettshow About the Show Logan Bartlett is a Software Investor at Redpoint Ventures - a Silicon Valley-based VC with $6B AUM and investments in Snowflake, DraftKings, Twilio, and Netflix. In each episode of The Logan Bartlett Show, we sit down with the people behind today’s most important startups and extract the tactics, lessons, and frameworks they’ve learned the hard way. Conversations span hiring to GTM, product, growth, fundraising and everything in between - collectively forming the ultimate playbook to make you a better CEO, investor or board member. Tap follow and enable notifications to stay ahead of the game.

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:05Logan Bartlett?

  Welcome to the 44th episode of Cartoon Avatars. I'm your host, Logan Bartlett, and on this episode, what you're going to hear is a conversation that I had with Sid Sabrandi, who is the co-founder and CEO of GitLab. GitLab's a $5, $6 billion public company that focuses on developer tools. Really interesting conversation with Sid. Sid is both building an interesting business as well as taking an unusual approach to both the level of transparency he operates with, as well as being an early person focused on remote work and thinking about that as a holistic kind of org-wide solution and how to do that in a purposeful way.

• 0:50Logan Bartlett?

  And so we go into a bunch of different stuff around all of that. And yeah, it was a really, really fun discussion. So I hope you enjoy that now. I'm joined today by Sid Sabrandi, who is the co-founder and CEO of GitLab. Sid, I've wanted to do this for a long time, mostly, I mean, GitLab's obviously an interesting business that we'll talk about, and you guys are now a public company. But I've actually personally always found you to be such an interesting leader and kind of first principles thinker in how you approach, I guess, everything, but specifically what I've been exposed to is how you run the company. And so I think I'll hopefully take us in a bunch of different directions that relate

• 1:35Logan Bartlett?

  to all those things in your journey around it. But maybe can you take us from your story and how you went from, I guess you were an engineer building $2 million recreational submarines to being the founder of a public enterprise software business? Can you take me through that path?

• 1:57Speaker 01

  Yeah, Logan, thanks for having me. Yeah, I studied applied physics and management science, which is kind of half MBA, half engineering. And afterwards, I had a Job offer at IBM, but I was very intrigued by the opportunity to build personal submarines. It wasn't a company yet.

• 2:18Logan Bartlett?

  What year is this?

• 2:19Speaker 01

  We're talking 2003.

• 2:22Logan Bartlett?

  Okay, so you were faced with IBM. Was it going to be a software engineer? What was the role?

• 2:27Speaker 01

  It was going to be a strategic consultancy on software, kind of a cool role.

• 2:34Speaker 01

  So I did what every good MBA student would do. I made a balanced scorecard, put in all the factors in a spreadsheet. And I showed my dad. My dad was like, what is this super high weight rating over here? I said, oh, that's the good story factor. And I gave a very high rating to the submarines. And he said, that is a ridiculous way to choose your career. And I said, well, I'm going to tell everyone what I do. I want it to be a good story. And years later, he comes to me and said, look, we tell everyone what you do. It is such a good story. And we're very proud. And in hindsight, it is at least something to weigh in what you should do.

• 3:14Speaker 01

  So spent five years doing that. Very proud of where the company has come since we left. Company's called Hubot Works and they still make the most submarines every year.

• 3:24Logan Bartlett?

  It's mostly focused on personal submarines, right? This is off of cruise ships and yachts and like this is for people, their own, their own purposes. Is that right?

• 3:33Speaker 01

  Yeah, it's to have fun on the water. So you're in a cruise and they have two submarines hanging off the back. And when they anchor somewhere nice, you can, you can take those and go explore the underwater world.

• 3:46Logan Bartlett?

  Interesting. Okay. And so you were doing that. You did that for five years. And then where did that take you?

• 3:50Speaker 01

  Five years into that company, I saw Ruby, the programming language. And I was always kind of curious about programming, but it always looked very boring. If you looked at how programs were written, it seemed very tedious. And I look at this new programming language or new to me and it is beautiful. It got so much better. So I was intrigued. I'm like, okay, now I'm going to give it a go. I'm going to give it a try. I bought a book and taught myself how to program. In the beginning, of course, I wasn't very good, so I.

• 4:25Speaker 01

  I started as a consultant with a very low hourly rate and kind of got more proficient over time, increased my rates and ended up doing some great and interesting consulting jobs, had a stint as a part-time civil servant. And then at a certain point, I saw GitLab while reading Hacker News. GitLab was one year old at that time. It had over 300 people who contributed to it. And I thought, wow, this is amazing. And I did a show Hacker News, like, hey, everyone, GitLab, right now you have to download it. Who would like to use it as a service? Who would like to use it as gitlab.com? And 300 people signed up to that and was super excited. So I started doing it.

• 5:09Speaker 01

  I sent an email to Dmitry, the author of the project. I said, hey, Dmitry, hope you don't mind me commercializing GitLab without you. And Dmitry said, of course, it's open source. That's the whole idea. Thanks for making GitLab more popular. A year later, Dmitry sent out a tweet to the whole world. I want to work on GitLab full-time. And I saw that tweet, I'm like, that makes a ton of sense. And I figured by that time that it was hard to make money with the dot com, but there were lots of companies running GitLab themselves and they needed more features and more support. And Dmitry, as an author, would be uniquely qualified.

• 5:50Speaker 01

  So we agreed on a monthly wage as a contractor. We incorporated and a year later, we joined Y Combinator. From that, we were nine people, I think, or seven people in 2015.

• 6:06Logan Bartlett?

  Just to back up a little bit for people that don't know, so GitLab, it was an open source project that you just got intrigued by. What drew you to this open source project in particular? What really stood out? And then maybe if you can give a little bit of a primer on how open source projects work, right? Because there's the author, but then you're going to start a company around it without the creator of this. And so maybe you can give a little bit of a primer of how that's even possible.

• 6:39Speaker 01

  Yeah, so GitLab is a single application that does everything you need in DevOps.

• 6:45Speaker 01

  It's a DevOps platform. You can go all the way from planning what you want to make, writing that software, checking that, making sure you run all the tests, making sure it's secure, deploying that and monitoring the result. GitLab is the most extensive DevOps platform. And what you get is a much faster, easier, more secure way to write software. GitLab is also open core. So when I saw it, it was open source. All the code was available to everyone. And we started a company and we tried to charge people for support. But it's kind of like a perverse incentive because if you charge for support, when a customer comes with a problem, you can tell them how to fix it. The best thing is to also tell the documentation how to fix it.

• 7:31Speaker 01

  But then the next customer doesn't need your services anymore. So over time, we started doing something else. We started making proprietary features on top of the open source. Those proprietary features, if you use them, you have to pay us a subscription. You can still view the source code. You can still contribute to it and modify it. And today, hundreds of improvements every quarter are driven by our users and our customers who are contributing back. The open source part of the license allows people to have permissionless innovation. Anyone can do anything they want with the open source part, including me, taking that and running gitlab.com.

• 8:13Speaker 01

  But you could run an alternative to gitlab.com today and you won't have to ask for permission and multiple organizations and people do that.

• 8:21Logan Bartlett?

  So it's an interesting concept, just in general. I mean, there's this open source project and there's someone else out there. You see it, you're intrigued by it. And so you're thinking, hey, I'm going to be interested in potentially starting a company around it, right? Initially, it was support contracts for it. Is it true, by the way, that you invested $100,000 that you had made from Bitcoin trading or something? That was where the original money had come from to kind of support the side project?

• 8:49Speaker 01

  Yeah, that's true. I had a few smaller businesses before and I doubled the money to 100K by speculating in Bitcoin. And I invested that to bootstrap the company. So paid for everything until we were in Y Combinator in 2015. So first...

• 9:07Speaker 01

  Three years the company was bootstrapped.

• 9:09Logan Bartlett?

  That's a great Bitcoin use case right there. And so, so you, you see this project and it's an integrated solution, right? And, uh, and historically, you know, there's old Jim Barksdale quote that, uh, money is made in software or whatever, bundling and unbundling. And so you see that there's this vision that Dimitri had started of integrating these things together and making a, uh, a suite of solutions and you'll have a single throat to choke around it. And so then the, the opportunity was how do we actually make money around doing that? And support, to your point, there's perverse incentives, right? That can exist of why don't you actually make the project product better so you don't need support.

• 9:51Logan Bartlett?

  But you ultimately landed on this, this open core, uh, business model. Was there precedent for it at that point? Open core is something that's I think become much more commonplace where there's additional features on top of it. But were there people that you looked to, uh, or looked up to to kind of build this out when you were thinking about it?

• 10:12Speaker 01

  Yeah, I, I don't want to take credit for, uh, thinking that GitLab should allow you to do the entire process. That kind of came up organically, or at least by other people. In the beginning, GitLab was just version control, just that part of it. So one tenth of the current scope. And then Dimitri, uh, didn't want to use the CI product he was using at the time anymore, Jenkins. He, he just, without asking anyone, he made his own CI functionality to test our code. And then that became a problem in the company because we, we ran our tests and it, this software wasn't good enough. So we, we allocated people to, towards improving the stuff Dimitri made.

• 10:57Speaker 01

  And we saw the people starting to use it. And then there was a person from Poland, Camille, and he made a better runner for this CI thing. It's a really important part of the testing of the code, much better than ours. So we just shut our own runner down and said, okay, from now on, Camille's version is, is, is the one you should, should use. And we made Camille a job offer like, hey, this is really good. Do you want to work for us? And he, he agreed. And then after a while, he said, look, this, this, this testing of code part and this source control part, they are really close to each other. We should really just have them in the same application. And I said, Paul, you're, you're wrong. Like, that's not what our customers want. Our customers want

• 11:41Speaker 01

  separate applications that they can mix and match. And Amitri also explained how the Unix philosophy requires you to have kind of different point solutions that you can, that you can combine. So we said, no. And, and he persisted. He said, look, this, this makes sense. We'll save a lot of work. It will better be better for our users. And we could see that we would save in work. We didn't see it was better for the users. But we agreed to it. And it turned out that it was much better for the users. You lose so much context as you hop to a new application, a new interface where not everyone might have access in everything else.

• 12:24Speaker 01

  And we, we stumbled across this secret, a secret not in the sense that we kept it hidden, secret in the sense that nobody believed it. And today, it's, it's common in the industry, right? You wouldn't launch version control without CI today. But at that time, it was, we were, as far as I know, one of the first ones to do it in the same interface. And, and it, it changed the industry. And we knew that because we had this secret, we had the opportunity to build the most extensive product. And today, if you look at GitLab, where you can go all the way from planning to monitoring, from security to governance, it's the most comprehensive scope and the most comprehensive functionality. And Camille now kind of

• 13:09Speaker 01

  has an, has created an operating principle in GitLab, which is disagree, commit, and disagree. Some other companies do disagree and commit. Really important that you can disagree. And then if a decision is made that you that you work to make that decision effective, even if you don't agree with it. But at GitLab, you can always keep making your case. As long as you execute on the decision, you can keep making the case that the decision is wrong, because the most important decision in our history was something us as co-founders said no to.

• 13:43Logan Bartlett?

  That's fascinating. And I mean, one of the other things that you've done, obviously, you've taken the company all the way to IPO. But one of the things I found most fascinating in watching you all operate is you espoused transparency in such a meaningful way, right? And I think you did it internally with employees, from what I've heard. But then also, even publicly, as you built out this suite of products, right? I remember, I assume there's still elements of this that were on your website. But I remember five years ago, going to your website and looking and you had your product

• 14:24Logan Bartlett?

  roadmap, or some of the things that you were working on and when you were going to deliver it and all of that across this very broad surface area of product. And so with contrast to, I don't know, Apple on the other end, right? Who never tells you what they're working on and they do this big reveal. Can you talk about transparency as like a cultural value for you? And, and I don't know, some of the interesting stories as it relates to things that you made transparent in the ecosystem?

• 14:56Speaker 01

  Yeah, we started with transparency because we were building a commercial company around an open source project. And what you typically see is that the wider community kind of becomes less active. You kind of push them, push them away. Because what fun is it contributing to a black hole? You contribute to a project, but you don't see all the inner workings of what happens.

• 15:21Logan Bartlett?

  And from a cultural standpoint, for people that don't know the open source world, like initially, this starts as like almost a nonprofit or a social good to some extent, where it's just, hey, we're going to make the world a better place and have this out there. And then inevitably, the tension of there being a company around it is, hey, why are we going to keep working on this if it's going to make someone else make a lot of money around it? Is that fair in some of the tensions that exist?

• 15:49Speaker 01

  I think that tension is not so much that people don't want other people to make money. It's more that it's very frustrating if you contribute to something and then someone, for reasons unknown to you, takes it in a direction that you don't agree with. And it's not even that everyone has their own interests. I think that's okay. It's more that you don't see what happens and you don't understand what happens. And there's also, if the company makes a mistake, there's no kind of early warning signs like, oh, they've really implemented something that doesn't make sense to me. And we wanted to reduce the odds of that happening.

• 16:28Speaker 01

  And I'm really glad that today you have more people contributing to GitLab than ever before. So that was the initial reason for transparency. It was, hey, let's make sure that we keep aligned to this wider community.

• 16:46Logan Bartlett?

  And how did that actually manifest itself? Like, the product roadmap is one that I remember. But are there interesting things that you all did that, outside of that, that you would call people's attention to?

• 16:57Speaker 01

  I think it's not just publishing a roadmap like, hey, this is what we plan to do next. It is actual open development. So GitLab, at some point, we had an engineer who was just new and they were asking like, hey, I can't find this product manager. On our page that lists all the team members, we looked into it and this person wasn't the product manager. It was the customer who requested that feature, who was reading his code and said, "Look, you misunderstood my request. What I really need is X, Y, Z." So we develop out in the open. And over time, it's gone from a way to interact with the wider community to a way to also recruit team members.

• 17:38Speaker 01

  Because most companies, you're not very aware of how they operate before you join them. With GitLab, you have a much stronger sense of what our strategy is. You can even watch all our boring meetings by going to GitLab and filter it on YouTube. So it went from open source contributors to a talent branding advantage to now an advantage in the market.

• 18:04Logan Bartlett?

  And when you're making decisions about, like, I was told the story that after the Series B investment, there was a big data loss and you all made the decision to actually stream it live on YouTube, your ability to, or your efforts to recover the data. And to some extent, like, losing trust with customers, especially data loss, is like cancer for a business like yours, where it's almost, you know, it just keeps spreading and it's irrecoverable. But I was told at least that this actually led to even more trust and you guys were maybe sent bottles of wine as thank yous because it was such a good educational opportunity.

• 18:49Logan Bartlett?

  How do you, one, do I have that story right? And any interesting anecdotes around that? And then, two, like, do you make decisions at all times thinking about what, how to make it transparent to the community and the employees?

• 19:03Speaker 01

  Yeah, I think for that, the data loss was limited, but we did have 24 hours of downtime, which is an extremely long time for such a mission-critical system on gitlab.com. And we made the decision to start a live stream, share the Google Doc that we were working in with the wider world. And that led to two things. It led to many more people being aware of it. So in some, in some sense, it hurt us because this is not something you're proud of.

• 19:36Speaker 01

  The other sense was that was the first time probably a company did that. So there was a lot of empathy. Also, people could see what we were doing about it. And many times when there is an outage at companies, the number one frustration externally is like, "Okay, it's down. What are you doing about it? And when can I expect it to be up?" So there was a much higher fidelity communication from our side. So I think it has pros and cons. But at GitLab, we don't have to think about the pros and cons as much as like, "We're transparent. This is what we're trying to do."

• 20:17Speaker 01

  And although our number one value is results, if we're not sure, we'll be as transparent as we can be.

• 20:25Logan Bartlett?

  Internally, as you think about transparency, I mean, there's sort of the Bridgewater, Ray Dalio, one end of the spectrum where I think all meetings, with the exception of stuff from a compliance standpoint, can be watched or dropped into by other people. There's the practical implications of transparency, right? Of like, "Hey, I'm giving negative feedback to you on your performance." Or, "Hey, I'm going through something personal and I don't want the entire company to know." How do you think about the balance of transparency versus just empathy, right? Or some of the things that maybe shouldn't be out in the open with in particular employees, less so the company side of things?

• 21:09Speaker 01

  Yeah, I think a negative feedback about someone's performance is really tough to have in the open. I think it makes it harder to talk about it. I think it makes it harder to accept the feedback. And at GitLab, that is something we are not transparent about. We keep that to a limited group. I do think that the majority of content should be more transparent. And I mentioned streaming some meetings just to the public internet. I also have a CEO shadow program where people join like 80% of my calls.

• 21:50Speaker 01

  And if that's a one-on-one with a report, typically it's 20 minutes that they join. And then we asked them to leave for the last five minutes where we discuss some performance management going on.

• 22:03Logan Bartlett?

  Makes sense. I want to get to the shadow program in a minute because I think it's fascinating what you're doing there. But on the other thing that I think you all have been very early to is remote work, right? And now it's become much more commonplace. But when you were doing it, I know there were a lot of people that doubted whether or not any company could be built to scale and become public, fully remote, right? And I know Automattic before you was, and I think Matt has been or is a board member of yours. And so I'm sure you got good mentorship along the way. But can you tell the story of how you actually

• 22:45Logan Bartlett?

  started going remote? Because my understanding is it wasn't purposeful originally, that, you know, obviously, you and Dmitry, you had mentioned he was in the Ukraine, but this wasn't something that you philosophically believed originally that you were going to do, right?

• 23:01Speaker 01

  Yeah, it's not something that we set out to do. One of our company operating principles is boring solutions. We don't try to reinvent the wheel. But Dmitry was in Ukraine. The first team member that we hired was in Serbia, and I was in the Netherlands. So we kind of started off remote. I hired a few people in the Netherlands, and I found that something very peculiar happened. I would ask them to show up on Monday to my office at my home. And they typically came in the second day, and then the third day, they didn't show up. The first time that happened, I was a bit puzzled, like, what's wrong? And they were

• 23:43Speaker 01

  like, yeah, well, might as well do it from home. We were kind of remote first, like we were using video, we were using Slack, we were using GitLab issues.

• 23:54Speaker 01

  So we kind of let that happen and then we joined Y Combinator and they said, okay, this works for engineering, it doesn't work for marketing, it doesn't work for sales. And we're like, okay, makes total sense. We'll get an office. We got one, but the same thing happened. People stopped showing up after two days because why sit next to Sid on video calls the whole day when you, when it's better to not have to commute and focus on your own work. At some point, we kind of got opinionated about it, but like this works really well and it's not going to work as well if we have some people at the office and some people remote. So we're, we're just going to be a remote company from now on, unless we see that it doesn't scale. But of course it scales much better than sitting

• 24:37Speaker 01

  in an office together. Like sitting, sitting in a room together works really well with seven people. It works really badly with a thousand people. So as, as distances increases and you're no longer in the same room, no longer on the same floor, no longer in the same building, no longer on the same continent, like there's decreasing returns to in person. So I think the, the head does it scale is kind of, it's almost the wrong way to look at it. Of course it scales a lot better.

• 25:03Logan Bartlett?

  And so, I mean, now, at the time when you were doing this, this was, you went through Y C when? 2014, 15 in that timeline?

• 25:11Speaker 01

  Yeah, winter 2015.

• 25:13Logan Bartlett?

  Winter 2015. And so, uh, obviously the pandemic, um, I think changed a lot of people's perspectives on how these things could work. But I mean, you were to some extent blazing this path without a lot of role models to look up to. And so I'm sure there was a bunch of trial and error, uh, to the point that you've actually written a, uh, what GitLab's guide to all remote. And so I think there's a very long, uh, good document about all the kind of principles and things that you all believe about, about remote. But can you, can you talk to some of the things, either, um, strategies or, uh, or processes, uh, or just philosophies

• 25:57Logan Bartlett?

  in place that like has allowed you to be successful with a remote company of how many people do you have today?

• 26:04Speaker 01

  Yeah. So we have about, uh, over 1,500 people at GitLab today.

• 26:10Speaker 01

  And we found out during the pandemic that remote was a lot easier than we thought. Because everyone was so skeptical of it, we always assumed it was very hard. We had to work extra hard to have a have a well-run company. During the pandemic, companies discovered that it was very possible to run remote. I do think that along the way, because we were so conscious of how we were organized, we discovered some other things. We recently bundled those in Team Ops. So Team Ops kind of is a bundle of four big principles that that we discovered and we think are useful for other companies, whether they work remote or not.

• 26:55Speaker 01

  And what is Team Ops? Can you talk through the four principles? Yeah, so the first one is creating a shared reality for your team members. And that entails things is having a single source of truth, like being really diligent about not duplicating information. It is about situational leadership and varying your your management style. And it's about having shared values. The second principle is to allow everyone to contribute. We do that through things like iteration, reducing the scope of things and getting them out faster. Always allowing other people to give suggestions of what you should do in your role,

• 27:38Speaker 01

  but without the necessity to take them. I think you're able to combine the best of the speed of hierarchical organizations and the information that flows in consensus organizations. Always allow people to bring suggestions, but never require the recipient of them to acknowledge them or argue with them. So you don't have to defend your decisions because if you would require that, things start flying under the radar. The third principle is decision velocity, like making decisions faster. Giving agency, having a bias for action to explain your reasoning, to work asynchronous when you can.

• 28:21Speaker 01

  Be transparent in how, not just how you measure, but what the measurements are for all the different parts of the company to the extent you can. And making sure that people always kind of work with the same other people to the extent that you can.

• 28:36Logan Bartlett?

  Yeah, I want to go through a bunch of your operating principles and things like that because I think a lot of the things you just said touched on. Touched on a bunch of them, but on the, on the remote point. It seems like you've, you've found a handful of tactics, like I've heard you say meetings are very expensive, right? Which I think is fascinating as a, as a concept, or it's actually good if people are doing other things in a meeting. To some extent, like sending email, I shouldn't feel guilty about it. Can, can you, can you talk through like how you actually put some of these things into action? Like are documents sent in advance before, before a meeting?

• 29:21Logan Bartlett?

  Are there, are there videos for presentations to sort of help people prepare asynchronously? How, how do some of these things manifest themselves?

• 29:31Speaker 01

  Yeah, I think almost everyone agrees that they're, they're longer in meetings than they would like to be. And it stands in the way of work. And one thing we do at GitLab is always prepare meetings, so always have an agenda upfront. The second thing is to evolve that agenda into the notes as the meeting goes. And I've seen so many companies where the agenda and the notes are different. I think that's ridiculous. The agenda is kind of what you're going to discuss and then you fill out what you discussed as you go along. When you want to ask a question, you typically put your name in the kind of the agenda that's becoming the notes as a kind of a placeholder. Preferably with the question you're going to ask.

• 30:15Speaker 01

  What we never do in meetings is present in meetings. A meeting is very expensive in the sense that you need to bring everyone together at the same time. It is hard, especially if you work across time zones. GitLab has people in over 60 countries, so that is sometimes very tough. So it is encouraged to have a presentation and you can send that to people in advance. Typically, you also link it from the agenda, you link the agenda from the meeting invite. If you want to present, that's also encouraged, you record a video beforehand. Then another thing that you alluded to is that we think it will be spectacular coincidence

• 30:57Speaker 01

  if a hundred percent of a meeting is interesting to you, probably not a hundred percent is relevant to you, and it's totally cool to do your email on the side, to do whatever you want on the side. And it's okay to say, oh, sorry, I wasn't paying attention, can you repeat the question? That is, that is not a problem, it's, it's a, it's almost a badge of honor. You, you're apparently are a good manager of your own time, you thought that part wasn't relevant. It also helps that notes are taken, so it's much quicker to get up to speed with the meeting if it suddenly is interesting or, or something happens. So we try to have quicker meetings and allow you to do some of the prep upfront.

• 31:42Speaker 01

  And we allow you to not have to feel bad if you're, you're looking somewhere else in your camera.

• 31:49Logan Bartlett?

  That's fascinating. So, so a meeting at GitLab will, agenda is in advance, materials, if I, if I wanted to present something, I'll record it in advance and then people may or may not be paying attention in the meeting, uh, which leads to, I guess, overall efficiency. So it's really a level of, um, respect for people's time, I guess, to some extent. Um, and, you know, saying, hey, if we're going to call you together, we're going to make good use of, of it. How long do your meetings typically last? Do they, do they last a long time because you don't want to have a lot of them? Or does it, does it end up being short because all this work and prep is done in advance?

• 32:28Speaker 01

  Yeah, typically meetings last 25 minutes. And if there's too little time and we feel we need more, then we'll, we'll schedule another meeting, but they, they don't go over.

• 32:38Logan Bartlett?

  Interesting. Now, one of the other elements of remote that I know we felt and I've heard from my companies is the connective tissue to other people within the organization, right? And to some extent, it sounds like you guys are very explicit about principles and values. And you know, there's documentation, so there's shared history and shared knowledge and all of that stuff. But there still is this interpersonal kind of human element, right? Of knowing your coworkers out, you know, not just in a work, work setting. And, and so occasionally, it sounds like you guys will get people together or you'll host people at your, your house if they're, if they're local.

• 33:23Logan Bartlett?

  But you'll also do informal coffee chats and kind of informalizing some or doing, formalizing some of the informal interactions that happened in an office. Can you talk a little bit about that and how that actually works?

• 33:37Speaker 01

  Yeah, I believe that informal communication is essential to creating trust and camaraderie at the, at a company. I believe that getting everyone to an office is a ridiculously expensive way to create that. Spending 10% of payroll on just the, the infrastructure, the, the office and everything that that entails. Plus 10 hours of everyone's time a, a week for the commute is very expensive. I can't believe it that people are forced to commute to work to be very inflexible in, in how they plan their day. And that's then to sit behind the laptop in the office. If you're gonna bring people together, make good use of that time.

• 34:21Speaker 01

  People at GitLab get together, we're not gonna sit them through a presentation. We're not gonna sit them behind the laptop. You're gonna hang out together and do the things that are better in person. Like doing an excursion or having an informal communication, conversation with a bunch of people.

• 34:36Logan Bartlett?

  Interesting.

• 34:37Speaker 01

  We believe that you should formalize informal communication. You mentioned the coffee chats. When you join GitLab, we're gonna require you to pick five people and have a 25 minute conversation with them. It's a bit awkward to send someone a calendar invite for a coffee chat without an agenda, without, without a reason. Maybe you don't have to explain why you picked them. But it works really well and it's not something that necessarily has to happen around a water cooler. You can have, you can organize that informal communication.

• 35:10Logan Bartlett?

  How do you keep it from being awkward? Or is it just something people power through? Do you have like prompts for people to talk about? Or like, how do you actually actionabilize this? If I send Sid an invite and we just show up both on the Zoom or whatever you guys use together, how do I keep it from being awkward?

• 35:31Speaker 01

  Yeah, we do have kind of conversation starters. Typically, in a one-to-one environment, it's easy. Like, you have things in common, you've noticed things. And otherwise, you ask, like, where do you live? It's just like making small talk in real life. So one-to-one is relatively easy. Think in a group setting, like if you bring your team together, it's like, now we're going to have fun. But that's a little bit harder remote. So if you Google GitLab informal communication, we have over 15 ways in which to kind of do that in a call setting. And that there's all kinds of things from playing games together, to doing quizzes and everything else.

• 36:14Logan Bartlett?

  I think I heard from you prior to the pandemic, you all and the handful of other companies that I know were all remote at some decent scale, were pretty dogmatic about remote needs to be first principles across the board. And even if people want to go into the same office together, there can't be different classes of people on a meeting, right? Where Sid and I are in a room together and then someone else is on Zoom and it makes that person feel like they're not as included due to body language, due to subtleties of

• 36:56Logan Bartlett?

  communication, all of that stuff. I guess, is that something that you still believe today? And what does that mean for, I mean, we've had so many people in our company, or so many portfolio companies that are doing this kind of hybrid thing. Do you think that's kind of a failing strategy?

• 37:14Speaker 01

  I think in hybrid, it's very easy to get the worst of both worlds.

• 37:21Speaker 01

  And I think a good example of that is a hybrid meeting where some people are in a conference room together and some people dial in via video. I think for the people who are dialing in, it's hard to see who's around the table. They tend to have a little bit more latency. It's harder to get to get to make a point. It's harder to hear what people are saying. For the people who are around the table, they typically don't have their chat open. They don't have their computer in front of them. It's harder to screen share to them. It's harder for them to screen share with the rest. It is, it's kind of the worst of both worlds. So.

• 38:01Logan Bartlett?

  You guys have been so out in front and leading around this remote stuff. And then there's obviously so many norms over the course of the last, whatever, 100 years or 1,000 years of how businesses operate in person, right? But now there is this, this weird mode that's popping up more and more. And I guess there's people like, I think it's Toby from Shopify, right? Haven't they actually ripped out all their, their conference rooms? And so you can have an office, but we're going to replace it with, with a bunch of individual phone booths. And so everyone's going to be on a level playing field.

• 38:34Speaker 01

  Yeah, I think that's an example of that kind of strong leadership that's needed to make hybrid work. And that's, that's a great policy. I've not heard a lot of other companies do it. And I want to make sure that people don't conflate us being all remote with something like working from home. At GitLab, if you want to work from an office, we totally support that and we'll pay for the office space you rent, but we just won't rent a big office space to put everyone in. Everyone can rent a space close to where they live and work from there.

• 39:07Logan Bartlett?

  Let's say Logan's starting a company tomorrow and I'm saying, hey, Sid, I want to go remote. How much of the benefit in your mind do you feel is the talent unlock of, hey, you have access to the global pool of, of people that can do the job? Why be limited to a certain area versus the efficiencies that are gained within, you know, commute time and, and all these other things that we've talked about here? Is it mostly the talent unlock? Cause we haven't really talked about that specifically, but maybe that's implicit to this whole thing is that you get access to the entire world.

• 39:42Speaker 01

  Yeah, I can't pick between the two. I think they're both a really big deal. And what you see talent wise is that you can be much more opinionated as a company. If you're dependent on whoever lives close to you, you're going to be a less explicit company because you don't want to alienate any potential people you recruit. Well, if you have a much broader set of people to recruit from, you can get more opinionated in in what you stand for as a, as a business. Uh, yeah, and I, I, I think the, the benefits for not having to commute and not having that, having to go to that office are, are great, but they're great both for the employer as for

• 40:26Speaker 01

  uh, the team member who has a lot more flexibility in how they, uh, how they, uh, spend their day.

• 40:32Logan Bartlett?

  So, so I want to shift gears a little bit to the operational side of things. And we've touched on a bunch of, uh, these earlier, particularly when you were talking about some of the principles that you all have, but, um, one of the ones that, that you alluded to, uh, I, I forget the way you said it, but, uh, disagree, commit, disagree. Uh, I, I've also heard you say something to the effect of you would rather have someone make the, make a decision quickly and be slightly wrong than slowly and be right. What is this bias to action and, and, uh, and how do you think about just having people operating with less information, but, but moving the ball forward?

• 41:10Speaker 01

  Yeah, I think most organizations probably should make decisions faster rather than slower. And most decisions are two-way doors. If you make them and it turns out you're really wrong, you have the opportunity to reverse the decision and, and then to go back. Um, so as long as you can go back, it's probably better to, to try it and, and see where you end up rather than wait, because most of the time you, you tend to be right.

• 41:40Logan Bartlett?

  Are people empowered to make those, uh, those decisions at an individual level? Like, uh, how does this actually manifest itself within the company?

• 41:48Speaker 01

  We try to empower people to the extent that we can. We try to push decisions down to the, um, to the people who have to do the work where we can. We try to make it very clear who is making a decision. Typically, we have a DRI, a directly responsible individual who can make the decision. We try to prevent consensus decisions wherever we can.

• 42:13Logan Bartlett?

  How do you go about preventing consensus decisions around? Like, is it having this DRI concept of who the person that is ultimately going to own it? And it's their call at the end of the day? I feel like people inherently find comfort in consensus because it allows them to share blame if something goes wrong.

• 42:32Speaker 01

  Yeah, I think so. The opposite of that is accountability, which I think is healthy. And at GitLab, you should give everyone the chance to chime in on a decision. You shouldn't keep it under the radar. But those people who chime in should expect that they might not hear back about what they say. They can expect that the person making the decision will read it, but nothing more. And if they have questions or if they want more information, they'll ask you. We're not going to require the DRI to convince all the people who've chimed in. They can make the decision.

• 43:10Logan Bartlett?

  And one of the other things you alluded to earlier was just measuring a productivity and ultimately coming up with, I don't know if you call them OKRs, but coming up with different things that groups ultimately get measured on from an output standpoint. And so I think one of the examples I had heard was engineers maybe get measured on, or one of the things they get measured on is how many changes they make to code that actually impact customers in a given month or something. I guess, how did you come up with a framework of actually coming up with these objectives?

• 43:52Logan Bartlett?

  Like, was this something that you thought of from a first principle standpoint? That everything should be measurable and therefore we should come up with these different tactics? Or did you see someone else doing it?

• 44:04Speaker 01

  Yeah, what we faced when we started GitLab as being all remote, people say, how do you measure productivity? And we said, well, that's really hard to measure productivity. And so we'll do our best. And for example, in engineering, engineering is notoriously hard to measure productivity. What we do is we measure how many changes in the software that you make that went all the way to users and customers. And then the requirement for every change is that there's some benefit. Either you improved the documentation, or you added some API, or you've made some flow better, but there has to be some customer benefit. And when we rolled that out, all our engineers said, you know what?

• 44:48Speaker 01

  This is super easy to game. I'll just make all my changes smaller. And we said, go for it.

• 44:55Speaker 01

  And we expected that the measurement might kind of stop being useful as people try to game it. But what we found so far that it is a really good way to measure it because as people break up their work, it becomes easier to review, less risky to deploy, easier to communicate, coordination becomes easier. So it's beneficial if they break it up. We measured them not on an individual basis, but in their team to make sure that collaboration and making each other better is rewarded as well. But we also kind of learned something about a lot of other companies where there's presenteeism. And people are rewarded for showing up early, leaving late.

• 45:39Speaker 01

  Even some remote companies, the managers are watching kind of what time people come online and things like that. We really discourage that at GitLab. And for example, as a manager, you're not allowed to ask people about their working hours unless you suspect they're working too long. Also, we don't thank people for working outside of office hours. If you want to thank someone for that, that's okay. You thank them directly. But you don't do it in a group setting because we don't want to incentivize that behavior. Sometimes it's necessary, but we don't want people to think that that's the thing. That we're rewarding and we'd rather have people be able to work during office hours.

• 46:21Logan Bartlett?

  Did engineers push back the hardest on these OKRs as you were coming up? So what group was the hardest to get on board with it? And then what group has been the hardest to come up with OKRs for? It may be the most qualitative.

• 46:38Speaker 01

  Yeah, so at GitLab, OKRs are things that we do different in that quarter. What's these like, for example, MR rates, the amount of changes for an engineering group? We call that KPIs, key performance indicators. And the only department that doesn't do KPIs is our legal department. If I'd have to make KPIs for legal, it would be how fast they review things,

• 47:06Speaker 01

  what ratings they get from other departments and how much trouble we get into as a company. But we've talked to some other organizations and it's really hard to capture in metrics. So we haven't gone there. They have agreed to do OKRs, which is also maybe not an everyday thing for legal departments. So very happy about that.

• 47:30Logan Bartlett?

  You kind of want your legal department protecting against catastrophic risk as one of their main KPIs, but that might be hard to measure on a regular basis.

• 47:41Speaker 01

  For sure.

• 47:41Logan Bartlett?

  And so what group pushed back the hardest?

• 47:44Speaker 01

  Measuring results is not easy. It's one of the harder things we do. And we frequently have OKRs that specify things that are inputs instead of outputs. I'm going to give this many workshops instead of I'm going to have this many companies sign up after my workshop. It's hard to measure output and result. And it's a continuous thing we focus on as well as iterating. Iteration is our toughest value at GitLab. And for example, I regularly do iteration office hours where we discuss.

• 48:23Speaker 01

  With people who bring problems or who bring a case like, hey, what would be ways in which we can make this smaller?

• 48:32Logan Bartlett?

  In being so public around this, I mean, I'm hearing all the things you say around remote and some of these like more first principle management styles that are just going to be different types of type of operating than other companies. Do you, do you find that when new hires come in that they have already pre-qualified themselves into being the type of person that would, that would be enjoy all this because you are also public around it? Or does it end up being, hey, maybe I thought this is what I wanted, but there's a little bit of an adjustment period because this is so different than, than what, I'm sure it's a mix of both, but, but which of those

• 49:16Logan Bartlett?

  like, do you typically see with employees as they kind of get used to this way of operating?

• 49:21Speaker 01

  Yeah, there's, there's certainly people who kind of self-select in. Someone said, I feel like I found my corporate soulmate after reading our handbook. I'm sure there's people who opt out and we, we never heard from. I think the degree to which people are prepared really varies and that's okay. People who join are really surprised to the extent we live our values that these are all things we kind of really practice and that the handbook gets like sometimes 10 updates in a minute, in 10 minutes.

• 49:56Speaker 01

  I do think there's an effect kind of degrees from the CEO where sometimes it's more pronounced in, in the meetings I attend and that it kind of dilutes a bit, the further it goes from me.

• 50:08Logan Bartlett?

  Now, the, the shadow program, you mentioned it earlier. You said it's, it's one of the best things you've ever, ever done. Can you talk a little bit about what it is, how it came to be, how it works?

• 50:21Speaker 01

  Yeah, so I was recruiting for a chief of staff and

• 50:26Speaker 01

  I've read a couple of articles that said a Chief of Staff is great because every year or two you'll have someone who's seen all the different parts of the company can now go on and contribute to a specific part of it. And I was like, okay, that's, that's nice. But we're, we're, hey, we have 50 new managers or something like that in the next two years. And I'm going to train one person. That, that doesn't seem enough. A lot of it, of the benefits of being a Chief of Staff are not so much what you do, but kind of the meetings you're allowed to attend. We figured we could be better in that. And so people sign up, they have, it's, it's a paid assignment, but they have to kind

• 51:09Speaker 01

  of be on vacation from their regular work. They join about 80% of my meetings. So that's about 12 meetings a day that they join. And then they take notes during those meetings, they make changes to the handbook if something comes up during the meeting. They sometimes are asked for like feedback or their opinion on, on things, especially if it's in the function they came from. And they're, they're, they see a lot of all the different functions in the company, which is super important because we're functionally organized. So the, the first thing that kind of breaks down is, is the communication between different

• 51:50Speaker 01

  functions. And if you have a good idea of how other functions are thinking, you'll be more effective in your role.

• 51:57Logan Bartlett?

  And so are these people that already work at the company and they opt into this as a, as a learning opportunity? How long does it go for?

• 52:05Speaker 01

  Yeah, it's for two weeks. It used to be three weeks. I was inspired by the, by medicine where they say, see one, do one, teach one. But we did, we made it see one, teach one. So the first, the second week, you have some additional responsibilities of kind of training the person coming in. It's two weeks and we graduate like 30 people a year.

• 52:33Logan Bartlett?

  And so these are existing employees at GitLab that are opting into doing this and they take a break from whatever other job they have to come and do this?

• 52:41Speaker 01

  Correct. We used to also have people from outside the company participating, a few. That was really cool, but because we're a public company now and there's a big, you come in touch with material, non-public information, we cannot longer do that.

• 52:58Logan Bartlett?

  And so the benefit, you have a Chief of Staff as well, or is this taking the place of Chief of Staff?

• 53:04Speaker 01

  I have a Chief of Staff as well and her name is Salas. She's been amazing. And she has a whole team of people helping her. So she has about four kind of internal strategy consultants who are available to get put on projects that need to move faster. And two engineers that assist me with with certain things I need or seeing the product or want more information on.

• 53:32Logan Bartlett?

  And so the Shadow Program, as you see it, is it's really for the benefit and the development of the individual. It sounds like the stuff you get out of it is updated meeting notes and your handbook notes as makes sense, but it's really a program for their for their own personal development?

• 53:55Speaker 01

  Correct. Like 80% of the benefit is for them and 20% is the notes and handbook updates.

• 54:01Logan Bartlett?

  How many people have gone through this program now?

• 54:03Speaker 01

  You can find out if you Google GitLab Shadow Alumni.

• 54:10Speaker 01

  30 a year and we've had it for a while, so more than 50.

• 54:14Logan Bartlett?

  Wow, that's great. Super, super interesting, interesting program to set up. I've never heard of other companies doing that. Very cool. Now, one, one, one other one that I have for you, I mean, you have the opportunity to live wherever, quite literally, because you're a remote. First company and you've espoused, you know, you built a lot of the playbook for, for how to operate like a remote company and yet you've, you've stayed in the, in the Bay Area, which is a little contrarian, I think to, to what we hear most days, at least in the, some of the public discourse about, about the Bay Area. What, what originally

• 54:58Logan Bartlett?

  drew you to, to the Bay Area and what's, what's kept you around when you can live, presumably anywhere in the world?

• 55:07Speaker 01

  Yeah, I really love living in San Francisco. It's kind of Disneyland for entrepreneurs and for people who love tech. I think the, the density of people who are in the tech industry is, is unrivaled here. I spent a lot of time kind of with informal communication with other entrepreneurs, with investors, with just people in the tech industry. And for example, I have multiple dinners a week typically with people like that. And the benefit of San Francisco is they're here. So it's been a great thing. And by the way,

• 55:48Speaker 01

  just checked, checked on the CEO shadow program alumni. It's 119 so far.

• 55:53Logan Bartlett?

  And so do you see the Bay Area as it's, I mean, as remote has become more and more commonplace and at least companies are popping up in different areas. Do you see the Bay Area continuing to retain that benefit from your perspective that it's going to have that density and you see yourself staying there for a long time?

• 56:16Speaker 01

  I think the, the advantages of San Francisco might, might further increase. I think the, the density of investors and CEOs and experts and board members and executives is unrivaled. I think meeting up in person is important for informal communication.

• 56:38Speaker 01

  And because of remote, big, successful companies like Airbnb and Uber no longer have to hire like 10,000 plus engineers that they all need to put here. So it's going to be more of a city of leadership than having every single person in a company here.

• 56:57Logan Bartlett?

  I think you're a fan of High Output Management, is that right, by Andy Grove?

• 57:01Speaker 01

  For sure. I think one of the best management books ever. A lot of management books could be summarized with one blog post, and I think this is at least 10 blog posts. So super, super dense and useful information and something I recommend to all managers and other leadership at GitLab and other companies.

• 57:20Logan Bartlett?

  What were some of the lessons or one of the lessons that you took away from that that you think has been most impactful to your own execution?

• 57:29Speaker 01

  I think some of the lessons in the book are what you would call situational leadership today. The amount of involvement from the executive really depends on the proficiency of the report and everything else. It was an inspiration for a blog post I write about, I wrote about kind of things you should consider when delegating. I think I've listed over 15 things you could think about. One other thing is that the one-to-one between a manager and report is very important. I try to do them weekly and they tend to be run by the report, which is, I think, the way it should be.

• 58:14Logan Bartlett?

  Well, Sid, thanks for doing this. Anything that I didn't hit or any topics that are top of mind for you?

• 58:22Speaker 01

  No, thanks for the diligent prep and I hope that people check out GitLab and what we can do for companies. We're very proud that when companies switch to GitLab, they see that they can have a lower spend, they can, they have to invest less in kind of... Combine duct taping, all kinds of tools together. And instead, those people doing the duct taping can start doing something useful instead. You see that people are more productive when they don't have to hop between 10 different apps. And they see that they have a faster cycle time between starting an initiative and seeing the result of it.

• 59:05Logan Bartlett?

  Well, I know you, I know one of the, I forget how you termed it, but what is it? Simple solutions?

• 59:12Speaker 01

  Boring solutions.

• 59:13Logan Bartlett?

  Boring solutions. You even say it in a more, more slightly negative way than I was going to frame it. But boring solutions. But I really appreciate how not boring, a lot of the ways that you operate are. I think the level of transparency, being out in front of remote, thinking through all these different programs and that. I mean, you're, you're unique in, in a lot of ways in how, how you're operating. And so it's, yeah, it's been, it's been fun to watch and I wish you nothing but the best in, in kind of trailblazing in these, in these ways. It'll be, I'm sure there's a lot of people that have already emulated some of the stuff you've done to date. And I'm sure there'll be many more to come.

• 59:56Speaker 01

  Really appreciate you having me as a guest and thanks for preparing and bringing back all those, all those stories. Really appreciate it, Logan.

• 1:00:08Logan Bartlett?

  So that'll do it for the 44th episode of Cartoon Avatars. Thank you to Sid Sabranji for joining. Thanks to Rashad, Justin, Andrew for, for, for the help. And thank you to everyone for listening. Hope everyone has a nice weekend and look forward to seeing you again next week on the 45th episode of Cartoon Avatars. Have a good weekend, everyone.