We believe to be the most transparent public company that there is. We now have people who say, "Look, I'm trying to get my company more transparent and I'm holding up GitLab as a showcase." I think the easiest case is for internal transparency. So share more with the entire company. We expect people to think cross-functionally, to think like an owner to think like an entrepreneur of it. If you want that, you need to empower people with the information. From GGV, this is Founder Real Talk, where we get real about the challenges that founders start up executive faith and how they've grown from tough experiences. I'm your host, Glen Solomon. Without further ado, here's today's episode. On today's episode of Founder Real Talk, we're very excited to have Sid Sbrandy on the show. Sid's the co-founder and CEO of GitLab, the one DevOps platform that allows teams to collaborate, create, and deliver software in a single application. Before co-founding GitLab in 2012, Sid worked on recreational submarines and taught himself to code during that time. He went on to work at the Dutch Ministry of Justice and Security, where he did version control software around lawmaking. His love of programming would lead him to GitLab and the company has since built an open source community GitLab has been fully remote since day one, one of the largest companies in the world to do so, and now employees more than 1700 people across 65 countries. We're going to talk to Sid today about his commitment to his open source community and company transparency. We'll also touch on what GitLab's recent IPO means for its future. Sid, thanks so much for coming today and welcome to Founder Real Talk. Thanks for having me. I wanted to start by hitting the rewind button and asking about your origin story, which is really unique, before you got into web and app development, as we mentioned, you were working on recreational submarines, and then at the Dutch Ministry of Justice and Security, these are not well-trodden paths for future CEOs of great software companies. So curious, how did you find yourself founding in GitLab, what in your background led you to this great company? Yeah, thanks. You accumulate a lot of experience with doing different things and certainly some of the values of GitLab can be explained by what I did before. With GitLab, I saw the project on Hecker News one day. I love that. It's a side for programmers, and saw a combine I thought it made so much sense that collaborations are software or something that's open source, and you can contribute back to it. The project was one year old at the time. It got started in 2011 by my co-founder, Demetri. I thought it was great. I put a post-op saying, "Hey, if I start a service for this software until that point you have to download it to use it, I start the.com, will people join?" Hundreds of people signed up. Next year, Demetri tweeted out to the whole world. I want to work on GitLab full-time and I send them an email. I'm like, "Hey, I'm that guy from a year ago because I emailed him when I started a company. I emailed him with, like, hope you don't mind. I'm going to commercialize your project without you." The email back now, thanks for making GitLab more popular. It's open source. That's all I did. You can do what you want. I emailed him again and he said, "Look, if you want to work on it full-time, I can try to hire you." We came to an agreement. I went to the local Western Union money office, a white money from Holland to the Ukraine. He said, "Do you know this person or is this someone you met over the internet?" I thought both are true, but let's say I know this person and we were in business. A year later, we incorporated any year later, we joined the White Combinator and moved to the West Coast. Amazing story. Here you are today. I wanted to ask what life has been like being the CEO of a business from day one all the way through where you are today. It is, I think, your first time as CEO. You founded other projects and companies before, but this is your first CEO formal gig. Is that right? I think maybe the former projects I was CEO sometimes too, they were two-person or something like that. It's certainly the first time being a successful CEO. It's been great and it's been a very humbling experience. It's been a big learning experience. Basically, you make sure you're out of your old CEO job and somehow all kinds of new stuff come on your plate that fill it up a couple of years later. Can you talk a little bit about how the job changes over time, maybe from start-up phase to growth phase and now to public company phase? Yeah. There's the transition. In the beginning, it wasn't even me. It was Madden Youngkovsky. The first employee was working on it full-time and I was consulting for a project to make money to pay Madden to work on Kippa. Then it was me managing. As a company, you go from manager to senior manager, director, senior director, VP, SVP, etc. The skill becomes bigger and your role changes because of that. Now, we just went public. I don't think I'm managing our shareholders. I'm reporting to them more than anything, but you have shared other relations in your portfolio. Very cool. We skipped a step, but maybe you could talk a little bit about what does GitLab do? What does it mean to have the one DevOps platform where you're building, deploying, and helping developers build, deploy, and secure their software? Thanks for that. Today, most companies practice DIY DevOps. They've selected 10 best-in-class tools, and they've applied digital duct tape to string them together. They're switching to a platform because they get a single interface, one application. They don't have all the context switching and they're able to have one set of practices for developing, securing, and operating applications. That has four advantages. It allows them to save money, spending on software. It allows them to not have people work on the digital duct tape. Those sometimes 50 people can move on and do something that helps the business directly. Top of that, all their developers security operations people get more effective. People don't have to context switch the whole time. And best of all, their cycle time is faster because instead of Goldman Sachs spending two weeks to make an improvement to their most important application, they were able to do it in two hours we get left. I want to return to the concept of speed and how important that's been in your business and for your customers. We'll get to that in a sec. But I thought one thing I wanted to turn to next was the fact that we've seen in the last few years coming out of this pandemic, many companies had to go remote by necessity. But you at GitLab, you've been completely remote since inception. And I can remember meeting you several years ago and being just blown away by how you were running the company, documenting everything, but nobody really working necessarily together in the same office. The people were really working digitally with each other. And that was a new concept to me. So you guys really invented quite a bit about the way you're operating today and the way many companies are operating. On Twitter, you've bristled being called virtual or having quote unquote virtual meetings and have instead said you're remote and real. So I'm curious like what prompted your decision to go remote early on to be remote and real? And what do you think it's it's done for you as a business? Yeah, it wasn't so much a decision in the beginning as practicality. Manu was in Serbia, Dimitri was in Ukraine and I was in the Netherlands. And when I hired people in the Netherlands, they came, I agreed like let's meet up on a Monday and nine o'clock my place. And we did that for two days. And then the third day they didn't show up at my place. You just walk into Slack. But we never talked about that. And that happened with like two new team members in a row where the third day they just decided like I don't have to sit next to this person and listen to his video calls the whole day distracting me from what I'm actually supposed to do. So I'm like okay, well that makes sense. And then we found that being old remote is much easier than being hybrid. Because if you're co-located with some people like you talk and discuss things but the other people aren't privy to it. So it's great to be on the same page. And there's an open core company. It wasn't just with the company but with the wider community. Every quarter we get hundreds of improvements to GitLab that come from a wider community. We communicate through public issues and things like that. They can stay abreast of what's happening. So we decided okay, we're we're going to be over remote. And we did a bunch of practices that we thought were interesting. And we published the remote playbook which has been amazingly popular. I can recommend if you haven't read it. Things we did is writing down what we do. We have a handbook of over two thousand pages with all kind of the best practices and procedures that we have. We also paid a lot of attention to informal communication. Informal communication is super important but it doesn't naturally happen when it's remote. So you got to pay more attention to it and kind of formally organize informal communication. I did in preparation for this read your the work you've done on informal communication which I thought was was really interesting. And I did want to ask about you know as you've scaled we mentioned before you you know you're probably closing in on two thousand employees or so by now. It's difficult to keep a culture at a company a traditional company of that size where people are going into the same office. So I can imagine it must be even more difficult or potentially more difficult when you're that size and also running remote to kind of continue to promulgate culture and keep it strong. You talk a lot about informal communication and I think have listed like 15 ways to foster and ensure that informal communication continues to be a productive part of a culture. Can you talk to us about like how you've developed those key 15 items and maybe some of the ones that have been really important for you and have helped manage and maintain your culture at Gileb? For sure. So I think there's a distinction. There's a distinction between interpersonal trust. And culture as in values. So for the interpersonal trust informal communication is super important. Those 15 are examples. One thing that we do that we try to do is for example get everyone to get it for a week in person every year. So it's not that we're against in person events in fact we think they're great but use them for what they're good at. It's good for hanging out together and having an unconference not sitting in a massive room for five days watching PowerPoints. Regarding the culture as in values it's really important to reinforce your values. Even if you're at an office together you hire a lot of new people every year. Your values will dilute because every year there's just influx of new people and they dilute over time. So we have over 20 ways. Some really important. Some almost trivial but 20 documented ways in which we reinforce our values. I think that's been a great help in preventing them from getting diluted and I think they actually got stronger over time. Can you maybe outline a few of those 20 just to give people a sense for at what level you're operating and maybe what's been impactful here? I'll go from the most important one to the least important one in my opinion. The most important one is who you promote? Who you hire? Who you fire is also important but I think promotions are very visible events. So every promotion at GiltLab will be announced to the entire company with a Google doc that's structured according to our values as the primary way of organizing it. So everyone can see how that person being aligned to our values have led to the promotion. The most trivial thing is that we have a GiltLab songbook and that many of the songs reference our values. Is that made public or is that just for GiltLab in place? No, that's public. GiltLab songbook if you google that you'll find it. All right. I miss that in my preparation. I'm looking forward to learning some of those songs. It's 2000 pages in our handbook. So nobody's read all of them. Yeah. So speaking of which, you'd keep everything public from even your songbook, from like marketing, the infrastructure, even down to the company handbook. And I'm curious, like this level of transparency is pretty unique in my experience. Was this planned or did it grow out of necessity and what have been some of the unintended positives or potential risks that have come from being so transparent? Thanks for that. That being said, we have the longest list of things that are not public. I think are not public lists that now exceeds 20 items that we end up. We don't share. So there's long lists of things that are internal or that they even have a limited, more limited audience. So the reason those lists are so long is because everything is public by default. So unless you have a good reason to to make something internal or limited, it is public. And it started because building a company around an open source project frequently leads to the people who previously were contributing to that open source project kind of disengaging because now there's this big company and it's kind of like a black box. You don't know what they're doing and it's very demotivating. So we wanted to prevent that. So it was really to make sure that community would keep growing the wider community around GitLab. That's been successful. Hundreds of contributions every quarter. Then it became a way to build our talent brand because you can go to GitLab and filter it on YouTube. You can find like very boring meetings at GitLab and get an idea of what working at GitLab is like. And then it started building a kind of our customer brand. We now have people who say, look, I'm trying to get my company more transparent and I'm holding up GitLab as a showcase. And meanwhile, it gives us an opportunity to talk about our product as well. So it's evolved over time where it's contributed to. There's been remarkably few downsides to it. I expect it many more problems. I do think we have an executive team and a company that really subscribes to the value. So really appreciate, for example, what the legal team and especially Robin has done in preserving a lot of that transparency as we went public. Yeah, that must be a very difficult line to walk. Because the list of things that you can't make public when you go public paradoxically gets a little longer. It did get longer for sure because we don't have, we want all investors to have equal access to material information. Right. So it's kind of like a timing thing, not a desire to hold back, but maybe to time the information release so that everyone has like a fair access to it. Exactly. Would you recommend this type of dedication to transparency for other startups and do you recommend it when other founders talk to you about it? I think the easiest case is for internal transparency. We expect people to think cross functionally, to think like an owner to think like an entrepreneur. At least that's what a lot of the job adds say. But if you want that, you need to empower people with the information. And it's really important to make a distinction between being able to comment on something and needing to respond to that comment. So again, I would say, look, we share a lot of materials. You can comment on everything, but the author of the document or the decision-making, the directly responsible individual, they don't have to respond to your comment. They probably read it, but they don't have to defend why they're not doing that because as soon as you start requiring that, people will keep the information more limited to have fewer comments, to have less work because they're busy enough already. Interesting. Okay. So the rules, the road are important. If you're going to pursue this, this sort of level of transparency, that makes good sense. Is being open source linked? You mentioned that like transparency has helped you build a community. Part of your community are people who are contributing back to the open source part of your product. Do you think these two things are kind of linked together? Being transparent and being open source? I think it's very fitting for an open source company to not just share the code, but share more about the company. I do believe that the talent brand and the customer brand advantages of transparency will also translate to non-open source companies. Got it. Okay. Spending a bit of time here on open source and what it's meant to you at GitLab, you've talked about, I mean, I've watched over the years, your product has grown dramatically over time. And you mentioned that one of the core benefits of working with GitLab when a company adopts it is you can reduce the people, I think you use the word duct tape. The people responsible for kind of duct taping software processes together because you've done that. And so as you've increased the scope of what you've done of what you do at GitLab, it seems like one of the benefits has been that you are rapidly releasing new features with your product. Like this is not Microsoft releasing things slowly in kind of a very big way. Like your product is continually changing, continually evolving. How important has open source been? And is this a key part of your strategy going forward? For sure, it's the open core model this essential. And on a clarify that the people who were previously making the duct tape, they stay at our customers. They're just able to move to projects that directly contribute to their business. Many companies right now have a hiring stop, but they have more and more work to do. So like it's important to like get more people on the business priorities and make those people more effective. I think open source has been really key. So our customers are able to kind of contribute to the open source part of the code base. Our customers are able to contribute to the proprietary part of the code base. And on top of that, I believe that because we make our code base accessible to external people, we're better, more disciplined internally and allow our people to take very fast steps and have very short cycle time between starting on something and getting something out there. It's also help our iteration value. Make the scope smaller, get it out faster so you get feedback from the marketplace about what your next step should be. Shire from Elastic was a guest on the podcast several months ago about a year ago. And one of the things he said about open source, he said the real benefit for Elastic has been those rapid feedback cycles. Have you seen the same? I think it's very important. And I think cycle time is more and more a competitive advantage. How fast can you respond to the market? How fast can you learn something? It's the core thing we enable at our customers by switching to GitLab. T-Mobile was able to ship 10 times as frequently after moving to GitLab. But it's also something we try to practice ourselves. Yeah. Yeah. So I want to maybe talk a little bit about the competitive environment. You're not the only company that has operated in the developer tooling space and obviously in the source code control market, there are some other big players, Microsoft being one, at last he and being another. And you guys have talked on your public earnings calls about the frequency with which you see competitors and the success you've had, which has been phenomenal. But I'm curious maybe if you could talk to us a little bit about how much time you spend thinking about competition, none at all, does it impact your every day and how it impacts your organization. And whether or not you think others who are facing competition should be competitive focused or obsessed or what? I think it depends. I'm not going to talk about how other people should run their business. What we said in our earnings call is that the number of deals in which we meet Microsoft with their GitHub product has stayed the same as a percentage over time. And our win rate in those deals is equivalent to our deals where they're not present. What that tells you in our opinion, what we suspect is that means it's a very early market. If you add up our revenue and what we estimate to be GitHub's revenue, well less than 5% of the market. And the reason for that is that very few companies have made the complete journey from DIY DevOps with the digital duct tape and the 10 point solutions, the 10 best in class solutions to an DevOps platform. So there's a big, big world to win. We have started making that platform earlier. We have more capabilities today and we believe we're innovating faster. So that's the thing we're very focused on. Providing the value for our customers, making sure we can replace more point solutions. Make sense. And looking at your first few earnings releases as a public company, the growth has been phenomenal. And what I think is really unique is you're serving a tremendous number of customers who are paying you 5,000 or more a year, but you're also serving a huge number of customers paying you 100,000 or more a year and a bunch paying you a million or more a year. So you're able to serve companies at various points in their journey. And I imagine there's some very, very large companies that are working with you and also lots and lots of small companies that are working with you. How are you managing that? That's not easy to do for many companies. Like just the product, the go-to-market, is it really the same no matter how big a customer base or customer or prospect, let's say you're going after or this the size of potential customer impact sort of their experience with GitLab somehow? Yeah, we serve customers like they can be on many different clouds. They can like deploy to many different clouds. We offer GitLab. You can run it yourself or you can have us run it for you. We have different pricing tiers and then we have these huge sets of customers, small ones, large ones and across all industries. Then we are go to market some is sell, serve, some is direct sales and more and more is via channel. So that's incredible complexity. So it requires us to keep everything else as simple as possible. And a few years maybe it was harder to defend like having this complexity, but I think we've shown we can do we can do all of that. Yes, we can serve all those industries. Yes, we can help really large customers and give them the experience they expect and so have the self-serve motion as well. And as we get bigger that gets relatively easier. We mentioned in the earnings call we're really excited about the possibilities in channel with the hyperscalers with the global system integrators and well we're investing there appropriately. The enterprise has been more than half of our revenue and it's been that waste ever since the company got started. So we're not moving up market. Those have always been essential to our success. Very cool. If I look at a bunch of the other open source companies, modern open source companies that have been successful, the Mongos, the confluence, the Hashi Corpse were were involved. They all at least with those, I think similar to GitLab, they started with an open core model and have over time added cloud services at various levels of maturity in each of those businesses. You mentioned earlier that people can run GitLab themselves or you can run it for them. Are you seeing a growing number of companies either just small or small and large that want you to run GitLab for them? Is that a trend you're seeing? Because I'm curious whether or not that's part of what you see. Definitely what other companies in the open source mode seem to be experiencing these days. Yeah, I think you're comparing us to some infrastructure companies that have slightly different business models. With GitLab we see ourselves more as an application company and we charge per user per year and you pay the same price irrespective of your hosting it yourself or that we run it for you on GitLab.com. We talked about the complexity of the business. This one, how do you host it? Want to make super simple? It's the same price, it's the same commission for our salespeople. We're not going to twist your arm either way. It's to a large extent the same functionality. We run the same code base on both. It's not a primary decision. It's soon to be, the customer can choose. We're happy to serve them either way and we try to do a great job irrespective of what they choose. I love it. Making it easy for the customer. Whatever they want, however they want to receive, you are there to provide, which is great. Can you be real curious? If you look into your crystal ball, we're not trying to predict next quarter's earnings, but more like a three to five year look. If we get to do another podcast episode three to five years, what do you want to be saying about GitLab at that time? We want to make sure that we can replace more point solutions. We want to make sure that the majority of the market says, look, we're moving to a dev upslash form. In our earnings call, we said that for the first time in last quarter, we had sea level execs coming to us multiple ones saying, hey, I'm looking for a dev upslash platform. I realize that best in class solutions and then tying them together is not the future of us. We want to have a standardized process for development, security for operations. We don't want to tie that to any particular cloud because we're using multiple ones. We want to go to the cloud faster. We know this dev upslash form is essential and it's very encouraging. Very cool. Well, the future is very exciting for GitLab and it really seems like the wind is very much at your back. I'm looking forward to that podcast episode three plus years and I think you'll have a lot of good news to share. I wanted to finish up with a speed round. I'm just going to put you on the hot seat and ask you to say the first thing it comes to mind. What book or article do you recommend for founders? The book high output management and GitLab Handbook has a nice nice summaries and some other things about it because we encourage all of our managers to read it. One of my favorites, that's a great book and a great framework for thinking about how to build and continue to keep your company on the right track. What advice would you give a young sit knowing what you know today? Go to Silicon Valley earlier. Okay. Last question. We've got a lot of big tech CEOs these days building rockets. Are you going to be the first to build a submarine? What I love about rockets is what they enable. Not so much the the trips but Starlink getting everyone better internet all across the world. So if there's a case like that for the submarines, I'd be the first one to build some more. I'm really proud that the company we started, you boat works, now makes the most submarines of any company in the world. So they're quite successful but I like utility at scale. So that's what we're focused on with GitLab and that's what gets me excited about other endeavors. Well this podcast episode has been utility at scale. It's amazing what you've accomplished and I know that listeners are going to enjoy as much as I did hearing about your story, how you thought about and built an incredible company in GitLab and I think it's hard not to listen to you and feel like the future is incredibly bright for the company. So thanks so much for joining us and best of luck in the many quarters ahead. Thanks so much for having me and also thanks GV for your support both as a private company and as a public company. We really appreciate and view as an investor. Thanks for saying that. You've been listening to Founder Real Talk. If you like what you heard please rate and review us on the Apple Podcast app to help others find this podcast. If you have any questions you'd like us to ask out guests or founders you'd like to hear on this podcast feel free to email us at
[email protected]. Our theme song is by grapes. GGV Capital is a global venture capital firm that invests in local founders. As multi-stage sector focused firm GGV focuses on seed to growth across consumer social and internet enterprise cloud and frontier tech. The firm was founded in 2000 and manages 6.2 billion in capital across 13 funds. Past and present portfolio companies include the likes of a firm Airbnb, Ali Baba, Dede, Grab, Hello Bike, Hashikorp, Hous, Keep, Namely, New, Open Door, Peloton, Poshmark, Slack, Square, Wish and many more. The firm has offices in Beijing, San Francisco, Shanghai and Silicon Valley. Learn more at ggvc.com or follow us on Twitter at @ggvcapital or ggvcapital on WeChat.
PodcastTranscript AI