The GitLab way: Kindness, transparency, and short toes | David DeSanto (CPO)

[00:00] You guys share so many of the things that most people keep secret. You post videos of your team meetings on YouTube. We get people who then contribute because of what they see. Oh, I can go build that. I know what that is. Hey, I ran that same problem too. I'd love to hear how you solved it. You also have this handbook, how you onboard people, how count payables works at GitLab. We'll have companies who will fork the handbook. If you can leverage what GitLab has done, that's amazing. You mentioned the value of short toes, which I was definitely going to ask about. [00:30] on you. Whereas if you had short toes, it's about the work. It's not about you. You end with a lot less of the negative head-butting, especially in an asynchronous culture like you have. Is there any tips you could share with PMs that are just struggling in a remote world? If everyone's really annoyed at you, you're probably actually doing your job well. [00:46] Today my guest is David DeSanto. David is the Chief Product Officer at GitLab, which is an incredibly unique company. [00:56] It's the largest remote-only company in the world, [00:59] They share many of their team meetings on YouTube, [01:02] And they've grown from being just a source code management business competing with GitHub to a multi-product platform that covers security, compliance, continuous integration, project management, deploy tools, and more, many of which are infused with AI magic. In our conversation, we dig into GitLab's culture of transparency, including how they operationalize it, what they share publicly versus what they don't, the surprising benefits of working this way, and why it's worth considering going transparent with your organization. Also, we explore some of GitLab's

[01:32] values like kindness and having short toes. Plus, David shares a bunch of great advice for scaling remote work based on what's worked well at GitLab over the years. Also, when it makes sense to go breadth over depth versus depth over breadth when launching new product lines and how it worked for GitLab over the years. This was a fascinating conversation. And if you want to learn more about a company that's doing things very differently, while also kicking a lot of ass, [02:02] Don't forget to subscribe and follow it in your favorite podcasting app or YouTube. It's the best way to avoid missing future episodes and it helps the podcast tremendously. With that, I bring you David DeSanto after a short word from our sponsors. [02:15] This episode is brought to you by Orb. As a business, you care about revenue, but as a product team, the last thing you want to do is delay a product launch or a pricing change because your team has to rebuild billing from scratch. Orb is a flexible, usage-based billing engine that lets you evolve your pricing with ease. [02:34] The fastest growing product teams at companies like Vercel and Replit trust Orb to power their pricing changes and launches. Use Orb to ship product faster, stop worrying about billing, and evolve pricing with ease and control. Check it out at withorb.com slash Lenny and skip the line for a demo or sandbox by using promo code Lenny. That's withorb.com slash Lenny. This episode is brought to you by Eppo.

[03:04] and feature management platform built by alums of Airbnb and Snowflake for modern growth teams. Companies like Twitch, Miro, ClickUp, and DraftKings rely on EPPO to power their experiments. Experimentation is increasingly essential for driving growth and for understanding the performance of new features. And EPPO helps you increase experimentation velocity while unlocking rigorous, deep analysis in a way that no other commercial tool does. When I was at Airbnb, one of the things [03:34] I could set up experiments easily, troubleshoot issues, and analyze performance all on my own. EPPO does all that and more with advanced statistical methods that can help you shave weeks off experiment time, an accessible UI for diving deeper into performance, and out-of-the-box reporting that helps you avoid annoying, prolonged analytic cycles. EPPO also makes it easy for you to share experiment insights with your team, sparking new ideas for the A-B testing flywheel. [04:04] machine learning, monetization, and email marketing. Check out EPPO at getepo.com/lenny and 10x your experiment velocity. That's get EPPO.com. [04:14] dot com slash Lenny. [04:16] David, thank you so much for being here. Welcome to the podcast. Thank you for having me. Very excited about our chat. [04:26] I'm very excited as well. You definitely win for best beard of any guest of the podcast so far. [04:32] What does it take to maintain such a beard?

[04:36] That's a great question. So, [04:38] I would tell you it's not as much as you think it would be. It's just regularly going to a bar where you trust that can keep the shape and... [04:46] it does get washed and conditioned regularly because, you know, my hair... [04:50] migrated south for the winter and never came back. [04:52] And so, you know, it's kind of become the staple. So, yeah, KOMED. [04:57] put conditioner in and things like that. [04:59] Not a lot of maintenance, surprisingly. [05:01] Okay, and I think you mentioned offline your handle. Is that on Twitter? What is it? Oh, so I just started trying to use threads. No threads, okay. Everywhere else, I'm like D. DeSanto or David DeSanto. Those weren't available, so I'm David the Beards, David dot the dot Beards. [05:17] Amazing. [05:19] You're going to follow me there once you watch this because, you know, I think I've got 10 followers in the first couple of weeks here. We'd love to get it to a much higher number. [05:27] Yeah. [05:28] So you can help with that. [05:29] Okay, let's work on that. And then if you're not watching this on YouTube, you're missing this beer. [05:33] Anyway, I'm excited to have you here because I've always been really fascinated about GitLab's culture. [05:39] so many unique elements to how you guys operate and clearly it's worked out really well the company [05:44] I was just looking up the stock is a $11 billion business at this point. It's been around for a long time. [05:49] So I want to dive into a number of the different ways that you guys work, especially the stuff that's really unique. [05:54] And the first element is your very unique culture of transparency. [05:58] I have not seen anything like this elsewhere. [06:01] So first of all, as an example, you post [06:03] videos of your team meetings on YouTube. That's correct, yeah.

[06:07] Okay, and I want to chat about the policy, but just as an example, I was watching a [06:11] Product team meeting. [06:13] of your product team a while ago where they were talking about a book club, a Marty Kagan's recent book, [06:17] I was watching engineers talking about some scaling. [06:19] challenges they were having. There's a video of you being introduced to the UX team from a year or two ago, and maybe it was like after a reorg or something. [06:26] What's just like the policy on which videos go online? [06:30] Yeah, so that's a great question. And you're actually correct. So about two years ago, we moved UX from engineering into product to make them a much more strategic part of the company. [06:39] I knew a lot of UX, but [06:41] Didn't know everyone in UX, so we took the time to let me introduce myself to them if they weren't familiar with me or hadn't talked to me at all. [06:48] But to your... [06:49] question. Our policy is like be as transparent as possible. [06:53] So if it's not customer data, it's not vulnerability information, [06:57] we heavily encourage the team to put their videos, like record the videos, sometimes even live stream them onto our YouTube channel. [07:06] So for those not familiar, you can search for GitLab Unfiltered on YouTube. [07:09] And there's more content there than a human being could watch. [07:13] in a single day or even everything that's recorded during the day. [07:17] Because there can be multiple meetings happening at once that are also showing up there. [07:21] But a good example of that is my biweekly product meeting. [07:25] where we kind of go over things we're working on, things we're excited about, troubles we're having, challenges, and how we can [07:31] We're better together. [07:33] I can tell you that it was a change joining GitLab in 2019 to have that much content just be available.

[07:40] You also learn how to be better on meetings because of it. [07:44] My first meeting was like my first day and I spent a lot of time looking all over the room. So I was used to being on like a WebEx where, [07:51] you can't see anything, so you could be [07:53] looking outside while talking about it and you realize, [07:55] You're not really engaging because you're, [07:58] It's like just an audio call. And so I think it's been really good for the company. [08:02] A the. [08:03] Great example I can give you is like we get people who then contribute because of what they see. [08:08] And so we've had [08:10] you know, customers, open source community members go, [08:13] "Oh, I can go build that. I know what that is." And they will just knock it out and do a code commit or... [08:18] We'll get feedback on the video or feedback on social media. It's like, hey, I ran that same problem too. I'd love to hear how you solved it. [08:25] And so I think it's been really great for not just the company, but the broader community, whether there are paying customers or open source contributors. [08:33] So just to understand, there's [08:34] developers watching team meetings, [08:37] noticing there's like a bug or an issue or a challenge and then just going ahead and committing [08:42] code to fix it. [08:43] Yeah, so sometimes it'll be open source community contributors who are doing that. So, yeah, they'll hear about that. They'll look at the issue tracker because the issue tracker is all public. [08:53] And they'll be like, oh, I can do that. Let me just do that and make the project better. Oh, my God. [08:59] That's crazy. Okay. And so the policy, as you described, is it's up to the person. They decide, is this something we can share that we feel comfortable with? [09:06] Yeah, it's up to the person and the team. So like,

[09:11] I do have a couple of policies for the product division where we don't post the recording. We [09:16] Used to do live our what we call performance indicator reviews. [09:19] and key reviews. [09:21] we stopped putting those public because we want to talk about the customer that's impacted or we want to talk about [09:26] the thing that we need to move. And so we'll talk about it at a high level in our product [09:31] division-wide meaning that [09:32] is posted, but then like the nitty gritty [09:35] like down details that would be considered... [09:38] material, non-public information, or... [09:41] customer data that would need to be kept safe. [09:43] Those things we... [09:45] We will record those, keep those internal and not make them public. [09:49] Okay, amazing. So you have these videos. You also have this handbook, the GitLab handbook, [09:54] which is handbook.gitlab.com, which also shares tons of [09:58] pieces of how you all operate. So just skimming through it, there's your mission, your vision, your strategy. [10:03] how you onboard people, your anti-harassment policy, how account payables. [10:08] works at GitLab like [10:09] hilarious, amazing stuff. It's great too, right? Like, [10:13] I don't remember how many pages it is now, but it's huge. [10:17] And so... [10:19] What I see what happens and this kind of gets into the first example, I mean, like, [10:23] will have companies who will fork the handbook because it's just [10:27] source available to at the bottom of the page you can click views view source and [10:31] And I just heard from a company... [10:33] who's now becoming a customer who, [10:36] We're like, we want to redo our UX mission and how we operate in a UX department. So we cloned the UX handbook within handbook.getlab.com. And it became our baseline for building what we do.

