Founders Talk – Episode #70

Leading GitLab to $100M ARR

with Sid Sijbrandij, Co-founder and CEO of GitLab


All Episodes

Sid Sijbrandij is the Co-founder and CEO of GitLab — an all-remote company and complete DevOps platform. As a company, they have their eyes set on taking the company public to IPO and they’re very outspoken about their culture, open handbook, and how they work as an all-remote company. We talk through where Sid came from, the early days of GitLab, why IPO vs a private sale (like GitHub), what it means to put “family and friends first, work second,” how we should view work, and his biggest fear — the company failing.



DigitalOcean – DigitalOcean’s developer cloud makes it simple to launch in the cloud and scale up as you grow. They have an intuitive control panel, predictable pricing, team accounts, worldwide availability with a 99.99% uptime SLA, and 24/7/365 world-class support to back that up. Get your $100 credit at

Brain Science – For the curious! Brain Science is our new podcast exploring the inner-workings of the human brain to understand behavior change, habit formation, mental health, and being human. It’s Brain Science applied — not just how does the brain work, but how do we apply what we know about the brain to transform our lives.

FastlyOur bandwidth partner. Fastly powers fast, secure, and scalable digital experiences. Move beyond your content delivery network to their powerful edge cloud platform. Learn more at

Notes & Links

📝 Edit Notes


📝 Edit Transcript


Play the audio to listen along while you enjoy the transcript. 🎧

Sid Sijbrandij is the co-founder and CEO of GitLab, an all-remote company and complete DevOps platform. As a company they have their eyes set on taking the company public, and they’re very outspoken about their culture, their open handbook, and how they work as an all-remote company… But I’ve always been curious about where Sid came from, where did he grow up, where did he study, was he any good at school… So that’s where we started.

Sid, what kind of person were you before GitLab?

[laughs] Still the same, hopefully… I was born and raised in the Netherlands. I’m the oldest of four siblings. My parents are still here, still together. I did well at school. While I did well learning-wise, I was teased a lot when I was younger.

I went to university – I was really good at physics in high school, so I figured I’d study that. I also enjoyed it – it turns out that physics in university is a lot of math, which wasn’t something I was particularly good at or particularly liked… So I switched to management science, which is kind of a combination of an MBA and a taste of all the different engineering disciplines, which was super-fun to do. In hindsight, I should have learned how to program. I liked what I did on the side as well.

The first year of university I saw this ad on the local marketplace for an infrared receiver, so you could skip to the next mp3 track. I’m like “That’s amazing!”, so I ordered one, and I checked out the website, which was on Geocities, which kind of dates me…

Oh, yeah. I loved Geocities.

[04:01] Yeah. And it was open source, already at that time - the software, but also the hardware to run the device. And there was a big banner on the site that said “I’m not selling these.” Like “Huh? That’s weird. He IS selling them.” And I figured out he didn’t wanna deal with sending individual orders across the ocean… So that was my first business - I bought them from the person making it (he was a PhD student) and I started selling them. I asked people to send me cash with some cardboard behind it, so you could less easily spot it, and that’s how I got in business. It was fun, we did that for a couple of years. After graduating I did an internship at IBM, the IBM Extreme Blue program. That was super-fun. We got to work on a conversation bot.

After that, I had the option to get a job there permanently, and I was looking at strategy consulting… But I couldn’t stop thinking about submarines, because my wife and I went to a boat fair and we saw a submarine there, and I kept calling the owner, the investor, like “Joe, hire me.” There was nobody on the payroll. There was just an inventor, and then an investor. And it got down to the wire, because I had a job offer in hand, I had to make a decision, and he decided to offer me a job… But he asked what I wanted to earn, and I said something completely reasonable. He proceeded to offer me the salary he thought was reasonable, but that was reasonable 50 years ago… So I was finally poor after graduating. I always figured I’d be the poorest during my student days, but I had to move in back with my parents. I lived in their attic while making the life support system for the submarine.

Luckily, nowadays it’s a lot more professional at U-Boat Worx, but they’re still around, and they make the most submarines in the world. That’s kind of my story growing up…

Interesting. Well, let’s back-track a little bit. I’ve got a couple questions and I don’t wanna interrupt you, because I love hearing these kinds of stories of where people come from, who they are today - sure, definitely, you’re still the same Sid. There’s not much changed about you, except for maybe the external perception of who you are, what you’re building… And there’s a lot of assumptions that can come from that. And in many ways, what I try to do with this show is sort of demystify people like you, to some degree. Because to me, you’re amazing; you’ve done some really cool stuff at GitLab, and we’ll get into that, of course… But I like to know where you came from, to understand the building blocks of how you got to the mindset that is required to be who you are today, to do what you’ve done, to lead a company like you have done.

You’d mentioned – and I don’t wanna go into this too deeply unless you want to, but you mentioned being teased. How did that affect you when you were younger? Was it hard for you to make friends, were you a loner?

