 a good morning like Todd did. Come on. All right. I'm Scott Williamson VP of product for for GitLab. I'm joined by our awesome director of user experience Christy Leneville. We're very happy to be here and thankful that you took the time to to join us. We're gonna talk about three things today. We're gonna talk about some broad industry challenges with DevOps. We'll talk about how we feel the GitLab product can help you speed up your own DevOps adoption journey. And we'll talk a little bit about where we're headed with the product line and per Sid's comments earlier how everyone can contribute and we can build this out together. So DevOps is transforming the way companies build software. IDC estimates 77% of companies are on that adoption journey. So pretty much everyone agrees DevOps is the way to go. However, only 8% of companies are successfully using DevOps best practices on more than half of their applications. So why is that? We feel we have a tool chain crisis on our hands. Over time a lot of products have popped up to serve various aspects of the DevOps lifecycle like planning, source code management, continuous integration, continuous delivery, monitoring, security testing, you name it. They may very well do a good job in their own area of focus. But when you're trying to stitch it together across the whole DevOps lifecycle it gets ugly fast. These products have different data models, different ways of logging in, different user experiences. It becomes very tough to use that whole tool chain across the top. So you either end up with disconnected tools or you have a team that's stitching the whole thing together. And it's just a difficult situation that slows teams down. Here's a few numbers to back up my point. We are spending over $5 billion a year for these products and yet companies claim they're wasting approximately 50% of their time on repetitive tasks and logistics. And 87% of companies claim to be dissatisfied with their DevOps journey to this point. So we can do better. And of course we feel like GitLab can be part of the solution here. GitLab has evolved into a DevOps platform delivered as a single application. So from planning to source code management to continuous integration to continuous delivery to security testing to monitoring and more, we've got you covered. And if you adopt GitLab you can benefit from having one data model, one way to log in, one user experience, making it all much cleaner for your teams. It can communicate much better, ends up being much more simple and secure. And over time you can replace otherwise expensive, ineffective tools, free up budget, free up teams that are focused on integration to build more core value for your company. And we can also unlock things that are only available when you're doing everything on one platform. Things like fully integrated security testing, seamless collaboration between team members, and real-time feedback, just to name a few. All right. So when we pitch this vision to customers, almost everyone gets it. People tend to like where we're going. And then they look at their own journey and they're like, well, we got a long way to go and your product looks broad. Where do we start? So I thought we'd sort of give you a bit of a roadmap for how many companies have adopted GitLab. Oftentimes it starts with pairing up source code management and continuous integration. Put these two together. It's kind of like peanut butter and jelly. It's a great combo. And you can really start to understand the benefits of having a single app application. You get a lot of efficiencies from having these things in one place. And then oftentimes, and I believe this was backed up by the reference Sid had up there earlier, customers begin to use security features, shift it left, put more control on the power of developers to harden your security posture much earlier in the software development lifecycle. And then with everything in one place, it becomes a no-brainer to add on continuous delivery, which can then break down silos between development teams and operational teams. From there, you can choose your own adventure, if you will. We can help you manage your portfolio. We can help you manage your projects. We have a package artifact repository. We can help you monitor and defend your production applications. The key takeaway from this slide is you can choose the speed at which you adopt and the order in which you adopt based on your own journey as a company. So with that, I'll pass it over to Kristi. Thanks, Scott. So as Scott mentioned, there's a pretty consistent arc to how companies tend to adopt GitLab starting first with our SCM and CI features that are core to how product teams work together. And when we do UX research, we hear some pretty common themes about the problems that companies are trying to solve in these areas. So a really common problem is team communication. When information is spread across multiple tools or it's only captured in meetings, it tends to slow things down by forcing a lot of back and forth conversation. And then for companies that use chat tools, information tends to get lost either due to archiving rules or just bad channel hygiene. And when everyone is working from different information, people get confused and they unintentionally work it cross purposes. And it can be really time consuming to get things back on track. So another thing that we hear about is managing integrations between SCM and CI. Scott already mentioned the pain of designing, building and maintaining integrations. But as UX practitioners, what we think a lot about is building consistent experiences. It's already hard enough to learn one-tools conventions. It's extra hard when you have to learn several tools conventions. And then lastly, we hear a lot about the impact that bugs can have on a team's velocity. Quality issues can be hard to identify, and then they can also have a cascading effect. So developers don't want to know about bugs as early as possible, and they don't want to have to look through a bunch of different tools to try and figure out what went wrong. So when I joined GitLab, I'd been working in tech for almost 20 years. So I was intimately familiar with the chaos that disconnected communication can create. But this is especially true of today's highly cross functional teams, because it's not just developers who need to know about code related decisions, and it's not just product managers and designers who need to understand design rationale. To make great software, everyone needs insight to decisions as they're being made. And that's why I was so pleased to see cross functional communication happening right inside the GitLab tool where no one had to dig around to find it. Our integrated toolset collects all of the data from the DevOps pipeline, makes it available to every stakeholder, and that empowers them both to give feedback and take action. So I thought this quote from our Q1 usability survey did a great job of highlighting the power of bringing SCM and CI together in one tool. The user said, learning one tool's conventions has been so much better than trying to glue three different tools together, each with their own words. So during my own UX career, I've worked on more than one project that tried to solve this by layering a custom portal over disconnected tools. And these projects have a history of failure, either because the data models of different systems are incompatible or APIs are incomplete. So you end up compromising, either by leaving out important data and work flows, or you just go the other direction and you include everything and the kitchen sink, which defeats the purpose of the portal. I don't know anyone who likes working on these projects. And as for bugs, they're painful for everyone on a product development team because they impact the team's velocity. And then if they make it into the production app, they also impact the end user experience. And then the worst case scenario is when a bug goes unnoticed for a while and it either becomes really difficult to find, or it starts to have a cascading effect on other parts of the app. But here you can see which tests have failed and in which files. So everyone is happier when bugs are found the moment the code's committed. To be honest, I never thought I'd see the day when security wasn't some magical thing that happened after an app had already been built and was just about to ship, or even worse was already in production. But as a UX leader, I care about security because it's integral to the user experience. A great app is always a secure app. But when security is disconnected from the regular product development flow, we hear about the problems that come up. A big one is that slow detection means that security is left scrambling at the end of the product development life cycle to find whatever problems are there. And if the problems are bad enough, it can stop teams from shipping even close to their primus milestone. When we talk to security professionals, we hear them complain about an us versus them mentality, where security is more of an afterthought than an ongoing consideration. But when we talk to developers, we hear them say that they care deeply about security. No one wants to be the one who brought the app down. They just don't feel empowered to find and fix vulnerabilities on their own. But what everyone wants to see is security as a shared responsibility that starts the moment that the project begins. So these days UXers are used to hearing that everyone's a designer, which is true, because everyone on a product team is responsible for creating a great product experience. But this is true for security, too. Developers don't have to wait for a security engineer to find problems at the end of the software development life cycle. Instead, they can take responsibility for identifying security issues the moment that they commit code. And the trick is getting them the right information at the right time before the code ever leaves their hands. And then that means that security teams only have to get involved with vulnerabilities that developers can't solve on their own. And if developers are unsure what the problem is, GitLab empowers them to bring helpful information to their security team. So security can drill into the same single source of truth information that developers are looking at, and they can find and resolve vulnerabilities together. So as you can see here, when there are vulnerabilities in NMR, it requires approval to move forward, and then everybody can see and triage the vulnerabilities as needed. That makes security a team responsibility and it reduces the last minute heroic efforts we've all seen to find and push security fixes. But it also lets the security pros focus on bigger, more complex challenges. And with our security dashboard, everyone gets a higher level of view into the health of every single project. So you can see here that every project has a score of A through F, and then used to expand to see the details. But detecting security issues early doesn't just save time and heartache, it saves money too. So in 2019, we saw an increase in the volume of data breaches, the average cost of a data breach, and the average cost per lost record. And this is a trend that's been happening year over year. With the average cost of a data breach at $3.9 million, imagine how much money you can save if you find vulnerabilities and resolve them before they ever become a problem. So after companies adopt integrated SCM, CI, and security, the next leap tends to be into continuous delivery. And from speaking with ops engineers, we hear some common complaints in these areas, in this area. So first, there's still a tendency for code to get thrown over the wall without following documented procedures. And that leaves ops teams feeling like their job is just to clean up whatever mess is left at the end of the project. And while ops teams want to encourage faster time to market because they know it's good for their company, it also makes them nervous because they understand the impact that that can have both on their team and on the production app. And then lastly, ops teams are still struggling to deploy in hybrid environments. So in a recent survey by 451 Research, they found that getting clouds to interoperate seamlessly as part of the business function is easier to describe than to implement. So that's why GitLab is focused on building an experience that treats dev, sec, and ops as first class citizens. For everyone to work together, they all need access to the same data, but in dashboards that are contextual to them and their role. GitLab is best when it's the main interface for all contributors because it offers unique experiences that are tailored to everyone's needs. We want everyone to see GitLab as their main interface for getting work done. And as you can see from the Twitter quote on this slide, that day has arrived for some people already. So even in agile teams where the point is to break down silos, they still have a tendency to crop up and disconnected tooling is one reason why. But when dev and ops activities are co-located, everyone has insight and ownership over the delivery process. And then they also have an easy way to communicate about problems as they arise. And this transparency helps teams to deploy faster and with less stress. Because everyone can see what's already happened, what's about to happen next, and then how they need to be involved. And while deploying in hybrid environments is notoriously hard, GitLab makes it easy to set multiple deployment targets. So recently one of our customers said GitLab CI CD for the deployment in Kubernetes environments using Docker images is so smooth and satisfying. GitLab helps in implementing an amazing tool set for CI. So as I mentioned throughout this talk, a lot of different roles are involved in making good software. And this is the ultimate GitLab vision where everyone uses a single application so that everyone on the team is on the same page. So while we're still calling it DevOps, we're really expanding that definition to one where everyone can contribute. So you can see here where we call out roles like product, program and project management, but we're also adding support for roles like quality engineering and design. And at our own company, even teams like marketing, finance and people operations collaborate inside of GitLab. So it's our big hairy audacious goal to be the most popular collaboration tool for knowledge workers in any industry. And with that, I'm going to turn it back over to Scott for our 2020 product investment strategy. All right. So everything that Christy talked about is live and in the product and you can benefit from today, but we have ambitious plans as a product team. And here's a quick highlight of where we plan to make outsized investments this year. This is by no means comprehensive, but it's this is where we plan to really double down. First, we want to make it easy for enterprises to adopt GitLab. We've seen a real surge of interest from enterprise type customers and what we do. We want to make their experience awesome. Things like very configurable authentication and authorization, super high scale, on-prem self-hosted deployments with disaster recovery, built-in compliance so they can deal with audits just to name a few examples. Second big theme is improving our most used feature set. Per the adoption model earlier, most companies start with source code management and continuous integration. We want to make sure those core areas of the product remain awesome and best in class. And then finally is to make some strategic, add some strategic depth in some really important areas. This past year we spent a lot of time and energy kind of going wide establishing that single application capability. This year we want to add depth in some really important areas like security, planning, and operational aspects of the product. All right. So we've had an ambitious vision to be a single app for the entire DevOps lifecycle. We've got big plans in 2020. The good news is y'all can help. Stole Sid's slide from earlier, we've got a hundred releases in a row of shipping on the 22nd, seeing a real exponential growth curve in our ability to deliver to the market. Part of that is because we've invested really heavily in teams that help us build software, engineering, product management, design, research. Those teams went from 200 folks to 500 this past year. We're going to continue to keep our foot on the gas. And so our team is going to be doing really good. We're going to be doing really good. We're going to be doing really good health investments on our end. And we have this unbelievable community behind us. Sid talked about 2,000 plus contributors. We have organizations that actually pay folks to develop GitLab to make it work for their organizations. We honor the most prolific contributors in the world. We have a couple hundred merge requests per month. This is a massive tail end behind us. So thank you to anyone in the audience who's contributed in that way. The second big help is integration partners. We're working hard as a company to make sure we have an open API surface so that it's easy for partners to make their functionality natively available in the product. One of the recent examples of this source graph who's here has embedded their code intelligence feature set so that you can experience that within GitLab. And a white source has made their open source code security testing, vulnerability testing also available natively within GitLab. So thank you to those partners and to the many more to come. And then finally transparency. Sid talked about this. We choose to be transparent. It's one of our values. Every month we have an open kickoff call. Our issue trackers are open and we get tons of input from folks outside the company. We have a monthly customer advisory board. All this gives us really high fidelity feedback that helps us make good decisions. And I'll give you one more way that we can contribute. We have a program called GitLab's first look. The URL is up there. If you sign up, you get early access to beta features. And you can raise your hand to participate in interviews or surveys which help us gather information to make better product decisions. We really want to understand the problems and make sure the solutions we envision work for you. And this is a way for us to match up someone's interest with the projects that we're working on. And most importantly, if you enter in this, you get a chance to win GitLab's swag. That's it folks. Thanks for hanging in there. Please enjoy the rest of the show and stop by the booth for feature demos. Thank you.