[10:48] And you can see that even for startups who will say they've cloned the entire handbook and they've [10:52] use it as a way to start. [10:54] And I think for me across my career, [10:57] I've been in this situation where I needed to fix something or restart something or... [11:02] you know, [11:02] I'm the first person in the department and, [11:05] there's a lot of uplifting you have to do in that role. Whereas, uh, [11:08] if you can leverage what GitLab has done, [11:11] That's amazing, right? It really helps you continue forward really quickly. [11:15] Yeah, I think one of the most interesting for me has been the competencies for product managers. [11:20] Something a lot of PM teams are looking for is like, how do we... [11:22] Level and ladder and create levels for teams and you guys share all that and you guys have a really good version of that publicly and [11:29] So we talked about the YouTube. I have a bunch of questions about how this actually works. So you have the YouTube channel of team meetings. You have the handbook. Is there anything else that I'm not... [11:37] that [11:38] that I'm not mentioning that's public that other companies don't share. [11:41] I think there's really two things. So the first one is our issue tracker for everything we're doing. [11:47] The majority of those issues are public. [11:49] It's also available for people who have an account. [11:51] to also create and comment on. And so, [11:55] Whenever we do a call with a customer or I present at a conference, [11:59] or my team presents, we always say, [12:01] please go look at our issue tracker and [12:03] If there's something you like, vote it up. If there's something you want to see change, leave a comment. [12:09] And I think that's unique to GitLab. I think we've actually caused other organizations to do something similar. [12:15] Because of that, [12:16] And the other one is our direction and our strategy you mentioned earlier.

[12:20] Sometimes it's just a high-level paragraph, but sometimes if you go deeper... [12:24] we have like a one year direction that is very detailed and links over to our issue tracker to help you see like, [12:30] Hey, we're going to do... [12:32] I don't know, we're going to build widget X and we're going to do that in the next six months. And here's how we're going to do it. [12:37] And I think those are those all those things together have really allowed Gillard to be the most transparent publicly traded company in the world. And we're very proud of that because it's just in our DNA to do it. [12:49] I think what's really interesting about this is it's kind of the epitome of it's not the idea, it's the execution. [12:54] You guys share so many of... [12:56] the things that most people keep secret. And [12:59] It's worked. [13:01] I guess, is there any lessons there? Just like it's actually a lot. The execution is what separates you from everyone else. Someone could just basically copy everything you're doing and [13:08] in theory, build something like you built, but [13:10] but they haven't. [13:12] yeah i think you're touching on actually my i when i interviewed in 2019 i actually asked sid our co-founder and ceo a similar question i said hey [13:21] And I came from security Indigate Lab. [13:24] And I say like, hey, we don't share more than four or six weeks with a roadmap with [13:29] customers and even sales because we were in the situation where [13:33] We didn't want our great idea to be taken. [13:36] and built before we built it and that had happened to me at other places i've worked and so [13:41] what we... [13:43] In that conversation with him, he basically said, it's product's job to be ambitious and it's engineering's job to meet that ambition.

[13:50] And if you think of it that way, [13:53] and it's that collaboration between the two, it becomes less scary to put the information out. [13:58] But you're right, we're very even transparent there. [14:01] The thing that gets into what you mentioned, the ability to ship software, [14:06] I'm floored by these numbers, but these are real numbers for us. We still ship. [14:10] 12 releases a year. It used to be on the 22nd of every month. It's now the third Thursday, so we don't have to have people work over a weekend. [14:17] We've done that for over a decade, and our last release put us at 149 releases. [14:23] that have come out [14:24] essentially every month for the last... [14:27] a little over 12 years. [14:29] Someone listening to this may be like, OK, wow, we should try this sort of thing. Let's try to be transparent. [14:34] with everything, meetings everywhere, public, handbook, [14:38] I imagine this doesn't work. [14:39] for most companies. [14:41] So a question just... [14:43] on my mind is what do you think it takes for a company to work this way like what are some elements that need to be true [14:49] for them to succeed being this transparent. [14:53] I think it is pushing yourself to realize what is actually confidential and what actually is not confidential. [14:59] Other places I've worked, they end up with these artificial silos, even if you're all in the same office. [15:06] And that ends up impacting your ability to... [15:10] truly collaborate and get the results you're looking for. [15:13] And I can give you like a great example that sometimes you have a program manager or program management team who's tracking the schedule and now they're being forced to be the router between teams.

[15:23] As opposed to say, [15:24] It's all stored in a single source of truth. [15:27] Anyone can comment on it. Anyone can contribute to it. [15:30] And that starts all the way from... [15:33] Like, [15:33] team meetings, whether it's my leadership team, [15:36] Or it goes all the way down to coffee chats that we have where sometimes people just record that chat because all of a sudden there's something really interesting in that. [15:44] And for those who, [15:45] listening or watching us, as you said, looking at [15:48] the beer that I have instead of just listening to the, [15:51] I think they can hear the beard too. [15:55] It gives me presence. So, yeah. [15:58] Makes your voice deeper. [16:00] There you go. So, um, [16:02] What ends up happening for us, a coffee chat is like the equivalent of like walking in and running someone in a kitchen. So you're getting... [16:09] more coffee or tea or water, right? [16:12] And so sometimes those just end up getting recorded because there's something that's a good nugget of information that comes out of it. [16:19] And so, [16:20] realistically like [16:21] You just have to push yourself. [16:23] And, you know, [16:24] It almost has to be uncomfortable. And then you realize you're starting to really truly be transparent and you're allowing everyone to contribute. I imagine this isn't all upside and rosy and rainbows all the time. Is there anything that you've heard of or ran into where this caused the problem, either for the company or someone at the time? [16:39] Internally? [16:40] That's a great question. So I think if you go back to the, like, you have to push yourself to your own comfortable position. [16:46] Sometimes ends up being overly transparent. [16:50] and... [16:51] GitLab has had its fair share of things at times where

[16:55] an issue is public that probably shouldn't have been public, like in our issue tracker, or [16:59] The recording accidentally gets set to public when it should have been set to private. [17:04] And those are just [17:06] pain points and learning and then as long as you're reinforcing that learning across the team [17:11] you end up not making that same mistake again. [17:14] And I will say that [17:16] I think the risk of that occasionally happening is, [17:19] is way below the value of actually pushing yourself to do it. [17:24] So what I would encourage you to start as simple as publishing a team meeting. [17:28] and making that available for everyone in the company. [17:31] Begin to go from there to maybe like weekly meetings or even asynchronous readouts that you can post on Slack. They're just saying like, hey, here's everything that happened this week for the team. [17:40] And then you'll slowly find that [17:43] If you're doing it, others are doing it. And before you know it, you've actually achieved a high level of transparency. [17:48] Now, depending on the industry you're in, maybe you can't make your issue tracker public. [17:53] If you're like GitLab and you're using GitLab.com, [17:56] Maybe you can... [17:58] share the details we share about customer meetings and our, [18:02] conversations with them, obviously without saying their name, but [18:05] You'll find the right balance for you. And I think you'll truly find that as a company, you become more productive. [18:11] To convince someone that this is worth doing, what do you find are the biggest benefits of operating this way? Because it sounds like more work and it sounds like there's more risk. [18:20] And so what do you find are the benefits and also just like maybe second order benefits that you didn't directly expect?

[18:27] Yes, I would say the big thing I've seen is focus on results, especially for our customers. [18:32] We are a global company. We weren't always as big as we are, but GitLab is over 2,000 people. [18:39] It allows people to asynchronously consume what happened while they were offline. [18:45] And it gives them both more engagement and, [18:48] as well as that lack of feeling of like FOMO or fear of missing out. [18:52] And... [18:53] To me, those are really the top level items that come out of it. [18:57] The secondary benefits of those are, of course, teams are better aligned. [19:01] You find things that you may not find until the end of a software release or beginning of a go-to-market campaign. You have to redo something. [19:09] And so. [19:11] I just think really... [19:13] And I say this with encouragement to people. [19:16] pick one project and try it and if that's successful and doesn't feel like a lot of additional work try with another one and before you know it you might find out that [19:23] It's actually easier to be transparent than it is to not be transparent. [19:26] because now you don't have to worry about tracking things you may or may not have said. [19:31] Think about, well, did this person hear it or were they not in that meeting? [19:34] Like it just becomes that, [19:36] That's a lot of data that people can consume and then they can make informed decisions quicker. [19:40] because they're not being siloed out of the conversation. [19:43] Well, it feels like there's two elements here. There's being transparent internally with here. You can listen to every meeting that you've had. [19:49] as an employee. But where you guys go is one step further, as anyone can pay attention to this and read your handbook. [19:55] What do you find are the biggest benefits of that element, just being public about this stuff?

[20:00] Yeah, I mean, for me, it really comes down to the engagement we can get externally. Because our issue tracker is public, our customers comment on it, we get community contributors committing to our code base and helping get led to be a better product. [20:13] I can see where in certain industries, we'll say like financial services, maybe you can't do that. [20:18] As much? [20:19] But... [20:21] I would say that there's still a balance where there's probably something you'd be more transparent about. [20:26] I'm even seeing in heavily regulated industries where they're starting to publish more of the roadmap externally. [20:31] as a way to build more trust with their users and their customers, because now they know where you're going and it's not a cloak and dagger type feeling. [20:39] And so. [20:40] I will admit it can't be done everywhere, but I think it can be done a lot more than it's done today. [20:45] you get a community feedback loop, which [20:48] is great, especially when being in a product division. [20:51] So one takeaway here is it feels like most of the benefit is [20:56] in products that are building with a community component. [21:00] And, [21:01] developer-oriented and open source. Feels like those are like [21:04] the Venn diagrams of where this is most impactful versus like, [21:07] Slack doing this or... [21:09] I don't know, Salesforce. Yeah, I mean, I would say that [21:13] If you're in tech and you're building a product, regardless if you're [21:17] a developer platform or a DevSecOps platform like us. [21:21] I think there is benefit. I think, [21:23] Salesforce, [21:25] could have a little bit more engagement from a broader customer base, right? My last