Yeah, I was a loner. It was hard to make friends. I struggled with finding joy in the social processes, and I wasn’t good at it, I didn’t particularly like it. I stood out and I figured I’d have to befriend some people; I’d befriended people at the bottom of the social ladder, who turned on me and started teasing me instead. So I think what it gives you being teased is that you tend to be a bit less sensitive to social signals, and I think that from time to time served me well as an entrepreneur, where you go against common wisdom, from time to time.

Most of the time you go with common wisdom. One of our sub-values at GitLab is boring solutions. We don’t try to reinvent the wheel. And sometimes you have to do something that doesn’t make sense to the rest of the world. And that doesn’t mean you’re always right. I’m still the same person that had a failed startup; I wasn’t successful, so I’m not any smarter than when I had that failed startup, but if you keep trying long enough, at some point hopefully you get lucky.

At GitLab we got lucky, and I learned to follow – when there’s a conflict between what the world says and what you think yourself, I’m able to depend a bit more on what I think myself, and I think that’s sometimes really handy.

[08:19] See, that’s what I mean by these details - your perspective of that time in your life, and how that sort of shaped you to be resilient as an entrepreneur, to sort of go against common wisdom. To me, that’s awesome. If there’s someone out there that was teased earlier in their life, and you’re reminding them of that, and you sort of gave them a new perspective on how you can sort of change that perspective on that moment in your life and use it towards a future that’s more joyful. You know, more joy.

I like that. In high school if you stand out and if you’re different, it’s a problem. Later in life it’s an asset to the diversity of thinking and perspectives.

I might paraphrase a little bit, because I didn’t watch the full video, but I’ve got it in my list to check out, but I watch Tim Ferriss from time to time, because I think he’s a pretty wise fella… And he was talking about being a specialist, or being a generalist. And he said the idea is to be a - again, paraphrasing… What I grokked from it most was that if you’re a generalist, you could be a specialist with all of your generalist skills. So it’s kind of like that. You use a lot of what you learned throughout your life to get to where you are, but then use all those skills you’ve learned all your life in that position. You don’t just master one skill or one thing and become CEO of GitLab. You had to do several things throughout your life, and I’m sure that you still use a lot of your experiences, a lot of your skills, a lot of the patience that you’ve learned over your life to be and to do what you do.

Yeah, I like how what you learn in life – I worked at a lot of organizations where I saw some things going really well and some things going not so well, and I love how when you start your own business you get to do things differently. And I don’t think one organization is necessarily better than another, just different. And I like how at GitLab we optimize for speed of decision-making.

I’ve seen a lot of organizations where things have to fly under the radar, because as soon as you ask people for input, you owe them involvement in shaping the final decision. So you have initiatives flying under the radar for a long time, because as soon as you pop up, you wanna get to a conclusion quickly, otherwise you attach so many people that you become paralyzed in the decision-making process. And that’s something we’re trying to avoid at GitLab - like, no, you share your decision openly, so you can get more input and more data, but only the directly responsible individual has to decide, and you don’t owe everyone an explanation, you don’t owe anyone a joint decision.

There’s many examples like that, where we’ve tried to learn from what you’ve seen in your life before, and try to improve upon it. It doesn’t always work, and that’s not an ultimate solution, but it’s fun to try something different, and to articulate why, and try to add something to the world.

Would you say that some of your values - if not all your values - capitalize on vulnerability? I wouldn’t wanna connect the dots, but you’ve had some vulnerability younger in your life, and that’s a value I see being portrayed… Leveraging your vulnerability is pretty interesting, because it lets you be transparent. Transparency is vulnerability, to some degree, or can be perceived in that case.

[12:01] Yeah, what we say is that allows us to do iteration and transparency. Some of our most important values is kind of a low level of shame. We’re not afraid of sharing that something isn’t perfect yet, which is necessary for iteration. If you wanna get something done quickly, it’s not gonna be perfect and you’ve gotta live with it, like “Hey, you could do better work, but you don’t have the time to do it.” I think we as a company try to have the confidence, like “Okay, this isn’t done yet.”

One of the web pages I’m proudest of at GitLab is our Maturity page, which shows for every part of the product how good it is. By being frank about that, we can be open and we can iterate and we give ourselves room to ship something that isn’t perfect, because we’re not pretending it’s perfect. I think that’s really important. And that comes from the [unintelligible 00:12:59.05] had earlier in life. I sent the infrared receivers, and I sent them by postal mail, and most of the time they would arrive in a week, sometimes in two weeks, and sometimes in three weeks. It was just all over the place. We promised to ship them in two weeks, but there was this 5% customers for whom it would arrive late. To this day I kind of regret not being open and just communicating, giving the range to people, and instead pretending something that isn’t completely true. So that’s what we try to do.

