Episode 27: Leading with Values: Sid Sijbrandij joins Matt Mullenweg to talk about GitLab, Transparency and Growing a Distributed Company

“Every company has a poster on the wall,” says Matt Mullenweg in the latest episode of The Distributed Podcast. Matt welcomes Sid Sijbrandij, Co-founder and CEO of GitLab, another pioneering company with Open Source origins and a long-running commitment to a completely distributed workforce.  Sid and Matt settle into a conversation about GitLab’s six values – which have been cut down from the original 13, and which are always visible in Sid’s video background – are reinforced in 20 ways at the fully-distributed company.  GitLab, now with more than 1,300 employees, updated its values over 300 times in the last calendar year. 

“They have to be reinforced,” says Sid, “and be alive in that way.”

And as for sharing just about everything publicly? “Transparency is sunlight.”

The values are part of the publicly-viewable GitLab Handbook that, with over 10,000 pages, details data both interesting and “mundane,” from compensation to how employees should interact with Hacker News. An example: “I think what’s really interesting is our engineering metrics. We pay very close to what we call the MR rate: how many merge requests did an engineer make over a month; how many did a team make over a month?” Sid shares.  “If you push on that, people start making the changes that they make smaller to kind of increase that rate.  The whole process becomes more efficient.”

Sid and Matt – an observer on GitLab’s board – get into the details: taking time off, leadership development programs, scheduling coffee chats that actually work, and much more. And they revisit predictions Sid made on Twitter in May, 2020, about the post-Pandemic future of distributed work.  Check out the full episode above, or on your favorite podcasting platform.

The full episode transcript is below.

***

MATT MULLENWEG: Howdy everybody and welcome to the Distributed Podcast. I am your host, Matt Mullenweg. Today’s guest is a like-minded leader of a software company that is driven by its values, supports open source and happens to be distributed too. Sid Sijbrandij is the Co-Founder and CEO of GitLab, a fast-growing company and a single application for the entire DevOps (life?) cycle. 

GitLab has been distributed basically from the beginning. But last May, two months into the pandemic, Sid made some predictions that we will talk about today. Even more so, Sid very often talks about the values that  drive GitLab and how they experience each day as a growing company, a really rapidly growing company, actually. 

So it’s rare to get to talk to someone who has been such an advocate for distributed teams as long. And also as full disclosure, I am a board observer of GitLab, so I have had an inside view to some of what y’all have been building and it has been amazing to have a seat at that table. So Sid, thank you so much for joining.

SID SIJBRANDIJ:  Yeah, you’re welcome. And thanks for being at that table at GitLab.

MATT:  Yeah. Talk to me. Let’s start off with just a little bit of the values that you hold as a company because I think every company has a poster on the wall –  and you have one on your distributed wall – but how does it actually come into play for y’all?

SID:  Yeah, I think you can tell how serious a company is about its values in two ways – how often they update the values, our values got updated over 300 times last calendar year.

MATT:  Wow.

SID:  So it is a living document. And then the other thing is how do they reinforce the values. We have now 20 ways to reinforce our values. So it’s not that that document doesn’t matter, it is are they really lived. And for them to be lived, they have to be alive themselves and they have to frequently be reinforced and be alive in that way.

MATT: I saw you could reinforce the values by complimenting people but you could also put a virtual background with one of the values on it as one of the 20 things?

SID: Yes. If you see my Zoom, I will always have six logos above me. And those represent our six values. And yeah, I like the complimenting as well. We have a thanks channel and in that thanks channel people thank each other and then people can comment and they frequently do that with emojis that represent our values and then we keep count of who was particularly good in expressing certain values throughout the year.

MATT:  Do you tie them into performance reviews? Like, do people talk about the values as part of performance reviews?

SID: With those emojis, that is linked to our annual event and we select the people who best represent a certain value and those emojis are used to create a short list and a group of people decides who best represented it. So it’s input. It’s not ideal but it gives a good way to make a short list. 

And then, yes, performance reviews, the values tie into that but also into hiring decisions.  And for example, I think the most important thing is promotion documents. Every promotion document at GitLab is shared with everyone in the company and its primary structure is the values. 

