 I want to talk about something slightly different I want to talk about what does it take to to really establish a DevOps culture in a large Organization and much of those that is based on my experience at a large insurance company and we titled this you know Intention a little bit controversially right if you think you adopting DevOps then you're probably already heading already heading the wrong direction I'll show you why I believe that is the case in large organizations So the first thing when companies talk about DevOps the key driver They generally half is their IT is too expensive and too slow. They want to speed things up Additionally, you know when you ask a project manager to speed things up They pull out this is your project management 101 the first lesson you get right the project management triangle So what this means is you have a certain scope of work You have a set of available resources and therefore the work takes a certain amount of time You're trying to stack up a thousand bricks into a wall It takes a whole day if you have one person if you have two people it takes half a day And then most dangerously in dangerously in the middle is this quality thing, right? And that makes you believe that if you do a poor job, right? You can do it in two or three hours as opposed to half a day Now I have stood up in front of a room of About 20 or 30 senior executives and I ask them Do you know do you have IT managers who use this model and I like about like 10 15 hands went up and I said fire them And I said, okay. Well not really, right? But have a serious talk with them because if somebody manages software projects like this They haven't a fundamentally haven't understood how software delivery works Software delivery has very different levels. So money to get the same has very different levels And those levels are the following three The biggest reasons software delivery is slow because there's too much friction in the system and friction is a dangerous thing It's like I would say it's like an engine that is running, but the bearings are tight somehow There's no oil in the engine right somehow you put a lot of energy in but not as much comes out And the worst part about it is if you put more energy in usually the friction also goes up Right if you step on the gas you get more resistance until ultimately the whole thing overheats and breaks Now the catch with that is this friction is usually not visible right as some hair Somehow things are not spinning freely and the same is true in software So friction is waiting for a server to be provisioned right that's friction Somebody sitting there waiting two weeks waiting for your development environment to be set up waiting for your bill to be done But it's also ordering equipment or chairs or pencils for your team Or it can also be getting an approval waiting for a steering committee waiting for somebody to make a decision Right all that is friction right and you can easily see that getting that out of the game Is really going to speed up your delivery because that's one of the biggest inhibitors The second biggest lever you have is inventory now in software We don't think so much about having inventory right because inventory is usually stuff that piles up right inventory is a very bad thing Inventory is something that has incurred the cost something that has been manufactured But that hasn't been sold yet and to make it worse there's the notion of unfinished inventory That is also something that has incurred the cost, but it can't be sold because some piece is missing Right it's like a lot full of cars that don't have an ignition key right that is the worst case Right and obviously nobody's happy about having produced something having spent the money and not having the return on it Now in software. We think we don't have this problem What we do any software that is not in production is inventory right we have a source repository full of source code That is inventory unless it's in production unless it's in the customer's hands and you can easily do the math The company I work for we had a very large system We released about every six months so you can say like you know 200 working days in a year roughly roughly So it's a hundred working days hundred people on the project. So it's 10,000 persons Software inventory because it's not released and this was in Europe So make the math easy you say it's about a thousand euros a day day rate for the contractors is a boom 10 million euros Inventory sitting there right cost incurred money spent nothing gotten out of it, right? So that you need to reduce Because that is just money that's essentially wasted or at least temporarily wasted because it's just sitting there not doing anything The next part about inventory the next danger about inventory is that inventory lots, right? These cars that sit on the lot next week. They're still worth as much as this week That's fine, but a few months down the road when the new model year comes They don't they're not worth as much anymore, right? The inventory decreases in value It's not like you could buffer as much inventory as you want It's gonna rot and software does the same thing because people will forget what they did right? They have to look at it again software lots just as much so getting inventory down is your second second biggest lever The third one seems also obvious But it's also a giant one that's in my opinion not nearly used as much and that is don't do stuff That is not needed Right or rather we should say don't do things that don't provide value for the business Right easier said than done because often you have a business user says oh this is really important Or the existing system does it this way, right? So you are kind of bound by the need as I own all this is really critical And then you build it and you find out nobody actually uses it right? It provides no value just somebody thought it was going to be important useful Now those are the three levers right not the project management triangle those are the three things if you want to speed up software those are the three things you need to do and Interestingly if you translate this into the buzzwords those are really the three major shifts in software delivery That we have right reducing friction that is really what DevOps is all about Reducing inventory right this is all from Toyota and Japanese car companies in the 50s and 60s Right that is the lean story the funny part there is we always feel like we it people We sort of smarter and faster than anybody else We always feel we invent everything quicker in this case. We're half a century behind essentially right so they learned this in the 60s Now we are like all lean fantastic right finally finally We saw the light and the main reason is because our inventory is less visible And that's why it took us longer to understand this but economics exactly the same and the last one That's the essence of agile You know agile teaches you to build things of value agile teaches you to maximize the value Delivering and not to deliver stuff that doesn't have any value So in a sense right we throw these buzzwords around a lot in the end It's simple economics right this is all about getting the most out of software delivery This is not like all the developers want to have chaos and freedom and not write Documentation all this kind of stuff that people stick on these methods right that's that's all bogus right It's really about simple economics right get the friction out get the inventory out and only build stuff That provides value that way you get the most out of every development dollar you spend it's very logical And that's where these methods come from there's no magic behind it and Correspondingly that's my favorite definition of DevOps right is out of Len Bass's book a Lot of people say oh DevOps is about making deaf and ops work together And then other people say oh DevOps is like chef and puppet and salt etc Right those are all like little pieces of it. This is what DevOps is all about It's a set of practices And I would even say a set of practices and tools probably that minimize the time right between a change And it going into a production with high quality right not an emergency patch, but a regular release And that's why I like this definition because that is the driver Now one of the biggest Misconceptions people have is that these agile methods and some of these other methods are less disciplined Right like oh, it's the it's the revenge of the cowboy coders right all the agile We cannot do whatever we want right and I've heard this so many times in an organization You ask somebody when is the meeting? Oh, we don't know yet because we agile That's like yeah I want to strangle those people right because they really abuse you know the term agile is a more Discipline way of working because it's very easy if you try to go fast And you don't have discipline that is the best recipe for chaos the example I often give is an F1 pit stop right about the fastest manual process You can imagine is formula one the car comes in for pit stop in four seconds The car has four new tires that wipe the windshield and in the old days They even put fuel in the car in four seconds right now. Is that the most disciplined process on earth? Yes, absolutely. They practice this a thousand times everybody knows exactly what they're gonna do. There's no unknowns It's like the perfect execution So that's a great example if you want to be quick you want to be disciplined because at the pit stop people don't start debating Who changes which tire and whether it really needs to be changed right and this is true in agile in these methods And there's a nice analogy for my my friend here is like Usain Bolt right aside who who broke all the records for for Sprinting right the one thing is you know don't make a single mistake, right? You got to be basically say one suboptimal move ruins your game So you got to really run very very disciplined, but you also have to have confidence Right, so you can see the nice picture with the one guy's like oh, I'm gonna win right and the other guy just kind of It just goes past him right and That's very important because the discipline gives you the confidence the example I use is how do you measure test coverage a lot of people say oh you should have 80% 85 75 Yeah, whatever people start talking about the numbers So I say this is not the purpose of unit testing right the purpose of unit testing is to give you confidence Because if you don't have confidence if you hesitate you will never be fast Right if the end F1 pit car comes in and you're like not sure your your screwdriver works the thing To unmount the wheel or whether the screw is really tight that there's not gonna be four seconds Right, it's gonna be four minutes because you're like I'm not sure right if you're not confident you're not gonna move you're gonna hesitate So what is the main purpose of unit test coverage? The main purpose of unit test coverage is to give you confidence right the way you measure this you go to a team and you say Great I'm gonna you're gonna look the other way for a few minutes I'm gonna go in your source code and I'm randomly gonna delete Ten lines of code or make some random changes. I change a one to a two a two to zero I take this line out. I invert this if statement, right? I just you know monkey your code up a tiny bit don't worry version control right and then if your build stays green We push this straight into production Right that is the test whether you have correct unit test coverage, right because if the team goes Oh my god, right and they all start looking for a new job, right? Then you know their test coverage is insufficient if they say be my guest Then you know the test coverage is sufficient, right? And that is the purpose to give you the confidence and together the discipline and the confidence right discipline means no check-ins on red Right disciplines means, you know, everybody uses version control discipline can also be minimize branching put everything on trunk Right that is all discipline combined with the confidence in your toolchain that actually you know if something is wrong with your code You find out early that's what makes you fast and this is what the driver behind this whole story So sounds really good now putting this into the large enterprise can make you feel like this guy This is donkey or to chasing the windmills, right and these are the corporate windmills So as great as these ideas are getting this to work in a large organization isn't as easy as it should be The first problem is in a traditional organization. They often change Operations from development, right? It's the classic change versus run. They call that why I work I was like, what is that right? So changes application development and run this operations Now, of course, you can easily see how this is a bad thing because the idea is here that run doesn't make any changes So how can you do you get in a continuous integration delivery mode if operational software is not supposed to change, right? Something something is broken here because in a digital world what you actually like to do You like to put things into production as quickly as possible. It's otherwise is inventory And you like to learn what people do with it You like to improve you put it in production so you can make meaningful changes Right the traditional enterprise puts things into production and they think they are done, right? So in the new world and the digital world Software starts when things put a production, right because anything before that is just like warm-up, right? The software delivery really starts once the first thing is in production in the traditional model They believe the project ends when something goes into production is completely the opposite and that makes this difficult Now what this also leads to is that generally the development team and the operations team They have a little bit of a strained relationship with each other, right? So the developers of course we feel like we're the king makers, right developers We like yeah at least as cool as neo we can hack everything we can make everything work And basically the operations of the bunch of old farts who just haven't kept up with technology, right? So this is kind of the common view, right? And of course the opposite view is also true operations It's like the guardians of the universe, right because these developers they just break everything all the time And if it wasn't for us operations people, right? This whole thing would be like a kindergarten, right? It would be like you know all these little kids just messing everything up So you can see that it is gonna be a little bit of an uneasy Relationship between the two two teams and of course that is gonna generate friction, right? This is not gonna get friction out of the system This puts friction into the system because the operations people say whoa whoa whoa with your software release, right? This is a bunch bunch of you know stuff full of bugs you guys have there Let me go to my 27 step release process for this to go into operations, right? And that's where a lot of the friction comes from and what this leads to right in operations One of the most popular slogans you will hear is never touch a running system, right? Everybody's heard that slogan now why down there touch a running system because they equate you know if you touch it They think you break it. So they equate change to risk And I had this discussion I work a lot with financial services companies and they say oh We are risk averse company and I say so should you be right? You don't want to have a risky bank, right? You don't want to have a bank where the CEO goes gambling every weekend, right? This is sort of right. So yes, you are financial services institution So obviously you should be risk averse because you're keeping my money and I want it back, right? but Risk averse doesn't mean change averse, right? They have this belief baked in that two different things But this little slogan never touch a running system So that really personifies their belief that every change is a risk and in order for them to bring the risk down Because rightly so the risk averse in order to bring this down They believe they have to minimize the change and you can also see you can say like oh, this is not right But you can also see how hard that is to change, right because in their view They're doing absolutely the right thing, right? We are a bank the risk averse touching stuff breaks things So therefore changes risk so the logical conclusion is minimize the change, right? It's 100% logical So it's very difficult to argue against this right because you say oh, let's just change stuff left and right They're gonna go home. Oh, no, no, no, right? So you need to convince people that you have different mechanisms at play There is a reason you can reduce the risk of change and a lot of the DevOps and all the other methods we use recently Their main purpose is to reduce and minimize the risk of change And this is where a lot of you know Google your SRE the side reliability engineering a lot of it comes from that perspective Right fully automated operations because once things are fully automated It's much easier to do and undo things. You don't have human error, right? It's all these key can make smaller releases. You can do green blue deployments, right? This enables all the mechanisms that minimize the risk of change as opposed to just Minimizing the change But you have to acknowledge that this is a big shift in mindset, right? And as I said, it's not because the people don't know you're not teaching them something new in a sense You have to unteach them in existing belief, right? Because they are in their view Being fully rational, right? We've seen this a thousand times people made a change. It broke So therefore we don't make as many changes. They have proof for their belief, right? And they are fully rational so changing that is hard, right? And that's why I saying just adopting DevOps in a large organization is unlikely to work You need to really understand how people think and you need to demonstrate What has fundamentally changed so you can use different mechanisms that still fulfill the goal of being risk averse Right? Nobody argues with that So here's to make this even more clear here's The challenge you up against in a culture that has high friction Doing anything is difficult, right? And difficult means time investor time investor means money spent, right? So it's high invests. We are doing anything, right? Doing anything will lead to a high invest Now if there's a high invest, right? There's a lot at stake if you want to try a new product and this new product costs 10 million dollars US dollars Right? People will be very careful, right? Because a lot of money going around, right? Of course, what they will do is they will say let's check Everything very carefully to make sure these 10 million dollars are wisely spent, right? Quality control project reviews steaming of you approval approval approval review quality gate, right? They will have a lot of controls in there because there's a lot of money at stake, right? And of course unfortunately what this does you can see this right here, right? The more control spring more friction, right? Because now instead of writing software you're preparing for the steering meeting You're filing the weekly status report. You're doing the quarterly budget approval process, right? So you actually increase the cost because you increase the friction and that is a very dangerous cycle, right? It keeps sort of spinning this way No now in order to change that you need to stop you need to stop it from spinning the wrong direction and Then you can get it to spin the right direction. So it's quite a bit of effort involved there It's not about all I have you know Jenkins and puppet You know now I'm deaf ops that is not gonna do the trick What do you want you want to take the friction out of the system because once you do that? It's much easier and therefore cheaper to do things So now this new product you're trying to launch maybe that costs you ten thousand US dollars Not a trivial amount of money, but for company a lot better than ten million or one million, right? They're like, okay ten thousand dollars. Go ahead, right? There's less at stake. You will get support. They're like, oh go ahead Let me know how this goes Google is very much like this and sometimes people believe it's because oh we have so much money or we kind of loosey-goosey No, that's not the reason we can we can have this nice cycle the cycle is we try small things We make small iterations. We have low friction. So when somebody says go give it a try They're not gonna spend ten million dollars on this right they're gonna spend ten thousand or maybe fifty thousand, right? So that's why the organization can be an enabling organization because the friction is low the cycles are short And therefore you can try things very very quickly and cheaply and you can learn very quickly That's why Google can do that So just throwing money at the problem is not the solution you need to get the friction out and you need to get into an Enablement cycle without and and killing the disablement cycle, right? But again this shows you how hard it is to get this turning one way or the other because the existing system is self-supporting Right the existing system self perpetuates in a negative way, right? So you need to stop it first and then get it going the other way, right? And that's why Introducing dev ops is is quite a you know, not as trivial task So what the large organizations often do and this is the biggest anti pattern You know James Lewis yesterday was joking if you have a dev ops team You're already a little bit in trouble. I think you're even more trouble if you have the head of dev ops, right? Because you know what is this person gonna do and if you guys don't know the space See this is like Lomborg from the office space, right? It's the ultimate sort of silly manager I need you to fill out this status report basically, right? This is what you get in these large organizations Oh, I picked up this buzzwords and now I need you to speed up my software delivery because of this dev ops thing I heard about right? So this is what large organizations tend to do and I've seen this I have seen the heads of dev ops who couldn't code a line of code, right? So it's like totally no technical, right? But somehow they were gonna do this dev ops thing. Of course, it's an absolute joke doesn't work, right? oops, whatever So what does work, right? How do you get this this efficient way of doing things? I said much of this is inspired by the automotive industry. How do you get this into the enterprise? So the first thing you need to fix this change story. I talked about right a traditional enterprise is geared towards Change is abnormal, right? They think change is risk. So they don't like change. That's why they work in projects We said change versus run, right? Run is continuous, but doesn't like change and change is projects And these projects are very tightly packaged into a budget, right? There's a project budget the project starts and everybody's kind of happy when the project ends, right? Because to be blunt that for them is the unusual state, right? That's the one. They're not so comfortable with And that's you know because change breaks things that has to be abandoned, right? And a lot of people have the slogan projects versus products, right? I always say at Google here when does a project end, right? Like when does Gmail end? I don't know. Hopefully never, right? Google Wave did end, right? Our projects end when the product is dead in the market, right? Otherwise it keeps going you keep improving, right? There isn't a project with a beginning and an end for a digital product as soon in the digital world as soon as you Stop making improvements you essentially killing your product, right? Because the world is moving if you no longer moving you're moving backwards and nobody likes to work with a product That's moving backwards, right? So as soon as you let off the gas and a digital project or a digital product Basically you just sort of letting it come to a halt and it's gonna not survive in the market, right? Now people might say ooh, isn't that really expensive, right? I mean I'm spending so much money on my project already I can't run this project for like 10 years, right? How much money is this gonna cost? Of course, that's where the answer is you need to get the friction out of your system You don't do this with a hundred people you do this with ten people, right? And you do this on rapid feedback cycles You don't dream up features for the next ten years you build things you observe You see what works the three levers we had right to get the inventory out You get the friction out and you don't build stuff that doesn't have any value That's how you confront this if you try to do this with your traditional model Of course, you're gonna run out of money, right? You can't keep this hundred person project until infinity because probably half of these people are building stuff That's not needed you know another third is just building inventory which gets lost which gets launched like a month and months later And doesn't provide any any customer value. So this is a fundamental shift But this is ultimately critically important to get into this DevOps mindset if you stuck in this project You know model where the project ends you don't have DevOps, right? You don't have the mechanisms for that right another Important item to convince in the enterprise the folks who believe change this risk will think anything that brings more change We'll break more stuff. We talked about that. That's it's pretty deep So one thing you can start doing is you can show people that Cloud-based and DevOps based systems actually have higher system availability. It actually makes your software more reliable All right, again, the belief is exactly the other way. They think you know, you'll break more stuff But in reality you break less stuff and that is because you have automation your version control Right, you have speed and you have transparency in the infrastructure and you can lead that kind of conversation saying these things are the key Ingredients into a faster detection and recovery right Traditionally people worked on Maximizing the uptime the meantime between failure people bought high quality hardware They analyzed and studied everything so stuff doesn't break and that's a useful thing to do right is absolutely not wrong But then when something does break they were not well prepared for it So they don't have version control. They don't have good monitoring Everybody runs around like crazy Management wants a status update every five minutes right what the outages is going on So it takes them hours and hours and hours right versus you you have advanced monitoring your version control You can repush the previous state within a minute and you back up and running Right and I always say having a 30 second outage every day is a lot better than having a half day outage once a year Right, you can do the math on this very easily Right this comes out and especially the 30 second outage probably people don't even notice Right, they just hit sort of at five and the browser and they're back up and running So it's a very different model right is minimizing the time to recovery as opposed to just maximizing the time between failure So this is another angle you need to bring in in the large enterprise Now a lot of resistance against DevOps can come from the operations team. The same is for cloud adoption, right? I've worked for Google cloud so often the operations team saying like no no no all this cloud stuff is insecure unreliable We don't we don't want this here right and often it's not a very rational argument The argument is often just like well They kind of afraid that they lose their job right this cloud thing is you know supposed to it could be Replacing a large part of operations So obviously they're not very happy about it and the same thing happens with DevOps, right? I will say DevOps starts with death So, you know the operations folks feel like the developers that take it over and are gonna do their job Now I always say I don't like the no-obsterm so much because in the cloud operational considerations are actually much stronger than on traditional applications, right cloud stuff What does it have to do? It has to be globally load balance 24-7 you make updates without any downtime You can scale infinitely up and down anytime you have circuit breakers a circuit is measured skews distributed databases I mean the operational stuff you have on an internet scale application is a hundred times More complex and more demanding than riding an old monolith with some simple relational database So operational concerns are much more important now They're generally these operational concerns are at the higher level, right? It's not about it's my server up and running because that's why you have middleware failover Container orchestration Kubernetes you have all that stuff that deals with this But on the top you build a highly dynamic system and then highly dynamic system once we operate it Like an auto scaler right an auto scaler can go well But an auto scaler we've seen examples when auto scaler falsely scales the whole system down to zero has happened Right because of like bad feedback loops, right? So so you need to operate but you operate at a higher level, so I remind the operations folks There's more for you to do than ever as long as you're willing to change and learn some new things Right ops doesn't go away Just ops the way we used to do it in 10 years 10 years ago. Sorry that might go away Ops as overall doesn't go away. It's actually more important than other All right, it's not deaf replaces ups is deaf and ops working in a different model Right, so I think this is important to remind those folks because otherwise you will get strong resistance and strong resistance from the operations Team is never a good thing. Right suddenly the firewall change you need will take three months And you're not gonna put anything, you know, you will have three months of extra software inventory. Congratulations, right? It's not what you want so one key How do you say one key concept or mechanism in the SRE model is an error budget, right? So you say if you have a certain uptime target right at 99.95 is actually quite ambitious, right? It's like 22 minutes a month So basically but rather than saying don't touch anything and hope for the best people start using this budget smartly That's saying, you know, if everything runs very very well Maybe you can you know push a bit more stuff, right? You can evolve the platform more quickly You deliver more features more quickly maybe slightly increasing the risk But that comes out of your air budget So you're still gonna meet you SLA and vice versa when the error budget is exhausted Everybody works on operations. All right when the air budget is out if the stuff doesn't run as well as it should and you're You're just about to break your SLA You shift your resources away from new feature release into making this more stable So you finally get a very very nice feedback cycle Rather than the operations team having to deal with the outages and your development just keep on pushing stuff Here you shift your emphasis based on where you are with your uptime But the most important thing here is to create a feedback cycle When I was at Alianz one of the proudest statements are kept on making was my architects are on call That was true. We did operations on the architecture team And I always told people that is the feedback cycle, right when we draw a PowerPoint picture It's not somebody else's problem if it doesn't run It's our problem because we are on call for our platform and that is one of the the key you build it You run it one of those key SRE SRE mindsets Does we say feedback toil, you know Dealing you know being up at night dealing with facility outages toil is a very effective form of feedback for developers Nobody likes to do that, right? So if there's a lot of toil a lot of waste in this people will go and fix it All right, as long as the pain hits them if the pain hits somebody else It's easy to say, you know, we'll fix it in the next release, right? And the key thing here and I said the operations is equally important And I'm not so sure actually a hundred percent like the slogan of the king makers for the developers because it kind of Pitches a little bit the developers versus operations But what I do like is that I would say the development mindset is Something that permeates to the whole organization, right? And this is what SRE did right SRE brought the development mindset to the operations part Looking at the business context, right? And where sort of these things are coming for the new king makers is if it is the differentiator for your business Then the developers are the ones who deliver the software and if that is the key differentiator for your business The developers are some of the most important people That's that's what they mean by the king makers and I would say that part is true Do you need to be careful? This is not about pitching death versus ups This is saying for the business side of things if software delivery is what drives your business Then the people who make that software are very very important people and you should make sure they're happy All right, this is not something you outsource somewhere and make a five-year fixed-cost contract, right? This becomes a core competency. This is something you want to have in-house You want to hire good people and you want to treat them well? One thing that people often ask about also what about the architects in this DevOps thing, right? Because it's deaf and ops whereas architecture. Here's a nice slogan from Martin Fowler and Eric Dönemberg where they said well You know the stuff that the architects usually have done We can do this as easily by the developers by the tools or not at all and as a former chief architect I actually agree with this statement. Oops Because of the word traditionally Right what have architects done traditionally draw glass diagrams tell people how many characters a line of code has right Say what percentage test coverage you should have right those are the things architects used to do and that is no longer What the architects should be doing the architects now should be working on getting the software delivery flow functioning, right? They should make sure that the software bill has value is aligned with the business strategy Make sure you take the friction out of the system that is exactly what what the architects should be doing no longer like drawing class diagrams So as we'll see is that the DevOps story is a lot more than You know just now doing deaf and ops and having chef and puppet or Ansible or some sort of automated deployment Really, it's about transforming it right. It seems like a small change But it is actually a big change in people's heads right because they learn to do it a certain way for like 20 years Right and now you're changing the way in as I said, it's not just learning something new It's people have to unlearn the way it has to be done But there's many frameworks that sort of raise your awareness I wouldn't say I don't believe there's a framework that is a recipe for transformation and change It's not that easy, but there are frameworks that sort of help you think about and understand what is needed You know and here's sort of a classic one. This is here from Cotter. I think right so you're famous You know marketing organizational management people and they say Really the way change starts with a sense of urgency, right? And then once you have the sense of urgency you can build this guiding coalition, right? You can have a vision. Hey people we're gonna go here We're gonna release software 10 times a day and our customers will be happy and we make constant improvement, right? Then you need to get some volunteers, right? You need some people to help you not everybody will but some volunteers will and then you get this going Interesting relationship to this at Allianz. We actually got quite far And we built the private cloud platform and really changed the way they delivered software, right? From approval cycles over months and months and months into fully automated sort of Jenkins Farms CI CD Cloud Foundry pass here everything right is just like push software through and we were actually quite successful Until we hit this acceleration so the scaling through the organization So we found a lot of volunteers everybody loved it We removed a lot of barriers We had a lot of short-term wins and then it was hard to scale this through the organization, right? The early adopters were happy many people call this the chasm Right is like sort of the chasm between the early adopters and the late adopters and we had a very difficult time crossing that chasm And looking back what I believe the key hurdle was we didn't have the sense of urgency So we got ahead of ourselves successfully very successfully We covered all these but because we didn't have the basis in the organization We didn't have that base of a sense of urgency Ultimately this came to a stop, right? There were a few people who felt the sense of urgency and really valued the rapids of the delivery and the whole DevOps model And there was many other people who was like oh every quarter we have record profit every year my bonus gets better You know why should I worry so much about this and that really inhibited the The scale the scope of the change that we could do right So so the models don't give you a recipe for success, but they give you a good checklist to not forget about items Because this will catch up with you. This will catch up with you ultimately Now when you try to bring change into an organization, there's a few different models you can you can do right Normally if you want to change the way people work You send somebody there to tell them right? So the green is like the new in this way, right? You send somebody to work with the gray guys and the green person is going to show the gray people how the green way You know the DevOps way of of working actually functions I call this a missionary, right? You send somebody off right and they teach them sort of a new great way of doing things A friend of mine actually and any of this sounds like a noble thing to do Right as you go somewhere you teach people how this thing works It is not nearly as easy as it looks and a friend of mine said this in a very nice way He said many early missionaries Turned into food Right when they went somewhere to teach people a new way of doing things they were eaten basically by the cannibals, right? So being being a missionary can be a very difficult job Especially in the organization where the management structure is still the old one You might find support from the team But because these gray folks here they still report to a manager to their manager to their manager Their bonus plan the incentive systems their status reports their budget approvals that is all still the old way So getting this to change is extremely hard, right? Sounds like a noble thing to do in reality not easy to do So one thing you can do return this around so rather than sending somebody over you invite them in And in alliance we did this quite a bit. We call this the boot camp Well, I think my remote control. Oh, there we go. My remote control is a week. So it's a boot camp So this is me at work, right? Yeah, I'm a nice guy at conferences at work. I'm really tough Right as I cover people boot camp, right? Yeah, and that has the advantage That when people come into the boot camp The new way of working is the new normal. There's no arguing, right? You're falling into an environment where it's just different, right is sink or swim or rather swim or sink. Hopefully, right? So you should be swimming, right? So that has a big advantage Now, of course the part of the boot camp is the boot camp lasts a certain amount of time And then you send the people back into the organization at that point two things can happen, right? Either they become missionaries, which you know some of the same challenges Or you can cycle enough people through the boot camp that little after little you can convert the whole team The other thing that worked in this case unintentionally well for our team Was that a lot of folks who came for the boot camp didn't want to go back So it was a good recruiting mechanism for our team They just stayed because our boot camp wasn't that bad actually was quite a lot of fun Our boot camp, right? So they didn't want to go back So it was great for recruiting for our team But it wasn't as great for transforming the organization, right? Because they didn't go back And after I discussed with a few more folks around it We realized that there's another model that seems much harsher But that actually works relatively well if you can do it You pull the people out little by little in this boot camp, but you never send them back You basically rebuilding the function that they used to do in a new environment So basically you're replacing the old team With the new team, but largely with the same people, right? You take them out one by one You get them to work in the new environment But with a new environment, they're basically replacing the job that the old team did Right seems like a pretty hard thing to do But you do it with the same people And therefore you're not, you know, getting rid of people You teach the people a better way of doing and rather than sending them back into the existing management structure You keep them in the new management structure And we call this the Shanghai, right? Where people sort of get pulled on the boat, right? And sailed off It's a friendly version of Shanghai As always there's a catch, the catch here is in order to make this successful You need some strong captains, right? You need some people who can pull the folks on board and work with them and not just teach them the new way of working But actually do the new way of working, right? You are going to be the new team So you need to deliver so you need some strong captains The other thing is in this environment, the real losers are the management that used to manage the old team, right? Because ultimately you hollow out the team You move people little by little under a new structure and the old manager at some point doesn't have a lot of people anymore Right and that is the tough part that can bring some friction But that is also a strong message, right? If these managers learn the new way of working That's great. They can be a captain on the new ship But if they don't the team will be gone at some point and they have nothing more to do All right So in the end not one is guaranteed to be successful But overall it's good to have this repertoire of change models in the end We did a little bit of both, right? We did this in the beginning Then we did a lot of bootcamp and in the end we sort of Crank this up a little bit and we actually did much more Shanghai Where the new team would ultimately replace the existing team with many folks Including many folks at our ops, right? They were all there. They just worked in a in a new environment Now none of this Works if you can't bring some new talent in, right? What's very important to me is that if an organization has a hard time working in a new way It's usually the system's fault. Not the people's fault, right? So generally the people can be taught a new way of working especially in this bootcamp Shanghai model But you need to have some people to teach them Right, so I was joking, you know last night at dinner. I think we one problem We had when we worked in an organization. We had all these people who were in charge in charge of transformation But they never seen the target picture, right? They've never seen a digital company or company that really has a deaf ops way of working They've never seen it, right? So I was joking last night This is as as me taking a job as a tour guide in Zimbabwe I've never been there. I will read some books look at some maps, right? I'm sure I can tell people some things to go see But I can't be a decent tour guide because I've never ever been there So you need some people who have been there and you can do this to some extent with external consultants But it's much better if you bring the people on board So that's where recruiting talent is extremely important And of course there's always two aspects to having the right people The one is bring good people in and the second one is don't lose good people Because if your culture isn't isn't adjusted and now you're teaching people I mean, I did this at Alliance, right? You're teaching them, you know, like Cloud Foundry, OpenShift, Docker, Kubernetes Ansible automation deaf ops, their market value just goes through the roof, right? Like suddenly, you know, rather than being an insurance, you know, cobalt developer, right? Now they're the hottest item on the market So you really need to make sure they're happy because otherwise, you know You do a fantastic transformation for somebody else, right? Because they're gonna go so so that is not what you want So you need to make sure they're happy now The interesting thing is big companies often feel that they can't offer what a google can offer, right? Everybody wants to work for a google or facebook. What can I offer as a startup company? What can I offer in the end? I've we found actually that you could offer quite a bit, right? And that large organization is very international very multicultural you can go international assignments, right? Alianza is a hundred and forty five thousand people all around the planet You can go work in Singapore. You can work in France. You can work in Germany It's a very complex and fun business business domain. It's actually interesting business Also, you get to work with some Incredibly talented people, right like the board of alianza. These are people running 125 billion euro company They are heavy-duty, right? I mean these are world-class business leaders So working in a company like that, right and learning from those folks There's a lot to offer right often the organization stands in its own way of delivering these benefits to the engineers That's the problem. It's not like they can't offer something compelling It's often they don't because you know, they're kind of you know sort of paralyzed internally with hr rules But I believe as a large company you have a lot to offer There's a lot of people smart people complex business domains, right? International, right? There's a lot of things big companies have that a company of three people cannot Right. It's also many things the other way around But it's not as easy to say oh everybody wants to work for a little startup company And it's hard to compete with as a large company, right? So here's the things you can do right offer people a technical career path, right at google You can become a senior vice president as a programmer, right? No reports individual contributor. No problem at all, right HR will stand in your way, but there's no reason in a large company. You cannot do this, right? Why not, right? There's no no law book that says developers, you know, can't be very very senior in in the organization You know provide training provide people the right kind of tools, right? Take some same take some frictions out Make sure managers are not micro managers But managers are mostly there to get blockers out of the way, right? And if the managers are busy getting blockers out of the way They also very much don't have time to do micro management, right and then There's a reason salary is last because you know money is important But money doesn't fix any problems, right if you have a fundamental problem in the organization paying people more Will make it worse because in the end you will get the people who only do it for the money And the people who actually want to do good things go somewhere else, right? Like you you want to be fair and compensate people fairly But you don't want to try to fix problems with money. You cannot buy Your way to a transformation, right? You need to do this through the culture. You cannot do this with money That is a it's a very important very important lesson, right? So in the end what's what's very clear here is that this whole defops story is just one part of a larger Transformation, right people think like oh, let's do some defops Let's why say just adopting defops won't work, right? If you want to get into more defops style of working You need to really consider this is really a transformation, right and transformations are Difficult, right the interesting that challenging that can be fun. They can be extremely valuable for an organization They can actually be the only thing that That base in the end makes the survival of the organization, right transformation can be the thing that saves the business But they aren't easy right the one thing they're not is easy and they're not short term either Right, so you need to be prepared to put a lot of energy in and you need to be prepared to to do this for for the long run Right, so really, you know a defops adoption doesn't work It's really a defops transformation The same thing is putting all the new tools in doesn't do anything You need to change the mindset for people to actually use the tools, right? And always talking about the shiny object the pie in the sky Oh, we're going to be like google facebook whatever that doesn't do anything Actually do something that moves you in the right direction, right? Making a small step is much better than talking about oh next year We're going to fly on vacation whatever it never happens, right leave in the house and walking 100 meters It's worth a lot more than talking about where you could be going someday that you actually never do For sure a lot of large companies fall into this trap So you can see the difference right a lot of companies do the things on the left hand side because it's easy It's easy to talk about the pie in the sky It's easy to buy some tools and it's easy to say oh we're going to adopt defops, right? Everything is going to be great, right in the end that doesn't work So doing something easy that doesn't work as a pretty useless task to do right You want to do something that actually achieves the the results Oops, I have a little And with that actually I come to to the end. I think we're just about out of time as well And I wasn't going to end with an empty slide hold on people something is funny here I was going to end with a very glorious slide, right? So this is you guys right the cowboy is riding into the sunset right cowboys and cowgirls right so in the end Where did we start right defops is there because business wants stuff faster, right? It is always too slow and too expensive so defops is in fact a key vehicle to make this work So they have the right idea the challenge is there's a lot of stuff in large organizations that make that idea not work Right and we saw some of the things you have to be doing in order to get this to work And you realize that it's not a matter of tools or shiny objects You know it's a matter of really changing mindset and it's really part of a transformation Which is not like a six-week project, right? But it's an ongoing journey now the nice thing about the journey. I think it's actually very A very rewarding journey to transform an organization So I would leave you with that message right be prepared for the for the long run But enjoy the ride along the way. Thank you very much