 Hi everyone, thank you for joining. I wish I could be doing this in person rather than coming to you from a home office in Seattle But it's actually kind of appropriate given the topic Today I will be talking about how to cope and recover and thrive and challenging times And I'll be discussing some of the tactical steps that have worked for us here at GitLab as an all remote company And hopefully some of them will work for you as well a very quick bio I started my career in software quality assurance back in the mid 90s And since then I've had a number of roles and operations and product planning and a couple of stints as an industry analyst My contact info is on the screen. I encourage you to reach out So before we talk about how to achieve business resilience, let's talk about what it is This has not been a normal year clearly We've seen market forces and the way we do work torn apart in front in the air And when it lands it's going to look very different than it used to but even in a normal world in a normal year We have come to expect disruptions this year We just have more of them and we have less notice But change was already accelerating and we can't expect that to slow down Now resilience is about more than being able to get up when you're knocked down It's about being able to weather the storm more effectively So you can adapt quickly enough to find an opportunity in that challenge When we think of efficiency in IT, we generally have two goals We want to keep things running and we want to make things run faster for less money essentially do the same thing but more of it with whatever you have and Resilience in the traditional sense is built on that similar principle Build more than you need and it will be there when there's a resource crunch So that works great for certain things like a directory server because it's a commodity service and the main Differentiator is uptime, but it doesn't work when you have a seismic shift in User demand or as we've seen recently when you have to manage a suddenly distributed workforce and all of the ripple effects of that that it causes If you're headed in an outmoded direction redundancy actually complicates the problem by compounding it you can't just throw people at remote work or a new attack vector Any more than you can in this case throw hamburger buns at a pile of hot dogs. It doesn't matter how many you have they still don't fit Disruption can come from anywhere, you know, think of telephony as landlines disrupted by mobile and then mobile was disrupted by ubiquitous Wi-Fi and so forth But what do you do in the face of that change wherever it comes from now? Traditionally the answer would be some sort of digital transformation initiative. I've been through several I imagine you have as well And that change is necessary, but it still fails most of the time You know McKinsey will tell you that the vast majority of digital transformations while necessary still fail and Even when they don't they're exhausting no one wants to do that again. You certainly can't do that every Time a new opportunity presents itself or a new challenge shows up sometimes, you know with with that much lifting Sometimes you just have to hope that you guess right now. Why is transformation so hard? It's because things change constantly, you know technology evolves and competitors innovate and customers change behavior And if you think about the amount of you know overhead required to manage that top-down transformation You're probably going to miss by the time you're done Now that should surprise only three out of every 1,000 people we asked That's how many people told us requirements never change when we conducted our annual developer survey last year In fact more than 50% of those who responded said that requirements change most of the time or all of the time during a project But we're still planning these enormous kind of waterfall Transformation responses and we're constantly being let down Now that can work if you're building an internal app where you can eat the costs, but if you're responding to a potentially Cataclysmic competitive threat You can't afford to waste time and you can't afford to get it wrong So what do you need to do to be able to achieve that level of resilience? Well, the first thing you need to be able to do is move fast Opportunities present themselves for a very limited window It's hard to do as you get bigger and it's hard to do when you have more in the line and in this industry clearly The most successful companies are both large and have a lot on the line That's why you need to be able to sense and respond now typically this means operating your entire business not just your development teams According to many of the principles of agile development now I'm not talking about the ceremonies of agile your finance team and your risk team Do not need to operate in sprints and have daily stand-ups although they can if they if they choose to we have customers who do that it means concepts like self-organizing teams or Making decisions closer to the point of execution and failing fast and course correcting as you learn from your mistakes and foundational to that is trust both horizontally and vertically in both directions Now in that kind of environment trust can only happen if there's accountability and there's collaboration and for that You need to build a culture that is truly transparent Now at GitLab. We've been pretty successful at moving fast. We update our website More than 500 times a day. We have shipped major updates to our product every month for about nine years now And we have a constant stream of minor updates as well to that product We've kept up that cadence despite really significant growth in the company We have tripled the size of the company in the last year and we're delivering dozens of times the number of features We offered just a few years ago. So how do we do it? We start with extreme collaboration our motto is everyone can contribute and we really try to live that I Means everyone so employees across departments. I can join a conversation in the finance Organization and offer my opinion. I'm actually encouraged to External contributors like partners Customers we merged or integrated more than 300 contributions from customers in our very our last monthly release and even Competitors we have had Competitors suggest changes to our website when our competitive information is out of date So I came to GitLab from another software company the the largest software company in the world I believe at this point and It was a really big shift for me. This type of collaboration was was new to me It's terrifying. It's dizzying. You sometimes wonder what's happening, but it's essential to the agility that I mentioned I'm I'm personally accomplishing so much more than I ever did before in a given day and For the size of our team We are churning out so much more value than we have at any other company where I've worked When now when you're trying to hit a window of opportunity You need relevant input from all of your stakeholders and you need it fast And that's exactly what this allows us to do Another challenge toward to our situation is that our team is a hundred percent remote So my teammates in India are asleep by the time my teammates in Hawaii wake up So that means that all of that collaboration needs to happen asynchronously Now to do that we've really gone all in on transparency So meeting attendance wherever possible is optional and for non-optional meetings We try to move those around to share the burden among time zones Meetings are recorded where it's legal and makes sense Agendas are shared in advance so we can have asynchronous Q&A Leading up to a meeting and then everyone in attendance including the CEO takes notes in a shared document And all of that work all of that collaboration happens in shared spaces now for a regulated industry like yours That can sound really scary, but we're not throwing out security or permissioning What we're doing is actually just the opposite We are creating an audit trail for everything we do and we're eliminating Watercooler chats and private documents on private computers and pockets of knowledge so that we're actually Reducing our risk exposure by consolidating everything Now we surface this information a lot of different ways variety of views and dashboards One of those is this cross-team issue board makes it easy to understand what's going on and then to find ways to either Contribute to it to jump in and add something to it or to align your work with their work so that you don't have Any conflicts down the lines so that you have a lot of reuse and that everyone's being as efficient as possible And again that fosters the kind of open collaboration. I mentioned earlier. We can see some collaboration here with an end user In this case, we're surfacing user feedback before we've even developed something that saves us huge amounts of time and resources And it also helps the customer influence changes before it's too late to do so it adds value for them Now we're very conscious of what can and cannot be shared so your constraints will almost certainly vary But regardless I think the important thing is that you collaborate in a single source of truth that allows your teams to function With confidence, you know asynchronously regardless of conditions Regardless of where they are and at the same time still provide that traceability that you need Particularly in a regulated industry Now this is where startups have the advantage size They are small so they're nimble and they may even be able to operate outside of compliance frameworks because regulators haven't caught up So small companies generally have less to lose so they can take risks Large companies can do this too. We are iterating faster at 1300 employees than we did at 50 So you're probably familiar with the concept of a minimum viable product potentially even a minimum viable feature now we at GitLab think both of these are Too much effort. They're too big and when you think about the time you spend, you know Designing developing testing and shipping one of these Only to find out that it may not be what you need I mean that there's a lot of effort in there that can be wasted so We have aligned ourselves around what we call a minimum viable change You know, what is the smallest change we can make that is an improvement over what came before so not incomplete But but minimum, you know, not untested certainly but but minimum Here's an example of a web page MVC, you know, we start by saying here's the thing dev ups our dev sec ops We do it Next day or maybe an hour later, you know, I or someone else might add more detail Then we had a call to action button once we've sorted that out You know, we add images that reflect where we're headed We had a bunch of other features and then ultimately we have a polished end product but we didn't sacrifice the value of having something there for all of that time and Because we had feedback what we ended up with was much more aligned with what ultimately we and the customers both needed So MVCs are hard. You need to be willing to ship something that you wouldn't have shipped before But the point is if you move to smaller changes, you get feedback so you can learn faster Your risk from any one change is much much smaller and you can back out of that change much much faster and more easily Now when you do have that much feedback coming in, you need to be able to make decisions quickly That's why Here at GitLab. We have a directly responsible individual for every document or feature or business decision And it's typically not the person who is highest on the org chart It's the person closest to the work that person can then execute without multiple layers of oversight as the DRI Now when you couple that with the small incremental steps of an MVC it limits your risk exposure So if someone makes a bad decision because they're not the most experienced worker, that's okay You lose an hour or a day not a quarter Delivering fast makes no sense if what you're delivering isn't secure or high quality So one of the core principles in DevOps is automating the process of building and integrating and testing and deploying and delivering software We do that for everything we ship including our website We have an automation pipeline that validates security and quality and compliance of all of our changes including copy changes So we strive to automate everything. We haven't gotten everything there yet But the pipeline is the key to unlocking That piece of mind that allows us to have velocity without introducing crazy risk so Automate everything you can and when you can't if you have a manual approval gate that you need for instance Work within the same system to maintain that traceability and accountability So automation adds consistency and quality do it when you can Creates an audit trail and it gives you the ability to repeat that process continually with no variance Across all of those smaller iterations Here's an example of one of our pipelines where we have over 100 tests and scans running against just one code change what we call merge request This is where the developer gets their feedback. They get almost immediate feedback on any issues They may have caused. What's the implication of what you did? Does it make performance better or worse? Did it fail a test? Have you introduced new security vulnerabilities? You can fix those problems now rather than pushing forward defective or less than ideal code Again same holds true for security. We run security scans on every commit You can see immediately what's going on with new vulnerabilities if someone Allows a vulnerability They you know they they give it an exception and they pass it through you can note that in the same place along with Whatever reasoning they had behind it You can see the code changes that led up to it all of that exists in one place because it's all automated in a pipeline And that's gold if you're being audited the auditor can see every single Code change and every person who touched it and the reasons they did everything they did and that is only unlocked through automation We've embraced containers as a way to streamline and accelerate development So when you're spinning up test environments for instance at GitLab We have something we call a review app that we use for changes here The pipeline automatically creates a review instance of an application and deploys the app using Kubernetes So now the developer QA security can evaluate the app without waiting and without risk and when they're done They can destroy that container. So there's no evidence of you know anything that shouldn't be lingering We've embraced continuous improvement in our processes as well as our products So every process in the company is fair game. We're all expected to try to improve them For example, we frequently host live public retrospectives or monthly releases where we look at what worked and where we could have done better We welcome input from team members. We also welcome input from the public now again That might not work for you But the idea I think is to embrace as much participation as you possibly can and then build the systems to support that One of the systems we have that supports it is our handbook. It's a remarkable frankly living document We've got over 4,000 pages now. It's updated constantly throughout the day every day It is how we do work. It is where we do work and it is Why we do our culture is embedded in that handbook It's why we do the work that we do Everyone can contribute to that if you want to make a change to the way we do work You just change the document the DRI approves it. It's how you do work As a massively distributed remote company This has actually been incredibly helpful to bring us all together culturally and also Make sure that we're all following the same processes So in summary these five things help us go faster They enable our processes to become as resilient as our software and the whole company becomes as agile as our developers In the last nine years, that's allowed us to move from a source code and a repository to everything You see there on the right now, we didn't know where we were headed We couldn't have planned that out. We iterated our way there. We MV seed our way there and Again, your situation may be more constrained because of policy or compliance But if you realign your culture to enable iteration and then you build the tools to support that you can You can stay on the pulse of the change that's necessary in times of crisis and you can actually gain ground And with that I'd like to thank you very much and open it up for the last couple of minutes for questions Thank you