It sounds like you value owning flaws, or owning just truth, really. Because sometimes the truth hurts (as that saying) and obviously being honest isn’t being vulnerable, but being overly honest can be seen as a vulnerability. But you sort of capitalize on being overly honest, because that’s – you can’t make excuses for the truth. Truth is truth.

Yeah, I think that the truth is the first step towards fixing something. Yeah, some things aren’t great, aren’t where they should be. Take the speed of We want that speed to be higher. But you could argue with the benchmarks, because they’re never perfect, and everything else… But if we do that, we kind of put energy in that instead of energy in actually fixing it. And take the maturity of certain parts of the application - by having that page out there, it motivates our team to increase that maturity and make sure that things become better.

If you’re in denial about things as an organization, it makes it really hard to remedy the underlying cost, because you’re pretending there’s nothing wrong.

Well said. You mentioned earlier on you were interested in physics… It seems like you were also interested in psychology. Did you read any books in particular, any classes, any studies at all into psychology to understand vulnerability, shame, these kinds of things?

I think that every human is interested in psychology. One of my favorite Wikipedia pages is about common misperceptions. What I also like is mental models of how you view the world. Gabriel Weinberg of DuckDuckGo has a great blog post, and he even wrote a book about it - the mental models he finds repeatedly useful. That’s just very interesting, to have all those worldviews exist at the same time, to be aware of all these different ways to view the same facts and figures.

I couldn’t help but quickly google “DuckDuckGo mental models” and find Gabriel’s blog post, and I was skimming that for just a second… Skate to where the puck is going. That’s an -ism, but it’s definitely a concept to use to explain things, to explain how to do things in business even. You’d mentioned that before, going against the common wisdom. That’s a mental model.

[16:06] Yeah. There’s so many core competencies… Conspicuous consumption, price elasticity. The list goes on and on. I’m actually reading the blog post now, during my accent removal classes, and it’s been fun to go over them. Many I already know, but there’s a lot of new ones, and it’s fun to see all these ways of viewing that people invented over time.

I got into – you said every human is, to some degree, interested in psychology. I could agree with that. Maybe not even self-admitted; not everybody wants to admit that. But I’ve kind of found some appreciation for it when I was studying behavioral economics, and I was just trying to find – I got really interested; I’m a curious person, and I got curious about how people make financial decisions. The idea of sunk cost bias, for example, when you continue through something even though you know you’ve invested – I’m paraphrasing the behavior, but basically you keep going even though you’ve put a lot of money in. You know it’s a losing game here, but yet you continue, you persevere, sometimes to your detriment. To me, that’s what got me interested in psychology, and we started that show called Brain Science.

What we actually talked about recently - not mental models, but mental frameworks, which I believe are pretty much synonymous, but our framing of it was mental frameworks… How you view the world, how you see things, how you model what’s in your brain, how you perceive the world and continue on. It was a fun show.

And it helps you. For example, there’s loss aversion. We count a dollar lost – we experience it as much more painful than a dollar gained. So if you know that, all of a sudden you know why we do insurance. Insurance is overhead. We might as well just save, for everything but the largest expenses, that you really can’t bankroll yourself… But it doesn’t make sense to insure something you can afford out of pocket.

That’s right.

But it makes sense if you view it from the perspective of loss aversion, because you’re okay with paying from insurance, you’re not okay with taking some cash loss on things. So I think it’s really interesting, and it’s a great way to understand yourself and the rest of the world.

Okay. Let’s dig deep into the early days of GitLab, and let’s go back as far as you want to… When I recall the earliest days – now, I’ve been around for (I would say) a while… Just to preface it, we began our primary show called The Changelog back in November 2009. So we just last year celebrated our tenth anniversary, which was awesome. We’ve since spawned a full-on network of developer podcasts that we really love… And we’ve been doing this for about ten years now, so we’ve been paying attention to this space very closely.

And the early days, I can recall, was this perception that – you know, GitHub was really popular, and then we see GitLab, and it’s an open source version of it; change a few letters, very similar. Take us back to the earliest days of GitLab that you can recall. Why did you get involved, what was it for you? Why were you even concerned or involved in these problems that it solves?

Yeah, so GitLab was created by my co-founder, Dmitriy. He created it because he needed it. He had two things he wanted to improve. He wanted running water, and he wanted better collaboration tools at work. And he started with the latter. When he created GitLab, it was to solve his own need, but he also open sourced it, and within a year he got 300 people contributing back to it.

[20:05] That’s when I saw it on Hacker News, and I thought “Oh, that’s interesting.” I’d recently become a developer; I became a developer later in life, and I was surprised that all the tools I used were open source. I was a Ruby on Rails developer, and it’s amazing what ecosystem you get with Ruby on Rails, and all of that came for free… Except there was GitHub, and it was not free and it was not open source. It struck me as very ironic that the thing you collaborate with is not something you can contribute back to.