MATT:  To put you on the spot, can you name the six values?

SID:  Yes. We had 13 values before and even I couldn’t name them so that was a good reminder to rationalize. So our values spell the word credit. It’s the credit we give each other by assuming good intent. The first C stands for collaboration, the R stands for results, the E for efficiency, D for diversity, inclusion and belonging, the I stands for iteration and the T for transparency.

MATT:  I guess with D you kind of expanded it. It stands for multiple words, but that works.

SID:  Yeah, first it was D&I and now that we added belonging it.. I am open to changing the whole thing but I think having one letter per value is defensible. 

MATT:  Since you have a backronym or an acronym that spells things out does that make it harder to add values of certain letters or make it more incentivized, like certain letters to be added, like maybe it would be easy to add a value with an S but it would be hard to add a value that started with X. 

SID:  Yeah, Credits. Yeah. I guess there’s a certain amount of sunk cost there or inertia to overcome to change it. I think there hasn’t been a big push to add a value. We have had diversity changed to diversity and inclusion and now diversity, inclusion and belonging, that has been the major thing. Other than that, people talk about how do the values relate to each other and we have a lot of sub values. 

So for example, today I am having a call with Dara and Dara said, look, some of our sub values are more important than others. So the six values I mentioned are core values but then we have sub values that are kind of.. that relate to certain examples and that make it more concrete because otherwise it’s just words and they are very open to interpretation. The sub values makes them actionable. And Dara, her very good point was some of our sub values are more important and more actionable than others so maybe we should cull some of them or maybe we should elevate some of them.

MATT:  What were some of the values you got rid of or renamed? What were some of the seven that got cut out?

SID:  Yeah, I forgot about them so that’s good. But I think we found some overlap. The exercise we did is we wrote down all the values we had, we wrote down some that we thought we should have and started grouping them and we came to this. And actually it wasn’t a big exercise, it was me and my CEO coach who did that one afternoon in a couple of hours. And then I proposed it and it was clearly better and that’s how that happened.

MATT: This is probably a good time to introduce the GitLab handbook. So all of these values and the 20 ways you can put them into effect and everything like that is all  public on your website. 

SID: Yes. I think our handbook is now over 10,000 pages and it has all of our process and procedures, like how you work. And now just the boring ISO stuff but really what you would need to know if you join our company.

MATT:  What does ISO stand for?

SID:  Sorry, I’m from Europe and a lot of companies follow the ISO standards for documenting process. And that left a big impression on me because those ISO handbooks were not what really happened in those companies. There was the written ISO process which you could update once a year and the other was what people really did. 

So there was the paper handbook they haven’t touched in two months and there were the sticky notes on the computer how to really do things. And I was like, look, if you’re going to have something, it should be easy to change because how you work changes every day so it should be a living thing that people use every day and it gets updated every day.

MATT:  So let’s say I’m an employee at GitLab and I would like to update one of the values. Could I submit.. the entire handbook is in GitLab, I could submit a merge request? 

SID:  For sure.

MATT:  And what would happen?

SID: You don’t have to be an employee.  You don’t even have to be a board observer.  You can just.. anyone in the world can make a suggestion to improve them. And then if you think I should have a look at it, I suggest you at mention me on Twitter or send me a DM. But most of the time also people kind of check it out and escalate it within the company. We have a values Slack channel that will probably pay some attention to it.

MATT:  To give people a sense of the scale, its 10,000 pages but these are very, very distinct. So it has onboarding. Do you still have the org chart and everything on there? 

SID: Yeah for sure.

MATT:  Salary. And occasionally you will run into something that links to an internal google doc that you only have access to as a GitLab employee. But there is, yeah, what I can only describe as a radical transparency that the organization practices, that’s different than I have seen really anywhere else, even other companies that really practice a ton of open source thinking.

SID: Yes. And I think what has been cool, I gave a talk at YCombinator recently and there was a bit of what would GitLab do. So if you have a question (started?) the first thing is like try to see.. Google the question with GitLab and see if it is already in our handbook. And that is probably a decent starting point. And that is just because we kind of document a lot of mundane stuff. Like, I don’t know, I’m not sure we documented trademark registrations but it would totally be something we document. So because we document so many mundane sales, marketing, engineering for processes, it’s a good starting off point if you have to make something yourself.