[21:30] employer, we [21:32] started sharing the list of open requests for new features more externally, [21:37] And we got a much more honed in roadmap. [21:39] And that led to better customer engagement, which led to a higher retention rate, which led to better expansion numbers, right? So, [21:47] I think it's about... [21:48] what's right for your business and not necessarily are you in [21:51] column A or column B. [21:53] I was browsing around through the handbook and I looked at your core values and there's some really sweet things in there. [21:59] So within the collaboration core value, there's a value of kindness. [22:04] which I love. [22:05] What does that look like in practice at GitLab? The values really... [22:11] come together in a way that I've not seen other company values come together and [22:16] I don't know where these all are in there, but it ties into the kindness. [22:19] If you're all remote, [22:21] you're not necessarily seeing people in person. And sometimes it's hard to read intent on a Slack message or, [22:27] the emotion in the message. And so, [22:30] We say assume positive intent. [22:33] assume the person is traditionally just asking for help or is trying to be helpful. [22:37] have short toes, don't read something and think it's meant a different way. [22:43] And that's where like the kindness comes in as well. [22:45] is that if you're treating each other with kindness and assuming positive intent, [22:50] you end with a lot less of the... [22:52] negative head-butting you can have, especially in an asynchronous culture like GitLab. [22:56] Our team, I will see my direct reports usually at least a couple minutes a week on a Zoom call.

[23:03] But that's not the case for everyone at GitLab. [23:05] Right. And same thing with other teams. And sometimes it's hard to [23:09] assume what the person's intention actually is until we say, "Be kind." [23:14] Assume the positive intent. [23:16] realize that everyone's here to help each other out. And I can tell you, [23:21] When people ask me like, [23:22] What's it like working at GitLab? [23:24] I always kind of come back to the values and say we actually live them. And that starts with Sid. [23:28] all the way down the organization to a brand new employer straight out of college, [23:33] If we're doing that, then there's a lot less of that tension and headbutting that can happen in organizations, especially when we don't see each other all the time in person. [23:41] Some of the other elements along the "be kindness" is "say thanks" and "say sorry." [23:46] and negative feedback is one-on-one. [23:49] By the way, for those who [23:51] aren't looking at the values, you can go to about.getlab.com slash values. [23:56] and you can see them. But what I will share with you is that [24:00] like we have a thanks channel where people just post a thank you note whenever they are truly thankful for something. And, [24:06] that channel is constantly getting those messages in it. It's reinforcing that, [24:11] engagement that you really want to have where people are working together [24:15] collaboratively and assuming positive intent and so forth. But [24:18] I will say the negative is one-on-one that you mentioned, Lenny. That one's actually really important to me because... [24:23] You don't want someone to take a public message the wrong way. And so you [24:28] take that conscious step to say like, hey, I got to give that feedback. [24:31] Let me do that one-on-one.

[24:33] And that means if it's in a public channel, it's even easier to assume the positive intent because... [24:38] Negative feedback should be one-on-one. [24:40] Yeah, I think the more you talk about this, we're going to talk about remote work. It all works together. Remote work almost forces you to be very specific in how you communicate, be transparent about all the things going on at the company. So this all makes a lot of sense. It's kind of this. [24:52] flywheel I imagine that kicks in [24:54] I agree with you. I think you can't [24:56] be as transparent as we are without having our values. You can't be [25:01] have our values unless you're trying to put it sometimes into the remote work environment and vice versa. And I think they... [25:06] all fit really well together. And it's been... [25:09] the company continuing to grow and adapt them as we've gone from, again, like one person to over 2000. [25:16] You mentioned the Valley of Short Toes, which I was definitely going to ask about. [25:20] Talk about what that means. [25:21] Yeah. So the short toes is, you know, it's really about the, it's about the work. It's not about you. And so [25:28] If you have made something and you're getting feedback on it, [25:31] try to realize that as someone trying to help you make it better and not a personal view of how you are as a person or as an employee, [25:39] And so like a great example would be, [25:41] I make videos occasionally and post them on Slack and [25:45] People can consume them and [25:47] Those are not always well received. I don't take that personally. I take it as an opportunity to say, what could have made this video better? So the next time I do it, it provides a lot more value. [25:56] And I think that is really... [25:58] where that short toast comes in. It's about, you know, comment on the work, not the person.

[26:03] It's not, look what you did. It's like, this could... [26:05] I have been better this way. [26:07] And... [26:08] If you're assuming positive 10, having short toes, [26:11] you end up having less... [26:13] headbutting. [26:15] I think the implication here is that you don't want to feel like people are stepping on your toes, so your toes end up being short, right? That's where this comes from, I imagine. [26:23] It does. And part of that ties back to those other, those other values, right? Like, [26:28] you aren't your work [26:30] Right. So, [26:32] if someone's reaching over and doing something in your space, that's where if you have [26:36] Long toes, as they're called. [26:38] you feel like people are stepping on you. Whereas if you had short toes, it's about contributing and so forth. [26:44] It's so funny. I love the way of describing it and it's [26:47] The exact opposite of Uber, who's one of their values, I think, was encouraging toe stepping, step on toes. [26:53] Don't worry about it. [26:54] Long toes. [26:55] Our approach was to take the other side of the move fast and break things. [27:01] Right. It's more about building that community, that trust and everyone hitting the results together. [27:07] Sounds like a delightful place to work. [27:08] This is the happiest I've been in my career. It has nothing to do with [27:12] my success at GitLab, though I'm sure that's part of it, but it's also... [27:16] I know that we're all working together for the common good. We're all trying to aspire those values and it makes it, [27:22] a great place to work and it's been the happiest I've been. [27:26] And I've been here four and a half years. [27:28] Wow, I love hearing this. [27:30] And it's done great also, which is, you know, it shows that you can run, you can build a very successful business and people can be very happy.

[27:38] What a rarity. [27:39] Yeah, no, agreed. [27:41] Are there other values that you find to be really core to the way GitLab operates that I haven't mentioned? [27:47] Yeah, I think for me, it's the results and the efficiency ones that always hop out for me. Results is focused on results for customers. [27:55] And that's why we do everything we do. Almost any company that's really the case. [27:59] And so how do we help our customer get [28:04] their software should faster, make their software more secure, give them better visibility into its usage. [28:09] And having that focus on the customer is the number one thing. [28:13] it allows us to be a lot more empathetic with, [28:16] not only our customers, but the broader community. [28:19] And efficiency is really about how do you get work done and how, [28:23] we try to drive responsibility down to the lowest level [28:26] in the organization. [28:28] I, as the leader of prodigal set, a three-year, seven-year strategy. [28:32] But like how we get there, we leave up to the individual teams. [28:35] And... [28:36] that empowers them to be able to [28:39] work efficiently and hit that high level of velocity that we talked about at the beginning of our chat. And so, [28:46] I think for me, those things kind of come together. [28:48] It's okay to ship something that you think is good. [28:51] but maybe it's not great yet. [28:53] get it out there, get that flywheel working so you get the feedback from the customer and then iterate on it. [28:58] And I think those two things together, on top of what we talked about, the transparency and the collaboration really help us be who we are today. [29:06] Did you say a three-year and seven-year vision?

[29:09] Yeah, we have on the website up to, I think, a 30-year mission. So we have our mission, we have our vision, we have our strategy, and we have our direction. Those are the levels at which we plan. [29:21] What's the thinking there? The thing is to make sure Raleigh is going towards where we think our customers are going to need. And so to give you an example... [29:30] The three-year strategy says our goal has become the first all-ops platform. [29:34] And that essentially say that we want to be the single source of truth for R&D organizations. [29:40] And that's not just [29:41] the people who are in R&D, like product, UX, engineering, infrastructure, [29:47] but for the teams that work around them, including legal, sales, product marketing, compliance, and so forth. And so... [29:54] For us at All Ops means it's everything that's needed to do that. [29:58] And that's what we've built, not just source code management, code review, and so forth, or CI/CD. We've added security and compliance. We've added enterprise agile planning. We're even starting to add service desk service management functionality, [30:11] and GitLab as well. [30:13] For us, that's our long-term goal. [30:16] and then we empower the teams to [30:19] get there the way they think we need to get there for their area or a new area that needs to be created. [30:24] For those who are not as familiar with GitLab, we're structured by sections. [30:27] Those are areas like dev, [30:29] SEC and Ops. [30:31] those have stages in them that map to the DevOps tool chain, like create, plan, monitor, verify. [30:38] And then those have groups in them.