So when they started GitLab, I thought that makes a ton of sense. These collaboration tools should be open source. I looked into it, I opened up the codebase, and the codebase was pristine. It was really high-quality, which is remarkable. Most of the time you either have the founder doing it in their spare time; they might create something to test a new technology, or something like that, and you get kind of a non-idiomatic thing, where they took this pattern and kind of over-used it a bit, because that was what they were doing at the time. But that wasn’t the case. It was really beautiful, and idiomatic Rails. Also, all the contributions from those 300 people were integrated perfectly. So I thought “Wow, that’s a really good start.”

Then I looked at what was missing. What was missing was you couldn’t try out GitLab. You had to install it before even giving it a spin, so that’s why I created, so it would be software as a service. I was aware of the success of Salesforce, SaaS was the future. I didn’t create it yet, I just made that landing page, allowed you to sign up, and posted that to Hacker News. When that trended, I had a couple hundred people that were interested, and that’s how we got started.

Interesting. I never heard the story of how it actually began that way. I mean, Dmitriy beginning, and even having a pristine codebase - you’re right. Usually, it’s somebody tinkering with a new thing, an interest, and the codebase is (as you said) not idiomatic, and not the best patterns, not the best examples of the code, or the best examples of the framework, for example, to go that route.

Given the timing of GitLab/GitHub, what do you say to people, especially those who were there in the early days, that look at maybe the interface, and the name, and the mascot..> The similarities. What do you say to them when they say “Well, you’re just simply a copy and paste of GitHub”? What do you say to them?

GitHub and GitLab share a common ancestor in GitWeb. So GitWeb is the interface that came with Git out of the box. It allowed you to run a simple server. So in my mind, I don’t know how the name GitHub came about, but I can imagine that it was inspired by GitWeb. Now, the project already had a name when I met it, and if you change it, you change people’s URLs, and download directories, and the whole thing… Especially for software, a name change is very disruptive, so we never changed it.

Let’s talk about where you’re going. Let’s fast-forward quite a bit, just to sort of tease where we’re heading. You’re planning to IPO this year; November, if I understand correctly, is that right?

Yeah, that’s what we have set as a goal in 2015. I don’t think it’s likely we’ll make that date in November, but we’re getting pretty close. We’re over 100 million dollars of revenue. We’re still growing at a healthy clip. We’re unlikely to go public end of this year, but it’s getting really close. We’re now five years after taking our first external dollar, so that’s been an amazingly fast trajectory.

Yes. Over 400 million currently raised, I believe, if I got my numbers correctly. Current valuation - roughly 2.75 billion, which is what I wanna go into… GitHub was acquired a couple years back for 7.5 billion. They were valued at the time for two billion. You’re valued now over what they were valued at then… And I’m just curious, when you choose to go – so their route was a private acquisition, rather than going public (IPO). What is it that makes you choose that route for your company?

[28:05] Well, first of all, it’s not always your decision. The majority of the company is owned by investors. It’s not my decision, it’s a joint decision with the investors, and if someone came about and offered something that’s way more than we ever expected, that we can get to in the future, then I think it’ll sell.

The reason that we have the ambition to become a public company is because it would allow us to stay independent. If you stay independent, it’s more likely that you’ll be a good steward of the open source project, and that we’ll be able to preserve and further improve our values and the way we live them. That’s important to us, so going public would be a good way to maximize the chances of achieving that.

Well, also given the fact that you’re pretty focused on being transparent, which is to some degree an oddity for a public company. Public companies have to be, by regulation, very transparent with their fiscal reports and things like that, but you’re already sort of practicing all the practices that you would need to master as a public company, currently.

Well, yes and no. It’s ironic that it’s in the name, public company, but apart from the things that they’re forced to disclose, they tend to disclose very little outside of that.

Exactly, yes.

If we go public, we’d probably be the most transparent public company. It’d be fun to try that and to kind of push the envelope of what we’re disclosing. The more you disclose, the more things people have to sue you over and to cause problems… So it’d be interesting to see how we manage to stay and increase our transparency as we become a public company.

Yeah, there’s a lot of risk in it. Even doing things like this, once you go public, you’re gonna have to be very careful with what you say to someone like me… Even though I’m not a journalist, I’m just a podcaster, but it’s written, it’s recorded, it’s in history, it’s stuck, so you have to be very careful once you’re at that stage… Because it could influence your stock price, it could influence selling or buying, it could influence a lot of different things. Your perception of the business…

For sure. But there’s kind of rules around that, and the rule for this is material information, so it’s fine to talk about how GitLab started as a company. It’s not so great to say “Oh yeah, we’re over 100 million in revenue. Actually it’s (let’s do an imaginary number) 650 billion today.” Like, wow, that was a material disclosure. You can’t do that as a public company, because this podcast is not a channel in which we regularly communicate in information, and anyway, you and your editors would know it before the rest of the world, which is also not great.

