GitLab Product Marketing - Main, 7 Sep 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Business Resilience: Finding Innovation in Crisis | as featured at the Future of Financial Services

Description

We’ve spent decades building resilient infrastructure, only to discover that our biggest threat wasn’t a natural disaster or network latency, but a fundamental change in the way we work. What if your business could be as highly available, fault tolerant, and resilient as the systems that support it? What if you could adapt quickly enough to turn risk into opportunity, without compromising quality or security?

Leveraging GitLab’s experience as a 1300-person all-remote company, this session will examine the organizational, cultural, and technical steps businesses can take to build resilience into their everyday operations and create opportunities to thrive during disruptions.

Topics will include:
• Transparency and collaboration
• Iterations and Minimum Viable Change
• Process automation
• Increasing business agility and responsiveness
• Quality, security, and compliance

Get in touch with Sales: http://bit.ly/2IygR7z

A

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 uh it's actually kind of appropriate. Given the topic today, I will be talking about how to cope and recover and thrive in challenging times and I'll, be discussing some of the tactical steps that have worked for us here at get lab as an all remote company, and hopefully some of them will work for you as well a very quick bio.

A

I started my career in software quality assurance back in the mid 90s and since then, I've had a number of roles in 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.

A

Clearly, we've seen market forces and the way we do work torn apart and fern 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.

A

So you can adapt quickly enough to find an opportunity in that challenge.

A

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.

A

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.

A

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.

A

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 and so forth.

A

But what do you do in the face of that change wherever it comes from now? Traditionally, uh 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.

A

Sometimes you know with with that much lifting. Sometimes you just have to hope that you guess right.

A

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.

A

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 percent 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.

A

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 on the line and in this industry. Clearly, the most successful companies are both large and have a lot on the line.

A

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 standups, although they can, if they, if they choose to, we have customers who do that.

A

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.

A

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.

A

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.

A

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. That means everyone, so employees across departments. I can join a conversation in the finance organization and offer my opinion.

A

I'm actually encouraged to external contrib external contributors like partners, customers, we merged or integrated more than 300 contributions from customers in our very last monthly release and even competitors we have had competitors suggest changes to our website when our competitive information is out of date.

A

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. uh 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.

A

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.

A

Another challenge toward to our situation is that our team is 100 remote, so my teammates in india are asleep by the time my teammates in hawaii wake up. So that means that all 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.

A

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.

A

We are creating an audit trail for everything we do and we're eliminating water, cooler, chats and private documents on private computers and pockets of knowledge, so that we're actually reducing our risk exposure by consolidating everything.

A

Now we surface this information in 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 line 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.

A

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.

A

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,.

A

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.

A

Large companies can do this too. We are iterating faster at 300 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 get lab 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.

A

I mean 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.

A

Here's an example of a web page mvc. You know we start by saying here's the thing devops, our devsecops. We do it the next day or maybe an hour later. You know I or someone else might add more detail.

A

Then we add a call to action button once we've sorted that out. You know, we add images that reflect where we're headed.

A

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.

A

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.

A

Now, when you do have that much feedback coming in, you need to be able to make decisions quickly. That's why here at get lab, 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.

A

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.

A

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.

A

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 peace 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.

A

Do it when you can, it creates an audit trail, and it gives you the ability to repeat that process continually with no variance across all of those smaller iterations.

A

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? uh Did it fail a test? Have you introduced new security vulnerabilities?

A

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.

A

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.

A

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.

A

So now the developer qa security can evaluate the app without waiting 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.

A

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.

A

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 4000 pages. Now it's updated constantly throughout the day every day.

A

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. If 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.

A

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.

A

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 mvc'd our way there and again your situation may be more constrained because of policy or compliance.

A

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.