 All right, can I get a thumbs up if you can see my screen? You can see why GitLab, thank you very much. All right, the church bells next to my house are ringing, so it's time to start. Thank you all for attending my functional group update, rather than talking about what we're going to do next with the product, which is all available on our website. I wanted to talk about something else, it's also all available on our website, but maybe harder to find, which is why we're building GitLab the way we are, and what are the fundamental principles that we're optimizing for? And rather than have a slideshow, I figured I would just use something that's available on our website so that after everything that I said, you wanna refer back or you say, well, I'm missing something there, you know where to look. So that place to look is just on our website slash why. I created this base the other day, it took me a few hours to just put it together, and it's a great example of minimal viable chain, I think myself. So let me get into it. So you must be aware by now, and by the way, the images that I'll be showing you, I just opened the images that are on the same page, but I don't want you to be rereading the text while I'm talking, so. So you're all aware that GitLab is a single application for the entire DevOps lifecycle. Now, it's important to understand that the reason that this is a thing, this whole DevOps lifecycle is because everyone nowadays is building software. What kind of company you are, it doesn't really matter anymore. Every single company now has teams building software, and building software is a complicated thing. It's not just programming, which is hard in itself, but it's also project management. And then once you program something, you have to release that, and you have to, you know, you want to be sure that it works, so you want to be confident that when it's live, it's good and it's safe, and then once it's live, you want to be sure that it can handle all the traffic. So there's a million different things to think about, and we went from a place 20, 30 years ago where only tech companies had to worry about these things to a place where we are today, where every single organization has to worry about this. So that means that it doesn't matter what kind of organization you work, everyone is writing software and everyone gets touched by writing software. So that's very important. So if we can make it easier to do all of that, independent of whether you are a tech company or not, that has a huge impact on the world. So that's a very important thing to realize. This is something for everybody. Now, fundamentally, what we are trying to do, and what all our customers are trying to do is build great things that make our customers happy and our customers want to make things that make their customers happy. And the traditional way of building things in software is by taking a very long time because there are so many steps to this process, it ends up taking a very long time. So this is what we call cycle time, the time that it takes you to go from planning all the way on the left to having something live in production and scaling it and actually monitoring it that can take a very long time. So what we fundamentally believe is that if you shorten the cycle time, you're able to respond to your customer needs faster and have a really nice graphic for that, which is this one. So that purple arrow, pink maybe, that represents the cycle time or the size of the iteration that you take. So if you start on day one and it takes you three months to build something, that means for those three months, it doesn't matter what you learn in those three months, you can change your plans because you already decided what you're working on. So let's say you shorten that time and rather than in three months, you take two weeks to release something. That means that every two weeks you have the opportunity to release something, learn from that, gather feedback or see how the market responds or whatever else you might learn from deploying that. And it might help you adjust your plans if necessary. And it goes for every level of the organization. It goes from sales, right? We have a new feature. If it's shorter, we immediately learn what our customers liked or not to the lowest levels of engineering. Like we released a new kind of way of doing things and performance went up or down slightly and we might have to adjust our plans because it acts differently than we expected at first. So what we want to help organizations with is to make it easier to ship software. And one of the ways that we do that is by helping them reduce their cycle time. And the way we do that is just rather than having separate applications for all those steps in a life cycle is having a single application. Because what we see is that between each of these steps in the life cycle, there's a handoff. And each of these steps is a silo where there's a team that does product management. And once they are done, they hand it off to engineering. Once engineering is done, they hand it off to operations. And now those teams might still exist if you're using GitLab. But the magic is, is because it's a single application, what we do is we link everything together. And what we essentially form is a single threat, right? And you all notice, because you've been doing this every single day, there's one issue for one particular change. And in that issue, everything is linked. We link to the merge request, so to the code. And the beauty is with GitLab, what you can do is you can also link to the environment where this is deployed. So if you have a merge request and it's deployed, we show you, this is where it's live. Or even before it's deployed, we say, this is a review environment where you can check it out. Other applications or other setups that organizations have before GitLab, it means that all of these things are separate. So it means that once something is handed over to production, once operation picks it up, you have to now find out where it's live. You have to ask someone else. All those things have significant overhead and all of those things make that those steps take much longer and are much harder to do. And the beauty of all of this is that if you say, well, everything is in a single issue and everyone has access to that, now everyone has the same information to look at. And that means that rather than having to have a formal handover, for instance, between development and QA, now both of these teams not only can work together in the same location, not only do they have the same information, they can work concurrently. And that's what we call concurrent DevOps. They can work both in the same place, independent of each other at the same time. And that's another way that we reduce total cycle time. So that's the fundamental thing we try to address with GitLab. I always used to say, we want to make it easier to ship software. But I think what we really want to achieve is want to enable our customers to build better things, to help their customers succeed. And I believe that the best way we can do that is by reducing the total cycle time and shortening that cycle. So yeah, that's it from a very high level. And the beauty is that, which is a sentence I use a lot if you do this. So let's say you reduce the total cycle time, you have a lot of amazing small advantages. And I wrote a bunch here on their reduced engineering risk. One of them is if you have very short cycles, that means that you make smaller changes. If you make smaller changes, it's easy to understand every single change, right? If I say to you, let's build an entire new application, versus if I say to you, let's just add a small button. That small button is much easier to understand in complexity. It's easy to understand what the effect is of that small change on the application. It's much easier to estimate how much work that small change is than it is for a very large change. So if you're only shipping small changes, you become much more predictable. And it's much easier to think about where you are as a team and even as an entire organization. But there's more, there's more, there's more cool things. And I don't wanna go on too long because otherwise I'm going way over my time and I already see great questions. If you have these small changes, now you can just do something magic because in GitLab, Git, everything's built on Git, so it's just a commit. What you can do is you can, well, one of the things that we allow you to do is automatically deploy them, right? Let's say you merge to master, you merge to production, we can automatically deploy those changes to any particular environment for you. The smaller those changes are, the more confident you can be about the impact it has on your production environment. But even better, because you have small changes, you can also immediately understand why something has changed, right? If you ship a very large change to production and you see your metrics going all over the place, it can be hard to decide what actually caused those changes. But if you just add a single button and suddenly your signups went way down, it means there's something wrong with that button, either it influenced the application in some way or it was that button that created the problems. And what you can do then is you can just revert it. And because it's such a small change, that becomes much easier to do when it's a very large change. So that, from a very high level, is why reducing cycle time and having short cycles is so incredibly powerful. So yeah, that's what I wanted to talk about. I spoke about bridging silos and stages because it becomes much easier because everyone looks at the same thing. And ultimately, we want to automate all these things. And this is with other DevOps and you already know all about this. So I'm gonna leave it at that and please ask me questions. And I also welcome any proposals, things to add to the Y page. I'm gonna stop sharing. So Mark will ask, is there a way to navigate from a homepage to the Y page? I don't know, I don't think so. Yeah, I didn't add it yet, but we should probably make sure that it is linked in some way. And William also mentioned that there's three pages that also all answer Y GitLab, Concord DevOps, is it any good and why? And William says, do you have any thoughts on do we need all three, should they have different content, which one we should use? So I created the Y page because I give these presentations all the time at conferences where I talk about the way we work and the way GitLab allows us to work in a way we work. And I couldn't find the contents of my talk anywhere else than in my own slides, which I think is a very, it's not very good, right? Like I talk about this all over the world, but the only reference of this content is not to be found on our website. So that's why I put it on the website. Do I think we need all three pages? I'm not sure. We can probably consolidate, but at least we should cross link if they are not overlapping in content. But in general, we want to have a single source of truth for anything. I just wrote on our agenda, I think concurrent DevOps and why should be the same page probably on the concurrent DevOps. So we're going to talk about how we can combine the two. That's great. Yeah, you see, I never even saw the concurrent DevOps page, so which is very pretty. John May, can you also explain how you tie small changes to epics and road maps? Sure, John. So epics and road maps are features in GitLab. If you make many small changes, it can be hard to keep track of what are the bigger changes or how do we actually do larger changes across the organization. Let's say I do want to create a whole new application or a whole new big feature that has many different moving parts. It can be easy to lose sight of the bigger picture and not everyone is always interested in all the smaller parts. So that's why you created epics, which is a way to combine many issues so that you can look from a high level on what are the things that we're working on rather than on a specific small changes level. And road maps, they allow you to visualize how those things happen across time. So right now in road maps, you can say I want to see over the coming weeks what are the epics that are active that we are working on. It's just to give you a high level overview into these things. Yeah, I have a question. I just need clarification here. So when you present this to let's say a DevOps manager and they have a tech stack like JIRA, GitLab and Jenkins, right? Is the argument or maybe not necessarily an argument, but is the concept that using one application allows you to iterate smaller quicker as opposed to having that, because they may think, well, we do this already with this current tech stack. So I understand where you're going, but we can already do this. So can you kind of give a little bit more detail into comparing the two tech stacks, like a flow with GitLab, obviously one application allows you to work concurrently, but then also comparing it to a current environment that they may have set up and have pride about, how do you kind of navigate that to showcase, hey, you can actually, there's some serious advantages here and hear the specific kind of concepts that we're talking about. Does that make sense? That's kind of a weird question. No, no, I think it's a great question. And it's exactly what we say, like GitLab is a single application, there's a big advantage. So why is it a big advantage? The first and biggest one is the most obvious one. It's a single application. So that means that to get the same information, you don't have to look into places. The problem with having to look into places is that often those places have separate authentication, authorization. So I might be interested in seeing quickly what the status is of something, but if I don't happen to have access to that specific system, I might have to ask someone. And now what happened is now I have two silos that I'm in, right? Like the silo access to one application and the silo access to the other application. So I have to ask someone. So there's a big threshold to being able to get to the same results in the same time. And on top of that, because it's a single application, we can present you with this status all throughout GitLab, right? So everyone always has the relevant information at hand, which is not impossible, but significantly harder to do with if you have separate systems. So you can do small iterations if you use other applications. If you have a complicated setup of 14 different applications all integrated, but can you achieve the same kind of cycle time as you can with the single application at this GitLab? No, you can't because you will always be working in separate applications. You'll always have to either manually or having to set complex automations to cross-link information. And even then, not everyone has access to the same information. Not everyone has, there's not a single status to be focused on. So it adds significant complexity. And on top of that, if you go through the process itself, there's a threshold between each step, right? There's some amount of energy necessary to go from plan to create, from create to verify. With GitLab, that's the lowest possible. It's the same application. There's always one click away, right? And if you have separate integrations, that amount of energy is significantly higher. You have to look somewhere else. You lose context because you switch application, you have to switch back and forth, et cetera. So is it impossible with other things? It's not impossible, but you cannot achieve the same thing as what we are doing today which will help you significantly reducing cycle time. All right, thank you. Let's see. The person whose iPhone asked, how do we determine that an MVC doesn't live on as an MVC forever? That's a great question. It's essentially, how do you end up adding depth to the application and you don't just ship scope? The beauty is, is that if you ship an MVC, one of the most important thing is you deploy it as soon as possible, right? Like you get it in front of people as soon as possible. From that moment forward, you start to collect feedback from whatever you've shipped. If you have a very strong vision about something, it's worth often investing another MVC even without feedback and to iterate upon something. But in general, you want to listen to the feedback and use that for subsequent iterations. If you get no feedback on something, sometimes it's worth waiting out or removing whatever that MVC is, if it's not worth it to you. So it depends a lot on the feedback that we get and if any. To give an example, Surface Desk, when we first shipped it, there's a very, very small iteration and we barely did any subsequent iterations. We made it a little bit better and a little bit more accessible. And it took a while for it to get some critical velocity. Now, suddenly, we are inundated with all sorts of feedback from all sorts of direction, both internal and external. So sometimes if you believe in a vision, you don't immediately have to iterate on it and you will start to collect feedback over a longer period of time and then you start to increase the depth of the product. There's a lot of discussion about the navigation and I'm sorry, I can't help with that today. Any other questions? What would you say to people who are fear committing fully to GitLab? You know, because the good thing is, if I have a gyra and gyra is not working for me, I can replace it with open project or something. What's, you know, how do we handle the fear of committing to one big thing and if this big thing disappears? Well, the last part that you said, the big thing disappearing, GitLab's open source, that's true, help out a lot. But I think the bigger question is, committing to having a single application is something very scary. No one does that. None of our customers will do that and you see it only happening sometimes. But in general, the beauty of GitLab is that it has great APIs. It has great integrations. You can adopt one part of GitLab and then see if you like any other part of it. And what we see typically happening is that, yes, people do like the other parts. That's like our vision didn't come from the skies and it was like everyone should just do everything in one place. We started out with just SCM. We added CI and we realized, wow, this really works. There's a lot of natural adoption happening even without having to sell that very actively. So there's no reason for one, they in sales you often hear talk about rip and replace. Like rip and replace, taking out all your current things and replacing that old GitLab is incredibly scary and we should probably not do that, not propose that to organizations. Use one part, see if you like it and what tends to happen is we will start to adopt the rest of the tool step. So a bit like a virus infecting or something. I don't think that's very good analogy. No, more like a symbiotic thing. Yeah. Yeah. I think one of the interesting parts is that it proves itself, right? People start to use GitLab just for the Git repositories and they start to use the CI. One because CI is amazing and it's the best in the world. And the other because it's so incredibly low threshold. Like you just add your YAML file and nowadays nothing, just do nothing and we run CI for you. That's pretty cool. Brandon says friends, then dates, then marry maybe, yeah, yeah. Hey, Yob, could you talk a bit more about how customers that aren't using GitLab today are doing the feedback part? So the way that GitLab offers the value is because of taking you through from planning where you've got some idea about the business value you're gonna offer by this change. Then producing and shipping that change and seeing what the value customers actually receive is. How do they do it if they don't have a single application today? How do they tie it back to that initial idea that they had? With a lot of investments and issues. I think what I was talking about is that if you reduce that cycle time you have more opportunities to get feedback. It's not that it's impossible to get feedback if you are not using GitLab, it's just significantly harder to connect all the pieces and see what the value stream is as it were, which is also a feature that we're building by the way to visualize this but how to see what brings value to your organization. So there are tools nowadays that try to connect all the other different tools that you have to be able to visualize what provides value and what essentially creating a feedback loop as it were. But they suffer from the same things in that only a subset of the contributors to whatever you are delivering to your customers have access to this and have visibility into this. And what GitLab allows you to do is that every single person involved in this, every single stakeholder in the delivering value to your customers is actually able to learn from the feedback so that my dream is always and the example that I always give is that if you have a merge request and you merge it you get feedback inside of the merge request today. You can, that GitLab does this today so that you don't have to hear it from a colleague four weeks after you shipped something that your code introduced a problem and increased memory usage or even worse reduced total signups but you can just see it in the same place. And therefore you, even as an individual contributor are enabled to make changes that move your whole organization forward. So it's possible, it is very hard and this is a lot of issues with people not using, organizations not using GitLab. Did it answer your question, Simon? I think it does. I think it needs me to go away and research a bit more about the value stream piece and see what the solutions are out there. So it's a good point. We all, I'll ask Victor who is working on features for value stream in GitLab to give a presentation on this. I think that's a great idea. That's something that we're looking into. So yeah, I mean, I encourage you to do research yourself as well but that's something I'm writing it down right now. Thank you. All right. Any other questions? I don't see anything in the chat anymore. Less three seconds, less chance. Can I ask me anything? Lucas, will 11.1 be the greatest least ever? Lucas, it'll be so good. It'll be so good. I was today tweeting about, so we've been doing this refactor for the merge request for a long time. You think, oh, it's not really interesting but this means that the most fundamental cross-platform cross-team where everyone works together piece in GitLab will now be significantly faster. Like it'll be much, much, much faster. It will feel much more fluid. Ah, I'm so excited about it. And that's like just a refactor and a small performance improvement. And that's in 11.1. And there's tens of those kind of big deals everything in 11.1. It's amazing. I'm super excited. All right, that's it. Softball question, James said. Yeah, it's true. Thanks everybody. See you in the team call.