But I think we can navigate that, and we’ll see. We now have over 5,000 pages of our internal processes that are open to the public, and there’s gonna be some more disclaimers on there, but we’ll see what we’ll be able to keep having. It says on our Transparency value that it’s not gonna be easy all the time, and we’re gonna have – you’re basically providing a ton of content for your future short-sellers. Short-sellers - they short a stock, and then make a case why it should be worth less. They’re doing a useful job, but it’s very annoying running a company having to deal with that. And now, you’re giving them 1,000 times more things to weave into their narrative that they’ll be presenting.

[31:57] So that’s gonna be super-interesting, to see if we have the resiliency to deal with that as a company.

I believe in you, that’s for sure. What I wanna get into - you mentioned that it was not just your decision, but your investors and others who make this decision… And I really wanna understand - if GitHub can be acquired for that amount of money, at that same valuation, and given the annoyances you mentioned that could happen as a public company, and you know… You can share what you’d like, but I would imagine you have at least some early offers, or some indication of interest from people that would be willing to acquire GitLab, or bring you on to a Microsoft-esque, a Goliath like Microsoft… Why go through the pain of being an IPO company, and the scrutiny, when you can be the same company you are with no change whatsoever? How do you factor that decision to continue to go towards IPO, versus an acquisition that kind of gives zero opportunity for disruption of culture.

Yeah. Well, first of all, a shout-out to our investors relations person, Tony… Speculating about becoming a public company itself is something that is regulated. And the closer you are to becoming public, the less you can do of it. So the fact that we can talk about it now is only because we’re a private company, with no immediate plans to go public.

We don’t necessarily wanna cash out the company, a so-called exit. I like to keep going. I’m having fun, it’s interesting, we’re adding something; I think the people at GitLab are producing great work… And the community is really helping the product become better at a rapid pace. On the 22nd we’ll have GitLab 13 come out, with all kinds of great new features… The reason that we need to do something is that we raised money in 2015. As soon as you raise external money, they wanna get that back, hopefully more, and you need to get to a liquidity event. The two options are selling the company, or going public. And selling the company, you need to have interest.

A thing I can talk about is that in 2014, when GitLab was less than nine people, and I was living in the Netherlands, and we never took an external dollar - we got an offer for ten million dollars to sell the company. The company was owned completely by me and Dmitriy at the time. And my accountant said “You should sell. You’ll never have to work again.” My response was “I really like work.”

Yes. [laughs]

Of course, if you think it will be worth much less in the future, you should get out. But the most common reason to get out is it’s draining, it’s tiring. So that’s why we try to not get tired.

Yeah. Wouldn’t you be able to stay though? I mean, if you got acquired, wouldn’t you – I mean, you’re the negotiator, you can negotiate your ability to remain as you are. Why would things have to change given an acquisition?

I mean, generally there’s some change, but that doesn’t have to change.

It changes over time. There’s a couple factors - who is the acquirer? Some companies are better than others, I think. Microsoft has shown, for example with LinkedIn, they can do a great job of letting the company run by itself. It also changes over time. It tends to be straight after the acquisition you still have a lot of control, and then it dilutes over time.

But most of the time when a company is acquired there is a strategic benefit. The company is of more value combined with other things than before. For example, what you see with GitHub is they have now all kinds of Azure DevOps functionality, like packages and code spaces. It’s now branded as GitHub and shipped as part of the GitHub product. And that’s creating a synergy.

[36:07] During the selling process you probably make a plan for what you’re gonna do, but you should expect that to continue. And you might not always agree with it. In the end, it’s not your company anymore. Over time there’s gonna be more and more things you have to do that you don’t agree with. So most founders end up leaving after a couple of years, or something like that.

Personally, you’re saying that you like working, you wanna keep working, and any acquisition would possibly change that. Well, not just you, but you know…

Yeah… Well, first of all, the decision whether to sell or to get acquired is not about me. There’s a ton of investors, they have the majority of the company. There’s also 1,200 team members, so it’s not so much about what I want. The only thing is if I wanna stop working on GitLab, there’s no super-obvious successor. There are some really talented people that can run the company well, but sometimes that’s a reason where the investors say “Well, if the founder is no longer there, it’s a good time to sell.”

But whether we sell or not depends on what’s best for everyone involved, of the shareholders, as well as the shareholders that are [unintelligible 00:37:30.20]

Let’s dig into something that makes you quite unique… You’re all-remote, and in many cases, especially in today’s climate of the world, there’s a lot of press out there, a lot of interest in working from home and doing it well, ways to work remotely… And from what I can understand, you’ve always been all-remote. Is that correct? Always all-remote?

Yeah. I think the only exception has been Y Combinator, where we stayed in Mountain View for three months with the whole company. But other than that, we’ve never congregated in an office.

So if you’ve always had this as a thing – how did you get to all-remote? Was it just by accident, and you stumbled into it, or you sort of developed some values around it, and you were like “Well, this really makes sense for us, because of these reasons…” How did you get there? How did you get to all-remote?