MATT:  You know, there’s often CEO backchannels where you’ll ping another CEO and be like, so how does this work at your company or what do you do for this? And I would say that you are the one I ping. And 99.9 percent of the time it’s a link to your public handbook. I mean you don’t say Matt, let me Google that for you but [laughs] I’ve started just.. I’m probably pinging you a little less because just everything is on the website. I’m like, oh, how does GitLab do sales on boarding? I know you brought your time to productivity down quite a bit and your time to hire, some things you’ve been improving. So that’s all there, including what you’re trying to improve.

SID:  Yes. And Matt, rest assured that every time I send the link I’m just very, very proud that we have written it down. It’s not dinging anybody for not looking it up. It is very counterintuitive that that is out there and that it’s big. So it’s not.. Google really helps but it’s not always easy to find something.

MATT:  What is something that listeners might find surprising that you have public on the handbook?

SID:  I think our compensation ranges. Its maybe not as surprising anymore but it is always something people care a lot about. I think all the mundane stuff, like how we interact with hacker news, like people in the team should probably not post GitLab articles to that, we don’t want to be perceived as astroturfing, disclose who you are. I think there’s just a whole lot of mundane things. 

I think what is really interesting is our engineering metrics. So in engineering we pay very close attention to what we call the MR rate, how many merge requests did an engineer make over a month or did the team make over a month correlated to the team’s size. We found if you push on that people start making the changes that they make smaller to increase that rate, which is great because then it becomes easier to write, easier to test, easier to review and the whole process becomes more efficient. 

MATT:  That is interesting because developer productivity is notoriously hard to track and measure. What is the rate that you aim, an engineer at GitLab might aim for?

SID:  Yes, so we are around 8.8 right now. 

MATT:  Merge requests per month?

SID:  Yes.

MATT:  Oh, so that’s.. I had expected the number.. is that where you want to be or is that where you’re at?

SID:  We always want to be a little bit higher. So, like nine, ten-ish would be great but we are also in the middle of a global pandemic so we have not pushed very hard on it recently. So yeah it also differs a bit between teams and what they are assigned to. But I think it’s a great rate. And I think the awesome thing is it only counts if you actually got it all the way to the end user, people started using your code. And I think that helps to keep things small and to reinforce one of our top three values – iteration.

MATT:  How fast does GitLab iterate?

SID:  So I think it is very important to quickly get things out to users but I think in the end it is like how productive is an individual. So I think that 8.8 captures our productivity. 

MATT:  8.8?

SID:  8.8. Sorry. 8.8 merge requests per month.

MATT:  Oh, yeah, yeah. But to that question, you ship major new releases is it once a month and have for like a bajillion months?

SID:  Yes. We now.. I think we get code into production after it’s merged within 12 hours, so released on GigLab.com and it’s a continuous process. We just bundle it up per month because we have a lot of self-managed users, they kind of need a version number to make it digestible and a blog post to make it digestible but it’s really a continuous release. And every month we have over 50 substantial things that we ship, at least substantial enough to mention in the release post. So I think we are extremely productive considering the whole company is about 1200 people and engineering on features is about 500 people. 

MATT:  You mentioned maybe working with ISO in the past. Was there anything earlier in your experience or life, personal or work, that drove you to create a company which was so ruthlessly documented and relentlessly documented and process driven but in a really, really positive and enabling way?

SID:  Yes. I think a lot of GitLab values can be explained by my scar tissue. And I did a lot of things. I built recreational submarines, I was a part-time civil servant, I worked at Proctor & Gamble and IBM. I thought it was so inefficient. 

If you have to ask somebody else, like, how is this done.. It’s not just inefficient for the people on-boarding but I think it is most inefficient when you have to change something. If you want to change something what you had to do is you had to build up all that context for this is what I’m talking about and then say okay, and this part we are going to change and then present that to the whole company. And then a person onboarding a month later would now have that presentation.

