 Welcome to the second part in our series on CI CD. I'm Suri and I work on the content team here at GitLab. We're thrilled you're joining us to learn how to make your DevOps dreams a reality. If you have questions during the presentation, please use the Q&A box at the bottom of your screen. We'll also dedicate some time to answer your questions at the end of the presentation. If you have any technical difficulties, please use the chat function and I will do my best to help you. Today, John Jeremiah, a Senior Product Marketing Manager, will help us solve the collaboration conundrum. So let's get started. Hello John. Hi Suri. Thank you so much and good morning, good afternoon, good evening everyone. I'm super excited to be here with you today and to talk about what we're facing and to continue the conversation we started a few weeks ago when Victor talked about DevOps and some of the challenges people are facing and I want to focus really today on what we're facing. I want to talk about the challenges people are running into building on what Victor shared and look at what are some of the blockers and barriers and why are people running into those challenges and then how can you break down the barriers? How can you move forward? So let's get started and take a look first at the reality, right? And if you remember what we talked about, Victor talked about the reality that a lot of people are facing when they look at DevOps. People are investing an enormous amount of energy and resources to try to transform the way they deliver software. They're spending literally millions and millions, even billions of dollars to try to improve the way they deliver software. But in many cases, the results they're feeling, what they're experiencing isn't what they wanted. They're not getting the ability to go faster. And in fact, a lot of times people are reporting that they're disappointed with the results. And if you think about why and you look for why, you're going to find some really interesting observations. You know, a couple of observations I found when I started to look at why do people struggle with DevOps is, you know, if we looked at, you know, stories that people have written, two of them that came to mind that I saw that really resonate. Tech Beacon, they wrote a great story recently about one of the reasons why people fail with DevOps. What are reasons that drive it? One of them was, well, they create a DevOps department, like another silo to try to do DevOps when the whole goal is to try to build collaboration across the board. Same finding actually, interestingly, came out of an article on Dezone. They look at, you know, not thinking about capacity in a workload, not appreciating the real challenges that people are facing. And they're bringing DevOps in without changing the way they work. I love to have Dezone talked about, you know, how it's not just a set of tools, but it's changing the culture. And it's changing a culture that is inclusive of everyone who's involved in developing and delivering software. It's not just the devs and the ops. It's quality. It's security. It's the business owner. You know, one of the hardest things is getting business owners to engage and be part of these delivery lifecycle. I experienced it myself, introducing ads on an organization where they thought all they had to do is write the requirements and then come back in six months for what was done. Business owners have to change too. And it's one of these changes. It's one of these transformations that it can't be mandated from leadership. Leadership has to embrace it and support it. But it also has to be something that developers and engineers and security professionals and ops teams have to embrace and want to change too. This is a change of the culture in the organization that only happens if we all start to change the way we work. You can't just buy a tool. You can't just say we're going to do it. We have to really embrace and embark on a different way of leading and a different way of thinking about how we deliver software. And if you look at and think about the traditional world, the traditional enterprise IT organization of how we've evolved over the years. I've often I've written about this about how it's called tribes in the different tribes of IT and a lot of times we call them silos. So, you know, silos works here, right? There's a group of people who work on planning and governance and they have their tools and their language and they work together to manage and optimize their portfolio. They come up with an idea, a plan, a new project, something that they're going to deliver. And a team is formed and they go off and start building it. Sometimes in isolation with the people who are going to test it and make sure it's good and ready to go. I know in my past history, it was often in isolation. One of the biggest challenges was how do you get these teams to work together and not be at odds with each other? And then when you get done, well, how do you get it to production? I mean, this is what Patrick Dubois started to talk about when he talked about agile ops, which became DevOps not so many years ago. This is the, those barriers between development and operations, how operations could be more agile. But these barriers are in between the teams. Not only are they between the teams, but you know what? These barriers aren't just cultural. We built, too often we've built them into the way we work. We've built them into the tools we buy and the language we use. We've created all these different tools and then we've tried to solve this barrier with, well, we try to wire them together. And then we run into problems because we have different data models. We have different definitions of different elements. We often find ourselves in conflict and in having to maintain all of these different tools is how they integrate with each other. One change is we have to work on managing and maintaining and it becomes a huge overhead for organizations to keep track of and for teams to keep track of. And at the end of the day, the business really doesn't care about how the tools work or how they connect with each other. The business cares about delivering value at the end, how we do it, how we deliver value. They don't care. They really want us to go faster and deliver value. And so what we really end up with is some very real challenges and some very real issues that this model introduces. We don't have any real sense of visibility and we can pull it together with dashboards and reports and put it into PowerPoint or slides or different ways to show it to leaders. But it's hard. It's incredibly hard to have a clear view of status and what is where and then understand the status but where we're going. It's certainly not efficient. It's not a process or a framework that says, Oh, wow, we're going to be able to just let it run and focus on on resolving issues and delivering new value and new innovation. And and frankly, the other part about the other challenge we often run into is the one that our auditors and security teams and they expect to have some degree of control. When you have to go through an audit to demonstrate compliance with COVID or socks and you have to be able to demonstrate that you're following the process and the controls that you set are in place are there. And that people that they work in the old way in the way with all the different tools and the way we were traditional, it can be really hard. Because a lot of times people are going to find the shortest way to get things done to be efficient. And that often makes it hard when it comes time to audit and prove that you actually delivered and followed the process. So these sources of friction, these sources of challenges and pain points can be really a problem. And frankly, when you look at it from a tool chain perspective and you say, OK, well, it's not really that bad because I'm just managing. You know, we have one or two projects and it's fairly simple and our tool chains are simple and they're defined and we can deal with it, right? You say that. And then the question would be, is it not perhaps a bigger problem? Because if you think forward, think about where we're going. Think about the future of cloud native and how we're going to see more and more microservices and smaller, more granular applications. Think about how more and more teams are going to have be involved in building and developing and delivering smaller pieces of solutions. It's going to lead to a multiplication of tool chains and it's only going to get harder. It's not going to get easier. You might even consider a tool chain crisis that is that we're on the precipice that this is going to become much, much harder as we go forward. And you have to solve this. You have to think about how do you optimize your tool chain in order to be faster and more efficient? And if you want to move at the speed of business, if you want to accelerate and go as fast as the business wants you to go, then we have to figure out how do we collaborate? How do we bring teams together to interact with each other to have one common view to share their goals and to share their vision? Now, it started, frankly, it started probably 15 years ago, give or take. When we introduced and we saw people start to adopt Agile, Agile really was focused on lowering the barriers between these core teams. It was about how do we get developers and QA and project managers to work iteratively and to focus on having visibility on what they're doing and to work more collaboratively with each other. And I'd argue that Agile has helped these teams to be much, much more efficient. And when Patrick and Gene and Jez and John Willis and the guys who have been thought leaders behind the DevOps transformation, the world of DevOps, what they've started to force us to think about is then how do you go on and how do you start to lower these other barriers? How do you enable automation and collaboration and sharing and measurement? How do you bring those principles of lean manufacturing to lower the barriers to enable teams to collaborate and communicate more consistently from place, from part to part? So they're not thinking about their silos, but they're really focusing on how do they respond to the business demand for value, the business demand for innovation. This is the key. And that's why we do what we do. All of us. We come to work every day and we focus on building and delivering great software. It's not about managing the tool chain. It's about supporting the business. And in the old way of working, the old way of doing this, we were always often got stuck on thinking about sequentially, about from one hand off to another going from silo to silo to silo. And as you think about these handoffs, what does it do? It introduces friction. There's all these opportunities for waiting. In a lean mindset, you want to eliminate work in progress. You want to eliminate and reduce your constraints so you can go faster. But if you get locked into this siloed mindset of handoffs, it only leads to friction and finger pointing challenges. But when you're able to work collaboratively, and you're able to share and have visibility across the full life cycle, you can start to think about how can I go concurrently? How can I free it up so that we can have multiple builds a day and we can have teams working on multiple issues in parallel. And we're no longer constrained by the silos and our lack of visibility, but we're really able to move at a much, much faster pace. It's frankly a liberating mindset to be able to think about working together collaboratively across the full life cycle, rather than having to wait and wait and wait, because that's what the business is doing. And your competitors are not waiting. You have to figure out how to go faster and this is a key to doing it and a key to going faster. So let's go back and look at that tool chain for a second. This is what so many of you are experiencing every day. One version, one variation of these tools or another impacts the way you deliver. Now, if we want to look at what does the answer look like, how do you solve this? Well, one of the ways you solve it is it's cultural. It's about getting teams to work together. It's about aligning goals and KPIs and aligning so that people can work together collaboratively, but it's also about removing some of those barriers, removing some of those roadblocks so that way people can work together faster so they can have a common view and a common discussion that the team is able to unify behind. It's about having a single source of truth where you can really have traceability and visibility across the life cycle. It's really about how do you streamline the processes and enable teams to work in a way that they're more efficient. Now, you know, I have the term left shift in here or shift left, but it's relevant. How often do we wait until late in the life cycle to either do security testing or some version of performance testing, only to discover that we have a problem that's going to impact our ability to ship, or we're going to ship it and it's going to impact the value the customer experiences. And I don't know about the rest of you, but I know that we're make those decisions you have to make all the time. And a lot of times you don't have to do that. If you can identify performance and security issues as soon as they happen, as soon as they are introduced into the code, you have a chance of fixing it. So being able to shift left is an important capability and it's important to think about how do you help people do that. And then at the end of the day, you have to have a system and a platform and a framework in place that allows you to manage and govern the work, where it's not out of control, where it's really quite controlled. In fact, I wrote a piece about how mature DevOps actually produces higher quality and more reliable solutions than it does if you work in a more traditional waterfallish way. I wrote about Gartner's bimodal model once, and I think they get it wrong because it's really about how do we work together and how do we collaborate with shift left automation and testing to ensure that we're always delivering quality. If we do this right, if you do this right, you're going to have more control and more compliance and better governance than you ever would before. And while you do it, you end up reducing risk and delivering higher value. Now, I want to share a little bit of how we do this, right? This is something we do. We're doing this, right? This is not something that is theoretical and you might be able to do it. This is something that's for real. I mean, this is something we're actually doing. Not only are we doing it because we're as transparent as we are, you could actually check out our single discussion at GitLab because what we've done is we've brought our entire DevOps lifecycle into one view where we really do maintain a single conversation from planning future features and issues to how we go ahead and then start to create the merge requests and code to how we build testing and security testing into the pipeline. So everything gets built, every commit gets tested. It all gets moved through to consistently packaging, releasing and configuring. See really what we're doing and what we're demonstrating and we're doing as a team here at GitLab is we're building around a single conversation, a single conversation that helps us focus on delivering value and iterating at a remarkable speed. And because of what we're doing, because of the mechanics of what we're doing, the way we're working as a culture and as one team, we're able to deliver amazing value. And this is what we've experienced. And I think it's something you should look at how do you do it for your team, whether it's a combination of tools that you work to streamline around, or how do you bring your teams together to collaborate and deliver faster than ever. A couple of closing comments and a couple of closing thoughts, we kind of get to the end so we can take some questions is, and I want to reiterate what Victor had said earlier. And because in his presentation, I think he got it right and I think it's still true. I think at the end of the day, what we're talking about is a cultural transformation, a transformation in which involves how your people, how the people on the teams, the different tribes, how they work together, how they build trust and a relationship with each other, how they learn that it's okay to experiment and to start to take risks and to learn together and how they embrace a process and a framework that enables them to embark on continuous improvement. How do they continue to improve their process? Because at the end of the day, your DevOps journey really is one that it starts with the first step of committing to continuous improvement. And I'm not sure exactly where it ends because the business will always want faster release. They will always, they will start to consume the speed that you're able to give them. And the tools are an incredibly important part. They're enablers. The more the tools that you use can communicate and integrate together, the more seamless they come together, the lower the friction, the more you can reduce the friction and accelerate delivery. So it's an exciting time, frankly, and it's one that I have some time, I think, for questions. Dan is with us. He's been fielding questions as well as we're going. Dan, do we have any questions in the question that I could take? I actually have a question here for you, John. Okay, sorry. Someone wrote in and asked, what is the role of executives in a DevOps transformation? Great question. You know, I've spoken to executives. I think about this and I think that the role, I think executives are an incredibly important part of this. Executives, you know, while they may not be in the weeds and writing code and working on the details of how things happen, executives set the tone. You see, executives set the goals and the KPIs for an organization. And so if you imagine an executive who tells a CIO, who tells her VP of ops, I want no more outages. Okay, great. The VP of ops is going to execute on that KP on that goal. And they're going to implement a set of processes and practices to make it really, really hard to make changes, because they know that changes lead to outages. And so the CIO is in effect basically through that goal told the VP of ops, don't you dare, you know, make it easy to release or easy to deploy, because that might lead to outages. Unintended consequence of simple KPIs can often have a huge impact. So I think executives have to appreciate how the culture of DevOps is different, and how thinking in the end and distributing responsibility for having systems up can help people to work more efficiently and collaboratively. Yeah, I think executives are incredibly important. At HP, I worked with a CIO named Ralph Laura. And Ralph, I really love what Ralph said, he presented a DevOps Enterprise Summit 2015 and he said, my job is to provide the buoys for the team to follow, not the boundaries. And Ralph's idea was, you know, I need to give them general directions to what the goals are and where to go, but the exact path they take, they need to find their way. And it was about empowering teams to be successful. And I thought Ralph was his insight as a leader as to how to lead this I thought was spot on. Other questions? We have a question here. Where should teams get started on DevOps? Do you have any high level advice? That's a great question and I love that question because A, I get it a lot. I actually get a similar question. I had somebody else that asked me what's the best tool for DevOps and that separate question. And the answer to the number one tool you have to have for DevOps is the one on top of your shoulders. It's about how you think about changing the culture in the sense that you have to think first and not just start with, let's go buy tools. But where do you get started? And this is another very relevant. I had a conversation with Gary Grover who wrote a book about starting and scaling of DevOps and the enterprise. And I asked Gary exactly this question. I said, Gary, where do people get started? And Gary's answer is, and Gary's kind of a consultant at this role in this part of his life. He gave me a consultant's answer was it depends. And I tend to agree with Gary at some level is that it really depends on what's your scope of responsibility. If you're a development leader, if you're managing a team of developers or you're a developer, well, your scope of influence is you need to look at where can you influence. So that's one thing that it depends on. If you're a CIO, you've got influence across the whole life cycle. Then the answer is, and the answer for anyone really is look at your flow. Look at your pipeline, the flow of what it takes for the value stream, for what it takes for an idea to go through the development process to production. And then in the spirit of Lee manufacturing, in the spirit of thinking about, and in Kaiser, where is the biggest pain point bottleneck in your process? Is it testing? Is it test environments? Is it perhaps release management? In your scope and in your end-in process of what you can control, start to improve and remove those constraints. And that should be one of the guidelines as to where do you get started. Now, I think there's a couple of common patterns about how people get started. I think there's a pattern where people start to work on improving source control and improving their development processes with automated builds and automated testing. That's a common theme that we see people start there. We also see people, I've seen people start with, I'm going to work on releases and release automation. We have problems with all of our releases. We lose control of our environments. And Kurt Bittner, who used to be a forest generalist, I think he's now at the Scrum Alliance, his advice to some companies and to customers was start with production and work your way backwards. Start with making sure you can consistently deploy and make deploys to production and work your way backwards. So I think the answer, it's unsatisfying is that it does depend on the organization and it depends on who's trying to drive the change. It depends on where the pain points are. And the truth is, anywhere you start, you're going to end up touching the whole life cycle. And as soon as you start, I would argue you're doing DevOps because now you're focusing on improving your flow and improving your velocity. And that process of continuous improvement will just build on each other and will snowball over time. Thank you so much for answering that, John. And we have one here about tools. Focus on tools was listed as a reason for DevOps failure. Aren't you selling a tool? Yeah, I am. And I'm going to say this because I've been this person, but the term I use that I described myself in my past life was, I was a fool with the tool. I thought buying a tool would change the culture of my organization. And we bought and tried to implement a portfolio management tool in an organization that wasn't really ready. The cultural change, the people weren't ready to change. And so much as we wanted the tool to drive the change, at the end of the day, the hard work of change management, of organizational change management, was work that our leaders weren't prepared to go as far into push as hard. And so from a mid-level, we tried to push a change in the organization. The organization wasn't really ready for. And so the tool by itself does not get you, will not necessarily get you the results. And only a few isolated situations will buying a tool just magically solve a problem. Ultimately, it's how you use and how you deploy and use a tool will drive the results. There's a great example of there was a blog post that James Shore wrote 12 years ago, 15 years ago. He described how to do, the blog post you can Google and we can put a link in. But the post was how to do continuous integration for a dollar a day. I think it was a dollar a day. And he described in that post how to use a rubber chicken and a bell for a team, to enable a team to do continuous integration. And the point is it wasn't about the tool, it was about the process. It was about how the developers use the chicken to determine who was building at a given point in time and how the bell was a signal for the other developers to realize that there was a new version on the build machine that they needed to go pull down and get an update of the code they're working on so they can continuously integrate. It's a great post and it's one I've used in the past. So it's not, the point is it's the people and process as much as it is the tool. And absolutely get labs, get labs, single application to address the entire life cycles is frankly pretty darn cool. But the tool alone won't do it for you. The tool alone can enable you. If you're committed to making the change and moving in that direction, tools can be a huge enabler and can help accelerate that journey though. So I would leave with that. I'm putting my vendor pitch hat on just for a moment. So speaking of people, we have a question here. How can you build trust between teams so that rather than having one team hassle the other for an output, they can trust that something will be delivered? Boy, that's a tough question. So part of building trust is being transparent. Part of building trust is showing up with the other team and being transparent about where your priorities are and what you're trying to achieve. And being transparent about how you're going to engage and work with others. I think one of the characteristics that helps to build trust is just just organizational transparency between the leaders of those teams and the people working on those teams. If you don't believe that they're doing what they're going to do or saying what if they say one thing and you don't think that's really who they are, what they're doing, that any words trust, that hurts trust. One of the ways I think that DevOps in general, the principles of what we're talking about when we look at DevOps helps to build trust is automation. Culture is part of DevOps. So as soon as we start to automate those things that are important, you start to trust the pipeline to tell you where things are at and when you have those issues between teams of dependencies on other teams. I would suggest one of the strategies is to ask yourself the question, is this something we could automate? Is this something we could work together to automate, whether it's performance testing or whether it's user acceptance testing or whether it's compliance with certain requirements from a documentation and auditability perspective or whether it's security. A lot of times the reason the trust isn't theirs because we've eroded it over time. But if we can build into our development lifecycle, those handoffs, we can start to trust the pipeline too. And so I think there's an element of automation that can actually help to build trust because then we focus on how do we document, how do we automate this to make it repeatable and how do we make it so that way as we learn together, we then improve what we've put into our pipeline, our automation improves to reflect our knowledge. I think about when I joined GitLab a couple months ago, I was updating one of our websites and I broke something, which is good, breaking things is good. But the output of the result of my mistake led to a new test that would now prevent me from making the same mistake again. And so it's about trusting the pipeline too. And we have a question here. It says, I understand that culture is important to start with DevOps. How about the next step to technically collaborating as a team with a focus to achieve a solution? Yeah, it's circular, frankly. I mean, it really is. It's a circular journey in which the culture of sharing and collaboration works together to build trust and to focus. And when you start to think about this, I've seen this in a couple of situations, and I know Gary does this when he runs workshops. And I saw it when we adopted DevOps at HP. We brought together all of the leaders, all of the stakeholders into one room and they kicked off the whole journey around the summit. And they established some common definitions and common goals and they started to put into place what they called at the time. And if anybody wants it, I can find it or I can get it. I know people have it. They created their own DevOps manifesto of the principles that defined DevOps for them. And you can have an opinion about whether the word manifesto might be overkill, but it was a set of working principles that they collectively agreed to sign up to and how they were going to work together. And that was a way that they won built culture, but it quickly led them to how do they start to collaborate technically to work together as a team to deliver software, to deliver value. And as I see this, it's an iterative cycle. Gary likes to work. His customers, when Gary Gruber does his work, he likes to get them into a one month rhythm of one month, we're going to improve something. What are we going to improve this month? And it becomes a cadence of every single month. They're working on improving how they deliver while also working on delivery. And so I can't recommend Gary's book strongly enough. I think he offers great insight as to how to do it practically. It's not a technical book. It's a practical leadership book. And so if anybody would like that, I can either tweet at me or ping me somehow. Ping me. I didn't put my contact info in here. I probably should have. But ping it. Contact us and let us know. I'll be glad to connect anybody with Gary, or figure out how to get you inside to Gary, into what Gary does. So speaking of practical tips, we have a question. When working in a waterfall style organization, what kind of conversations are good starters to help executives see the change you want to introduce? Tough question. I think the conversation with executives. So here's, gosh, it was a quote. And I'm going to say the quote. I'll get the guy's title wrong. I just don't have it in front of me. But this is the chairman of the World Bank in Geneva, the World Bank Economic Forum. And he said it about three years ago. He said, the world is no longer a world in which the big fish eat the small fish. It's now a world where the fast fish will be eating the slow fish. And you know what, if you're in an organization and the mode of development being waterfall oriented, and you know what, waterfall works. If you know all of your requirements, and if you know exactly what it is you're going to build and nothing is changing, you know, it's a stable, static environment. If I'm building a bridge, building a house, waterfall is pretty good. I mean, the laws of physics don't change. Concrete doesn't change. Things are pretty set. If my world is what is one in which my environment is one in which that's what it is, then you know, maybe that's good enough. And maybe there isn't pressure in the industry to go faster. Maybe there isn't the driver to do this. Although I would argue from an executive perspective, and I have argued this, that every single industry, Mark Andreessen's quote from 2011, I think, that software is eating the world is spot on. You know, taxi companies aren't software companies. Tell that to Uber. Hotels have nothing to do with software. Tell that to Airbnb. And I would argue that every single company has a component that's digital and has a component that defines how they relate either with their customers or if you're a government agency, your citizens, or if you're just B2B, your partners. It's digital. We establish and maintain relationships and we deliver value through a digital relationship often first and often and sometimes only. And so from my conversation with the executive, it's going to be, where is your disruption because it's out there? Somewhere in a garage. There is someone in Kiev in a garage preventing a new solution or looking at a problem who says, I want to change this. If they're not in Kiev, they're in Johannesburg or they're in Silicon Valley. And they're thinking about how they could take the combination of ubiquitous computing on the cloud, whether it's AWS or GCP or Azure, if they can spin it up on the cloud in moments, they can deploy it to these supercomputers that are in our pocket that we call phones. And all of a sudden, your Home Depot, a hardware company, and now all of a sudden there's this disruption that emerges because someone has come up with a better way to get hardware supplies to their users. And so rather than going into Home Depot and wandering around the aisles looking for the right tool or the right hammer or the right nuts or bolts, I can get it on my phone. I mean, it's not out of the scope of imagination. And so my conversation with an executive would be to try to help them understand how, one, that disruption is coming. And that if your waterfall world has you releasing every quarter or every, you know, say you're going fast in your quarter doing a quarter of a release, ask them what would happen if there was a competitor that was forcing, you know, pushing new changes in innovation that was coming out every month. And before long, they're going to realize that if they can't move faster than their competition and they start to lose market share, they're going to have to change. And so that's one. I think the other part of it is an education for executives. A lot of times, and I went on this personal education myself and just to be transparent, I used to think this DevOps stuff was crazy thinking that we're going to automate all of this and we're going to have people pushing code to production that fast. It's crazy. That won't work. You know, I came from an ITIL background. I thought from ITIL and sort of a traditional waterfall background myself. But it was once I realized that the power of what we're doing here is based on the principles of lean manufacturing and the principles of continuous improvement and automating all of the things we do such that when I make a change, any change, it's going through tens of thousands of automated tests and security scans and checks and that everything is being validated to make sure that my change is not going to break something. And if it does, then it doesn't go. So what we achieve with DevOps is higher security, higher availability, better quality, lower risk. These are all the things executives want, but you got to get past the mindset that has led them to think that the barriers and the silos of the past somehow gave them better reliability or better availability. And I would frankly argue that the traditional way of putting in all the processes and the checks actually makes it harder to deliver with confidence. But that's a whole separate conversation. Thanks, John. I have a question about mindset. How do you help people shift their mindset from just thinking about something to taking real action to start the journey on actually building it? I kind of wonder where that question came from because I would suggest that you look at our handbook and our core values of iteration and get that one of the things we really, really embrace and I would suggest that we are probably at the forefront of doing this, which is iteration of what's the minimum viable change you can do to move forward and think about when you have the idea, the mindset of I want to go in this direction, what's the smallest change? What's the smallest valuable step you can take in that direction without having to have the whole answer? And I think the opportunity for people to think differently is to look at if I want to change... I'll use an example that's relevant for me right now is I've been working on trying to define and articulate kind of a maturity model or maturity framework for how people adopt DevOps and it serves a couple of reasons and so I've discovered a model Ticketmaster build which I think is brilliant and so I'm applying this idea of minimum change what's the smallest change I can do to refer to or to reference or to start to do that and so I'm in my head building out what are the steps I need to take to either build consensus or to make changes that help us to go in that direction and so there's a couple of sides to it one side of it is I think you have to at least communicate and build consensus and get there's a collaboration part of it before I take action I like to at least make sure we've thought it through and I understand other issues and pitfalls and have we done this before but once you've done some of that then let's start going and it's small changes and it's about the power of small changes on our organization that you don't have to have you don't have to boil the ocean you don't have to know what the full DevOps lifecycle is going to look like in order to take one step and automate and either look at how do I start to automate testing more to do testing more consistently and effectively one step how do I do builds more consistently one step is what it takes to start that and you don't try to solve world hunger it's one bite at a time I like that you solve world hunger one bite at a time and really the case here is you got to take one bite at a time and how you're going to do this and be open to be open to the reality that where you thought you were going when you started your journey maybe you may end up somewhere different because you get 10 or 15 steps into this journey and you realize that there's a better alternative than what you thought you were doing at the beginning so you have to be open to that evolution as well but by taking small steps you're moving further along the journey and that's the key it's to get moving don't get stuck talking about it start doing it thank you so much John we have one last question here how do I know when I'm done with the DevOps transformation well that's actually I think an easy question because I don't think you ever are done so you know you're done you know you're done when the business says to you they call you up on the phone and say you know what don't go any faster this is fast enough when the business calls up and says you know what you're delivering is super fine value we don't need any better there's no competition where we don't need it anymore and I think that will never happen I've never known if you want to talk about unicorns the unicorn I've never seen is a business leader who said I love our IT shop they're great they deliver on time and they're efficient and fast that's the unicorn that doesn't exist out there at the end of the day the business leaders that I've worked with demand demand that IT go faster that IT deliver faster solutions and are more responsive to their needs they've all been frustrated with the long Gantt charts and the delays that's going to take the ship stuff and the fact that they don't get what they want so I believe you're never going to reach that point where the business is going to look at you across the table and say thank you I think you guys are awesome you don't need to go any faster I believe that as soon as you give them a taste of faster they will want more they don't know it today but as soon as you give them a taste of what it's like to be able to get an idea out of their head and into production in three months say you're at six months today you're doing it every six months which I don't think many people are but let's say you are and you get them to three months they'll consume that and then they'll want you to go in two months or one and they will be they're going to need it because the market is incredibly fast and the competition is fierce so you're never done, simple answer you're never going to be really done it's continuous improvement and the spirit of Kaizen is really what it's all about it's about improving and going faster and delivering higher quality and delivering more value that's what this is all about this is exciting times thank you all for joining us we hope you feel ready to adopt a DevOps model if you'd like to learn more please visit about.gitlab.com we hope that you'll join us for the third part in our series in which we explore ways to use CICD to remove barriers between development and operations teams thank you again we hope you have a nice rest of your week bye