Yeah, it started with me being in the Netherlands, Dmitriy being in the Ukraine, and our first team member, Marin, being in Serbia. So it wasn’t practical to get together. Then I hired a few people in the Netherlands and they came to my house (I had a spare desk) for a couple days… But after that, one day they just didn’t show up, but they were online, so I’m like “Hm. Interesting.” They never asked permission, but they just didn’t see the use of commuting to my place every day when all we did was work online anyway.

And after Y Combinator, they told us that there’s been very few companies that were all-remote successfully, so they advise us to get an office, and especially for the non-engineering functions, centralize them at the office. But after we got an office, the local people stopped showing up after a while. Kind of the same way as in the Netherlands - they came in for three days, and then they saw that it had little added value, and they didn’t ask for permission, but they just stopped showing up, and kept doing their work.

That’s awesome.

So we’re kind of remote because there’s just no added value in being in the office.

So they didn’t ask for permission… That means that you have a perspective of giving individuals an opportunity to make choices in their position that best-suited themselves, as well as their position and the work they do. They didn’t have to ask for permission because you already sort of gave them permission to make their own choices, it seems…

Never explicitly…

[40:04] Right. Just through your demeanor.

They never asked me. But the other people were working remote, so I figured that they didn’t think it was a big deal.

At what point did you begin to develop values around it? You’ve got a lot of – like you mentioned, 5,000 pages of written material that describe and help people understand your culture, as well as internals and externals… So how did you get to this point where everything you were doing was documented?

Yeah, in Y Combinator we kind of changed our ambition. Before going to Y Combinator we wanted in five years to be a company of 50 people. During Y Combinator we changed our perspective. We want to be a company valued at at least a billion dollars, which kind of means at least 1,000 people in five years.

Then I was on-boarding someone and I was like “Darn, I’ll have to explain this…”

…again and again and again. I’d better start writing some things down… And it escalated from there. I think every significant company has a knowledge system or something resembling our handbook… But most of the time it falls into disrepair. It’s not updated anymore. It’s stale. So one of the most important things we do is work handbook-first. If you wanna communicate a change, you should change the handbook and communicate the change you make to the handbook. You shouldn’t use a presentation or an email or another medium to communicate that change.

That’s interesting, because that was my next question, “How do you then sort of become handbook-first?” and that makes sense. So if you wanna initiate change, it being in the handbook doesn’t mean that it is change; it’s sort of initiating change, because you or others have an opportunity to iterate on that and contribute back to it, and disagree or agree… Do you often have fights, to some degree, or spats, or however you wanna describe them, on changes?

Well, disagreements…

Yeah, sure.

Yesterday I wanted to change something in our values. We have a value in transparency, like explain why, but we also have this mode in how we operate - the directly responsible individual doesn’t have to consult with everyone before making a decision. And it wasn’t clear what wins. Does the DRI have to explain themselves? And I’m really afraid of decisions flying under the radar, because if people find out about the decision, you’ll have to explain yourself. So I wrote up “No one’s owed a WHY. DRIs don’t have to say why.”

And then someone in the organization, Emilie Schario, said “Well, I disagree with that.” We called about it, and she had some good points, so I asked her to close my suggestion and make one herself. I’ll review that, and I assume it’s gonna be better than mine, and we’ll merge that and it’s set.

There you go. How do you think your company has been better because of this? Communication-wise. Not just helping you to onboard. That was sort of a selfish - for good reasons - initiative early on, but it’s now blossomed into this highly-communicable handbook that 1) clearly states to the outside world that has interest of working at GitLab, the kind of company you are, the kind of ways you operate, but at the same time it’s highly-communicable to the people inside to foster and develop and ingrain in black and white, in text, your culture, who you are, how you operate.

Yeah. I think externally it really helps people opt into the organization. A lot of the people that ended up joining GitLab were people that saw the handbook and were like “Yeah, I’d like this way of working.” I bet there’s also a ton of people that see our handbook and are like “I don’t like that way of working”, and never end up working at GitLab.

[44:17] So I think that companies are gonna become more differentiated. As remote working becomes more common, you don’t have to appeal to all the people in your immediate area. If you can appeal to a small group of people, but all over the world, that is enough. So you can be much more opinionated as a company.

I think internally, it causes us to be very intentional. For example, we’re very intentional about informal communication. Being remote, you have to design informal communication. It doesn’t happen at the water cooler, because you don’t have one. But you can still facilitate that, so we have the concept of coffee chats. You are scheduled with someone else once a week, and you get to meet that person for 25 minutes. And it’s like having that water cooler conversation, except it’s a random person in the company. It could be from another country, it could be from another department. You don’t just meet the people on the same floor.

I think intentionality is on average a good thing. Same way with our values - there’s not just six words, there’s a whole lot of context on what we exactly mean, and then there’s 14 ways in which we reinforce those values.

What are your values?

So the acronym we use is CREDIT, and it stands for Collaboration, Results, Efficiency, Diversity, Inclusion and Belonging, and Transparency.