So, like, how does that work? It kind of works but it’s really silly. And I think one of the biggest benefits of having a handbook is that you can change something and it’s.. You don’t have to build up all the context because the context exists in all the links from the documents so everyone understands what you are talking about. And it is relatively easy to change, it’s easy to make the suggestion, anybody can do it, it is easy to discuss that suggestion. And then when that is merged, when that is pulled in, it’s clear to everyone from then on that that is effective. 

MATT:  By the way, this has been very influential on me as well in that I have been asking a lot, actually for a few years now, like, why can’t we make more of our stuff public?  And the answer is generally just that it takes time. There’s not a real reason that anything in our internal field guide needs to be private, most of it. And so that makes me think that if you do this from the beginning it is just so much easier. So I would encourage anyone listening that is curious about this, just start publishing things as soon as possible. 

What would you say to people who think it’s scary or we have things that are proprietary to our company or if our competitors know what we’re going to do they’re going to be able to out-maneuver us?

SID:  I think there is a page at the bottom of our strategy page from Peter Drucker, strategy is a commodity, execution is an art. I think the really great companies, they have a super obvious strategy, they just do it better than anybody else. I think if you depend on your strategy being a secret it’s first of all very hard. Some of your people are going to quit and then talk to the competition, so it is very hard to keep it secret.

I think it is actually very hard for everyone in your organization to know your strategy. Most companies I have been with, like, people didn’t even understand the strategy, the people who worked there. So I think in general optimize for more people knowing your strategy, not fewer people knowing it. And we have found that having our roadmaps public and things like that has been a bit benefit. It has been such a big benefit that we might have inspired our competitors who are also now publishing their roadmaps. 

MATT:  And you are in a highly, highly competitive space.

SID:  Yes. And I think a lot of the things you do are not differentiated. No one is going to buy from GitLab because our accounts reconciliation process. Like, people don’t care. But it should be efficient and the best we can do but it’s not like we lose our ability to compete if our competitor implements the same process. In general, people have a super hard time embracing even just best practices, let alone their competitors’ practices. 

And I think you lose a lot and you win a lot, I think. Transparency (and sunlight?) makes you do better work. You get a bigger.. an easier ability to change. And yeah, there is a bit of hesitation that is from being afraid. I think that doesn’t make sense. I think what does make sense is that it is more work. When you want to make a change, changing it in the right context takes more work than firing off an email. 

So I think while the change is more work, it is more durable. So over time you can start reaping the benefits but it’s a.. Short term it is more work and then it pays off over the long term.

MATT:  And that is because, and this is my understanding, that the change isn’t actually.. it isn’t real until it’s in the handbook, right? 

SID:  Yes.

MATT:  So we can’t say we’re going to do this for a month and then we will put it in the handbook later?

SID:  Oh no. That doesn’t work. So we are very adamant about handbook first. The only way you can communicate a change is when it’s done in the handbook. And then commonly you just refer to the (dif?), like this is what changed, you link directly to it. What we cannot have is someone emailing, presenting, talking about a change that is not in the handbook. 

Because if you instill in the company oh you can document it later, it’s not going to happen. Like, people have jobs to do, they will move on. So it has been one of the hardest things to enforce in the company, to work handbook first, but it prevents what happens at 99 percent of the companies where the knowledge base is very big but most of it, a lot of it, is out of date.

MATT:  What is maybe underappreciated about this approach as well is that due to the fact that everything is in version control you have essentially an organizational block chain of every way the company has run and every change and who made that change and when it happened going back to when the handbook started, which.. was it at the very beginning of GitLab or a little later in its life?

SID:  Yeah, no from 2015, so from when we were ten people. So I think someday hopefully if we continue growing, some organizational research is going to have a field day. Because I think we are the best documented instance of a really steep growth trajectory for a startup and how your processes changed and what’s important. And it’s all kind of.. it’s to the letter dated and everything else. You could see all the comments.  I think that’s gonna be an amazing research if you’re into organizational research.

MATT:  It is the code that runs the organization, which I think, like you said, super fascinating, I hope it gets studied. Is – 

SID:  Yes, we both have a software engineering background and I think we just moved onto a higher level language, namely English. 

