 Hi, Mr. CIO. Thanks for your time and your attention. Glad to be here today. Appreciate it. I'm here to present our company GitLab and what we can do for you. Some background about GitLab. Currently, two thirds of the self-hosted market, mostly the larger organizations in the world, in total over 100,000 organizations, are running GitLab for their DevOps needs. We got an amazing number of organizations running it. And as a company, it started in 2011 with an open source project. But the company really started in 2015. At that point, we went to a program called Y Combinator. We were nine people at the time. Today, we're more than 270 people. And the interesting thing is that those people all live and work from 270 different locations. We're an old, remote company. We care a lot about our values. And what people see from the outside most is our transparency. We're a lot of things that GitLab are public, including our strategy, our feature proposals, our roadmap. And what we've found is that every company is becoming a software company. And the pace of business is accelerating. And every time you want to make a change, you're constrained by software. So if you can ship software faster, you can become a better business because you can get changes out faster. And although companies spend a lot of money on DevOps, they're not happy what the current results are. And we think we know why that is. We think today's tool chain is in a local optima. The tools themselves are good for what they do. But the problem is the integration between all the different tools. The problem is the handovers between all the different tools. If you have 10 different tools that you use throughout the lifecycle, you have 24 interfaces between those tools to make them work together. And even worse, different teams are using different tools. So you don't have 24 integrations. You've got hundreds of them. And you've got people not being on the same page. And as microservices become more popular, and with that multiple projects, you're spending more and more time setting up those tools and making everything work together. We think that is inefficient. So what we did is make something that allows you to unlock from that tool chain. We call it concurrent DevOps. It's opposite to what people are doing today, which is sequential DevOps. They hand it over between the different tools and between the different teams. Only one team can work at something at the same time. With concurrent DevOps, you can work in parallel. And you save a lot of time because you can do things at the same time. That's GitLab. GitLab is a single application for the whole DevOps lifecycle, all the way from managing and creating something to monitoring and securing it. It consists of these parts. And some of these parts are in a different color. This is the stuff that we're shipping this year. And as you can see, it has all the different parts. So it replaces 10 to 20 tools you'd otherwise have to integrate yourself. And that is a better experience because now suddenly you have a single conversation. You have a single data source, single permission model. Everyone is on the same page. Everyone can message each other. Everyone knows exactly what the status is. It's also great for governance and security. There's one concept of a user of what they can do and that's consistent. Now, no one adopts all of GitLab at one time. So it works great with the applications you already have and want to continue to use. If you adopt more of GitLab, you'll see that you'll have better visibility. You know what the status is. You know you can drill down until the lowest level, but you can also look at a business portfolio management level. It's more efficient. People don't have to wait. Your security people can start the work as soon as the code is pushed, not when it's handed over. And it's much better for governance. You have complete auditing of who did what at what time and what, what, who approved things that went out. Benefit to business is a much improved time to value. And also because you're quicker, any cancellation won't waste as much work. If you get things out faster, you can iterate. You iterate. You can listen to the feedback from the marketplace and base your improvements on that. There's also benefits to the IT organization. You don't need as many people to work on your tool chain. You can focus those people on improving your products instead. Now, very frequently when we give this presentation, people say how can you be best of read in 10 product categories? Because that is very hard. And the amazing thing is GitLab, for example, GitLab CI is better than anything out there, even from the pure play CI vendors. That's not because we have the best people working at GitLab, although they're very good. It's not because we get the most working at GitLab. It's because we co-create with our customers. The 100,000 organizations using GitLab, they help us to improve the product. Over 2,000 people contributed co-to GitLab. And every single month on the 22nd, there's a new version with great new features. The speed of innovation is much greater than it's ever been before. And that collaboration, that sharing of best practices across organizations, that's what generates a better product. Not only overall, but in every single product category. Now, there's multiple ways to get started. Sometimes people are already using GitLab for version control. Sometimes they're using it as for CI CD. Sometimes they're using it for security. We know that there's already a couple of service inside your organizations of people using it, and we'd love to talk to those people. Thanks for your attention. What do you think, Mr. CIO? I'm interested. I've got some questions. You mentioned a few different things about the DevOps lifecycle. And there's between 10 and 100 different integrations if I have lots of tools and lots of groups using different tools. When I decide to be a modern DevOps shop, and I've already committed using microservices, I've got a hybrid cloud environment, I believe that I can continue to achieve the same kind of dev cycle improvements with my tool chain because I do such a good job managing it. The way you describe it, it sounds like you believe that that's not possible with my 12 products in the tool chain. What are the real limitations that are absolute? I can keep trying to improve my integrations, keep improving using the best-of-breed products. Where does that break down? That makes a 5x improvement impossible with the single app. That's a great question. This is our secret. It's a secret not because we don't tell anyone, but it's a secret because it's hard to believe. We find it hard to believe. Why is a single application better than two products that work really well together? We only got convinced ourselves after we tried it. We had GitLab, the version control, and GitLab CI. At some point, someone contributed a better runner for CI. A runner is the agent that runs the jobs. We switched to that and we offered the guy a job. His name is Camille and he lives in Poland. After working at our company for a couple of months, he said, I think we should integrate GitLab CI into GitLab. He proposed that to our CTO, our co-founder, Dimitri, who originally offered GitLab. He said, obviously, you're wrong. We need many small tools that we compose together. We don't want this big thing that can do everything. That's not the way you work. GitLab and GitLab CI worked really well together because GitLab CI you could only use with GitLab. Perfect integration. We made GitLab. The APIs were all there. They were joined at the hip. At a certain point, Dimitri became convinced it was better. They went to me and proposed it. I said, obviously, you're wrong because we need many sharp tools that we compose together. After a few months, I became convinced and we did it. The benefits were so... There were so many and they were sometimes really small and it's kind of hard to articulate. You can imagine that normally you have a CI job and you want to push to a container registry. Now, you got to go to the container registry. You got to make sure you have a user account there. You got to make sure you create the project there. You got to make sure that you get a set of credentials and you paste those back in like your CI job or you paste them in the environmental variables that will then be added to the CI job. That's a whole lot of work. In GitLab, it's the same application. It's a single data store. It knows who you are. You're the same user. It knows what the project is doing. It knows on what CI runner it's running. It knows it can push. It knows the location of the container registry. It's a level of integration. You otherwise will never be able to achieve. We call those the emerging benefits of a single application. There's a few examples here. There's a lot of further examples. The best way to prove that it's better is to look at the difference between teams that use GitLab for their whole DevOps life cycle and that don't use it. When we look at that, we find that the teams that use GitLab have a 200% faster life cycle. That's the real proof. It comes from all these little things. That's our secret. So let me share a little secret about me. I love the concept of true concurrent DevOps. It sounds great to me. I love the idea of getting more efficient in my tool chain. The truth is I actually have no idea how to do it. So I'm kind of nervous about even taking action and trying to start down a path because I'm worried that's going to expose me and the fact that I don't know how to actually complete this transformation. So I'm hesitant to even get started. How hard is this to actually do and what's my likelihood of being successful given that I'm not already expert in this? You don't have to make the decision to get started because the people at your company have already made that decision. They got started. There are multiple GitLab servers right now today in your company. We don't know exactly who are running them but I'm sure together we can find out. And I propose we go to those people and we look at the data. We look at whether how much they use of GitLab influences whether they're faster. And then if that's the case and we look at the data and we conclude together that that's the case, we can have those teams present to the rest of the company how they're using GitLab and what it's doing for them. Now apart from that, we also got a great professional services department with all kinds of trainings and all the usual things you expect. But we really want not for you to take a leap of faith but to look at the data that's already out there in your own organization by your own people and have them convince the rest of the organization. You mentioned customers can see a 200% improvement in cycle time. Have you ever had customers that did a great job implementing did change their process but didn't see any improvement? And if so, why? And if not, why is it always a consistent improvement? So the amount of improvement depends on how much of GitLab you adopt and people adopt different ones. We never had someone that like it got worse or there were no benefits. At the same time, we're still early in measuring this. So I'm sure at some point we'll have someone where we'll learn. Got it. And then I guess, you know, thinking about my team, what do you see as the most obvious sort of organizational and or sort of skill changes I would want to make in my org to be successful. If I, you know, said, hey, map this out for me and say, well, you've got 14 tools you're managing today, a bunch of integrations. Here's how your head counts probably going to end up change a little bit in the responsibilities. Yeah, I think there's two important things. I think that the people should stop thinking of themselves as kind of almost product experts and start thinking of themselves as according to the stages of the life cycle. So they shouldn't define themselves as I'm a Jenkins expert. They should say, hey, I'm an expert in making sure that we have the appropriate tests being run in our application before it goes out. The other thing is that if you implement GitLab, you're going to save a lot of time and money by integrating all those different applications. What you do with all that time is up to you, but you can imagine that there's always going to be something that is the slowest. And GitLab has cycle analytics. And with it, you can see where in the DevOps life cycle you're slower than other companies in your industry. And there's always something to do. And we can give the hints for what to do, but most of the time it consists of both technical things to do, like, for example, with fixing flaky tests and training people, training people to improve the caching or something or to improve the automated testing or to take out a manual step or an approval process or to make sure that you can link your requirements better with the code that got shipped. So there's always something to do. So our recommendation would be to use those people to further keep speeding up the process. Got it. So I'm sitting next to Mike. I'm actually an investor. I'm with Fidelity, and I know you guys were thinking about going out in 2020. How big do you see this market and really how addressable is it? Obviously, lots of companies don't have developers now, but how many of them is this really actually an effective solution for them and cost effective given what it costs to really take advantage of the futures? Yeah. So there's about 10 million enterprise developers right now. So our market is our highest plan is $99 per year. Maybe after discounting, let's say $1,000 per user. So we think this is a $10 billion market. The market is global. Almost every Fortune 500 company or Global 2000 company has good lab instances in it. So it's just a question of making sure that it's not only bottoms up, but also top down that the CIOs of this world are also behind it and they make the existing teams visible to the rest of the organization. And then we think this can be really big. And it's not just developers. It's also people in operations, people in product management, and it's not just a question of making sure that it's not just for the sake of determining the market. We'd be really happy with a third of that $10 billion in revenue a year market. So if you were running a company and GitLab didn't exist, how would you replicate or at least get as close as possible to a good and effective DevOps organization? I do what everyone else was doing today. Get best of read solutions and most of the time, those will have okay integrations with each other. And I put 20 or 30 people on it to make it work for our use case. Got it. And that 20 to 30 people to make the integrations work great. How common is that sort of 20 to 30? Is that what you need if you have 1,000 developers or if you only have 100 developers, you still need 20? You need a couple of hundred. But at some point, it's just going to be too much of an expense. So we're working at GitLab now with 2,000 people and we're not even done. So you really need a couple of thousand people. But at some point, it's too much of your development budget. So for most companies, we see, let's say, at some point, it's 10% of your developers working on tool chain integration. Is it enough? No. But we can't afford anymore. So that's why you shouldn't go by yourself. It shouldn't be the 10 or the 50 people you have at it today. You should use the 2,000 people that have already worked on this and that are the best in the industry. Got it. I'm going to step out of character for a second and just ask you Mike McBride question. I'm curious if there's truly a link between a couple of the current trends. One, microservices to migrating workloads to the cloud. And obviously those kind of go hand in hand for some customers. But let's start with microservices. If I have decided, hey, I'm going to migrate all of my infrastructure to a modern microservices architecture. I'm going to actually run it that way. I haven't completed that yet, but I'm started and I'm smart enough to get that done. Are there any inherent limitations in my current tool chain that make it so that I'm actually not going to be able to realize all of the benefits that I should expect from that architecture because it turns out my infrastructure, which wasn't limiting me in my old approach, now actually will become a bottleneck in my new architecture. For sure. So you have a current tool chain that's all set up for the current way of working, kind of virtual machine base. Now you're moving on to a cloud world, you want to move to cloud native applications, applications that can deal with machines being down with the network getting disrupted because you're no longer in your data center. You're in the cloud and it's more noisy. These cloud native applications, they're based on containers on Kubernetes. And they require a different way of composing the application. Now your developers and your organization today are already working on this, but they're doing it, not using your existing tools. They're not using Puppet and Chef to store the configuration. They have to kind of do a shadow IT operation. Also, it's costing them a lot of time to do it. What you get with GitLab is auto DevOps. You just push the code and GitLab takes care of the rest. GitLab knows how to turn it into a cloud native application to deploy it, to monitor it, to have the logging, the performance metrics, everything works out of the box. So it's a much more efficient way to get the whole company to be cloud native. That's super helpful. Because where I'm kind of going with that question is I'm looking for cases where we go from being better to a requirement. So on the one hand, hey, 200% better is a massive deal, but I'm still functioning. If I'm making this big investment, it's like one of the examples was Intuit. Intuit's spending $200-some-odd million to move all of their infrastructure to AWS. And that's just a migratory to the cloud. They're paying Wipro to do that. What I'm kind of thinking through is like, hey, you're making this investment. You're moving that. And by the way, your current tool chain flat isn't going to actually work. But in order to do that right and realize all of that, it's like you have to actually modernize your tool chain. And I'm trying to understand the credibility of that statement, like how accurate is what I'm saying? Because this is my kind of uninformed way of trying to... No, it's accurate. And there's people in the company doing it, but they're not doing it in a consistent way and it's taking a lot of their time. They're making their own helm charts. That's not a value add. That's something you could just... It should just work. And people spend weeks where we're helping someone today, like bringing this application to the... It's spending weeks integrating all these different parts. And they're all figuring that out themselves. And there's a perfectly viable solution from the 22nd of this month of June 2018. AutodevOps is generally available. Just push your code. Kila makes... Runs all the cloud native stuff. And then one more thing about the big picture for investors, right? They care about the market being big. They also, just like customers, care about the problem we're solving. So one thing is to point out, hey, if you're making this move, here's the stuff that's going to break. Here's what's going to be inefficient. Here's what could be 3x faster. Is it possible that the customer hasn't realized all those things yet? They might be listening to us and believe us. They might not believe us. But even before we walked into the room, presumably they also had some real problems they didn't know about. They were not opportunities for improvement. They were problems. What are some of the sort of burning problems that we encounter very regularly that were a clear solution for? Yeah. Many, many different things. Some of the times it's kind of... Their CI and CD infrastructure is now based on Jenkins and they can't even upgrade it anymore. It's so brittle, everyone's afraid to touch the system. It's a very brittle CI CD infrastructure. There's compliance. I need to make sure that every co-change that goes out is approved by the right people and need to be able to audit that. GetLab solves that. I want to make sure that I can see our top initiatives, what comes out of that, and then the status of these different projects. GetLab portfolio management solves that. We're really slow in getting stuff out the door and I don't know where we're spending the time. Psychoanalytic solves that. We have a lot of different teams in our company and they're not collaborating. They don't know what others are working on. They're not sharing code. They're not contributing to each other. GetLab within our sourcing solves that. One of the things that I'm thinking about is as I'm hearing this pitch from different perspectives and obviously one of the things I want to get the sales team to be really effective at is A, being really consistent in knowing what the GetLab message is for each audience and being able to deliver that super effectively, but also to be able to frame it in the modern way. I know the default right now for other people is to go straight to features and really modern way to sell stuff is we're talking about, hey, here's the problem and if we define that well enough, the customer is nodding because they just came out of a meeting about that fire and so we get agreement there. We point out the trend in the industry. Here's what the leaders are doing. The leaders are all doing this to solve that problem and they should nod to that too because they've read about that. They know who the leaders are and they're actually doing modern DevOps, that's one thing. And then we show them the business results that those people are getting. Oh, I didn't even know about how good those business results were. I was just worried about solving my problems and now I see the business result. It's not until after we've sort of established all those things that, oh, and by the way, now's the right time for you to do this and we can actually help you get that business result. We haven't yet talked about features but we've sort of linked that chain of thoughts from I see the problem, I agree with that. I see that the right solution of business outcomes can be attained. People are doing that. Hopefully it's peers that I admire. And then we can help you get there which is kind of my point of hey, how do I make sure I can actually be successful here because not all of our customers have the self-confidence we like them to have. Yeah. And then the last thing is, and of course we have the product to deliver on this too but that's reversed to I think how a lot of the team is talking about it today. I totally, we should get out of the feature cell and go to the solutions slash transformative cell. Because I don't think we have to always close the big sale as the only sale, that or nothing. I still think we can do the pitch that you and I are both talking about here. It's the solution sale and that first sale might be the first step, right? But we've already got you thinking about this is a journey, not it's not just about Jenkins and then my work is through. Yeah, we can solve your acute problem with Jenkins but like a cocky vendor, right? If we were really that confident we could say and actually I don't even want your business if that's all you're doing. If all you're trying to do is replace your middle Jenkins deployment. Frankly, I don't want to spend my time because I'm going to spend my time with someone who's really trying to get effective at service delivery. That's extreme. Everyone can contribute, everyone can use skill up but maybe if we deploy professional services it should be about that transfer. It should be about how can you make sure that every single change you deploy is secure and is tested in all the different ways. We can do that. We're the only vendor on the planet right now that has a thing that actually works in development teams. That's where we should spend our time and effort.