 Hey, thanks for joining us. I'm here to provide a quick update from GitLab on the managed stage of the DevOps lifecycle and what we've got ahead for 2019. I'm Jeremy. I'm a product manager here at GitLab. I'm super excited to share with you what's ahead and I'd appreciate any feedback that you might have. Please find me on gitlab.com and my contact information is at the end of this deck. Everyone can contribute. I'd appreciate and love your feedback. I frequently get the question, what exactly managed works on? And even though the heart and soul of our tooling here at GitLab lies within the dev and off stages of the DevOps lifecycle, there are two stages that kind of span across our entire tool chain. Those are managed and secure. And even though you have this great set of tools here at GitLab in a single application, you need a set of strong configuration and management tools to understand what's going on across the full stack. So you can read more a little bit about the managed stage and what specifically we work on and how it fits into the DevOps lifecycle at the link below. But managed itself provides the foundation for users to thrive. And this touches on a number of different features within GitLab. The way that I think about it is we have administration, policies, sync, and analytics. And these are all kind of part of the same feature set that managed helps to drive. In administration, you have kind of the fundamentals of GitLab like projects, groups, dot-com navigation, admin area and how users interact with the product On the policy side, you have authentication, audit management, policies in the areas that we... and guardrails that administrators set up in order to define how you can use GitLab. We're splitting off in 2019 the sync area of our team, which is how billing and licensing kind of works in GitLab into a new team so we can move faster and deliver improvements at an even greater rate. And then finally, managed also works in the analytics features of GitLab and how those deliver value and show how your instance is actually working and shipping software. In short, the way that I think about managed's goals is twofold. It's number one, we try to help organizations prosper with the configuration and analytics they need in order to structure their instance in a way that works for their organization. And then secondly, we try to remove barriers to finding solutions. We try to iterate on the user experience. We try to deliver value to users faster and reduce the amount of configuration and the amount of busy work that's done and keeps you from finding value in GitLab. You can find more details about the managed kind of direction and our vision at that link below. Feel free to read it at your leisure and I will even welcome and merge request if you have ideas on how we can improve it. When I think about our road ahead for 2019, I really think about four big themes. And the themes that I kind of think about are operating at scale, how we can make that easier and better for GitLab instance users, how we can make GitLab more compliant and more secure especially in environments where regulatory compliance is important, how can we improve the rate of insights that our analytics are generating and overall how we can make GitLab a more lovable product that people just enjoy using. The first one I'll talk about is really operating at scale. And when we see instances scale from dozens to thousands of users, we want to make that a very easy and seamless process where we remove most of the managed manual work that administrators are willing to kind of take at a small scale. But as they scale up, it becomes more and more challenging to deal with. We want to target those tasks, be able to automate them away and make it very easy for instances to scale to thousands of users and beyond. The second thing I think about is how we can enable custom workflow across stages and automate a lot of those business processes that are handled by hand. We want to use GitLab in new ways that really help you get work done and we see that instances and organizations use GitLab in common and uniform ways that don't tend to change much over time, such as applying labels or defining certain groups that are approvers. And ideally, if you're doing the same thing over and over again, we should be able to automate it. And this applies to business processes and we want to be able to automate things in a way that works for your business and reduces manual effort. On the left-hand side, we see what's next. And what's next, I generally think about in the next quarter, the next three to four releases. We don't have specific timing here because the issues and the links that you'll see here are always the best source of information when it comes to what's coming up next. So please click on the links here and the milestones there. We'll be able to tell you kind of when specifically the thing will ship. In the future, I think about things that we're planning, but kind of slightly beyond the next three to four releases. What's next for operating at scale is really improving on GroupSAML. So we shipped GroupSAML previously at GitLab, but we want to iterate on this feature and add things like SSO enforcement and automatic provisioning and deprovisioning with SCIM in order to make it very, very easy to manage membership in GroupSAML. The next priority for us is really like making licensing very easy. One of those pieces is going to be Licensing Sync, which is a new idea where we will push licenses to instances and make it so that you never have to manually deal with a license key again. You'll simply renew a license and we'll simply push a new key to your instance and be able to enable that for you with a seamless kind of user experience that doesn't involve kind of dealing with licensing keys through email. Thirdly, I'm excited about adding new services to .com. As GroupS kind of use our SaaS service, they kind of typically run into some barriers like CI minutes, storage. And as you scale, those become more challenging to deal with. We want to abstract that away and make this very easy to add more minutes, more storage so there's no barrier to your organization to scale on our SaaS product. In the future, we're doing exciting things like making it really easy to manage users and inactive users kind of in bulk. And then we want to start doing some of that workflow, adding some of that custom workflow by automating away frequent tasks by defining some if-then-else logic with automations in GitLab. It's excited to get your feedback on that. So I'd love your feedback on what we've got there. The next thing I want to talk about is really compliance. And GitLab is frequently used by organizations that operate in regulated environments. We want to make GitLab a first-class product for these customers. The first thing that I think about is traceable changes. How can we audit what people are doing and what user-driven changes are taking place in GitLab? Make it very easy to backtrace and make it very easy to understand who is doing what in GitLab. But I think we want to go beyond that. And we want to be able to define custom guardrails depending on what your organization needs and be able to establish what we think about as continual compliance and ongoing compliance without ongoing effort. So the way that we're doing this is by, firstly, by creating a comprehensive audit log in GitLab. Our goal is to record 100% of all user-driven events in GitLab and make it so that if anything, any kind of investigation that needs to happen in GitLab, an administrator is able to have a clear source of information on where to turn and who did what. The second idea is how we can we improve access control for groups? How can we make it so that you can restrict the membership of the access for a group which is very important for GitLab.com and our self-managed customers and do things like restrict group activity to a IP whitelist. So that incoming connections or attempts to change code from outside that a whitelisted range will be denied. And lastly, we're also working on smart card authentication. So being able to support hardware tokens within GitLab and authenticate with actually like something like a YubiKey is something that we've heard lots of requests from customers and we're excited to continue to iterate on. From there, what we're excited to do is to limit like our project and permission scope for an API consumer to only what's needed. Things like personal access tokens require overly permissive kind of scoping. We want to make it so that when you grant access to external parties to consume the GitLab API, you're only granting them enough access to do what's exactly what's needed. And from there, we want to do things like instead of requiring an administrator or a human to be able to parse a log, we want to be able to do that monitoring strictly in GitLab by being able to define suspicious activity and alerting administrators when that takes place. So really, we're excited about like I'll kind of drop in a highlight on smart card authentication in particular. This is going to appear as a login option and you'll be able to kind of sign in specifically with your smart card, even authenticating its LDAP in order to kind of up the ante on compliance and security. We'll also provide administrators the option to even require use of a hardware token to abstract away the need for any kind of username or password, instead users are required to actually have that token on their person and use that to get with GitLab. So we're excited about this. And as we kind of talk about these, the feedback that I look for and then I still have questions on is what manual tasks do you still struggle to work around as a GitLab administrator? What authentication strategies like LDAP, like SAML, would you like for us to continue to invest in? How can we continue to improve the workflow across stages? What typical manual tasks kind of like do you find yourself doing over and over again? Or do your people and your users typically find themselves doing over and over again? And on compliance and security, how do you currently comply with like the internal rules that are set by your organization? When you lie awake in bed at night, where do you feel most vulnerable? Do you feel like the permissions model needs improvement? Do you worry about the auditing capability of GitLab if something goes wrong? And overall, like how should we improve these capabilities and how should we make investments? Those are the questions that we're looking to our users to help us answer. Moving on from those two themes and talking a little bit about analytics and insight in GitLab. Analytics is a tool that we use in GitLab extensively and we want to continue to iterate on it and make it a more and more useful feature to tell users kind of about what's going on in their instance and really what matters. We have, like I mentioned, we have a number of analytics tools within GitLab. And I think one goal for us is to be able to have a flexible scope for when you use them. We're a little bit prescriptive in how you use features like cycle analytics and contribution analytics. And we want to abstract away the necessity to look at these on a project and group level respectively. And we want to be able to provide users with a flexible scope to say, look, if you want to look at cycle analytics at the project group and instance level and compare yourself to others in the industry, you can do that and you can gain insights for how others are using it. So what's next for analytics is really some is really DevOps score, seat utilization and cycle analytics improvements. So for DevOps score, we're really excited about this and we want to be able to provide instances with a little more guidance on how they can use GitLab and how they can continue to reduce their cycle time. The second request that we've heard a lot from users is about how they can visualize how their instance is using seats over time and at which specific users contributed to how their instance is using seats on their license. And lastly, cycle analytics is a really important tool that lots of users of instances use and love in GitLab. We want to make it better and we want to make it scopable to the group and instance level as well as visualize kind of time across stages. We're excited to tackle this in early 2019. Looking ahead to the future, there are two kind of key and interesting analytics tools that we're looking to add. The first is really how we understand contribution analytics at the user and commit level. Who's committing what and how often is a question that frequently gets asked and we want to be able to answer it natively in GitLab. And then lastly, code analytics and identifying hotspots in your code or specific files or maybe not being touched as often or being touched and have knowledge silos where only one developer kind of understands that code. We want to be able to identify those, call out those risks and be able to inform user maintainers and administrators about these kind of areas of risk so they can address them. The first one I mentioned is DevOps score and we want to be able to identify and distill kind of GitLab's adoption into a single metric. And ideally we want to be able to provide clear recommendations and guidance on how users and instances can actually find GitLab, reduce cycle time by comparing your instance to leaders and having clear recommendations and kind of what to do next. So we want to make onboarding and going deeper into GitLab really, really easy and we're going to do it with this analytics feature that we're calling DevOps score. Like I mentioned, visualizing seat usage is also something that users kind of ask for and need. We want to make this really easy to understand, very transparent. We want to be able to clearly show with a visual graph where the y-axis is the number of users over time and then the x-axis represents the month on a week-to-week basis and be able to see just very clearly how your use change on your seat change uses on your instance has changed. We want to be able to have a table on the right-hand side where we backtrace new members and see on a month-to-month basis specifically who is added, specifically what those users cost you and understand that on a month-to-month level for both self-managed and GitLab.com. So we're really excited about this. And then finally, the last theme is really about loveability and how we can make GitLab and the fundamentals really enjoyable to use. Like I mentioned, Manage kind of works on a lot of fundamental concepts in GitLab like projects and groups and user profile and the admin page and we want to make all these really not just functional but also really enjoyable to use. So we want to be able to iterate on those and make it a terrific user experience. And then secondly, we really want to find those magic moments faster. GitLab is a tremendously functional product but when you're getting going, especially as a new user, we want to be able to help users find the magic in the product really quickly and get them up to speed and productive as quickly as possible. So the way that we're doing this is we're improving the group overview. We iterate it on the project page and we want to continue to do this and target the group page next. We want to continue building tool tips throughout the product. We want to do things like improving our status messages so that you're able to schedule out of office time and when you assign issues and merge requests to someone who is unavailable, you're aware and you know. And in the future, we want to go beyond this and have more ambitious additions for the user experience like adding smart dashboards and replacing the homepage with like a customizable set of tools that give you a clear idea of what you need to do that day and what is going on in the instance. We also want to improve onboarding to help new users and admins get started quickly. And we also want to continue to improve the settings pages including adding inline search to be able to help admins find exactly what they need as quickly as possible. Stuff like the group overview I'm tremendously excited about. We want to be able to summarize group activity in a quick view. So as soon as you see a group, you know exactly kind of what this group does what projects they work on and what's going on on a week-to-week basis. We have an overview of the past week to provide an immediate sense of what's going on and epics and pin projects provide a sense for what code and what projects are most apparent in the group. Tool tips. We added these recently for users. We want to continue to iterate and go beyond that for both issues, merge requests, milestones and more. The idea here is that we want to use we want users to stay productive in the moment on the page that they're currently on without having to open up a million tabs and browse away from what it is that they're doing break context. We're excited about this and we want to be able to have a lot of information that's readily accessible but still provides a great user experience. Overall, you know, I'm curious what you think about these themes. You know, what are the most important analytics features for your organization? What do you typically use in GitLab when it comes to analytics? What's still needed? What are the questions that you wish you could answer in GitLab and which features should we spend the most time investing in and improving? And as far as loveability goes, what parts of GitLab still need, you know, a better user experience? What needs attention? What still feels confusing and hard to use across stages? Would love your feedback and love your thoughts there whether or not our road ahead kind of addresses kind of the things that you think we need to be addressing. But really, that's what Manage is all about. It's about helping organizations prosper meet their needs with strong configuration and insightful analytics and removing barriers to finding value for new users and administrators. We want to do this in 2019 by helping instances operate at scale, be more compliant, adding more analytics and insights to the product and creating a lovable user experience. And that's all for now. If you want to learn more, you can read Manage's direction page and browse links in our relevant epics there. The single source of truth on timing should always be what you see in .com, not this presentation. The milestones there are always our single source of truth. And from there, it's over to you. Would appreciate more of your feedback both on this presentation. You should be able to see the link to this deck in the YouTube description below. Feel free to comment there directly. Feel free to mention me on irrelevant issues on .com. And also just feel free to contact me directly through email or by scheduling a video chat through my calendar link there in the link. From there, thanks a lot for your time. Really excited to hear your feedback and I appreciate you listening. So thanks a lot.