MATT:  [laughs] It’s less deterministic for sure, I don’t know.

SID:  Yes and it’s hard to trouble shoot and there’s no tests for it and there’s no indentations.. Well, the indentation standards are pretty okay but it’s much  harder but it’s much more powerful.

MATT:  To give a sense for the listeners who might not be familiar with GitLab, you mentioned ten people in 2015. What are some of the growth milestones since then, in terms of people?  And I think some valuation has even been public in the press. 

SID:  Yes. So I think our craziest year was 2019 where we tripled from 800 to 1000, or something. We are now 1300 people. And the last  public metric we share was a valuation of $6 billion. 

MATT:  That is pretty incredible because I think that.. You know, one of the criticisms, I don’t know if you heard this much in the early days of GitLab, but that distributed or remote companies or open source companies can be nice lifestyle businesses or some of these approaches work if you’re like base camp and only 50 or 60 people but it doesn’t turn into hyper scale or blitz scaling, as Reid Hoffman might say. But you did that. You went from 300 to 900 or 1000 in a 12-month-ish period. What broke that year? 

SID:  Actually not a lot. It was kind of hard to do recruiting at such a scale. I think we relied a lot on in-bound. So we got 15,000 applications every month and I think now that we grow a bit less fast we are better able to reach out to people who will add diversity to the company. And any time you grow faster, that’s tougher. 

I think I have to thank you because WordPress was the number one example to convince investors that we’d be able to scale fast a distributed company, an all-remote company. So thank you for giving that example. I don’t think we could have convinced them otherwise. 

MATT:  I appreciate it.

SID:  And now looking back on it I’m like how can you scale when you don’t’ have a handbook, when you have not documented things? Like, that is ridiculous. If two-thirds of the people at the end of the year are new, how do you do that? So I think having all these practices has enabled us to scale. And I think in general, all remote, you don’t have to do special things for it, you just have to do things that would be good for any company and you are forced to do them sooner.

MATT:  There are stories I hear from friends that have hyper scaled around like they can’t find enough desks in the office and so they’re squeezing people into the same desk and things, which is such a quaint concept if everyone has their own office because they work wherever they’re coming from. So I wonder what might be a.. 

I  have heard kids now don’t know what the disk icon, it represents a floppy disk so when they see a floppy disk they’re like oh, cool, you 3D printed a save icon. It’s totally lost the original metaphor. So I wonder if there’s other metaphors around work that have completely changed maybe permanently even now with the pandemic.

SID:  Yes, it seems that most companies are going back to the office but I think.. I don’t know, I look back on cubicles as super outdated and I think one day we’ll look back on the open plan offices as something super outdated. Like, how could you be productive there?

MATT:  How does your values impact your meetings?

SID:  Transparency impacted that most meetings.. Like, my calendar.. Most meetings are shared with the rest of the company. In advance you, because of efficiency, you link a Google doc with the agenda and then the notes are taken in line and most documents are open to the entire company. [crosstalk] [00:26:33.16]

MATT:  So while we’re meeting someone will be taking notes on the shared Google doc so people will have both up on the screen?

SID:  Yes, multiple people will be taking notes. And if you ask questions you also commonly put them in written before and then you get to verbalize them.

MATT:  Are there any external meetings? Like, let’s say the board that you also run in a similar manner?

SID:  Yes. We are blessed with board members who have an open mind and I’m learning a lot about how to run better board meetings with their feedback. What they have embraced is running it from a document and that’s been super successful. They actually start putting in questions like days before and we already start answering them. So when the board meeting actually comes around a lot of things are like well that’s already answers, we can skip that. And like any board meeting, we can fill the time but it’s just they have much more opportunity to get their questions answered.

MATT:  It also requires a lot of pre-work. Do you want to talk about what you expect people to do before a meeting and for board meetings and I imagine internal meetings as well?

SID:  Yes. Board meetings are quite special. They require more work than any other meeting. Of course you can Google GitLab board meetings but I’ll do some of the highlights. I think one thing that we do throughout all meetings is no presentations in the meeting. It has been one of the toughest things to enforce. People really like a captive audience. 