[30:40] And those groups are that lowest group I'm talking about where we've pushed on the priority. And those will be the things that have our categories. So there's a group. [30:47] that's called environments that manages [30:50] our Kubernetes integration, [30:52] our deployment dashboard and so forth. And that, of course, then all feeds back up to that top-level vision. [30:57] And so it's allowed us to be structured in a way that helps us [31:00] ensure that the people who need to work closely together can across those groups. [31:05] and allows us to tie stages together [31:07] to make sure we're hitting the outcomes that we need. [31:10] And so that kind of is how that all then fits together. There's like a group direction. [31:14] There's a stage and section strategy and there's companies longer term vision and then mission. [31:19] And I love that all of this is there in the handbook. Like, you can see all this. And then you can also see your cadence for... [31:24] Revisiting it, planning, team meetings, executive staff. [31:27] discussions. [31:29] Yeah, and by the way, we also put... [31:31] That's all the way down to the group level. So on our marketing site, if you go to about.getlab.com again, slash direction, under direction is the product direction that we've set for the next year. And then that links out to those stages and groups. So you can really follow along. [31:47] And when you get lower into that, like to the group level, they're linking to their epics, their issues and their tasks. [31:52] in our issue tracker so you can easily find them. [31:55] I think 72,000 open issues right now in our backlog. [31:59] And it'd be hard to dig through all of that. It's people creating new ones, customers commenting on it. It just keeps the backlog really... [32:05] large, but [32:07] You can go through that marketing site that we have and get to the thing you're actually interested in reading about. There it is. I'm looking at it.

[32:14] I love it. [32:15] When someone joins GitLab and... [32:18] things don't work out. They don't end up being a fit. [32:21] Other than... [32:23] them not just having the skills they need? What do you find is the most common reason for them not being a fit at GitLab? [32:29] So I think it [32:31] really kind of doused into the remote. [32:34] experience remote is not for everyone. [32:37] And we'll have people who come and they're really great. They don't even have to be an underperformer. [32:42] but they're missing that [32:44] in office every day feeling. [32:47] Maybe in some cases they just want to, [32:50] get out more and be [32:52] not at their home or at the same co-working space all the time. [32:56] And so for them... [32:58] That's really the thing that's the... [33:01] The thing for them is that they just don't feel connected the way they want to be connected. [33:06] And I'll be honest, I started at GitLab a couple months before the pandemic. And so... [33:11] For me, [33:12] I got to attend our sales kickoff, but that was only a third of the company [33:17] And it's not until actually... [33:19] in March this year that we're doing our first [33:22] company-wide get-together [33:24] where I'm going to get to meet some people I've never had the chance to meet in the four and a half years I've been here. And so, [33:29] I myself found that a little... [33:31] jarring initially. I worked in a company that had a hybrid model and I knew what that was like to have [33:37] People not with you. [33:39] But the fact that like, [33:40] that, uh, [33:41] human connection can be missed. [33:44] more so for some people than others. And I think

[33:46] That's really what it comes down to. Yeah, you're right. They could not [33:49] understand the technology. Maybe they're not fitting into the role. [33:53] But I think sometimes it's also... [33:55] I just said I'm not enjoying the Alvaro mode. [33:58] I'll call it lifestyle because it is an adjustment to how [34:01] how your day goes and how you engage and all that sort of thing. [34:05] That makes sense. And that's a great segue to where I wanted to go, which is talking about remote work. [34:09] So I think you might be the... [34:10] largest all remote company. Do you think that's, is that true? [34:14] We were pre the pandemic when we were around 1,100 people. [34:18] I [34:19] I think everyone... [34:21] now having recalls back to the office, we might be back to being the largest all remote. I've not seen a number yet from other companies of how much are they still remote, but [34:32] During the pandemic, I think a Google and Apple would win as the largest all-remote. [34:36] Right. Whereas [34:37] Yeah, now those people are coming back to the office, we might be back to being the largest. Okay. And I think even if you aren't currently the largest, it feels like you will be probably long-term because people... [34:47] kind of go there and then move back. [34:48] Also, GitLab has been doing this way before school, way before everyone else started to try to [34:53] Go down this direction. [34:54] Feels like there's a lot that people can learn from how to work remotely successfully. [34:58] I'm curious when you talk to other leaders and other companies that are trying to improve the way they work remote, what advice do you share? What tips do you have for people? [35:05] making remote work more effective. [35:07] Yeah, I think there's a handful of things that I really encourage people, which by the way, I do get reach outs on Facebook. [35:12] It's now called X. LinkedIn, where someone will say,

[35:16] I read this in the product handbook, but I don't understand how this then applies in an all remote environment. [35:21] And so I usually kind of say like, [35:24] If you're looking at [35:26] being a remote first culture, there's a couple things you just need to [35:30] to understand and focus on things like, [35:33] Be transparent. We've talked about that a bunch already. [35:36] Focus on results, not hours. [35:39] you know with sometimes people get fixated on the well did you work the full 40 hours this week or [35:45] wow, you worked more than 40 hours this week? What's going on? And [35:49] Instead, it should be about, hey, we've agreed to an outcome and how we achieve that outcome. [35:54] I think over communication is also key that I share with people like, [35:59] The best way to put it is I have an executive coach. He's a great guy. [36:04] One thing he said was that [36:06] If you think you're communicating 100% accurately, that's probably 60% or 70% for the other person. [36:12] and shoot for like 150%. And so that's something that I think really helps in that environment. [36:18] And then lastly, and we just talked about this, is making time for in-person. [36:22] Events. [36:23] I have my leadership team get together every quarter. [36:28] Every other quarter of that, we bring in our Director Plus group, and we're actually doing that next month. [36:33] Last time we did it was in October. [36:35] and see if you can find ways to get more part of the team together. I'm just sure we're having our first company-wide team [36:41] get together since the pandemic. [36:44] But that doesn't mean that we had to wait that long. I got the product division, all 140 of us together.

[36:51] across two different cities over the course of a month to allow [36:54] people to finally get to meet each other and make that human connection. I think, [36:59] When someone gets to do that, [37:01] it makes Zoom feel a little less scary because you've actually seen and, [37:04] maybe hugged or shook the hand of that other person and now you've got that same human connection that you may [37:10] not otherwise good if you just never saw your coworkers in person. [37:14] So the four... [37:16] Pieces of advice you shared: transparency, spent a lot of time just being more transparent, [37:21] Focus on outcomes versus quality, quantity of hours. Over-communicate and make time for in-person. [37:27] Within the outcomes bucket, [37:30] A lot of people, like... [37:31] Yes, it sounds great. We will focus on outcomes. We're not going to think about how many hours you're working. [37:37] It's hard to do a lot of times because in this sort of work, it's like, I don't know, this... [37:41] Like, what should I expect of this person to achieve? Maybe this bug takes a week, maybe it took a day. [37:46] Do you have any just advice to help figure out a nail like here's how we can [37:51] create outcomes that connect well with people actually working [37:54] Fully. [37:55] Fixing a bug is more of a deliverable than a business outcome. We try to make them things like, [38:04] We want to have... [38:06] 60% of our customer base using this part of the portfolio. [38:12] Now, what do we do to get there? [38:14] And that allows people then have a measurable outcome [38:18] That does tie back to how many hours they're working to a degree, right? Because you're scoping it.

[38:23] But it's not about the ship 20 features next month. That could take you... [38:28] more than a month that could take you a day and a half if you break down your future into tiny little features right [38:35] Whereas it's more like, [38:36] celebrate the adoption, not the shipping. [38:40] And I think that's really where we've tried to move. GitLab as a company has always been very [38:45] Focus on how fast we ship software. [38:48] But that's not really how our customers use it. It's more about, [38:51] what pain point or use case did we solve? And if you're now framing it in that way, [38:56] you begin to move away from the [38:58] deliverable and the hours and you get into the [39:02] Did the customer adopt it? [39:04] What was their outcome? Like what success did they have? What are you trying to do with that? [39:08] And by the way, I think that's the biggest challenge for people who move from a different role into a product division or product role. [39:15] is changing that dynamic to not be like the bits and the bytes, but be the use case, the pain point. [39:22] Because sometimes you actually don't need to ship a new feature, per se. Sometimes you just have to make it more usable. [39:26] Right. And then all of a sudden you're getting the outcome you're looking for. [39:30] You said that a lot of people reach out to you and try to dig into some of the things you've [39:34] What are some of those most common things? [39:36] questions people ask you and or where do people most often go wrong when they're trying to [39:41] work the way y'all work. [39:42] probably the top [39:44] topics that people reach out to me for. The first is [39:47] How did you get into product? [39:48] Because my background, I started as a software developer, [39:52] Had my own company, sold it.

[39:54] For all those listening, just enough to pay off its bills. It was not like I am independently wealthy now. And moved into security research and eventually into product. [40:04] And it's like, how did you make that leap? How did you know it was the right thing for you? [40:09] The... [40:09] Next topic is the IC GitLab has this very transparent handbook and this GitLab unfiltered channel. [40:16] Like what? Like how did this happen? Why are you doing it? [40:20] And then the last one's usually... [40:21] How do I know remote development is for me? [40:24] and i make the jump and i i talk about myself and my time in the office versus not in the office and [40:30] the things for me, I... [40:31] was very transparent with the team when I started in 2019 that, [40:34] I'm like, [40:35] This makes me a little freaked out. I'm not sure this is going to be the thing for me. [40:38] And I love it now. I can't imagine not doing it. [40:42] I like to look back at that time when Gilad made the offer to have me come in and [40:47] start leading a part of the product division and my wife saying, you're going to love this. I don't know why you're questioning it. So listen to your friends, your family, your, [40:55] Your partner, they can also help you with that sort of decision.

[41:25] around authentication, messy third-party APIs, and debugging integration errors. Engineering teams at companies like Copy AI, Cinch, TLDV, and over 100 other SaaS companies are using Paragon so they can focus their efforts on core product features, not integrations. The result? Their shipping integrations on demand, which has led to higher product usage, better retention, and more customer upsells. Visit useparagon.com slash Lenny to see how [41:55] Paragon can help you go to market faster with integrations today. That's useparagon.com slash Lenny. [42:04] Let's do a quick tangent on that first bullet you mentioned of getting into product. What advice do you share with people? And they're just like, should I get into product? How do I get into product? [42:11] I'm very transparent that product is not necessarily the rock star role that people think it is. [42:17] you know, [42:18] The way I tell people who are new in their career, maybe they're now an associate or intermediate PM at lab or [42:23] Other places I've worked that like, [42:25] If everyone's really annoyed at you, you're probably actually doing your job well. [42:29] right? Product is the, like the hub in the middle of the wheel and the spokes are engineering, marketing, sales, legal, and so forth. And, [42:37] like they can't do your job unless you're properly leading. And if, [42:41] you're pushing the boundary and they're all kind of getting a little like, [42:44] Are you really sure that's what you want to do? Or... [42:47] Wow, that seems like a lot of work. [42:48] Or, you know, [42:49] Huh. [42:50] I hadn't thought about it like that, like, [42:52] You're probably doing your job well. [42:54] And what I encourage them to do is think outside the box and,