Yeah, for sure. Iteration is, I think, the value that is toughest at GitLab. It’s the value everyone coming in externally says “I love iteration…” And then internally, we do it because it works really well, but we dread it, because it’s so hard to have this idea about the future, and then have to break that up into smaller pieces.

Gotcha. How did you get there? I mean, sure, you’ve got these six values, but did they just develop over time? Did they naturally bubble up, like “Okay, these things seem to be common trends throughout our documentation, throughout our ways we present ourselves, the way we present new changes to our guidebook…”? Was it a committee decision, was it you? Who did this?

I think early on we took the material we created and what was happening and we said “Okay, what are our values?” and I think I took the lead in that. We had 13 values. Then I quizzed a few people, including myself, and no one could remember more than three of them, so they were a bit too many, and causing people not to know… So I work with my CEO coach at the time, John Hamm, to cluster them. We tried to cluster them, and we came up with these six overarching values that now we recite from memory, so it’s getting a lot better.

And we checked them against five dysfunctions that can happen in organizations and made sure we address those five dysfunctions… And those became our values. I’m very proud – if you look at the bottom of the Value page, you’ll see an Edit button. If you click that and then click History, you’ll find that these are living and breathing values. They continually get refined and refreshed. Not that the six big words change frequently (we’ve had those for years), but we continually try to improve the explanation of them. I think that’s what’s important - it has to be a living document.

Do you happen to know the five dysfunctions by memory?

No, I don’t.

[48:03] I was curious about those, because I like how you pair that up with these six core values against the – it could be more dysfunctions, but five most common dysfunctions in organizations. That’s an interesting perspective, to identify and capitalize on the opportunity to establish these values - I don’t know how to describe them besides just saying values - against the dysfunctions.

Actually, I think the five dysfunctions is in your list here, so… I think it’s “Absence of trust” – this is based on your Docs, so thank you, Docs… Absence of trust, fear of conflict, lack of commitment, avoidance of accountability, and inattention to results.


I don’t know where that came from. There’s a link to that, too. Maybe that goes somewhere else. Wikipedia!

It’s a book by Patrick Lenicioni.

There you go. We’ll put that in the show notes for everybody to listen to them too, so you can find that… That’s awesome, I like that. I’m always curious how these things come about. Over time, organizations become to better document themselves. Some, as you said, they’ll start these guides or these handbooks, or some sort of knowledge base, and it becomes into disrepair, not look at often… But it seems that you’ve found a way to not only communicate in text that everybody can contribute to and edit and scrutinize how you operate, but you’ve been able to keep it alive. It’s a living thing for your organization.

Yeah, and it’s remarkable - there’s more updates to this than fit on one page in this month that we’re currently in, so that’s great to see… Actually, I think now we have 14 ways in which we reinforce our values. I think we’re gonna add another one, because I think we’ve just launched the GitLab Songbook. So we’ll have a 15th way in which we reinforce our values.

Let’s fine-tune down to an execution – I’m not sure where those might stem from from a value, but it’s definitely something I value that you’ve shared with the world. We’ve put a post out there from you on called Family and Friends First, Work Second… And it was an explanation by you, saying why GitLab publicly shut down for one day. Now, this (I believe) was back on May first, if I got the date correctly…

Take us back to the Slack post on Friday, April 17th, where you shared why. Give us the behind-the-scenes of that post, and what Family and Friends First, Work Second means to you.

What it means to us is that we understand that work isn’t the most important thing in people’s lives. A lot of companies make you pretend that it is, and I’ve always thought that was weird. Obviously, family and friends come first, and if there’s something that you have to attend to, that is more important. We try to give people that space.

We’ve noticed that after Covid, people were more productive than before. We’ve always been a remote company, so that wasn’t the change; it’s logical that people can deal with that. But it’s strange that if people now have to take care of their kids, because the schools were closed, and still overall productivity was up… Maybe not for all the people with kids at home, but overall, because there were fewer distractions, people just started working more. And we wanted to make a statement at the company level, like, although we appreciate everyone contributing, this is kind of weird. We want people to take time off. That’s why we said, “Okay, the first Friday of the quarter we’ll have a no-work day if you can, if your function allows it.” We’re not gonna have any meetings, and we’re gonna work on other stuff.

[52:03] It wasn’t so much about that day, it was about the message we send… Like, “Hey, we recognize that everyone is working hard”, and people should allow themselves some time off, because it’s intense… And if you’ve worked remote before, you know you’re more productive per hour, and you should use some of that productivity to work fewer hours.

I have a quote here from the article - one thing you said was “Over-working or maintain the status quo during a crisis is not a badge of honor. In fact, I’ll be more proud if employees were taking time off to reset and refresh, or spend time adjusting to this new normal with their families.”

Maybe I’m wrong, maybe I don’t know many IPO companies that are on that trajectory… Maybe companies are changing, I don’t know, but this to me doesn’t seem like a public company kind of thing. It just seems like you’re gonna be the opposite of what public companies do out there, because not everybody is saying that kind of thing, Sid.