So before the board meeting I will send out a video with my overview, our go to market leaders from Sales and Marketing will send out a video where they review that. My notes kind of sound like an earnings call because we kind of.. we aspire one day to be a public company. So those videos are sent up front plus a deck  plus a doc for them to ask their questions.

MATT:  Do you have a sense for the scale for like how many slides, how long the documents, etcetera?

SID:  I think our worst has been 140 slides, which is not good, so I think now we’re back to like 60 slides or something like that. And I think what is essential is like how do you allocate the time in the  meeting. So we have three key questions or key discussion points that we state up front, this is what we like to talk about as a company. 

So as a company we are going, we are thinking about this new product offering, give us feedback about the pricing, about the implementation, about the roll out, what do you foresee. As a company we are struggling with X, Y, Z, do you know people who  might be able to help, what do you think about our current approach. I think board members should want to help, they give you advice, if you don’t indicate what you need help on, they will start helping you on stuff you don’t need help with, which can be a big distraction so channel all that energy into something that they can help with because they will do a great job.

And we spend most of the time on that. And then there is  Q&A, in which they can ask about anything. But that has been a really big improvement. And I think that should be true for every meeting in general. In our internal meetings my policy is I want to discuss a proposal, I do not want to do brainstorming or something like that. Have a proposal and we can review it, that is a much more better spend of all of our time.

MATT:  So if everyone asks the questions before and reads everything and watching everything before and you answer them before, you don’t run out of stuff to do in the meeting?

SID:  No, you don’t because people build on each other. And even if you might’ve like tried to answer the question many times you still verbalize the question. So I mentioned an example of something that.. where people would say oh its already answered, we can skip it. That tends to be about trivial stuff. It’s important that we don’t skip, like, hey you asked this question and even though it’s already answered – 

MATT:  So they present the question?

SID:  Yes, they present the question. And frequently you learn more. They will say it in a certain way, they will have more intonation, they will have enthusiasm or worry or be pensive or other things and they’ll tend to say more, like it’s easier speaking than writing so they tend to elaborate it a bit more. And then we call it reenactment. We reenact the question and answer so that the answer.. they answer people too, they reenact their answer. And then hearing all of that in the rest of the room, now suddenly, now that they have heard that, they have something to add as well. So no, we don’t run out of stuff. 

MATT:  It makes sense for why the sort of reenactment of the question and answer might give additional information that is not on the page. But couldn’t you make that same argument for the entire presentation?

SID:  Yes. And so I think it is really good to, if you want to present, to do that. Just record it and send it to everyone upfront asynchronous and don’t want for the super expensive, synchronous time to do it. 

MATT: So it’s maybe about the amount of time?

SID:  I think meetings are for back and forth.

MATT:  Because interrupting a presentation could be good, right? Like we are having a real time conversation so we can jump in, like I just did?

SID:  Yes. I think that’s the benefit of this, right? We can go back and forth. I think interruptions are great because if I say too much or too little it’s easy to give me feedback in the moment. I think most presentations, especially remote, there’s not enough interruptions, interruptions are awkward. We just (did delay?) because it’s kind of hard to hear someone breathing in to ask a question. Maybe you can look at who is un-muting their mic but it’s much harder. So we find that in general there’s not a lot of interruptions so  you might as well just do your presentation and then have people ask questions during the meeting. 

MATT:  A hybrid meeting makes that especially hard. I remember when I first joined I was.. I thought everyone was going to be remote. Everyone else was in the room. I think I was the only one remote and it was very, very difficult to both hear and jump in.

SID: Yes, hybrid is horrible and I’m very glad that our board meetings are now all remote.

MATT:  I remember we also talked about sending people some microphones and some other things because there was some varying audio quality.

SID:  Yes, we did that. Thanks for the suggestion. A lot of board members received that Sennheiser microphone you suggested.

MATT:  It’s like the cheapest way to make a meeting better, if you’re going to have a couple hours together. The collective value at that time is huge, particularly because you have so much of the team there, like, might as well spend a couple hundred bucks to make it sound better. 

SID:  Yeah it’s a $100,000 meeting, you better make the most of it. I send a lot of people I meet with, I send them cameras and microphones kind of as a thank you for meeting or just to help them out. 