[42:58] not focus on [43:00] the I call like order taker, like deli counter worker. [43:04] In the US where like everyone gets a number and you just know what that is. [43:07] Think about what do all those requests together really mean? [43:11] And then do that. [43:13] and nod. [43:14] take the orders, [43:16] And so that's kind of the advice I give is like, [43:20] It's not the big sexy role that everyone talks about. It's actually a lot of work. [43:25] A lot of [43:26] discussion sometimes tension [43:29] And... [43:30] you know, [43:31] Lead with the customer first and the use case and the pain point and then everything else will kind of fall in behind that. [43:37] I completely agree. It's the most thankless, painful job there is, but also the best job. [43:41] Yeah, I mean, I now have been doing it for a while. I can't imagine not being in product, you know, and so... [43:47] I'm glad I made the change and, [43:50] I've not looked back. [43:52] Specifically with PMs in a remote culture, I never worked in the remote world as a PM. COVID happened after I left the field and started doing this crazy weird job. [44:01] Is there any tips you could share with PMs that are just struggling in a remote world where it used to be? You just walk up to an engineer, hey, how's it going? How's this thing looking? Let's check out this design. [44:10] Do you have any advice for just how to do those sorts of micro-interactions and [44:13] Stay on top of things. [44:15] Yeah, there's probably two or three points I would make. The first is, [44:19] If you're in an all remote world, your requirements have to be clear. [44:22] You know, sometimes you can get away with, hey, I have a daily stand up or a couple of weeks stand up. [44:27] and then you use that as the opportunity to clarify something.

[44:31] you have to get it written right the first time. [44:34] or at least refined before you expect someone to work on it. [44:37] And so as part of the interview process at GitLab, we do what's called a deep dive interview where we have the person try that out. [44:45] and they engage with another person or product who's playing the engineering side of that conversation. [44:51] It really helps both us see whether or not the person has the potential, [44:55] to be able to work in that type of environment. Oh, this is part of the interview process. [44:59] in the interview process correct and then it also gives them the opportunity to decide [45:03] Can they actually do it? [45:05] And we've had candidates who go like, you know, this wasn't for me. [45:08] And so, [45:10] That's the first thing is like writing real concise requirements is really key. [45:15] Just understand. [45:16] Before we move on, so in the interview, so what is it that they do? You ask them here, write the requirements for this feature that we have, and then [45:23] they kind of do a role play with [45:25] as part of the interview with an engineer asking them questions about it? So it's actually they can write requirements for anything. We're not using it as a way to get free... [45:33] Requirement's written up. [45:35] as part of the interview process. So like one candidate, [45:38] Their topic was they chose... [45:40] bicycles, [45:42] And so it's like, you're going to ship a new bicycle then? Like, what's the epic? [45:46] like the higher level vision and like, what's the first thing. [45:49] milestone for us milestones are releases, but like that first, [45:54] iteration, what is the MVC for that or minimum viable change towards it? [45:59] And then they create that after having like an hour...

[46:03] Zoom call with the person who's going to do it with them talking through it some time. [46:07] They then go write those things and they engage people. [46:10] with that person. It's always someone in Prague. We don't pull our engineering team in to do it. [46:14] But... [46:15] They'll ask a follow-up question on the issue, and then [46:18] let them rewrite something in the issue or they'll ask them a question. Maybe that causes them to [46:23] define something better and [46:25] I personally, when I was interviewing, thought... [46:28] Like, this is a weird step. I'm coming in as a director at the company. [46:32] And then I finished it and was like, this is the best experience I think I've had. This has to stay in our interview process. And so... [46:40] That all ties together is that first... [46:42] first thing. The second thing I tell everyone is [46:45] Don't wave. [46:46] like if you're concerned or worrying something is going off the rails or [46:50] You just want to know something's a... [46:52] on track, like don't wait until your next check in point, whether that's [46:56] A lot of the teams here do a once a week stand up. [46:58] like just, [47:00] ask a question on that issue or on the merge request or send a Slack message right away. [47:05] The last thing you want to do is have a 24 hour, 48, 72 hour cycle go by and, [47:10] and a developer or your engineering manager is stuck, [47:14] Or... [47:15] you know, they've asked you a question and now you're leaving them kind of hanging. [47:18] and not getting the answer they need. [47:20] And that's where, like, to your point, you used to block up to a cubicle, taps on the strong, like, hey, what's going on? [47:25] And now it's, [47:26] You got to do that digitally and that is [47:28] reach out on the communication platform. We use Slack. [47:31] It's like reach out on Slack or comment on the GitLab issue or merge request.

[47:35] For this to work, the values again come up where you assume good intent, [47:40] you be kind people [47:42] Because I think oftentimes the companies that I'm checking in often feels like, god damn, [47:46] Leave me alone. I just want to work on this thing. You just don't trust that I know what I'm doing. [47:50] But I think with these values, that helps avoid that, I imagine. [47:53] It does, and I think it also... [47:56] kind of feeds back into those remote [47:58] work items as well. [48:01] that it's actually good for you to over communicate. It's actually good for you to focus on [48:06] is the outcome happening because you may end up in a situation where the outcome felt like it was really big but [48:12] three days into your one month long iteration which we have here [48:16] All of a sudden, you're always like, [48:17] this is gonna be knocked down a week, right? Well, [48:20] Now don't just wait. [48:21] reach back out and say like, Hey, this is dumb. Like what's the next thing? [48:25] Awesome. [48:26] You mentioned Slack as a tool you use. What other tools do you find really interesting that people may not [48:30] be thinking about for working successfully in a remote environment. [48:35] I'm going to be biased here and say GitLab as a product. [48:38] We call it dogfooding, but we use it for everything we do. [48:43] And that's become key because it makes sure that the product we're shipping is going to work for our customer and our end user. [48:50] But... [48:51] Our policy here is like, hey, if you have the idea, like open an issue and then tag your team. [48:56] And then that issue becomes that single source of truth. And we can then turn that into an epic or [49:01] If it's going to become work for the engineering team, it can be converted into one of those types of issues.

[49:08] We do it that way. We also encourage people to use Zoom [49:12] If you have too many back and forth, so let's say like, [49:14] Like Lenny, [49:16] you ask me a question, I answer it and you go to, but I understand like you ask it a different way and then I answer it again. You're still confused. Like, [49:22] Practically reach out and get on Zoom because maybe it's just something in writing is not translating. [49:27] And so between those three main communication tools, that's what we use. GitLab is very anti-email. [49:33] In a lot of ways, obviously we use it for external communication, but internally it's on an issue. [49:38] it's in Slack or it goes into the handbook. So if we've made a decision together, [49:44] Whatever you and I were going back and forth on, we think this is really important. [49:47] We go update that part of the handbook or add a new handbook page or whatever needs to happen so everyone can benefit from it. [49:53] So when someone updates an issue, do they get pinged in Slack when they go check it out? It's not like an email? [49:58] Yeah, it does. If you have your notifications set up, any comment on something that you created will give you a new notification. The notification shows up in your to-do list in GitLab. [50:08] You can have it send you an email. I have it actually email me and it goes into a folder. Actually created, we use Google Workspace and, [50:16] If it's a you've been mentioned... [50:19] to do it goes into one [50:21] Like it gets one Gmail label if it's a, hey, this was an issue that you're following that there's been activity on that goes into a different label. And that way I can quickly find the ones that I should be responding to. Got it. [50:34] You talked about this handbook workflow. [50:37] So I was reading a bit about that. So basically, the handbook is like, you know, it's like essentially treat us code, people submit PR requests to change the handbook, which essentially is changing the way the company's operating. Can you just talk about that workflow?

[50:49] there's like a piece of like update the handbook before you make change. Yeah. So we, we talked about a little bit about single sources of truth earlier. And one of those is the handbook for us. It's how the company operates. And so, [51:03] If you're finding something that's inefficient in a workflow or you're finding something is unclear, you're encouraged. [51:09] even as part of your onboarding to open up a merge request and make it right. [51:14] And we sometimes make jokes in the product division because when product managers are onboarding, the handbook feels like the product. And. [51:21] in their three week of onboarding, they may end up opening a bunch of merge requests for things like, [51:27] I found this typo. I fixed it. Or, [51:29] The sentence could have been worded better, so I reworded it. Now it makes more sense, right? [51:33] but then there's also the bigger things. So, [51:36] Our product development lifecycle and that workflow and the framework that supports it is all in the handbook and it's in the public handbook. [51:44] And so, [51:45] what that allows people to do is understand exactly how we're going to operate for a milestone, that iteration again, where [51:53] "Hey, what's expected three weeks before, two weeks before from you?" [51:56] And then that allows some of those values we talked about earlier to come into effect because now, [52:01] You also have your EM on the other side who also has something similar and knows when to expect something from you. [52:07] when not to expect it from you. [52:09] But then if there are bigger changes, we of course have processes for those that are defined. [52:14] Great example is if you're going to introduce a new category, which is a new part of the product, it requires my sign off to do that.