Yeah. You get what you measure, and I’ve always found it strange that companies measure hours put in and hours worked and hours behind the desk, and kind of celebrate that internally.

For example at GitLab you’re not allowed to praise someone publicly for working outside of office hours, for that person. Or working hours, I should say, not office hours. And that’s a very conscious decision. We wanna celebrate results. We’re a very driven company. People work very hard, but we make it about working hard and achieving results, not about working long. Many times, people should be good stewards of their time, and make sure that they make the hours count… But we’re not counting the hours. That’s not what we’re about. We’re about results, not input measures, and that’s what we want to articulate.

Last year we tripled the size of our team, and a lot of people come from companies where the competition is who can take the least time off, and we want the competition to be who can get that work done, but take the most time off. That’s what we’re trying to do… But not very successfully, because we see people working very long hours during this crisis. It’s a tough thing to change, and it’s a tough thing to have that focus on results, and sometimes people try to make up for it by working long hours, and sometimes it’s even needed. It’s a complex subject, but I’m proud of the way that we celebrate people taking time off.

It is a complex subject, because – I’m reading this book called Indestructible, and it’s so interesting, because the story in there is about a woman who is dealing with a crisis in their life, and she got addicted to this pedometer application. The problem wasn’t the pedometer, the problem was the crisis in her life, and the thing she could control was her ability to do what the pedometer said, essentially… To earn the points, and do the steps, and be active, and stuff like that. So her opportunity for control in her life, in this story, in this book, was the fact that she could control listening to the pedometer, and doing what it said. That was her lever of control. And it is complex, because if you take someone’s ability to control their work - maybe the only thing they can control in a world like we’re in right now - away from them, then that can have ill effects as well.

Yeah, for sure. And people are like (as I was saying), “What am I gonna do with all that spare time that I have, since I can’t go out?”

“I just wanna work!”

[56:05] Well, I’ve found a solution. It’s called City Skylines. It’s a super-awesome computer game, and I’m having a lot of fun with it. But it’s hard, and the interesting thing is “Why are games so much fun?” I think one attribute is that level of control. Another attribute is – I call it transparency, but you have a lot of insight in how the mechanics work. The rules are very clearly defined.

There’s boundaries.

You know how it works, it’s understandable. And it’s an important lesson - what people want at work is a sense of progress (that’s the most important thing), but they also wanna know clearly how it works, what the rules of the game are, and they want something where they have a high degree of control and autonomy to influence the results.

Yeah. Let’s focus a bit on - for this last part here - maybe some hypotheticals, or actuals (we’ll find out). I’m curious, given GitLab’s future and what you know you’re gonna do, what are the things you’re most afraid of, and the things you’re most excited about, about the future of GitLab?

I’m afraid of the company failing, and we made a nice web page about that. If you google “GitLab biggest risks”, you’ll find that. I’m super-excited about the impact of the product and the community around it. We’re making people more productive. With GitLab you can get from having an idea to coding it and having it used and getting feedback about it and getting people excited about it in a shorter amount of time. And that’s one of the things that make games fun - a very quick reward cycle, a very quick cycle time between doing something and seeing the result. And with GitLab we’re making that easier for developers, operators and security people. I think that’s super-fun, and I’m very proud that every month more than 200 improvements in the product come not from our team members, but from the wider community around GitLab.

Let’s ask this final question on the horizon - I call it my horizon question. What’s on the nearby horizon, that not many people are aware of? Not so much that it’s brand new, or unknown, but something that people are less aware of, or not very aware of… On the nearby horizon for you, for the organization, that you could share today.

Yeah… I think what’s super-interesting is that it’s clear now that a DevOps platform makes a ton of sense, and we now see our biggest competitor, GitHub, starting to ship more features. How that perception in the market changed a couple of years ago - everyone assumed that old products would be connected to each other and you’d have product marketplaces, and now it’s clear that the idea Kamil (an engineer at GitLab) coined a couple years back, “Let’s make it a single application [unintelligible 00:59:23.21] That’s kind of gone silently, and unnoticed… But I think it’s a really big development, and it will greatly help people be more effective.

Sid, it’s been fun talking to you. I love to go back into your history, into the early days of GitLab, and even yourself, to sort of grok where you came from. We didn’t go too deep, but deep enough; maybe one day we’ll have a chance for a part two, but I really enjoyed learning a lot about you and a lot about the DNA of the business you’re running, and a little bit more clarity around why IPO versus private sale… Still more questions for me, but we’ll live it there for now. Thanks, Sid. I appreciate your time.

Yeah, this is great. I’m always up for a second round.

Awesome. We’ll make sure we do it then. Thanks, Sid.

Thank you.


Our transcripts are open source on GitHub. Improvements are welcome. 💚

Player art
  0:00 / 0:00