MATT:  To go back to transparency as a value, like, you have started broadcasting many meetings, not the board meeting but lots of others?

SID:  Yes. So by default we put our meetings on GitLab unfiltered on YouTube. So  most meetings can probably be public and we just live stream them from Zoom to YouTube.

MATT:  The only other organization (that has a way of?) doing this is probably Mathematica, the Wolfram [00:34:40.16] stuff, (Steven?) Wolfram. But what is that like? I have watched some of these or I have tuned in to some that are happening live because YouTube will ping me. 

SID:  Well you have trouble sleeping because most of these meetings are very boring so I assume you watched them because you had trouble falling asleep.

MATT:  Yeah ya know, I find it kind of fascinating because I’m an organizational voyeur. I am very fascinated on how different companies work and how they solve  problems. And also I feel like as a duty, as someone trying to contribute to GitLab, to get to know the organization as well as possible. But also,  YouTube pings me about it because you’re one of the only channels I follow that does live broadcasts basically all the time.  Who watches these besides GitLab employees and has anything interesting ever come out of that?

SID:  I think it has been great in finding and convincing potential team members. So I think like what you always want to know is like what is that company like on the inside. You go talk to people, you go have lunch with someone who works there and they say stuff but there is nothing like being in the meeting, that boring meeting that no one cares about on Thursday at 3PM about some boring subject where everyone is kind of bored. 

Like, that’s what a company is really like. So I think it’s amazing for potential team members. People watch that and like, okay, this is a boring meeting but it’s a better boring meeting than at my old company because like they’re efficient about stuff, they are transparent with each other, they are really goal oriented. They try to make.. try to come to actions and to agreements, it’s well documented, people screen share, people try to contribute, people are positive, people assume good intent.. this is better boring than the company I’m at now. And then they apply for a job. 

MATT:  So all of your culture around meetings doesn’t make them more exciting?

SID:  No.  No. I don’t think they get more exciting, I think they get more effective. 

MATT:  This approach to meeting culture sounds very efficient. But how do people get to know each other better?

SID:  Yes, you have to organize that too. So I think one of our biggest lessons is to be intentional around informal communication. There’s a web page we have with 20 ways to kind of stimulate informal communication. And most of it is like have a meeting but have it explicitly not be about work. And that is tough and the concept doesn’t always translate well. 

I just had a meeting with a country manager of ours, an international country manager, and like we tried to signal to him hey, this is going to be a coffee chat, it’s going to be a social call, this is.. here’s how coffee chats work. And still like, I can’t imagine out of the blue you’re going to talk with the CEO, you have some backup slides about the business. And he did that, he had the slides ready but he was like, oh, this is a different meeting than I expected. 

It’s a coffee chat, so it’s informal and can be a bit about work or a bit about our private life. I wanted to kind of set the tone, this was just getting to know each other better and get a feel for how he was experiencing his work and our support for what he was doing. And that’s one example, we’ve got a ton. 

But I think what is most important is that you make it okay to do that because it feels really weird, it feels like somehow when you’re on Zoom it feels like you should be working and then people are not always working but they’re always not working when they are not on Zoom. And you have to make it okay, like, hey, two of us are in a call and we are not working and that is okay and we can just hang out together. 

So that water cooler chat, organizing that, that has been hard. I think we’re the most effective at it, that doesn’t mean it’s perfect and we do try to augment it with in-person meetings where that’s a lot easier to do.

MATT:  Yes. So if I were to try to be more social in a more goal driven meeting would that get shut down or do you have some space for people to goof off a little?

SID:  Yes, I think it’s appreciated when the meeting hasn’t started yet. So people at GitLab tend to come early to meetings. So in the first few minutes you joke around a bit. I had an interaction like that today in a meeting where I joined a few minutes early and we had some banter but then we tend to start on the dot, so on the top or the bottom of the hour.

MATT:  Literally on the dot almost to the second, correct?

SID:  Yes.

MATT: Tell me about your personal thoughts on timeliness. Does this translate into your personal life as well as professional and how have you gotten the whole culture – because you have people from dozens of countries – to make this important?