[52:20] If you're going to change that product development, [52:23] framework that helps you prioritize, that's going to be approved by myself, the CTO, the [52:30] as well as a lot of our directs, [52:33] that are involved in making sure we're delivering efficiently. And so, [52:37] It can all be from... [52:39] a team perspective to a global wide that you can contribute to. [52:43] what we have encouraged people to do is create their own mini versions of these things. Cause like I want to provide guidance. I don't want to give you direction. And what I mean by that is, [52:52] Like, here's how I'd like you to prioritize. Here are the important things to the company. [52:56] But whether you make that [52:58] One milestone is 100% new features, next one's 100% bug fixes. [53:02] as long as you're achieving the outcome that we've said, [53:05] how you get there is your own decision. And then, [53:07] those individual teams create their own mini version and references back to the bigger [53:12] handbook. [53:13] Got it. One more tactical question about remote work. [53:16] What's your time zones policy? How do you align time zones and get people talking and not bothering each other when they're asleep? [53:23] That's a good question. So we focus on asynchronous communication first. And so that means that like key decisions are. [53:30] that involve people who are in a time zone where the meeting is not occurring. [53:34] that waits until they're back online because they're the directly responsible individual or DRI, as we say here. [53:40] We also focus on making sure the meetings that do happen are optional. [53:45] and are both recorded as we talked about the beginning, but also have really good notes. [53:49] And so that way someone who's in a different time zone can

[53:52] can read that and consume that when they're online. [53:55] Our goal is to make sure we're as inclusive as possible. [53:58] And so that includes even leadership roles, our leader of our team, [54:04] Product portfolio for our SaaS platforms, which are getlab.com and getlabdedicated. [54:08] He lives in Germany. [54:10] but he's a leader at GitLab. [54:11] And his product team is in the US. I think he's got someone in South America. [54:16] people in Western Europe and so forth. And so, [54:19] That means that he may not be online when parts of his team are online, but if he's communicating asynchronously, [54:26] and giving clear outcomes and empowering the people who make the decision. [54:30] it's okay that they may not have overlap. [54:33] I had a leader in our team who was in Tel Aviv, [54:37] At that point, I still lived in the middle of the United States. We had [54:41] a half hour overlap in our day, [54:43] But... [54:44] She was always highly efficient as a leader. [54:47] and her team was also geographically dispersed and they were highly effective and [54:51] To kind of give you the way I've looked at it, it means that you can empower the people around you. [54:57] so that you don't have to worry about those meetings that happen at weird times of the day for you. A good example of I, I, [55:05] can't make it to a leader or meeting that is more APAC time-friendly. [55:09] Because maybe that's where a lot of the team members are. [55:12] I have leaders on the West Coast United States will take that call and they're empowered to do that. And so, [55:17] That's how we kind of deal with it. We are in 60 countries or over 60 countries at this point. We've had to be very careful to be inclusive.

[55:25] And that's what drives those things. Well, no. [55:27] taking recorded meetings that asynchronous focus on communication. [55:32] I was just thinking that with all the recordings you've done, you could train an LLM to basically run your business at this point. I imagine engineers are thinking about that. [55:40] I don't think anyone's thinking of that yet, though maybe they are. They have actually focused on how do you make a version of David who's in every meeting, and they're playing with some of the AI-generated stuff, training it on videos that I've done. There you go. [55:53] We have a lot of fun at GitLab, but we also accomplish a lot too, is the takeaway from that. [55:58] Before I move on to a different topic, in terms of transparency or remote work, is there anything else that you think would be worth sharing or giving people advice on? [56:06] the best summary of the conversation is make sure you're focused on [56:11] communication being clear, [56:13] setting. [56:14] the clear steps like a framework for how to operate. [56:18] And, [56:19] be uncomfortable with the transparency to make sure people can follow along and [56:23] If you're doing... [56:24] those things right [56:26] Remote is actually really great. [56:28] I can't tell you how I feel today in a measurement that's not just like I'm really happy about it, but like, [56:35] I just felt like other places I've worked where we had to hire to an office, I'm [56:39] It really limited... [56:41] the candidate pool you could have. And now being all remote, [56:45] We can hire anywhere for the most part and find the best person for the role. [56:50] And that's a lot of people to have... [56:52] the life they want i don't live in the bay area anymore and i think it's phenomenal i can your family and friends that i grew up with and

[56:59] I can still work that tech job and [57:02] That's not just true for me. That's true for the [57:04] gentleman I mentioned who's in [57:05] you know, in Germany, [57:07] We had an employee who was in Israel in the leadership team. We've had PMs, UX designers, technical writers, UX researchers all over and [57:14] That's not just true for a product, it's true for every product. [57:17] Division IcatLab. [57:18] Okay, so I asked a previous guest who worked with you, Hila Chu, [57:22] who was head of growth, I think, at GitLab for a couple of years. [57:26] and asked her what to ask you, and asked generally about GitLab, and she said that [57:30] GitLab is really good at this breadth over depth. [57:33] strategy of building product and that's been the key to success so far. [57:38] Can you just talk about that and why that's been important? [57:41] I love Hila, by the way. I worked with her for about [57:44] It's a little over two years. I think the time she was here. [57:47] Still, [57:49] talk to her occasionally over LinkedIn Messenger. Someone asked me if LinkedIn was dead, by the way. I think it's how I'd stay in touch with former [57:55] colleagues and playing things out. Now, LinkedIn is killing it. I think they're on the way upswing. They're killing it right now. I think they are. I think... [58:01] That's a whole other podcast on why that is. [58:06] So Hill's right. So when she started in 2019, a couple months after me, we were very much focused on [58:12] of breath over depth. [58:14] And that was so we could build out what is the DevSecOps platform. [58:17] The only way that we could truly help people from a platform strategy [58:21] was to be touching the different parts of the DevSecOps lifecycle or the SDLC, depending on how you look at it. [58:27] Now, last year, we made the conscious decision to start to pivot to depth over breath.

[58:32] And that's because we have a very broad platform today. We are touching everything from [58:37] Business continuity planning and OKRs. [58:39] to [58:40] enterprise agile planning and team planning, decoding, deploying, securing, monitoring, [58:46] the entire SDLC. And, you know, [58:49] We now know there's key areas where we need to be really deep to help companies accelerate delivering software. [58:54] And so in those key areas, they are... [58:57] source code management and the things around that, like code review, ID experience, remote development, [59:03] CICD. [59:05] security and governance, planning, [59:07] and AI, we know if those are really deep, the things that aren't as deep around them, we'll get that like a rising tide lifts all boats effect. And so we've, [59:16] Pivoted in those queries now be depth over breath. [59:19] That's awesome. That's so interesting. Basically, to [59:22] To create a wedge. [59:24] and gain traction sounds like initially they'll just do a lot of things. [59:28] but not be the best. [59:29] And now that you're doing great and have all these products, the strategy has shifted to going deep. [59:35] This is a question a lot of founders always face. Should we... [59:38] Go wide, should we go deep? [59:40] I know you weren't there at the beginning, but just, I guess, do you have any thoughts or insights from... [59:44] when it makes sense to go wide. [59:47] versus when it makes sense to focus. Because usually the advice is just do one thing really great and that's the only way to win. And it sounds like clearly this is... [59:53] an opposite approach here. [59:55] Yeah, and for those who are as familiar with GitLab, as I know you are, we are the leader in our space. We are the DevSecOps platform. [1:00:02] Not just us calling them, but

[1:00:04] User reviews, analysts like Gardner and Forrester are calling that out. [1:00:09] And so, [1:00:10] What for us it was, was that [1:00:12] I think when you're going really wide, you're trying to find your niche and like what you're going to be really good at and what you can differentiate on. [1:00:20] And for us, what that was is, you know, where are the key areas that we can truly help someone accelerate delivering software? [1:00:26] And over the course of those years, you're right. [1:00:29] We were still in a fast growth period when I started and I was part of that [1:00:33] breath first when I started in 2019, but [1:00:37] we found those key areas that we know if they are truly deep, [1:00:41] they bridge to the other area that's deep. [1:00:44] And maybe some of those areas would have to be as deep as the things around them. And so, [1:00:49] A good example is we started adding model ops functionality to GitLab in 2020. [1:00:54] We focused heavily on adding depth to MLOps, which is just one of the three pillars of that. [1:00:59] And we know that DataOps will probably be needed at some point, but if we have a nice integration with DataOps platforms, [1:01:05] you can actually do all your MLOps work in GitLab and be successful at it, [1:01:10] with a lightweight connector or component that's there. [1:01:13] And so, [1:01:14] That's what we've done is we've started really investing deep in those key areas. [1:01:18] knowing that it's going to [1:01:20] Help those areas that we aren't investing necessarily as much in be still good enough and kind of touch on what you're touching on earlier about the. [1:01:28] getting to that good enough level. [1:01:30] What's interesting is my last interview that I did... [1:01:33] was with the co-founder of HubSpot.

[1:01:36] Darmesh and they had the exact same strategy [1:01:39] breadth over depth, [1:01:41] Also, one of their core values is transparency. They share all of their financials with everyone, salespeople, everyone. They see everything. [1:01:47] So it's so interesting that there's [1:01:49] companies are very different and have very different markets. [1:01:52] But there's two really similar elements here. [1:01:55] And I've worked out for both. I guess does that bring up anything? I don't know how much you know about HubSpot. I mean, I know the company and know some people who worked with me in the past that have gone there. I think what [1:02:05] what you're touching on is that [1:02:07] There's some like product frameworks that are universal. [1:02:10] I occasionally will have founders reach out and ask the question, [1:02:14] When do I make that pivot? [1:02:16] And it's really like, have you found your fit in the market? [1:02:20] And have you done the whole, and I'll, you'll use like, [1:02:23] you know, Jeffrey Moore's book, "The Crossing the Chasm," like, have you found that? And if you have, [1:02:28] Now you know to put all of your wood behind that arrow to [1:02:32] use a saying, right? And then you're able to get that differentiation and that market presence. And [1:02:38] We go back to breadth over depth when we're looking at new investments, so it's not like it's left GitLab. [1:02:44] It's currently part of our AI strategy that we're finding the spots for DevSecOps for AI makes a lot of sense. [1:02:51] But we also know that [1:02:53] if those five things I shared with you are, [1:02:55] leading and we see them as leading in the industry, it's going to give us the ability to do more of that breadth over depth as we try to expand our SAM or try to go after a new marketer. [1:03:05] What's interesting with...

