 Welcome to this CNCF webinar and my name is Baruch, I am the host of today's webinar and before we start just a couple of housekeeping items. First of all, as this is a webinar, your own mute, which does not mean that we don't want to hear from you. We definitely do want to hear from you. There is a Q&A panel at the bottom of your screen, and please go ahead and put there any questions that you might have. Also, this webinar is recorded and you will be able to get the recording after it is done. Also, a reminder, this is an official webinar of the CNCF and such a subject to the CNCF Code of Conduct. So please do not add anything to the chat or questions that would be in violation of the Code of Conduct. Basically, please be respectful to all the fellow participants and presenters. With that, let's get to business. So, I have a co-host here with me, Leonid Golnick. Good morning, good afternoon, everybody. And with Leonid, we're going to discuss today how to influence DevOps without authority, hopefully in ways more successful than yelling at DevOps. Well, and we're going to take you on this mythical journey together with our friend Alex. They are a system administrator, old school system administrator in a company that is not exactly a software company, Western Textile. And like a typical old school company, they're facing some of the typical problems a system administrator would face. You know, the software gets tossed over the wall and the development team leaves them to fend for themselves hoping for the best. Well, Alex is obviously upset with this state of things and embarks on a journey to find a solution. One of the potential solutions to this problem looks like DevOps. A lot of people write about it and they mention literally DevOps as the solution for the problem of silos. Another very nice side benefit of doing DevOps is apparently money. If you look at the salaries of system administrators comparing to DevOps engineers, you can see and Alex saw that being DevOps engineer actually is much more attractive. So Alex does what a rational person would do, applies for one of those jobs and finds a new one as a DevOps engineer at a fabric company this time. And as you can imagine to Alex's dismay, the situation is not much different. Well, Alex does what DevOps engineers are supposed to do, DevOps engineering and installing Jenkins on a desktop computer under their desk or implementing DevOps in their own DevOps engineers department and basically DevOps engineering all the way. For some strange reason, it doesn't really help. Yeah, basically, we're back to the vicious circle of software getting tossed over the wall. So Alex is starting to realize that DevOps is not really a job title or a position. DevOps is a set of practices and goes ahead and learns more about them, of course, where you learn about DevOps, if not the source of all truths in the world, the Wikipedia. But Alex goes even further and realizes there are some really good books on the subject. Barbara and I like to talk about the three of them to start, right, the Phoenix project, the fundamental kind of the seminal book about the DevOps practices. The follow on to that, which is the DevOps handbook that talks about the mechanics and implementing the DevOps. And of course, the Accelerate book. And that gives Alex a good set of practices that equipment was the theoretical foundations. Alex starts to realize that it's not about the DevOps department or DevOps job title, it's about a set of practices and deep specializations that bring and set of practices that bring those practices together, right, with common goals and common culture. On this journey of discovering what DevOps is and learning about DevOps, Alex also discovers the state of DevOps report. And this, as the participants of CNC webinar, you probably know one of the most important researchers in our space. And it analyzes more than 30,000 organizations in terms of where they stand in their DevOps journey. And Alex sees the metrics and compares their organization to others and discovers that their organization is pretty much a low performance when it comes to implementing DevOps. They release very rarely and their lead time for changes is pretty long. And it takes ages to restore service. And a lot of their deployments actually go bad. They also discover that the majority of the industry are leaps and bounds ahead. And there is this group of elite performers. And those elite performers actually grew three times just in one year. Since 2019 to 2019, from 7% to 20% of their organizations are now elite performers. And Alex starts to wonder why. It is interesting to wonder about that in the age of every company being a software company. And obviously, every company cares about who, they care about their customers, or about the users, right? And what do those users or those customers want? Well, naturally, they want new features, right? It is the competition for survival and delivering the right capability at the right time. And ideally faster than your competitors so you can keep your users that you have already acquired and perhaps acquiring the new one. So the next natural question is when do they want those features? And of course, as a user myself, I want those features now. Speed kills. Somebody who can deliver a capability I'm looking for when I want it will probably win over somebody who cannot. On top of that, and you see that evolutionary pressure in the DevOps report as well. You start seeing the strong getting stronger and starting to separate themselves from the medium performance, right? The medium performance category has grown and the elite category has grown. And the part in the middle is continuing to shrink. And that's for me a perfect example of an evolutionary pressure of companies that will figure it out and will survive and adopt new practices and continue to please and delight their customers and their users and those that will going to be falling by the way of a fall, by the way of progress. And I think in the current economic environment, that evolutionary pressure will only increase the competition for the user and for the dollar will only be that much harder. So not only Alex understand that in their organization, obviously, and when Alex get themselves into some very important meetings with some very important people in their organization, they hear the same thing, we need to release faster. But they also hear some very strange and bizarre ideas of how to do that. Some people will say, well, DevOps helps, so let's just hire more DevOps engineers. Other people say, let's remove bottlenecks, QA is a bottleneck, let's just fire all the testers and we will release faster. And more often than not, when Alex actually suggests implementing DevOps the right way, the culture, the methodology, well, you know how this meme ends. And it's there lies the rub. Unfortunately, that's how the bottoms-up transformations that a lot of companies end up. And the reason for this is pretty simple. The folks that are pushing for those bottoms-up transformations tend to find themselves talking to stakeholders at the very top of their organizational chart. Those are the folks that can make the decisions and move the organization forward. And very often they end up finding themselves as far down the organizational chart as you can imagine. And not being equipped with the right tools and techniques is not helpful. So this is all very grim, but our hero Alex finds the way and we want to present you with this way. Hopefully it will help you in the same situation. And by we, I mean, my name is Baruch Sadogurski. I'm the Chief Sticker Officer at JFrog, no stickers now. So only head of DevOps Advocacy. I'm also a proud CNCF ambassador. And the most important piece of information on this slide is my Twitter handle at Jay Baruch. And my name is Leonid Igolnik. I'm a software engineer and an engineering leader who was lucky enough to find himself at the right place at the right time 23 years ago. And for the last 23 years, I've been building SAS products, most recently, heading engineering at one of the CNCF sponsors, a company called SignalFX, where we were helping our customers monitor some of those modern high-velocity environments. And now to the most important slide of today's webinar, Jeff, the comments are show notes. You go there and you will find a special page dedicated to this webinar, in which you will find those slides, the video once it's published. Excuse me. All the links, everything that we already mentioned, like the books and the state of DevOps report and everything that we will mention down the road, a place to comment, to rate, and a very, very nice raffle for thanking you for being here that you definitely shouldn't miss. To make it easier for you to always go to this page and also to follow us on Twitter, our Twitter handles, the official CNCF Twitter hashtag, and the link to show notes will be visible on each and every slide. So it will be more convenient to you to actually go there. Now, as you may judge by slide accents, Baruch and I have. We grew up in a former USSR country that was founded on one of the principles of always learning. And in order for you to be equipped for any kind of DevOps transformations, you will have to also learn. And we have a set good set of books to recommend for you to start that will give you that theoretical foundation. Yeah, so Leonid already mentioned a couple of them, like the Phoenix project and DevOps Handbook, just to add to those the unicorn project, which is kind of an alternative reality novel for the Phoenix project. And Accelerate is actually the theoretical foundation behind the state of DevOps report, also very important. War and Peace and IT, very important book that actually tells the story of DevOps in the lingo of the managers that we are trying to influence. So that's very important weapon in our inventory. And liquid software, the book that I have the honor to co co authoring with two co founders of JFrog, and and the stuff like side reliability engineering. And that's about who the real DevOps engineers are, the people who are in charge of the DevOps infrastructure in your organization. And there's a ton of other content out there, including several great podcasts. One of them is hosted by Vara called DevOps Speak Easy. DevOps ish and tons of others. There are a lot of of the DevOps days presentations and talks that are available on YouTube that you can just find them, most of them are recorded. And lastly, we also wanted to mention a tool that we like to go to, to see the state of technology practices, tools, and techniques from a company called ThoughtWorks that publishes the technology radar. They just unveiled the new version preview this week. And that's a great tool to see what what techniques ThoughtWorks believes you should be adopting or maybe considering to adopt. And they do pretty good and deep research on those. So we always like that as a source of up to date information. So you read everything, you know everything, you are vested tons of information. And now you feel pretty confident to go to your boss and dump all this information on them to make sure they understand that they need to implement DevOps properly. And yet, in spite of that readiness, you tend to find yourself in the situation like that. Let's dig into some of the reasons as to why that is the case. Well, it's kind of you need to be prepared to take a lot of no's. Some of them might come in the plane of rejection. No, we have other stuff to do, not our priorities. We're not going to do it. Others can come in the form of, yeah, sure, it's a great idea. Maybe we'll get to that later and then people get distracted. You will also encounter yourself talking to people that will be all the talk and getting all excited, but never engaging or never helping you with any of your goals. So we'll talk about how to diagnose that situation. And then in general, any change, and if you remember studying chemistry, there's this concept in chemistry called the activation energy. The energy you have to put into the system to get the reaction going, you have to put a certain amount of energy into your system that you're trying to transform to get the transformation rolling. And that activation energy is hard to get into the system sometimes. So in general, you will have a lot of very good compelling reasons to give up, and you will be very, very tempted just to throw the towel and say, you know what, I don't want to do it anymore. But as Winston Churchill teaches us, never give in, never, never, never. And at my age, it is important not to give in or give up. It's also important to remember not to try to boil the ocean, because that also is a loose, loose proposition. And that brings us to the book that we wanted to highlight today that will guide the rest of our discussion. One of our favorite models for that type of influence that you need or Alex needs as well, to get the transformation going from not a position of authority, but from a position of being a member of the organization is a book that teaches you about that types of influence and how to influence people without authority. Uncle named influence without authority. And the book walks you through a six step model that we will decompose together in the talk step by step. So why don't we begin with step one, the most important step and typically not a very intuitive step. The book encourages you to assume that everybody in the organization, whether you know that or not, can be your potential ally. Well, that's a great idea to assume that everybody are friends. But obviously, there are a lot of stakeholders in organization. If everybody are allies, who do I actually speak to? So we'll give you some concrete examples as to where to find some of the better allies that you can partner up with for your journey. So in any organization, sometimes you can find a forward looking team. They may have come from outside of organization. They may just want to embrace some of the new techniques before the rest of the organization is and learning about their organization and understanding your organizational landscape. So you can find that forward looking team is a very important technique to finding your partners in crime. Furthermore, sometimes in an organization, you may have a highly visible project. That project, especially if it's done by a forward looking team, is also a ripe opportunity for partnership on a transformation. Because if you are successful and we all hope that you are, that visibility will help you with the activation energy we talked about earlier. It is important to remember that not every visible team is a team that wants to do the right thing. So you have to learn how to diagnose those situations as well. And in order to do all of that, there is no better tool than a water cooler talk, talking to people, understanding what's happening in their professional lives is an important tool and technique for discovering the forward looking teams, the visible teams, and the teams that may be a good opportunity to partner up with. What you need to remember when you approach all those people, stakeholders, teams is why would they want to help you? Why would they want to advance your cause? Why would you, why would they do anything for you? And there are a lot of reasons and here are some less intuitive examples. So first of all, it might advance their career. And nothing wrong with that. It's a great motivator. In the end of the day, it's group effort. And if you manage to transform your organization with the help of all those people, this achievement, this transformation will go directly to the resume on each and every one of you. And that's a great driver. Generally, when it comes to people motivation, it might be not as intuitive as you assume. In a great book drive by Daniel Pink, Daniel actually explains that not everything is stick and carrot. More so once we go pass through a simple mechanical work, stick and carrot doesn't work. What does work? Stuff like giving people autonomy, mastery and purpose. Down the road today, we will show you how different people in different organizations within your company can fulfill autonomy, mastery and purpose by implementing DevOps correctly. Another thing that you need to remember is that people are irrational. They do not work in the way the computers do signal in processing signal out. Instead, this machine, this compute machine that we have in our heads acting very irrational, but sometimes predictable. You can guess what people, how people will react after you analyze their world. And we will get to the details of how to do it very soon. So basically, there are a lot of books that allow you to sway people in the right direction. You show three, which are great example. We have more down the road. And what you need to remember is what they really care about. Let us also not forget about people caring about things is what the decision makers care about sometimes, right? When it comes to influencers, not just your peers in the organization, but folks who have the decision-making authority, their rationale may be creating that legacy. So that sets them up for an opportunity for another transformation like that or another successful journey of the company. And that's also an important psychological factor to consider as you try to influence folks. And when it comes to psychological factors, Baruch, I think, has quite a number for you to look at and consider to help you diagnose the other party. So here are some examples of what goes on in the head of the other person when you try to convince them to do something for you. They will ask, will it help me to get measured, to raise my measurements on the stuff that I measured? They will ask themselves, if that's something which aligns with what they're most expect from them, they will ask themselves, will they actually enjoy doing it or it will be painful for them? They will ask themselves, if they're aligned with their career goals, are they in the rapid promotion path or maybe they are in a specialization path? They will ask themselves, how do I think my peers will react? Will it something that will make me more cool or less cool? They will ask themselves, do they have even the capacity to embark on this journey? They will ask themselves, will the organization support this effort? They will ask themselves, or this is not even the question, they will know if it comes natural from them or not based on their background and of course it has to even be possible considering the things that are going on in their lives. All of those considerations bring us to the next two steps in the model, clarifying your priorities and diagnosing the world of others. Let's start with clarifying your own priority. Obviously, as we talked about, the evolutionary pressure that all the organizations facing today is a good place to start. Doing the right thing for yourself, for the company, for your peers is incredibly important. Not the list of which is also making sure that the environment in which you work, the tools that we use, the way you go about doing your job is also built such that you enjoy taking part of that journey. So having the right tools, having the right techniques, avoiding unnecessary conflicts. Also, let's not forget building up your own resume so you pick up some useful skills to set you up for your next journey. There are many, many other factors that you will have for yourself. So we're not going to dive into trying to diagnose every attendee on this webinar. You probably know your motivation better than others, but we will talk a bit about diagnosing the world of the other person and what can you do and where can you find the data, some very concrete clues that will help you understand what drives the teams or the people that you're trying to partner up with? Of course. And when we're talking about diagnosing the world of other person, we need to know how to measure what is going on in their head in the context of what we try to achieve. And what we try to achieve is advancing in state of DevOps in your organization. And the metrics for state of DevOps in your organization is the same state of DevOps report that I already mentioned. It names four key metrics, the lead time to deployment, the deployment frequency, the change failure rate, and the time to restore service as the key metrics. And then in the report and especially in the Accelerate book, there is very, very concrete examples of how to measure it and how to apply it to your organization. With those metrics collected, you can start analyzing the world of other people to build a good strategy of how to convince them that going from low to elite is in their best interest. So those are great measures. Those are very concrete measures. You can apply that to DevOps specific, but there are a lot of other measures in the organization that people are being motivated and driven by. So let's talk about some of the areas where you can look for your other clues. If your organization has some kind of OCR process, objective and key results, or some kind of objective goal setting process, you can go and look at the goals of the teams you're trying to work with or other teams that you're considering partnering up with to understand what are some of the key results and see if you can find some alignment with the transformation. You can also go and look at the backlog or prioritized work of what they're working on, whether it's Giro, some kind of other backlog system, or perhaps a presentation that the team does on periodic basis reporting on their status. Those are typically available through share points, your week is, and places that can give you the clues as to what's important for a particular team, particular organization, maybe a particular individual. And again, let's not forget the water cooler talk that we already covered, the socializing with people in casual conversations to understand what may be driving the day-to-day transformations. And in order to help you today, we're going to give you also some concrete examples of on archetypes, in different archetypes, you will encounter in this DevOps transformations to help you understand some of the more concrete drivers that may be driving them for certain behaviors. And of course, today we're going to start with developers, right? And like everybody else, like any knowledge worker, as the book drive that we mentioned specifies, we all strive for autonomy. And in case of your development archetype, that autonomy for the developer is getting the code into the production environment as quickly as possible with minimal set of obstacles, which may materialize as, you know, I don't want to deal with in the system an ops person or an SRE every time I need to get a bug fix or a new feature into a production environment. When you come following the model of the drive book of autonomy mastery and purpose, when we look at the mastery of developers and how we can align their mastery with DevOps, is actually DevOps requires a certain type of applications. We can talk about 12 factor apps or beyond 12 after 80 18 factor. But in the end of the day, it is about how the apps are written in order to provide massive scalability, elasticity, support for cloud native, obviously, running in Kubernetes, working with Istio, etc, etc. And all this is about mastery of developers. Can they craft the software that is required to be truly scalable cloud native? Continuing on the drive principles, let's talk a bit about a purpose for the developer archetype. It's pretty simple. It's great software that everybody loves in the production environment. It matters only when that software gotten to the production environment, being used by the user or the customer, and the developer gets feedback on it. And once we understood those three, those are the three from the from the drive book, there is one more aspect that you always need to keep in mind when you go and influence people, what they fear of. And again, their fear is by their archetype, if you wish. And the question is, what is the fear of developers when it comes to their transformation for developers, the fear is, we will have much more work. All this DevOps plot is just CISAD means trying to offload their work on the developers. And now the developers should not only write code, but also deploy it and maintain it in production. And that's a lot of load. Why would we do that? So this is their fear that you need to first understand and then be able to answer. The next archetype in the software development lifecycle is the testing team. Their job is to make sure that what we deliver is of the right quality, continues to work as expected, meets all the non-functional requirements. And for that reason, their autonomy needs have to do with ability to do all of this without having any necessary dependencies on other teams, which can mean having as many test environments, being able to deploy into those test environments, it will, being able to destroy those test environments and conduct destructive testing when they need and being able to recreate them, ideally, was a click of a button. That's the kind of autonomy a high quality testing team tends to strive for. For mastery, obviously the mastery of the testers of the QA team is being able to provide quality. And usually in a lot of organizations, this ability is tampered by viewing the QA team as the bottleneck. Whoa, they stand behind us and the production. Let's cut the time allocated for QA and those kinds of things. So DevOps that actually promises baking the quality into the pipeline answers this mastery aspect of the QA team. Of course, for the QA team, the purpose is pretty simple, right? Production quality software that doesn't break every time we deploy, that does what it's supposed to do, does it within the parameters that were specified, both the functional and non-functional, they strive to make sure that the developers deliver, and not just the developers and the good environment, the entire team delivers an overall quality to the customer, because ultimately, if you remember what do they want, they want those features, that what matters. And the biggest fear of the QA people of the testers is that they will be automated out of the job by DevOps. I have another talk that I delivered in a couple of QA in the testers conferences. We have DevOps, Let's Fire, or the testers. Obviously, that's a fake title. This is not going to happen, and it's your job to convince those who worry about it that it's not going to happen. So continuing a journey through the archetypes, then that's logical one is the operations team, right? The site reliability engineers as they now like to be called, and they all have their own needs. Their needs for autonomy is being able to deploy the software, upgrade the software, maybe scale the software, move the software from one point to another with minimal dependencies to another team, whether it's the development team, because the configuration is automated and documented, or the test team, because perhaps they have an automated regression suite that they can apply to a new production environment after deploying it without having to get in line to wait for somebody from the testing team to come and certify that environment for them. Mastery is easy. Obviously, the mastery of service or sidereal ability engineers is what DevOps tooling goes all about. All this CNCF foundation portfolio, every single project there is the mastery of the new ops people of the SREs. The purpose of the operations person is also pretty simple, much like testers destroy for one thing. Up and running available, durable production environment with the software available to the customers, with in that case very concrete measures, SLAs, SLOs, performance metrics, etc. Those are the things that tend to drive those folks along the side of overriding theme of system stability. And their biggest fear is giving up control but still being blamed for things that go wrong. So once they build those pipelines and developers start to deploy their code directly in production, when things go wrong, they will be the ones to blame. And obviously, they are not very happy with this equation because this fear needs to be answered as well. Interestingly enough, on our journey to the production environment, like a lot of the organizations, we forgot about security before operations. And let's talk about that archetype. Security in this stage is incredibly important. I'm sure you all read the news and you understand the reputational risk from a breach to a company, for some companies that may mean case of death. And therefore, security is becoming a much more important part of the software development lifecycle, especially giving the velocity at which we're all now moving, and they have their needs as well. When it comes to that autonomy, it's all it's being able to make as much impact as they can, again, without those third party dependencies and those dependencies can manifest in requiring vulnerability, patching and upgrades for operating systems, remediation of vulnerability that were reported or found by a penetration test, ability to have environments much like the testers where they can conduct destructive security testing in a like production environment to ensure they provide the best possible safety net to your organization. And that changes the mastery of the security people. Now, not only they need to be the masters of the penetration tools and the masters of presentations and meetings about how bad the security is, they have an entire new set of tools that they need to master all the DevSecOps portfolio tools that, for example, scan the images in the containers like Jeff Rock X-ray and others. So their mastery is now DevSecOps tools. Now, when it comes to their purpose, I'll tell you from my experience, good security folks hate to be the bottleneck. They don't want to be the bad cop. They don't want to be the bad guy in the pipeline. They want to enable the organization to deliver software as fast as it needs to be delivered while still maintaining the security privacy and all other aspects that they tend to worry about. So for them, the purpose is really support the organization in its velocity and support it such that the pipeline continues to be secure and delivers secure software. And of course, their fear is ending up in the news and being blamed for security issues. If DevOps helps with that fear, then DevOps is a good thing for those people. The next archetype will depend on the type of company you are. If you're a product company, i.e., software company that builds software products, you probably have software product managers. If you are a company that uses software for internal operations, you may have a business analyst or somebody generally representing the business, and we'll call that archetype product here. Obviously, they also have the same strives and the strive for autonomy, i.e., ability to deliver features and deliver the features that they believe that the organization requires to be successful without any unnecessary obstacles. Their mastery is being able to experiment as much as possible. Since no one knows what the customer would really like, either internal or external, not even the customers themselves, the only way to deliver the right set of features is putting something in the hand of customers and see how they use it and if they like it or not. DevOps allows us build a lot of different pipelines that provide a lot of different experiments and fail cheap. This is how DevOps actually helps mastery of product, user, business people. Quite often, the way to enable that autonomy and mastery is through metrics. You can think of the ultimate metrics, i.e., the profit, but that's a pretty costly grain matrix. In order to enable that purpose, they need other metrics, usage, understanding how people use the software, what does the software do, etc. But ultimately, in most organizations, the purpose is either profit, kind of high aspirational success, maybe industry recognition for being a leader in your own space, or perhaps success that is measured in the ways related to the specific industries. And the biggest fear is delivering the wrong thing, investing a lot in delivering features that no one really wants. DevOps obviously answers this fear when we iterate fast and we release often, we can minimize the risk of doing the wrong thing and this is how DevOps helps these product people fear. So it looks like you need to know everything about everybody, which is you need to be the developer, the ops, the QA, the security and the product in your head in order to diagnose their world and this is obviously impossible. But frankly, you don't really need to. Instead, you need to be you and you need to understand a little bit about each and every one of them. So those five slides that we went through, it's obviously not enough, but also it doesn't mean now that you need to go and specialize in each and every of those aspects. Instead, you need to be kind of what is called the T-shaped people. What we actually mean is that you have a deep specialization, you are who you are, and I would assume for CNCF webinar, we have a lot of people that come from ops background, a lot of people who come from dev background, be you, but also invest in understanding others people world. It will help you in your job, especially if you're already doing DevOps correctly, and it will also help you convincing for DevOps. One last thing that I really would suggest is although you might like duck typing in your development, Python, Groovy, whatever dynamic language you use, avoid stereotyping when it comes to people. People might surprise you, not everyone fills into this pigeon hole that we just drawn, so be open-minded. So hopefully this gives you a good context about the world diagnosis and understanding what you need to learn about your possible future partnering crimes in order to partner with them successfully. Now let's talk about how do you find that common motivation and how do you align on common goals, and the model talks about identifying relevant currency, yours and theirs? What can you offer and what can they offer for that journey? And there are several types of currencies that we can talk about. One of them is money, by the way. All of them are currencies which are currency in your organizational negotiation, if you like, and they can easily be an inspiration related stuff like you just excite the other person so much, they really want to do it. It can be task related, what you suggest will help them do what they already supposed to do better. Position related, what you suggest them will advance their career. Relationship related, they will do something just a favor for you because you build this relationship. Or even person related, if you know the other person well enough, you know which buttons to push to actually make them do the right thing. And making the right things means creating symbiotic relationships, where both parties get some kind of benefit, even in places where the parties may not be of equal size, equal value, or equal placement in the organization. And there are several good examples of how to get those relationships great, and I think Baro has an excellent one for you. So here is an example which is a great currency, and that's a hackathon. It's actually two currencies in one. It's this like multifaceted tool. From one side, you can actually provide value to the other person. Whoever you need to sway your way can benefit from the laborers of the hackathon that you organized. They will obviously owe you a favor and will do the right thing. So that's kind of a task-related currency. But the hackathon is also an inspiration related currency because hackathon is implementing DevOps in a micro level. You build empowered teams and you deliver value very, very fast. And you can use those teams and the outcomes of the hackathon as a great example of how DevOps can help release faster and inspire people by pointing them that way. So that's an inspiration-related currency. I'm sure if you counted the number of times we said the word people and understanding people, you would realize that the important part of all of this is dealing with human relationships. It's not about technology. It's not about the process. It's not about the tools. It's about those variable feedback time, non-deterministic machines known as human. And the model also agrees with that. And there was an entire section in the model requiring you to be successful to understand how to deal with those relationships. Yeah, basically the idea is you don't want to end up like this. We already mentioned some books that help you understand people better. There are much more. And here are more examples of the books that we definitely suggest you to read in order to understand people better and be able to convince them better actually by, as I mentioned, pushing the right button sometimes. So you will have to do that mastery as homework. There's not enough time on a webinar of any kind to teach you all of those skills. And I'm sure you have some of those already from your personal lives. So why don't we move on to the last step of the model, which is the influence through give and take, also known in the world as quit pro quo. And quit pro quo lately in the world quite often has a lot of negative connotations about exchanging something for a nefarious purpose. This is not the kind of quit pro quo we are talking about. Most real organizations today function because there's some kind of quit pro quo happening. And several examples could be you have access to a particular server that somebody else needs and you gave them because you can spare it or you've received some favor from a team that you've been working on with and they kind of pitched in and help you, for example, to finish a manual regression test if that's still an issue on time. That's a great example. Let's try to put some labels on those examples and others. So we'll give you some concrete types of the exchanges that can happen in the organization with some examples. So number one is interest alignment. You and your other parties that you're trying to work with are going towards the common goal, whether it's launching a feature, delivering a project, maybe stabilizing the system. That's one type of exchange where that interest alignment can drive. Another example is exactly what just Leone just mentioned, just Barter. I have staging servers that I don't need. Do you want to use them for your penetration testing? And if you want to use, then you will owe me a favor that I can call later. And favors and kind of owing and calling in a favor is a very common way for human relationships. And I think thinking about that and being proactive about that, i.e. not starting from a position where you ask for a favor, but possibly doing a favor is a very useful technique to start getting the relationship with the teams you identified going and starting to build that relationship so you can partner up with them. And with that, this is the end of the model. And I think it's the end of the webinar. Well, not really. I think we would be at fault if we didn't leave you with some more concrete examples of how to deal with the most important thing you will be running in those influence setups without authority is getting to yes and getting through no. So let's talk about some concrete examples. So there are several barriers that you have to overcome and those barriers can be both external and internal. So for example, an external barrier is the power differential we saw at the very beginning of Alex's journey where Alex was stuck at the very bottom of the org chart and the influencer and the decision makers he needed to influence were at the very top. There may be different goals. We talked about discovering OKRs, discovering priorities of the teams you're trying to partner up. They may have mutually incompatible goals. So that's an external barrier you may need to overcome. The measures may not be compatible. You know, if your ops team has measured just purely on SLA that precludes feature delivery, that's an example of incompatible measure for the overall organizational success. And you know, there's good old team rivalry. Microsoft was famous for pitting teams against each other and you have to be aware of those and figure out how to overcome them. Some barriers are internal and the hardest barriers, internal barriers, are the barriers in you. For example, let's experience with the model. You heard about this model before you rush and implement it in trying to influence in the four devops in your organization. Do a smaller experiment. Try to influence for smaller things just to get experience with the model. Another one is blinding attitude. You can give up on some things without trying them just because you think you will never succeed. Oh, I'm not going to try and influence this big boss because there is no chance. If you won't try, how you will ever succeed. Another important internal barrier is fear of failing. I won't even start on this journey of transformation because I will probably fail in this way or another. So why bother? And another one is fear of reaction. If you think that you will be punished for your initiatives, then you will restrain yourself from even trying. For this one, last one, the fear of reaction, my suggestion would be always having best alternative to negotiated agreement known as Betna. Betna is what do you do when there is no agreement? When you try to convince someone and you got no. The worst thing you can do is just not having one. Well, I have no idea what I will do because then you will restrain yourself from being the best you in negotiation. Another bad one is I'll pretend that nothing happened and I'll pretend that nothing happened means that you need to be able to undo what just happened. And that means that you cannot do bold moves because bold moves are impossible to undo. You might realize that whatever you do now, there is no coming back and you will have a look for a new job after you burn your bridges and fail in your efforts. Looking for a new job is stressful. It's hard, especially now. So you might want to give up on the entire attempt. The best Betna you can have when you go into this kind of influence for DevOps transformation is actually having a great plan B and this is a job offer in your pocket. Then you will be your best in trying to influence for DevOps. Another important aspect is look at the end goal. Consider the entire journey and you might want to lose a battle to win a war and give up something to actually reach the end goal in the end of the day. And while you do that, it's also important to remember that with some partners and some parties, you're going to have one silver bullet to shoot. So you have to come prepared. You have to come educated about their world so you don't waste that shot. With that, I think it's important for us to get into some concrete examples. And let's use a simple one that we already touched on in the presentation. An engineer saying, hey, you know what this whole DevOps thing means? I'm going to be on call and it's not my job. I just code. So there are great answers to this objection. I try to summarize them in my talk DevOps for developers or maybe against them when I actually battle this exact objection and give you some ideas of how to do it. The link to this talk is in the show notes. And just to remind you, the link to the show notes is in the bottom of each and every slide. So a next common objection is like, hey, listen, we've gotten to where we've gotten. We're very successful. Why should we change? What's wrong with what we're doing right now? The world changed. The world changed a lot both in terms of the evolutionary pressure for features that we already mentioned, but also security can be a very big driver for change. So if your boss don't want to end up in the papers as someone who got fired because of security vulnerability, you cannot keep doing what you were doing previously. All right, all right, all right. You convinced me, but you know what? There's no time. We are so busy. The roadmap is so long. We don't have enough people. We're just overloaded here. Well, everybody are overloaded. There is no time for anything for anybody. But it doesn't mean that we don't need to strive to be better. We actually have to force ourselves to get our head out of the water and look for ways to be more efficient. So you spend some money, you spend some time in order to get time down the road when you actually implement DevOps correctly. Listen, you also keep talking about this T-shaped personality, understanding the world of others, but like, don't you end up with people that know a bit about everything, but nothing about a lot? And like, I'm silo is good for specialization and you need specialization. You definitely need specialization. Specialization is great. But specialization in the silo won't help you to solve the problem of your pipeline. If you have a bottleneck in your pipeline as a great Elio Goldrod teaches us in another great book that called The Goal that Phoenix Project actually based on, then you're actually not solving any problems. You might have great amazing specialists for this example in the stations two and three. But if your bottleneck is number four, the specialists in two and three won't help you not a little bit to actually release faster. Yeah, but I can't blend everything together. We have regulations like name your own favorite regulation, HEPA, PCI, DSS, financial authority of Singapore, whatever. Those regulations prescribe that we have separation of duties. We need to make sure that things that we change in productions are controlled. Like you're talking about this whole blending of teams together. How can we make that work in that environment? That's a great question and it's actually a question that we have been asked in the Q&A panel as well. You can add still more questions, by the way. And the answer will be stop trying to approve or to pass the regulations by looking at the end product. Instead, switch to certifying the pipeline. Once you certify the pipeline, every product by definition will be certified and all the regulatory bodies actually acknowledge that and will allow you to certify the pipeline instead of certifying each and every version of each and every project. All right, all right. That's great, but you're still confused me. We have to release faster, but then you said we have to worry about security because the world has changed. But it takes time to certify something for the security or it takes time for those features to make sure that they're high quality by our testing teams. We can just simply start releasing faster. And that's the ultimate objection for adapting DevOps. We cannot move too fast because we need to pay attention to details. And you know who's good in paying attention to details? Machines are. Machines are much better in doing monotonous work of creating, of building something out of human creation and then passing it through security gates, through quality gates over a release pipelines. So all we need to do is letting machines do that. Once we have that, we can benefit from both worlds from releasing faster and being with the quality and the security that it requires. So a mythical hero, Alex being fully equipped with all of those techniques and objection handling ideas, partners up with several teams in the organization and successfully transforms it to DevOps to the point where Alex becomes the CIO of the org. And not only that, he gets head hunted giving the success that Alex had by another org and does that same journey again and again. So to summarize, to summarize two things. First of all, the model, give it a look, give it a thought, practice it. And we believe that following this model, you can be influential without being the boss. And I remember to diagnose the part of and the motivation of others, right? Understanding the other party is incredibly important for that successful transformation through influence. With that, thank you very much for the last time. I'm Jabarrochan Twitter. I am at Alagonicon Twitter. And just the show notes are Jeffrock.com, the show notes. Since we are in the shameless plug section, I want to remind you that we have our own Jeffrock user conference coming up in the end of June. Go to SwampUp.Jeffrock.com to learn about the agenda, the amazing speakers and the amazing content. With that, thank you very much. We have two minutes. So if you have more questions, shoot them now. Well, I guess no questions. So you know where to find us offline on Twitter, obviously. And with that, thank you very much for coming and have a great rest of your day. Enjoy your weekend. Oh, it's Friday. It is Friday. That's great news.