SID:  Yes, I think we set the standard, like, hey you start on time, you don’t wait for people to arrive. So if you say in a meeting we have quorum or everyone is here and so we start, I will remind you, no, we’re starting because it’s time. And everyone is here because we start on time and we don’t wait for them. And then also very important, you end on time. 

And we do speeding meetings at GitLab, which is a settings in Google Calendar that means 25 or 50  minutes, not 30 or 60. So you have some time in between the meetings to do whatever you want to do.

MATT: And for you, how important are meetings to how you do work? Like,  how much of your week is meetings?

SID:  Most of my week is meetings. I think if you radiate a lot of information it’s a very efficient way to work. For me also, it’s.. because its interactive, it’s easy to ask for a little more or a little less information and to speed things up. So I think there’s a bit of a burden on the other side but I’m.. because I tend to be on the busy side I optimize for my own time. And I think also as the company progressed, I get more and more interrupt driven where I just have to respond to things so I set up the mechanisms that force me to.. that send out pings where I just have to respond to it.

MATT: In terms of other unusual things, that probably hits transparency as well. You have a shadow program. Could you talk a little bit about that? And is it just for you or is it also other roles in the company?

SID:  Yes, it’s called a CEO Shadow Program and it’s two people who go to most of my  meetings. And the idea is we are a functional organization, as a CEO I’m the level at which all those parts come together. So it is an opportunity for them to look across, see more than just their own function and see all those other functions. 

So its two weeks, it’s an opportunity to learn and get a broad perspective. They also have to work. They take a lot of notes during meetings and they sometimes get assigned small changes to the handbook that come up during the meeting. I think it’s a great opportunity. Look at the bottom of the CEO Shadow page, you’ll find videos from alumni and how they experienced the program. And hopefully it is a way to create that next level of leadership at GitLab.

MATT:  How has it evolved over time? It used to be one person, now it’s two?

SID:  It used to be three weeks. So I was inspired.. First of all, it was trigged by when I was recruiting for a chief of staff and they said well it’s great because for the chief of staff you have one person a year that kind of.. you graduate one person a year that knows the entire organization. And I was like, wow, that’s not fast enough. [laughter]  

So I’m like how about three weeks? See one, do one, teach one, which is kind of a medical thing. And then they were, well, the see one made a ton of sense, to learn from the old person, the teach one makes a ton of sense but to do one is kid of.. well, when you see one, you can do one. So we cut out the middle week also to make it more approachable for people who couldn’t be away from their family when it was still in person. 

Now luckily [00:43:44.13] like I have a lot of external meetings and those used to be in-person but I think that even after the pandemic a lot of those can keep happening online so we might keep the program remote to keep it more accessible from other places. 

MATT:  Yes, I recall when I was a board member you even were like hey can this shadow join this meeting. And for some of them it made sense and for some I think we were going to discuss something private and so I was like well maybe not this one. 

SID:  Yes, so they attend board meetings and things like that.

MATT:  How do people respond to it?

SID:   Well people never tell you the negative stuff so maybe some people are weirded out. But in general it gets a really positive reception and I think it drives home that we are a really transparent company.  You have to be pretty transparent and have a high bar for sharing.. or not a high bar but be comfortable with sharing things to even have such a program. So I think in the meeting with external parties they exemplify our values. 

MATT:  I think a common question people would have – oh well we could do that but what if something private comes up? So what do you do both for the shadows if something private comes up, or sensitive, and for these broadcast things?

SID:  You say bye shadows. And I say it a lot. I think I said it three times yesterday. But we tend to.. It happens mostly during one-on-ones where we have to discuss performance of one of the reports of the.. my reports. 

MATT: So your one-on-ones are really three-on-ones. 

SID:  Yeah, they’re one-on-ones but with two shadows in the room. But what we tend to do is we put it on the agenda, so there’s confidential subject, and then at the end we, depending on how many there are, we take five or ten minutes without the shadows.

MATT:  How about for any of these live broadcast meetings? Does ever anything come up that you need to take down later or you turn off the broadcast, maybe dealing with a specific customer issue or things you want to keep confidential?

SID:  Yes, t