[1:03:08] Garmesh's approach I'll share briefly as their goal... [1:03:11] internal metric was if we're the top three product in any of the categories, we're [1:03:15] doing too much. [1:03:16] We're investing too much in these products. We don't want to be the top three in any of these yet. [1:03:21] We just want to be fine because holistically it's going to be great. But just, I want to move on from this topic, but just it's interesting. [1:03:28] The approach you shared. [1:03:29] for GitLab of why going white made sense was [1:03:32] explore opportunities and then go big when you find something that works. [1:03:36] HubSpot strategy was [1:03:38] Our customers need all, like the problem they have includes needs all of these many things. [1:03:42] And so to solve the actual problem, it turns out we need to build a lot of things that [1:03:46] That way it is. [1:03:47] And I imagine that was a part of GitLab's need too. [1:03:51] Yeah, I'm sure as we grew, you know, I... [1:03:53] I joined 2019, company started [1:03:56] years before that and [1:03:58] You know, I've just seen the maturity of the company as a whole and the growth and, you [1:04:02] the need to focus on going deep in some really core areas. But like I said, we, [1:04:06] Still go back to that same approach that they have. It just depends on what we're talking about and why we would make that decision. Cool. Okay. Just a couple more questions. [1:04:14] I know you guys are doing some cool stuff with AI. Let's talk about that. What's going on with AI and GitLab? I would say we've taken a very unique approach to AI as part of software development. [1:04:24] And the reason why we did that is that GitLab has a very unique position. We are a true DevSecOps platform. A lot of our [1:04:30] competitors that people talk about are like a developer platform or developer experience. [1:04:35] type tool and [1:04:36] we know that if

[1:04:38] 25% of the SDLC is actually creating code. 75% is not. [1:04:44] And we want to help all those people around the developer be successful and [1:04:48] To do that, we kind of set ourselves like three core tenets or principles for AI a couple of years ago. [1:04:52] The first one was, "A.I. across the entire software development lifecycle, we want to help product managers, [1:04:59] QA teams, [1:05:00] Ops teams, security teams also benefit from AI. [1:05:03] If you make your developer 100 times more effective, it just means probably everything around them is going to break. [1:05:09] And so to make them more effective, you've got to help everyone. [1:05:12] The next was we wanted to be both transparent, which fits into our conversation earlier, right? [1:05:18] and be focused on privacy with AI. And that means that [1:05:21] We tell you what models we're using, we're source available so you can see how we're using them. [1:05:26] We tell you how they're trained. [1:05:28] And the privacy part is we don't use your intellectual power for training and fine tuning models. [1:05:33] Our models are trained on data that is not yours, which means that you don't have more safety. [1:05:38] and using that, I think [1:05:40] Other companies have shown why that's important with leaks of customer data. [1:05:46] And we want to avoid that. I think the thing that's interesting is, [1:05:49] as a source available open core company, [1:05:52] were actually trusted by more than 50% of the Fortune 100. [1:05:57] So, [1:05:58] If more than 50% of those top companies trust get allowed to secure their intellectual property, we had to do that with AI as well. [1:06:04] And then the last one was AI efficiencies. We wanted to make it so...

[1:06:09] There is a boost in efficiency. GitLab [1:06:13] Ultimate are top tier [1:06:15] has a 7x boost on productivity. [1:06:18] as from our customers doing a data analysis of their improvements. [1:06:23] We want to take that to 10x. [1:06:25] as part of it. And so we think AI can give us that last little bit of a burst. [1:06:30] Now, [1:06:30] I did mention a minute ago and I'll stop there and see if you have questions on those. And then, [1:06:34] I just want to talk a little about where we're going with AI, because I think it's pretty exciting. [1:06:38] I guess the only question is just for other companies, other product leaders thinking about [1:06:42] integrating AI, working with AI, any [1:06:45] tips or lessons you can share that might be helpful on their journey. [1:06:48] What I would say is like we spend and this is really the third ten is finding the right model for the right use case. [1:06:54] And good, I pointed out that your question reminded me of it. [1:06:58] What sometimes people will do is they go, oh, there's this really popular large language model, whether that's a commercial or open source. [1:07:05] And they make everything fit into it. [1:07:08] and what you end up doing is actually reducing the quality that someone can experience with that feature that's leveraged by AI. [1:07:15] I encourage people to find the right model for the use case. We have [1:07:20] around 16 models we use today to make GitLab [1:07:23] have its AI suite, which is called GitLab Duo, [1:07:26] And we've done that to say like, hey, this one's really good at explaining and resolving vulnerabilities. We're going to use that for that use case. [1:07:32] This one's better at summarizing conversations and plan. [1:07:35] Let's use that. [1:07:36] And of course, like code creation is also an area where

[1:07:40] If you're using the same model for inline code completion as you are for code generation, which is, [1:07:45] sharing blocks of code, [1:07:47] you're going to have a much different user experience. The things that generate blocks of code, like functions, [1:07:53] Those actually take a while to run. They take seconds, sometimes 20, 30 seconds to fully respond. [1:07:59] If you're just asking for the next couple of lines to be completed, you're not going to wait that long. [1:08:03] And so you've got to have something that can handle that as well. [1:08:06] We've done that and I encourage everyone else to do that. [1:08:09] If you go to the GitLab docs website, you can select GitLab Duo and you'll see all the models we're using. [1:08:14] And you can start to understand as you learn about those models, [1:08:17] you start to see why we chose them. [1:08:20] And it actually has allowed us to get closer and closer to that 10x that we're wanting to get our customers to. [1:08:27] I'm pulling up that page, but when you talk about models, are you talking about like, [1:08:30] OpenAI's, APIs for one, and then Gemini for another? Or is it like internal models you're building? [1:08:35] It's both GitLab created, open source, and commercial. Today, we've partnered with both Google... [1:08:42] and Anthropic, and those are where the commercial models come from. Got it, got it. Yeah, and then we actually acquired a company at the beginning of 2021 or 2022, [1:08:53] named Unreview. [1:08:54] and [1:08:55] We have those models. Those are the ones that would be good lab proprietary. And then, [1:08:59] We do use open source as well. [1:09:01] We're actually looking at how we can leverage open source more and contribute back there. We have a really awesome AI model validation team. [1:09:08] There are a bunch of AI researchers that,

[1:09:11] I've studied things like ethical AI and AI at scale, and that's allowing us to select the right [1:09:18] the right model. [1:09:19] Cool. I imagine part of this is because [1:09:21] GitHub, your competitors owned by Microsoft and OpenAI, and try to avoid that whole area, as I'm guessing is a part of this thought process. [1:09:29] Well, it's also about meeting those tenants, right? And so, you know, we, our partners at their commercial, they need to meet that same requirement and that same vision. And, [1:09:39] both Google... [1:09:41] as in Google Cloud and Anthropic, were able to meet the privacy requirements we had, and those are really important to us, right? [1:09:46] And so... [1:09:48] Not every company, [1:09:50] that we could partner with could do that. And so we had to be very careful as to who we partnered with. [1:09:54] And so, [1:09:56] There's nothing about the companies we're not partnered with. Maybe we just haven't gotten to that point yet. [1:10:00] Right? But... [1:10:01] That's part of being a partner is you have to meet those same [1:10:04] values, for lack of a better way to put it, that we have base of our customer base, especially [1:10:10] Trusted by more than 50% of the Fortune 100. Makes sense. [1:10:14] Okay, going in a totally different direction. [1:10:16] Heela also said that [1:10:19] You're a leader with it. [1:10:20] great sense of humor, and you often use your humor [1:10:22] to navigate very high stakes conversations and executive negotiations [1:10:27] And I think a lot of people would love to have this skill. [1:10:30] Do you have any advice or lessons? [1:10:32] Other than just being David and being who you are, I guess, any lessons for leveraging the skill, building the skill, how you apply it? [1:10:39] I'll take the compliment from Hilo. What I learned early in my career is that tension, especially very...

[1:10:47] like high, very tension... [1:10:49] driven conversations. [1:10:51] can really kill productivity, kill morale. [1:10:53] And then I found that if I can deflate that a little bit and kind of re-add that, [1:10:59] some [1:11:00] I don't say humanity to the conversation, but really disarm the topic that people are able to move forward. And I think that's what she's talking about. I will say that it probably is partially David being David to a degree. [1:11:12] Maybe I'm leveraging the class clown experience of my elementary and high school experience and [1:11:17] harvesting it for good now. [1:11:19] But I think people can also do that and [1:11:23] Leaders who have seen me do that, like Hila, have learned that there's ways to do that. If you can read the room and the nuance and know whether or not it's okay to try to add a little bit levity. [1:11:34] But... [1:11:34] I consider a value part of my tool, tool belt now, like a tool in my tool belt and [1:11:39] I'm glad she appreciates it. You know, [1:11:42] Not every joke lands, which I'm sure you're surprised. You're not surprised by that. Right. So, [1:11:46] But yeah, I think it's been... [1:11:49] Good to help. [1:11:50] keep people moving forward. [1:11:52] Love it. [1:11:53] David, is there anything else you wanted to share or touch on or leave listeners with before we get to our very exciting lightning round? [1:11:59] The big thing I just like to let people know if you're not familiar with GitLab or you haven't heard of GitLab in a couple of years, please go check out our website. [1:12:07] We do... [1:12:08] everything across the software development lifecycle. [1:12:11] When I started in 2019, I was hired at compliance and security to DevOps, which has made us a DevSecOps platform.

