Stanford Seminar - Making Teamwork an Objective Discipline - Sid Sijbrandij CEO & Chairman of GitLab

Key Takeaways

first time I was at the Stanford campus I was slightly angry that nobody told me that this place existed so it's cool to have to have some business here I'm uh I would have loved to be a student here but I'm glad to be able to give this lecture um we uh getlab's mission is to make it so that everyone can contribute and what we what we make is a devops platform a single application that allows you to do everything from planning what you want to build create it package that up secure it deploy that and monitor what you've built and there's a couple of things driving devops going from multiple tools to a single application there's more and more software there's more and more applications there's more and more tools to help you in the devops process and there's more more a need to quickly onboard people and make developers happy if you look at the number of tools in the beginning devops you could do it with some git some Version Control some CI today is 10 plus applications if you look at all the applications there were a few big projects that a company had nowadays you have microservices you have hundreds of different applications and together that's that's causing an exponential growth in the number of Integrations the beginning companies said hey any team can bring their own tools can use their own tools because when devops was New it is very important to shift to newer more modern tools really quickly but it kind of caused the mess because people teams couldn't communicate across because they were on their different tool Stacks so a company said we're going to standardize on Best in Class as a company we're going to pick the 10 tools we're going to use we're going to use jira for planning GitHub for Version Control Jenkins 4ci J frog artifactory for packaging Etc that really helped everyone was on the same tool set but what didn't go very fast is the cycle time the cycle time is the time between deciding to do something and getting it out there and that didn't go very fast because you because you had to hop between these different tools so the company said you know what we're going to make these Integrations better so that you lose less context in between these hops and then that's the era of DIY devops this is where 80 of all companies are now if you're going to work at a company they say we have Best in Class tools and you know what we spent the last five years integrating them better we have our own kind of they typically have a really uh fancy name for it and also typically it's a worse experience than you'd have otherwise because it really allows them to constrain things but it it is a really big effort to make something like this and every company is kind of making it themselves doing the Integrations themselves you never kind of get the tools quite right all the tools have different concepts different models they don't quite fit so you try to kind of duct tape something together but it the end result looks pretty messy GitHub is the next phase it's a devops platform a single application where the same concepts are used throughout the application where you don't have to switch from one interface to another interface we don't have it that your colleague doesn't have access to the same tool or the same credentials and it allows you to go 10 times faster we typically see that the cycle time is reduced at T-Mobile they were able to deploy 10 times as frequently with gitlab a Goldman Sachs they went from two weeks to two hours to make an improvement in their most important application apart from making a devops platform also known as the largest remote company before the pandemic I think now that after the pandemic it's it feels very natural that you can work remote it used to be very controversial um and for us we're one of the first companies that didn't had a headquarter our headquarters was in a mailbox somewhere in a UPS Store I think um sometimes people refer to us as a virtual company and I always find that pretty funny I find it funny because a company inherently is an abstract concept right your company doesn't doesn't consist of your furniture or your your building if anything it may be consist of your people uh but probably also of your processes and your systems and the data and the relationships you have but but certainly the headquarters of anything would matter the least not not the most I think because there was a lot of skepticism about being an old remote company we paid extra attention to defining our culture because all the people said like how how if you're all remote can you create culture how can you create camaraderie um culture I think but I'd love to know if I'm missing one of these so please add but I think it consists of three things what are your what are your values what is your camaraderie and I think a big part of that is is trust and friendship within the within the people at the company and how do you work and we've been very intentional about all three we have 22 ways in which we reinforce our values we explicitly have programs to promote um kind of meeting each other I'd like to say we formalize informal communication if you have a company that's co-located the informal communication happens at the water cooler or here at the campus if you are remote it needs to happen in some other way and we have a bit more intention around that um we've shared over 15 ways in which we you can help that informal communication and then a company a part of culture is how you work what you do and we've been trying to get really uh maybe a thoughtful maybe prescriptive almost about that we think there's there's better ways to work so that you spend less time on communication on average we all like to do a great job at work and all like to have a little bit time left and the only way to get there is to be more efficient and I don't think um that Intuition or what people naturally do is necessarily always optimal I think there's ways to further improve it and I think companies can be more opinionated on how you communicate an example would be at gitlab we don't present in meetings we think that can happen async if you want to present great sent the slide deck up front if you want to verbalize it great send a video up front but give people the opportunity to watch it at a time of their choosing maybe a twice speed instead of doing this right we made you show up and and then present but I think they had a being here synchronous should be for Q a so it was great to see that there's a lot of time for that today we have um six values of which the most important ones are results transparency and iteration and I'll I'll go um through them later on we we also have made something called t-mops it's a couple of months olds right now and it's because a lot of things we thought were very logical doing when you were remote uh didn't turn out to be very much connected to being remote it's more connect connected to like making the fish decisions and we think are more efficient and inclusive way so we we thought of four principles for team-ups the first one is a shared reality making sure everyone is on the same page and we do that in a couple of ways a gitlab things are public by default for example if you uh type in gitlab unfiltered you'll find a YouTube channel with a ton of boring meetings so you have trouble falling asleep tonight you can go to a wide selection of meetings but it just it does reach more people like if you miss the meeting it's very easy to see it um it's on YouTube so you can watch it on any device and if you plan on interviewing at gitlab you wonder what reality is like that is a really great way to see it we try to have a single source of truth I think in a lot of organizations information is duplicated and if you duplicate it it's really hard to update it later you tend to update only one part and it gets out of sync so if you look at for example at our Handbook of over 2000 Pages you'll find a lot of times things are links that could also be have been there but we intentionally link so we don't duplicate the information we try to practice low context communication if we are synchronous you can be very fast like I do a ton of meetings and they're efficient for me because I can say the minimum and if people are like this I can elaborate a little bit more um if we communicate for example to the entire company we try to give contacts on what is going on and provide like backup materials whenever possible we pay a lot of attention to situational leadership um I think I have a blog post out there with over 13 factors that might factor in of whether you delegate something or not I think if you become a leader of any any sort from manager manager up it's really important that you adjust your communication to your audience and it's going to be different for different people at different times depending on the situation where we're an inclusive company we try to make sure that people can contribute and maybe one one called a trivial but as a simple way in which we do it is that in meetings we write down if you want to ask the next question so there's a Google doc it's real time the agenda kind of becomes the notes during the meeting and you can write down your name and your question because if people talk sometimes some people find it hard to kind of interrupt or or kind of quickly raise their voice and this this allows us to kind of be more on an equal playing field between the different personality types we found and having shared values and reinforcing that in 20 different ways the second thing apart from a shared reality is making sure that everyone can contribute it's it's our mission um and there's lots of ways in which we try to do that one way is iteration so we try to make work as small as possible and then get it out as quickly as possible so reducing scope to get it out quicker that sounds maybe easy it's it's by far the hardest thing we do and it's the only value where I regularly hold office hours because lots of times the way to do that is not intuitive to to people and frankly to ourselves like I I frequently get my case it this this can probably be smaller and if you make something smaller and get it out quickly it allows people to respond to that the longer the bigger a chunk of work you're going to ship the longer it takes before you can incorporate people their feedback another operating principle we have is short toes [Music] and that means that anyone in the company can give you a suggestion about what to do and not all of them are going to be great suggestions but they're always welcome you don't have to listen to them you don't even have to acknowledge them we do we do think you should read them so read them but you don't have to defend yourself I think if you if you start requiring that like where people acknowledge their contributions that's a lot of work and then people will make sure that their projects stay under the radar so that they don't get as much feedback um a few other things are the dris making sure that there's for every project there's one accountable person informal communication for example this quarter we had visiting grants where people got 500 to a thousand dollars to meet up together um and we always try to distinguish one-way door and two-way door decisions um a one-way door decision is something that's very hard to reverse a typical example of that is a a rename or a pricing decision most decisions in companies are two-way doors like if if it's really a bad idea you can reverse course and it it doesn't it doesn't impact too much and if you realize that it's easier to try something out that people suggest the third team Ops principle is decision velocity I think a company the speed of progress in a company is very much correlated to the speed of making decisions um we try to combine the best of a hierarchical and a consensus organization I think typically people thought you had to choose either you are hierarchical top down very fast at making decisions but not always very informed consensus is the opposite everyone participates in the decision making process they're going to be very informed decisions but it tends to slow things down if you Institute a consensus making out decision process you have two things happening fewer decisions happening and people trying to stay under the radar so that other people can start chiming in slowing down their work I get live we say look the the kind of the the part of the decision where we get opinions and get data everyone can participate but the person who does the work or maybe their manager they make the decision and all these people who chimed in they shouldn't have they shouldn't be upset if they didn't even get acknowledged for their contribution it is the flip side of being able to voice your opinion that it won't always be acknowledged because if we require people to acknowledge it and defend it and everything else we're going to see fewer decisions and we're going to see things flying under the radar and I think it's it's very much misunderstood as a trade-off I think you can have the best of both worlds decisions should be taken at the lowest possible level no I'm involved with decisions every day so apparently we're not always able to do that but we try to try to do that as much as we can we try to reduce politics in a couple of ways we try to see why especially in our handbook when we encode the decision like this is how we operate it's important that you have the Y there because the it might times might change and if you don't know the Y you never know when to change the underlying thing we try to work asynchronous as much as possible we try to embrace boring Solutions um there's a lot of I think computer science people here they like new technologies and that's great and we encourage people using them we don't encourage people bringing their Hobbies into our product because our mission is everyone can contribute and that's only possible if everyone understands what they're building upon so if you make a layer in the product that is very novel and very interesting it's going to be hard for other people to build on top of that so we try to avoid that whenever possible and we try to reduce constraints the more constraints you have the more gates the slower things are going to go and the last part of Team Ops is is Clarity of of measurement and and of execution we don't have a matrix organization a matrix organization is where you report to a functional boss and kind of a project type of manager if you have two managers it's going to be really really hard to make get decisions done and have clear sense of career progress and things tend to get political we measure results and not hours I think there's still a lot of um presenteeism I'm actually I'm pronouncing this right but companies focusing on people showing up like if you are very visible if you come in early and you leave late they assume you do good work if you measure those things you're definitely going to see people doing that except it's not the goal of the company to do that so for example gitlab as a manager you're not allowed to talk with one of your reports about how many hours they worked unless you suspect they were too many hours we always want to make sure the focus is on the result and we discourage managers for sometimes praising an effort um because if if we start celebrating kind of people spending a ton of time on something you're gonna you're gonna get that and we do we want to spend a minimal amount of time getting the maximum result I think transparent measurements is also very important for everyone to know kind of what page they're on in engineering we for example measure merge request rate how many pieces of code did you get into production considering the size of your team you've measure that at the team level to encourage collaboration and we don't really we don't just on a kind of an engineering level we don't just measure what our Engineering Group shipped us all but we include outside contributions hundreds of improvements in gitlab every quarter are made by users and customers they help us improve the product and they they work on the same level as us so we don't just share our roadmap publicly even our work in progress we had an engineer start at gitlab and say who's who's this kind of product manager telling me what to do and it wasn't a product manager it was a customer who really cared about the feature they were writing and were following that in real time as they were making commits it was funny when we started measuring Mr rate our engineer set like hey it's going to be really simple I can just make smaller changes and I'll get a higher rate and we're like yes exactly what you should do because we know the smaller you make it the easier it is to review the lower the odds it will blow up production the easier it is to make fixes and and change things every every change should add some value for the end user to add some functionality or something else but please make it as small as you can because overall we're going to be more productive as an organization we prioritize due dates over scope for example new version of self-managed gitlab ships every month on the 22nd and we've hit that for as long as we existed ever since the first release that's now 130 releases in a row because that train just goes and it really because that is the case people know that it brings predictability I think people know when something ships but also helps people reduce scope because they know that train is going to go so they reduce scope in order to make the train we have a value that's disagree commit and disagree we love disagreements because otherwise there's too many people in the meeting then at some point the dri is going to make a decision and we expect everyone to execute on that and implement it but that doesn't mean that from then on you cannot disagree further the execution should happen but you can keep arguing for a different decision the best decision they made in gitlab history was a case of disagree commit and disagree there was an engineer called Camille and he said we should combine our Version Control and our CI our verify functionality into a single application and uh Dimitri my co-founder said obviously not [Music] um that is technically complex and and no other tool does it that way and I said obviously not our customers do not want data in a single tool they want composability they want unit experience suppose compose different tools so we disagree and Camille commit it and he added value to the product but he kept coming back and at some point we relented um and it was the best decision in in our history we started it set us on a path of making a devops platform and it was so not intuitive that our competitors took years to to catch up to the same thing and we are now ahead we have the most comprehensive devops platform all because Camille kept disagreeing with us last thing we do is a key review meetings normally you have a report communicating up to a manager about your work and what you did I am the only one that's working very cross-functionally like of course people in the company work with other functions but my reports are have had all the different represent all the different functions in gitlab and instead of presenting to me they present to a group of people and it's called the key review meeting they say hey here's the three things top of mind for me things I'd like to I think we should discuss here's how we're doing according to our okrs our goals for the quarter and here's how we're doing Accord to our kpis the metrics that are always important and we do that as a group and it brings a lot of accountability but also a lot of transparency of what is going on and it helps the the whole kind of e-group and other people um be on the same page and then we repeat that presentation we we give those materials and that agenda we give them to the entire company and we have a group conversation where anyone in the company can join gitlab is now 1700 ish people about 80 people join and their their questions are less sharp than the ones in the key meeting and that's not their manager their peers but it is a lot of questions for clarification people who want to understand and that's it really helps to keep the whole company kind of informed of everything going on allowing them to make better decisions in their departments if you're interested in team Ops we we do a certification it's free it takes about an hour um and I I encourage you to do so I think um what's happening in our industry right now according to Gardner the adoption of devops platforms is now less than 20 but they see it tripling in the next three years so we're looking forward to kind of the industry switching from multiple tools to an integrator tool what we also see is devops model Ops and data Ops converging every significant application of the future will have machine learning it will have code that emits data you train models on it and it informs how the code executes right now those are completely different Pipelines different ways of working different tools stack just like devops brought development security and operations together I think there's a there's a role for having an integrated platform for that significant application where those things work together instead of separate and we're adding ml Ops and data Ops functionality to get live I read a lot of great questions so I hope we have ample time for that thank you [Applause] any questions good question I'm kind of curious whether you can comment on um and I know this isn't exactly the same as my kid lab does but um whether there is an intention to do something similar uh and what I mean by that is what's going on right now with GitHub and their development of co-pilot and their use of basically you know taking all the code that's on their platform and utilizing it for an external service that they're selling I wonder if you or I'm wondering if you had like an opinion as like how you feel about that in terms of what it spells for industry what it spells you know for you know software development in general and the legality of the whole situation as it pertains to git lab and again the industry at home thanks uh yeah questions of what I think of GitHub co-pilot I get a co-pilot is a coach suggestion tool it's trained on code that is some of it is open source licensed some of it might not be licensed in a way you'd intuitively you you can copy it but what co-pilot does is is not necessarily copying it it's using it to train and then based on training it does something and I think that's the debate is this copying or is this like teaching a student and then the student yes has ideas in the future and I think over the coming months and years where we're going to see people argue about that and and that's going to bring more clarity I think it's uh it's a it's a useful tool quote suggestions make a ton of a ton of sense and we're working on those um we think that there's lots of areas in which um a devops platform can benefit from Ai and ml and the feature we've released doesn't help an individual coder work faster but it helps with the overall speed the cycle time and that's it it helps you determine who should I assign this code review to because if you look at speeding up the time between making something and getting it out there most of the time isn't lost because people cannot type fast enough most of the time is lost because you assign it to the wrong person who doesn't have expertise on that part of the code base and then it's kind of stuck there for days so um we're focused on making it a lot better we'll have Coach suggestions too but um we'll also do other things to to make the app better apart from that we want to make sure that gitlab got gets better for ml Ops and we're starting day or two with small functionality what we just released is the ability to use ml flow to inform an experiment in gitlab link to two together so I love that you published the handbook and you also mentioned the public by default so I would like to hear more about the rationale behind making a lot of information probably yeah we make so much public it started because we started a for-profit company around an open source project and what typically happens is the amount of contributions goes down and I thought if we are very open about how what we do as a company but also how the company functions who are there who's responsible for what um we're gonna better be able to to have the wider Community kind of join in that journey and also call us out when something goes goes astray and that worked Maybe correlation is not causation but we have more contributions now than we had than when we started the company what we discovered over time is that it really became a way for us to attract Talent people I recently had an interviewer say look I looked at your handbook and I feel like corporate soul mates now might be stating it a a bit definitive but a lot of people say look I looked at your handbook and this is the I I can sympathize with that this is the way I want to work there's also probably some people who I never speak to or like look at our handbook and say I'm not a fit for this company and I think that's fine too I think it's always a bit curious when a company doesn't tell you their strategy but day one you show up they tell you the strategy and they expect you to be totally aligned with their strategy and way of working well you should have told me before I joined and I think it's it's a way to see whether whether you're a good fit and I think companies used to be constrained to a certain metro area so you kind of had to be appealing to everyone it's no longer the case we can hire we have people in 60 countries we just need a few people to be really excited about Gilma and I'm recently we've seen that it also now started to lead to customers being more interested in us and people say like hey yeah I compared you to what we our DIY devops and one reason to switch was your transparency thanks curious about your name about the company is it a tip of the hat to get it done yeah for sure the name um when a git was made by a line of strovals he also made Linux um and uh in English a git is an unpleasant person so he he joked he named both his projects after himself um get came with something that's called get wet it was a way it was written in C you could run it locally to have a web view of your repositories can do anything but you could kind of browse them GitHub came after that and gitlab came after that so we all Trace back to get I was wondering if you were talking about like your hardest job is reducing the size of work that gets to um yeah like can you talk more about like some Frameworks that you use that uh that have helped you with that things that like changes in how you do that uh over the years yeah the questions about the iteration value how do you do that um I think one thing to recognize is that it comes from a really good place to want to do something Broad in scope just like most of you um the people at gitlab are very ambitious like they want to achieve a lot and you start thinking about something impactful and meaningful to do and all the things they could do and they come up with a big plan to do something and then it's really hard to kind of Whittle this down to a thing that is so small and sculpt that you're almost ashamed to ship it and it's it's not intuitive it's not particularly Pleasant um and it sometimes takes almost an external view to do that so if you Google gitlab iteration office hours you'll you'll see a bunch of YouTube videos of us discussing these projects together and sometimes we're able to reduce the miscope and sometimes it's not possible it's different solutions and most of the time it's like okay can you drop that requirement without kind of while still having a positive impact foreign what's the senior Shadow food yeah thanks for asking the CEO Shadow program that you asked about is um people being in about 80 percent of my meetings it's two Shadows at a time graduate between 30 and 40 people and I had at a certain time the realization that I see a lot of the company in my meetings I see all the different functions and we're a functionally organized company so the hardest thing in the company if you're there is to look outside your function and I have this great perspective and we decided to open it up to people first we did three weeks I was inspired by medical tradition of c121 teached one but we it was the shorter the better because people are taken away from their day job it's a full-time program and we've made it smaller and if you Google gitlab CEO Shadows you'll find what people say about it but it tends to give them a lot of insight and how the company is operating how we work and they're able to bring that back to their job in a function and kind of be better at that I I secretly and not so secretly also hope that that's going to inspire some people to uh maybe start their own companies in the future also inspired inspired some people to definitely not start their own company in the future and I think both both are good good outcomes so related to that there's this notion of situation with leadership most of the time requires cross-functional View um can you talk a bit about that yeah next the question is a situational leadership and it's a it's a big subject that could be a lecture all right in and of itself um here are the a situation situational leadership is much broader than just delegation but as an example here are the 19 factors that I sometimes I don't do this every for every decision but I sometimes on delegating something I consider one of these things what is the experience level of the report what are the skills required what is my own school like how good am I at this how important is this how urgent is this an urgency and importance are different things how many opportunities will I have to provide feedback how many times can we can we make improvements and you can you can read the rest I think um if you're a good leader sometimes you are you are delegating and it's almost like you're not there and they're they're completely on their own sometimes you're delegate you're not delegating at all you're micromanaging you're on top of it and probably both styles are called for in different situations and everything in between it so it's a really big decision like okay how much follow-up do I require in what way etc for example frequently I'll give feedback and say hey this is good to go you can publish it please consider this additional thing that way that person is unblocked and no longer a gate and they can decide whether to take my advice or not if it's bad advice they can just ignore it um but that's it if you want to have an impact you gotta motivate people to to do things you got to make sure they deliver good work and if you want to micromanage everything you're not going to get anywhere but if you if you delegate everything to an extent that you don't have control or you have very little opportunity for feedback that's also not appropriate if it's a very important task so you go first how did you identify the need for be allowed to exist when you're creating a company and then how did you go about creating the first version [Music] start existing um my co-founder Dimitri was working and he needed a tool to collaborate he would like to have purchased GitHub at the time but there was no budget being a programmer he said okay well there's no money but how hard can it be I'll just build my own version of it and in the first year 300 people contributed to that effort I saw it Dan that was on Hacker News I thought this makes so much sense that something you collaborate with is something you can also contribute to and I did a show Hacker News of hey I'm gonna run this as a service you don't have to download it anymore you can just log in to gitlab.com a year later I had was not making any money with gitlab.com but I had all these Silicon Valley companies that reached out like we're running gitlab like can you help us improve functionality and fix things that are wrong and Dimitri tweeted to the whole world I want to work on gitlab full time so send them an email like hey I'm that person a year ago who told you hey I'm going to start gitlab.com without you hope you don't mind to which he replied great go for it it's open source that's the whole idea but I saw your Tweet maybe maybe you can partner up maybe I can make sure you uh you get a monthly income we agreed on a monthly income I went to the local Western Union money office in the Netherlands and they said money to the to Ukraine no do you know this person or is this someone you met over the Internet because they were very afraid I was being scammed but uh I was quite convinced he was the real deal and he was and a year later we incorporated a year later we participated in y culminated 2015 we were seven eight people at the time and uh yeah that we were three months in the home in the Mountain View 24 000 for three months I still remember thinking that was a lot of money and um yeah classic kind of laptops in the living room and uh we raised money and off to the Off to the Races so what was the first product that you were selling going from the open source yeah the first product we were selling I don't remember um but after a while we noticed a pattern we were looking for a pattern in like what functionality was open source and what was proprietary and we first thought maybe it's the size of the company that cares about it nah maybe it's the maturity of the company that cares about it yeah we tried a couple of things and then we found it it's not any of those it's who cares about it most is it an individual contributor is it the developer security or operations person or is it an executive at the company if it's an executive it's going to be paid if it's an individual or contributor it's going to be open source and we call that buyer-based open core and if you Google Firebase hope and core you'll you'll find a talk I did at a heavy bit that explains it a bit more in depth about like what your what like your poor it um or if and since it's an open source providing such a big company um if it's not IP if there's not anything like patent or anything like what what what is it what is our core IP it is the proprietary functionality of gitlab so gitlab is open core that means some of it has open source some of it is proprietary you got to get a subscription with gitlab to use it now one thing is very unlike proprietary software that you're used to even the proprietary code is out there you can download it you can legally modify it you can send us contributions just that in order to legally use it you need to get a license with us how do you get how do you get boys to adopt and internalize gitlabs culture yeah how do we get new employees on board with with all these things many different ways I just did a call today for new people who joined us in the recent weeks and and we talked that basically it's them asking me questions it's an Ama we also have a pretty extensive onboarding the Google gitlab onboarding you find a page and if you click through you'll find a template you'll find in that template is over 200 tasks that have to be performed and one thing I personally really like it's not just the task you have to perform but also the task your manager has to perform Finance people out Etc so if they're not doing their part of it you know it it's not something that surprises you six months down the road when you need access that to that one system um and there's a lot of reading and and taking tests in that there's also things like coffee chats where we require you to have coffee chats with five people where you have a zoom meeting of 25 minutes with someone you haven't talked to before No Agenda can talk about work or life outside of work but to make it normal to have kind of that water cooler talk in an online company so [Music] um I guess you put a lot of thoughts into building the culture of the world and I think after coffee we saw a spike Indianapolis they are trying to still sell 15 points under the future of wall so I was just wondering what do you see as the biggest pain point that you today would like to see like companies try to solve now the question is what pinpoints can be solved there's so many companies trying to contribute to making remote better first of all I'm very grateful for some of the tools we use besides gitlab Zoom slack that's that's really a game changer I think um the hardest thing is to work handbook first so we at a typical company if you look at their handbook it doesn't contain everything it contains lots of stuff that's out of date and there's lots of overlap and everything else and the way we prevent that is in gitlab if you want to communicate a change you have to change the handbook and say hey look this is how I change the handbook that is not intuitive people much rather send an email give a PowerPoint anything but actually changing the handbook but if you're able to kind of to have that happen people can be more assured that what's in the handbook is actually the single source of Truth and and consult it but that's that's been hard um I think it's also really important that when changing the handbook there's a difference between who makes the suggestion and who approves it if you make that the same which is typical and Wiki becomes really hard because the the people who approve it maybe don't have the time and the people who can make the change maybe are not are not sure it's the right change and they want someone to review it um emphasized uh to understanding the why why you have like a certain policy in the case that you need to change it so what's the why and also in what circumstances do you imagine so what's the why behind that rule or okay um so what's the why is it important to give the why so um we try to always have it obvious why something exists so that when something no longer serves its purpose it can be removed I think you'll find that companies that existed for a longer time have more rules and more things you need to comply with that can be maybe you live you learn I think now that on the him I have more rules for myself than I was 20 so kind of makes sense but also you tend to overdo it a bit and every time there's a problem kind of introduce a new rule so it's important to read those out and to allow people to challenge that um and I'm thinking of making it even kind of a job requirement and maybe kind of something that factors into promotions like how much how many rules you were able to clean up and were able to address in different ways or able to make a case that trying to prevent that mistake is worse from accepting that it sometimes will happen I know that you know my action is getting better in the last few years so how does this web create new features to compete against GitHub actions and all the GitHub equal systems how do we compete with GitHub so um what we see is the bar for us is not GitHub but it's the best in class competitor in every part of the space think of planning lots of companies still use jira for planning we're now more and more able to replace that I think our Version Control our CI is already really good but we also want to make sure our package management is great we're competing with jfog artifactory there our security we're not we're competing with companies like sneak and check marks varicode Etc so making sure that in every single part of that whole workflow that goes all the way to releasing monitoring governance and everything you become Best in Class over time because right now some of the parts of gitlab are not as good as the Best in Class things so you have to make a compromise now the compromise is probably gitlab right now if you move to gitlab you can consolidate spend you don't have all these people working on Integrations they can move on and do something useful people become more effective and you get to move faster on your biggest priorities but I love for it not to be a trade-off and get both Best in Class and a single application on the question uh we talked about the functional organization in the company and the situational leadership but within each function inductive Team Dynamics do you follow uh like this concept of teams like Amazon started with or where do you choose to decide that a team is too big or too small yeah when is the team too big we try to make sure that no manager has more than 10 reports so every quarter we discuss the managers that have more than 10 reports and what the plan of action is for that because if I think if typically 10 you don't have time to be a good Mentor to all of your reports and be be familiar with their work and everything else um I think that's that's one way to prevent it I do think that smaller sometimes beautiful and one thing we have is incubation engineering where we have what we call single engineer groups it's a single person who is responsible for planning something making something promoting that to the outside world and making that happen and I think there's a team of one person can sometimes do remarkable things because your team meetings are just in your head and we try to stimulate that and kind of having that Heritage of everyone can contribute and all these outside contributions allows that model to work much better than I think than is possible in other companies talk a bit about the IPO what were the threats at the time and looking back what were the learning to have yeah IPO learnings actually we published a blog post about a week ago well it was October 14th on the anniversary of the IPO and I think that contained a lot of the the lessons we had um I'm very grateful for kind of how well it went it was one of the most perfect things that we did in our our history and uh a big part of that is having an amazing DNA team DNA's Finance people and legal and those functions have to do a lot of the work for the IPL and having very experienced people there who've gone through IPOs before was it was a big part of the reason why it went so well and I recommend the blog post we we've written up like more than 20 Concepts that I didn't know about before we went into the process I really admire you know the move that you make like you know your philosophy or no offices uh people like remote first what are the learnings the things that you believe became harder because of the distance or the things that you haven't figured out how to do it but no yeah what became harder about being remote first I think it became easier over time and I think one thing is really interesting is that people kept asking how does this old remote culture or if you scale and my return to that is how does an in-person culture scale I get the benefit of being in one room totally get it but then you're no longer in one room you'll run floor and you're multiple floors first time I see you I've been here three months work on the 31st floor oh oh yeah cool from buildings different cities different metropolian areas like I can't drone on a wow how do you scale that like if the benefit is being in a room together how does that scale I don't understand it and I don't think it does I can tell you how written culture scales you'd write it down once people read it multiple times that's worked for civilization now the only thing I think is really important is that you reinforce certain things how we do a presentation that's much easier to communicate than what our values are that in-person values what happens to that they get diluted you hire more people you sometimes like hire so many people that most of the people in the company were there for a very short time we got 22 ways in which we reinforce our values I've not met a company that has written down more than three ways in which they reinforce it so I think obviously I've written reinforced culture skills much better than counting on people being in the same room because because that doesn't happen at scale so you have a very structured way right including I'm I'm impressed if I have to read that every single time so how do you prevent this report you know and I get like pizza join because they love the company Etc and you get the best from everywhere but how do you prevent that you're not getting into this circle type of person that you're missing out diversity in a way of thinking approaching things yeah how do we make sure we're a diverse company um especially when things are so structured maybe let's start with the first thing things are very structured I don't I hope it doesn't come at the expense of unstructured thinking today we decided with the direct group to next meeting invite my singing coach and we'll be doing tongue stretches and motorboats in the next meeting so I'm looking forward to that our chief legal officer is also the chair of our practical joke Committee of which I'm expecting bigger output but let's say besides that point like it it shouldn't come at the not robots the whole reason we have people is because all those written down rules are not enough and then how you create diversity well you instituted at every part of the company and there's a lot that goes into it one thing I thought was interesting is that if people apply to your company obviously you cannot discriminate but you can decide who you reach out to like for your Outback recruiting you can reach out to whoever you want and I think that's a big lever in increasing increasing the diversity of your team and I'm super happy where we are in where we've the progress we've made in gender diversity at the company and we still have our workout out for us and for example ethnicity diversity thank you thanks for the presentation and you were talking about how implicit communication happens when you're in a room and that you are formalizing that and what are can you elaborate a good morning yeah thanks thanks for that how do you formalize informal communication um let's see how look I looky I am with Googling for that uh yeah for sure um so so maybe the first question so how do you organize informal communication um this on the right hand side is just the uh it's not the Lexicon what is it the table of contents of this page so I think there's more than 15 ways in here that we sometimes practice to do that the second part of your question is how do you do that across time zones time zones are the bane of our existence like remote there's no distance anymore but time zones are extremely hard being a remote company is easy being a company across time zones is very very hard there's no ideal Solutions sometimes important meetings we do twice so that uh all our team members can attend but still if I talk to our team members in Asia Pacific they don't have as as much interaction as as good of an experience as the people in the US and Europe um so it's very hard to do correctly I don't have magical solutions to that I do think there's certain things you can do asynchronous a big fan of sending small gifts to people you can do that across time zones but you're more likely to find out what the fun gift is if you're in a meeting together and you spend a little time up front before the meeting starts talking so no big solutions for that it's hard but I think being intentional and allowing a gitlab there's an agenda before and people kind of evolve that agenda into notes and so people got the chance to ask questions in the meeting even if they will not be present themselves and then they converts the notes or the recording afterwards to see what the answer was the company in terms of employees time zone in terms of growth rate and so on yeah sorry for not doing that earlier the scale of the company it's about 1700 people of run rate of 400 million dollars uh people across 60 countries I don't know how many time zones but basically around the world we're growing last quarter we were growing 74 year over year in Revenue our non-gaap operating margin was 89 percent and the last time we detailed our net retention it was uh over 152 percent and that retention is a metric of how much do your existing customers spent with you the next year in dollar terms and it's a good indication if it's high especially it's above 130 people really like what the product does for them there's a question in the back the presentation fascinating the way that you've approached us from the management perspective I'm curious with all of this material that's over there can you give some insight on what the sort of viewership or readership of all of these sort of policies is the question is how many people read our handbook and our our materials um I don't have that from the from the top of my head I think there was a little bit about um so the previous before team Ops many many months ago we talked about remote now that was extremely relevant at the time because of the global pandemic but at that time over 15 000 people download downloaded our remote Playbook and I've heard that it got distributed in many companies uh 40 000 people engaged with our course on remote Team Management on Coursera Coursera so we've reached a lot of people then and uh we uh we try to reach a lot of people with team-ups today um although this will be 98 plus your view uh essentialized on a review on what sorry uh the decentralized autonomies oh Dallas so my view on doubt which is a type of crypto organization I think um I think they're very impractically organized I think even if you look at government you'll see that there's a voting power and there's kind of the government trying to do as best as they can uh while incor