[1:12:18] And now we've gone from not just source code management and code review or [1:12:23] CI/CD but true security and governance. [1:12:26] That includes things like our remote development offering, where now you can even get developers up and running in minutes. [1:12:31] on a software project. [1:12:33] our enterprise agile planning capabilities, and of course, GitLab Duo. [1:12:37] We've heard from customers, they've seen efficiency boosts of 50% and above. [1:12:42] by leveraging GitLab Duo and [1:12:44] I would say if you've not heard from us in a while or aren't as familiar, please just check that out because... [1:12:50] We are truly unique in the space, and it's something I take a lot of pride in. [1:12:53] People said no one's going to want a platform. They want a bunch of point solutions and [1:13:00] Customers end up with 75 tools to try to deliver software and they adopt GitLab and all of a sudden they realize, [1:13:06] how much more effective they can be in collaboration and even that transparency stuff we talked at the beginning. [1:13:11] I'm at the website and even then I'm like, I still don't. I think it could do a better job telling me everything that you do. So just to quickly summarize so people know, what are the bullet points of all the products and solutions you guys offer real quick? [1:13:24] We do everything across the software development lifecycle. Some areas are really strong. [1:13:28] Those key areas are SCM, code review, what would be called the create stage and that [1:13:34] in the tool chain. [1:13:35] CICD, we're industry leading there as well. [1:13:38] Security and compliance. So we can do application security scanning. We can do [1:13:43] Things like software bill of materials and, [1:13:46] traceability and all the things that go around compliance and governance.

[1:13:50] And then, of course, we also have monitoring, whether that is [1:13:53] value stream management and analytics. [1:13:56] We can now do... [1:13:57] product analytics so you can have GitLab embed telemetry and then [1:14:01] see how that app is being used, [1:14:03] And we are currently working on expanding into observability and service management. [1:14:09] But... [1:14:09] It is truly an amazing experience if you start with just an idea in our planning functionality, [1:14:15] Again, been awarded a leading enterprise agile planning solution. [1:14:20] And then take that from idea all the way to running in production and then learn from that and bring it back into the... [1:14:25] into the life cycle. [1:14:27] But I'll take your feedback back to marketing and say, [1:14:30] I was just on an amazing podcast, met an [1:14:33] Great guy. Hope we get to talk again in the future. And [1:14:36] He said, I can't come back until the website's better. So can you please... [1:14:40] Let's just make it a little bit clearer. Yeah. [1:14:43] Make the website clearer, software faster. [1:14:46] That doesn't tell me what I need to know. [1:14:48] I like this list you gave me. Okay, amazing. We're solving all of GitLab's problems right here. There we go. [1:14:54] With that, we've reached our very exciting lightning round. Are you ready? [1:14:58] I am ready. [1:14:59] What are two or three books that you've recommended most to other people? [1:15:03] The two that I probably recommend the most are Crossing the Chasm by Jeffrey Moore. [1:15:07] The current edition still has some things that are a little bit older now as examples, but [1:15:11] the core of it is still very, very amazing. [1:15:14] The other one is essentialism. [1:15:16] And that is really about saying no to the right things and finding the thing that you really need to do to get the job done.

[1:15:22] And then not a book, but Jeffrey Moore created this. There's the Critical Core Context Framework. [1:15:28] And if you've read both of those books, it really helps you frame in [1:15:32] what is the critical part for your business? What is the core of the expectation? And what are the [1:15:37] say no to with the little battle risk. [1:15:41] those things together, [1:15:42] I think are really powerful. Does he talk about that in Zone to Win, or is that just something independent of his books? [1:15:48] I think it was a class he created and it turned into a class. [1:15:53] chapter two in one of his books. I don't remember which book it's in though. Super cool. [1:15:56] That'll work. [1:15:58] Next question. Favorite recent movie or TV show you really enjoyed? [1:16:01] The most recent TV show I really like, The Devil's Hour, it's a BBC show. If you've not seen it and you like... [1:16:07] sci-fi crossed with like, uh, I don't know, I'll call it like a mystery criminal, uh, [1:16:13] type of show. It's really, really good. [1:16:15] Movie-wise, it's an older movie. My wife and I just watched The Glass Onion, really liked it. [1:16:21] And then... [1:16:22] there might be a little bit of a Swifty in me and we watched the Arras tour when it came available to watch. And, [1:16:29] Also, it was phenomenal. I can't believe three and a half hours went by as quickly as it did. [1:16:34] I also watched it and enjoyed it. [1:16:36] Do you have a favorite interview question you'd like to ask candidates that you're hiring? [1:16:40] So I won't say there's a specific question. It's so much a method. So I really like the STAR method for asking questions. If people aren't familiar with it, Google it. [1:16:50] It's really powerful. [1:16:51] And then how I then apply it to be my favorite question, depending if it's PM or it's someone in engineering or another department is,

[1:16:58] Give them a scenario where there's a little bit of conflict, [1:17:01] or attention and having them work through that [1:17:04] As an example, I think those really kind of give you a sense as to how people can problem solve. [1:17:09] Do you have a favorite product you've recently discovered that you really love? [1:17:12] Yeah, so this is going to be a sad moment for me. My favorite new product is actually going away, Artifact News. [1:17:18] I love artifacts. Yeah. I think it's actually hit the point where it's hit its end of life, but [1:17:24] It was revolutionary for news. I thought it was fantastic. [1:17:28] The things I use that are not the app that just went away that [1:17:32] So what was that about? [1:17:34] I've really gotten a love for superhuman for email. [1:17:38] It's really allowed me to make our Google Workspace customer more powerful. [1:17:44] And most recently, I just started using the Arc browser from the browser company, and [1:17:50] I think it's fantastic. I like how it organizes everything and [1:17:54] archives tabs that they've been inactive for too long and all these things that I think just [1:17:58] took me from a single... [1:18:00] Chrome window to like five Chrome windows each with a hundred tabs and [1:18:03] has made me more effective. Awesome. Also a huge fan of ARK. They've been, Josh Miller was on the podcast talking about how they operate [1:18:11] And Superhuman is a sponsor of the podcast. So I love all your choices. [1:18:15] Do you have a favorite life motto that you'd like to come back to or share with people that you find useful and work during life? [1:18:20] I actually have like two or three. I'll say them quickly for everyone. But the first is like as a leader, my first one is, [1:18:26] Your team's accomplishments are theirs, but their failures and misses are yours.

[1:18:31] And I, early on in my career... [1:18:34] would have loved to feel like sometimes like my work wasn't just then praises for my manager. And, [1:18:41] As now a leader of a very large team at GitLab, it's been important. [1:18:45] The one that my team laughs at that I say a lot is as a general motto, like I'll go like, just make it work. [1:18:51] and [1:18:52] People who are listening to your podcast might realize that's a Tim Gunn saying from Project Runway. [1:18:57] And it was kind of like my way of taking on the work the problem statement and making it a little bit more... [1:19:02] Like, okay. [1:19:04] This is the thing you have to figure out, like make it work. Like, what does that mean for you? [1:19:09] And so it also lets me throw in pop culture too. [1:19:12] And the last one, and I'll say I came up with this when I was back as an engineering director. [1:19:18] was, you know, it's just software, so anything's possible. [1:19:21] you know, a lot of times someone will say, well, I can't really do that. It's like, [1:19:24] Well, but it is just software, right? Like, [1:19:28] It's just it hasn't been done yet, but it's it's doable. [1:19:31] David, this is so fascinating. The culture at GitLab is fascinating. You're fascinating. Thank you for making time and sharing all these stories and insights. Two final questions, where can folks find you online if they want to reach out and learn more? And how can listeners be useful to you? [1:19:44] If you want to follow along with GitLab, we're at GitLab on basically every social. [1:19:48] So go to any social media. You can find us. For me personally, [1:19:52] I'm D DeSanto on LinkedIn. You just search for David DeSanto. I should come up. [1:19:56] I'm David_Santo on X, and as I mentioned earlier, [1:20:00] I am David the Beard on threads. I'm also trying to make Blue Sky a thing for me. So if you want to catch me, I'm just D to Santo on. I'm.

[1:20:08] Blue sky. [1:20:09] And then how listeners can really help [1:20:11] There's really two things. One, please share feedback with GitLab, with my team. You can go and comment on our issues, our ethics, our tasks. It's all public. [1:20:20] Flip things up, give us feedback. [1:20:22] That's always very helpful. Just go to getlab.com and you can see our code base. [1:20:27] And then if you are someone who... [1:20:29] wants to contribute, like, please open up a Merge Request, improve the handbook. [1:20:34] Companies fork that handbook and then use it for their sales as well. So you're not just helping GitLab, you're helping everyone. [1:20:40] as well as maybe contribute to the code. It can be as simple as fixing a small bug to... [1:20:45] adding a new feature. Some of our favorite features are ones that others have contributed outside of GitLab. [1:20:50] Awesome. Well, David, again, thank you so much for coming and sharing. Now I'm going to go watch this meeting you're in later on YouTube. Anyway, thanks for coming. [1:21:00] And thank you. [1:21:02] Yeah, thanks for having me, Lenny, and love the conversation. Let me know whenever I'll come back. [1:21:06] Amazing. [1:21:07] Bye, everyone.