Influencing DevOps without Authority – How a DevOps Engineer can advance real DevOps
In this talk, JFrog’s Head of Developer Advocacy, Baruch Sadogursky will show how some proven influencing and negotiating techniques can be used to convince critical stakeholders in your organization in the necessity of DevOps. We look at the arguments, the techniques, and the small tricks, which work in particular situations with particular engineering and business leadership positions and will prepare you to deliver the message of DevOps most convincingly to each.
Webinar Transcript
Hello and welcome to the AWS Summit. Today, we’re going to talk about influencing DevOps without authority. We’ll start with the story. This is Alex and Alex is a system administrator in a low tech like textile industry. And Alex has a problem. The problem that Alex has is that they, as system administrator, are on the receiving end of this grenade that the developers throw them every time they finish developing. And Alex looks for a solution, and magic, looks like the solution exists. It’s called DevOps you’ve gain issue. Dmytro Zaporozhets one of the co-founders of GitLab is explaining how breaking silos in software engineering space by implementing DevOps helps solve, increase that problem. Alex does some research and they learn that it’s also paid much better instead of that. They can actually make that. And it generally sounds like a great idea. So Alex becomes a DevOps engineer.
What do DevOps engineers do? Well, they set up Jenkins on a desktop computer under the desk. They DevOps in their DevOps in environment. And as you might imagine, it doesn’t really solve the problem. Alex still has the problem. Why is that thinking Alex? Well that’s because there is not enough collaboration between the developers and then new DevOps department with the DevOps engineers that Alex is now a part of. So what do we need? We need a new methodology. We’ll call it DevDevOps. It’s a collaboration between Dev and DevOps makes sense, right? Obviously jokes aside. This is not what Devs is about. What Devs is about. Well is a set of practices that combine software development and operations. It’s a methodology. It’s a mindset. Alex reads some materials, The Phoenix Project, the DevOps Handbook, the Accelerate, and starts to get it. It’s bunch of professionals with their deep specialization come together and combine their expertise into common goals and common cultures.
One of the things Alex learns is one of the most important documents in our DevOps industry, the state of DevOps support is that their organization is what the state of DevOps support calls, the low performers they develop very infrequently. Their lead time to changes is huge. It takes tons of time to restore service in case of outage and deployments fail a lot. The change failure rate is huge. And what they also learned that the industry actually goes forward towards to being an elite only between 2018 and 2019. The number of elite performers, tripled from 7% to 20%. And Alex starts to ask themselves why, why industries embrace DevOps and moved towards DevOps? And I will give you two very basic and kind of on the surface answers. The one in is, well, the users, what do the users want? They want features.
When do they want those features? They want them now. And DevOps can’t find that you remember it’s about delivering faster. So obviously we deliver features faster. That’s good. The other problem, security, how DevOps help with security. Well, if you are in a security incident, you have three stages. You need to identify that there is a problem you need to fix this problem. And then again, you need to deploy those changes to production deploying faster, gives you better security posture. So in the end of the day, what you see here, the industry that tripled is because of an evolutionary pressure. It means that it’s only natural. That companies really adapt through DevOps, not like renaming Ops to DevOps engineers, but real true DevOps and win. Now, obviously Alex wants to transform their organization. They manage to get themselves into some very important meetings. And the discussions on those meetings are on point, how do we release faster?
The problem is that in a lot of organizations, they understand they need to release faster, but they don’t get how to do it. And they use some cargo cult, things like hiring more DevOps engineers, or let’s get rid of the bottlenecks without actually doing the right thing. As some naive steps of trying to release faster, none of them actually work. What they need to do is to implement real DevOps, the collaborative practice, but you know how this meme usually ends. No one wants to listen to Alex. One of the reasons is because the decision are about the culture and the methodology are really made up there. And Alex is down here in the trenches. No one wants to listen to them, but Alex finds the way. And today we are, I’m going to show you this way. My name is Baruch Sadogursky. I’m the Chief Sticker Officer and heads of DevOps advocacy in a company called JFrog.
We do tools for releasing faster. We do tools for helping you implementing DevOps. Check us out devops@jfrog.com. The most important slide of today is this one. If you go to JFROG.Com/shownotes you’ll find the slides already uploaded there. The video already uploaded there, all the links to everything I mentioned to you also there, the place to comment, to rate and a sweet raffle to thank you for being here. So JFROG.Com/shownotes. If you forget, don’t you worry, it’s in the bottom of each and every slide together with the hashtag to mention on Twitter, AWS Summit, and my Twitter handle. If you want to discuss this talk on Twitter. So let’s get back to the story. How do we convince for implementing real DevOps? First, you need to make sure you know, what you are talking about. You really need to go ahead and learn what DevOps is and what it isn’t.
And there are a bunch of books and resources that can help you. We already mentioned stuff like The Phoenix Project and the DevOps Handbook and the Accelerate book. There are others the Site Reliability Engineering, The Unicorn Project, the Liquid Software book that I co-authored with co-founders of JFrog about continuous updates. And one very important for this talk War Peace and IT. War Peace and IT is extremely important book because it discusses DevOps in the terms of managers and what you are going to do. You’re going to influence your managers for DevOps. You’d better know how to articulate DevOps correctly in their terms management and business, read War Peace and IT, if you are not into that many books, there are other great resources. There is a podcast, DevOps Speakeasy. There are videos from every possible DevOps conference ever. And two Technology Radars that can help you, know what’s going on in terms of technologies and frameworks and tools, and the one technology, or rather is from ThoughtWorks done by their consultants. And the other is by CNCF done by their end users strongly recommended both.
So let’s say you read all that. You watched all that. You heard all that, and now you really feel like you are ready. You are ready to storm into your boss’s office, explain to them what DevOps is and for sure they will see how great it is and will agree with you that all the company now need to transform to DevOps. Well, probably not. And the reason why you will hear this is because there are a lot of reasons for this kind of reaction. The first is people are busy. You come with new ideas that takes a lot of time and effort to implement, expect people, not being very, very keen about piling, more work. Some people really want to really hear you and think that it’s a great idea, but when it comes to actually doing it, they will be busy and distracted, and won’t have time to that.
Others won’t even try to do anything. They will be all talk, no work in any way. Even those who have the best intentions in mind need to put tons of activation energy in order to transform and entire organization. And this is hard. It, I guess what I would try to say is that you will have a lot of reasons to give up, but don’t, we will show you, I will show you how to overcome all those. And the first advice is don’t try to boil the ocean, start small. We will teach you how.
Today I’m going and to talk to you about one of the frameworks of influencing without authority. There are a lot. This one is called Influence Without Authority by Allan Cohen and David Bradford. And this book defines a six step model for influencing result authority. We’re going to go through these six steps and teach you how to do it.
Step number one, assume everybody are potential allies. That’s a weird step. I mean, yes, obviously, but is it? Think about how many people you will rule out when you think about potential allies, those they don’t care about what we do. Those, they’re not friendly. Those, they hate us. Those they’re overloaded. And just like that, without even trying, you cancel a lot of people that could be your potential allies. Don’t do that. Don’t cancel potential allies based on the ideas of what they might say. Instead, look for potential allies that will be beneficial for you. For example, forward looking teams, those are the teams that will embrace the change that you bring and will see the sense in DevOps farther than others or highly visible projects. Success in those projects will bring you the needed support throughout the organization. Obviously you need to be aware of self-promoting cheaters and douchebags.
And if you think that some people are not real allies, but self-promoting cheaters and douchebags, maybe you are right, but you need to double check that before you actually go ahead and count them out. How do you check? Well, you talk to people, you talk to people and then you find out if they serious, if they support you, if they don’t support you, what’s going on. So this is stage number one, stage number two, clarify your goals and priorities. You need to remember why are you doing that? What is important to you and why you try to do what you try to do? So remember why Alex started the entire journey because Alex had a problem and they needed to break the silos in software engineering workspace, because it is the right thing to do. Evolutionary pressure of our industry dictates that we adapt DevOps.
It also makes much more nicer place to work. You want to work in a forward looking and advanced company and not a backwards dinosaur that is going to die out of the industry anytime soon. And frankly, if you manage to transfer entire organization into DevOps, you will have a lot of breaking points in your resume and your career will go forward much faster with this achievement in mind. All those are super valid reasons. Once you know why you are in this game, it gives you clarity of what can you give, or what do you expect to get from other people. Next step is more complicated. You need to diagnose the world of other person, what people are living for, what drive them, what motivates them and how you can play into those motivators to advance your agenda. So, first of all, there are people they’re interesting in advancing their career.
So if you can promise them that if they stick with you and help you with their transformation, this it’ll help their career. This is a great motivator. When we talk about motivators and what motivates people, I think the best resource to know what motivates us, the IT workers is Daniel Pink’s Drive. It’s a book about surprising truth that motivates us. And it’s reveals that our motivators are autonomy, mastery and purpose. Autonomy is the ability to do the job ourselves without being dependent on tons of other external things. Mastery is that we learn new things and become better in what we do and purpose what we are doing is actually for a reason. We’re going to get back to autonomy, master and purpose very, very soon. But for now, please remember that while we have this magic formula with three ingredients, people are irrational.
People are very different. They have different motivators. They behave unexpectedly. They sometimes behave counterintuitive to their own best interest. And there is tons of literature about that predictably, Irrational and Sway, and many others talk about exactly that. There are obvious motivators though, for example, legacy. What is legacy? It’s part of the purpose item on Daniel Pink’s list is why we want to have something left after we are leaving, but you need to remember that people are preoccupied with their lives. And when we bring something new to their table, we need to think how they will react based on what happening in their lives. Like for example, will their metrics be aligned with what you want them to do? What they expect as their reaction from their boss, will it’ll be into interesting for them? Will it help or hurt their career? How they expect their colleagues to react?
What is their workload? Do they even have the capacity to help you? Do they have the inclination to help generally do you or anyone else? And of course that everybody have their lives outside of work that you need to remember and take into account. In the end of the day, when you go and convince someone the best way to do it is with numbers. In case of DevOps, our numbers come from the accelerated book and we have four very clear metrics of what successful DevOps organization is; lead time to deploy change, to deploy service, change failure rate, deployment frequency, time to restore service. If we can argue with those four numbers and say, “Hey, we are now on a low performance of those numbers, but we want to adopt DevOps to become an elite and establish our legacy.” This is a very, very convincing argument.
Where do we get the numbers from? Well, you can look at public information inside your organization, stuff like the OKRs if your organization published them. Backlogs that you can go ahead and check. How is the deployment frequency in an organization, presentations, public like organizational presentations, like the kickoffs and internal quarter summaries, spring summers, et cetera. And just by asking people on water cooler or whatever we use now, instead. In the end of the day, you need to go ahead and just map the world of other people. And you can use it using the three parameters of Daniel Pink’s, Drive autonomy, mastering purpose, and add to that. What is their fears that are barriers for adopting DevOps? I will give you just two examples, but you need to do this exercise for everybody that you are going to influence.
So let’s start with developers. What is their autonomy? Their autonomy is to be able to see their software through from the code that they’re writing all the way to production. Does DevOps help it? Of course, this is what DevOps is all about. Here you go. Developers will be happy to adopt DevOps because it advances their autonomy. But how about fears? What do developers afraid of when it comes to adopting DevOps? This is also clear. They afraid that the system administrators is going to offload their work on the developer shoulders for now. Deployment is an Ops concern. DevOps is going to make a deployment, the concern of everybody, including the developers. So the developers are afraid. They are going to work more. If we want the support of the developers in adopting DevOps, we need to convince them that this fear is baseless, right? And you can go ahead and do this exercise for a lot of different roles.
I will give you one more example, product managers, what product managers have to do with DevOps. Let’s check. What is their mastery? What is a good work of product manager? Well, it’s knowing which features the customer want. How can they know? They usually guess. Is there is better way? Yes, experimenting. If we can go ahead and roll out features, different features to a lot of different customers. Then we will know which features customers love and which features customers hate how we can do it? The answer is DevOps. All the feature flags paradigm, which is part of DevOps gives product managers, their mastery. If you manage to express that, boom, you have product managers as your allies in your quest for adopting DevOps. Amazing, what is the problem? The problem is looks like you need to understand everything about everything. You know, you need to know about delivery, about customer, about quality, about architecture, about security in order to be able to diagnose the world of other person.
The problem is it’s impossible. It’s impossible exactly like unicorn farting rainbows. The good news are that you don’t really need to know everything about everything. Instead, you need to be what David Epstein called a generalist in his amazing book, Range. Generalist is someone who knows a little bit about a lot of stuff like this key ring the keys are looking in all the possible directions. This should be you. You still have your strong core and you are, if you are on this conference, I would assume you are an Ops person. You know, the AWS stack very well, but you also know what the developers’ world is, what the testers world is or what the product manager’s work is. If that is too much books by now, the content of ranch can be consumed as a Ted talk done by David Epstein and this is great.
The next step is identify currencies. And you go like what currencies? The currencies that you will use for influence. And that I don’t mean money. There are different types of currencies. For example, inspiration related, something that will inspire people. Task related, something that will help them do their work better. Position related something that they will help going through their career, relationship related and person related. In the end of the day, the idea of currency is finding something that you can give to the other person. It will help them and they will help you. It’s like sharks and the remora fish that help each other in a symbiosis. I’ll give you one example of such a currency and that’s a hackathon. How hackathon is a currency? Well, not only is the currency. It’s a currency that actually feeds almost each and every currency type.
Is it inspirational? Hell yes. You took a small teams, empower teams of different people from different departments. And in the course of 24 hours, you created a working product. This is DevOps. You just exercise DevOps and you created something great. And this is very inspirational for other people to adopt DevOps. It’s also a task related currency because you created something that other people can use in their work. And it’s also a position related currency because someone might get promoted for either developing something or starting using something that was created during the hackathon and obviously person related and relationship related, great relationships start between cross organizations in hackathons. And you know that better than I do. So yes, a hackathon, it’s a great multifaceted currency. And this is just example for that.
The last, the one before the last step is dealing with relationships in the end of the day. Even if we did everything right and the person that we need their help with just don’t like us. This is what is going to happen? So in order to prevent that, you need to be likable. You need everybody to want to help you. How do you do that again? You remember that you are working with people and then you go and learn how to work with people by using those amazing resources and obviously much more, the last step is influence through, give and take. Yes, in the end of the day, the influence in itself is I give you something, you give me something in return. And anyone say, well, this is cheap. This is not how I expected it. But think about it. Everything that people will do for you will be a type of exchange. It can be because it helps them no less that it helps you.
And now it’s an interest alignment, or it can be a barter. You do something for them. They do something for you, or it can be a favor that you owe them, or they owe you. No matter how you look at it, this is the only way to influence without authority. And this is the end of the model. And you might say, this is the end of the talk, but not really. Because if you do everything by the book and you storm into your boss’s office, you will still get the same result. Why? Because there are barriers for influence that come in two different shapes are external barriers, which are kind of easy to spot and maybe easy to resolve, or maybe not. So for example, power differentiator. You remember how we started when Alex was down there and the decisions were up there, don’t try to cover that all and try and influence your CO through, give and take, go step by step.
And then you reduce this power in differentiation. Different goals, income measures, or you know what, just the rivalry, they don’t like you, as I said, and this is very… and this is obviously a huge, huge barrier but it’s very easy to spot. The more different, the more difficult to spot barriers are internal barriers, those lack of experience. That’s the first time you heard about this model, don’t rush and try to implement it, you probably won’t succeed. First train on smaller goals within smaller teams. Don’t try now immediately to influence your entire organization through it. Blind attitude, we spoke about it a little bit, it is a huge barrier. The stuff like fear of failing. I will never succeed so I won’t even start. Or fear of reaction, what will happen if I fail? Those are very significant barriers for your influence. So you need to remember those as well.
And I want to kind of finish this talk. With giving you some common answers to common objections that come up in conversations about DevOps. The one I already mentioned, and that’s the fear of developers that they are now going to work much more because the operations people kind of offload it, their work to the developers. And if you go to JFROG.Com/shownotes you will find there a link to another talk that I did. It’s called DevOps or developers, or maybe against them in which I go in the depth in explanation, why DevOps is good for developers, they shouldn’t fear it. And that’s a good answer. Now, when you speak with your boss or their boss or any boss, you might hear staff like what’s wrong with what we are doing now? The problem is that what you are doing now, if you are not doing DevOps is not enough.
You might not have competition that you need to beat in delivering features, but you definitely have a security exposure. So implementing DevOps and being able to react better to security threats is still very important. People can say, “well, we have no time for this. Everybody are overloaded.” And the only answer for this is, “Hey, sometimes we need to raise our head above the water in order to swim better.” There is no way around it. We need to stop and reevaluate what we are doing. You might heard, well, silos are good. They promote specialization. Why do we want to break the silos? Everybody will try to learn about everything and then no one will really be specialist in nothing. Well, there is truth in that silos promotes specialization. The problem is that they don’t help us in our pipelines. Which you can look at as a manufacturing floor when you assemble a car, every step of the way should flow smoothly.
And if you optimize not in the bottleneck, it’s like you don’t optimize at all. If you have very good developers, but your QA personnel actually serves the bottleneck, it doesn’t help you that the developers are great. This is Eliyahu Goldratt And he introduced this idea of the theory of constraints in his amazing book called The Goal. That will be the last book that I recommend to you today. And it’s available as a graphic novel, don’t miss that. It’s important. The last objection is, well, we can’t release faster. We need to check for a certain concern. We need to check for quality we need to check for security we need to check for compliance. Nevermind, the answer is exactly the same, stop checking for those concerns in each and every release. Instead, concentrate of making your pipeline compliant. Maybe make your pipeline check for quality and for security, once you do that, you are guaranteed that each and every release will be tested, compliant, secure, et cetera, et cetera.
So it basically means automate everything. Now, the only problem I have with this picture is the face impression of people that are going away from the manufacturing line. Instead of being said, they’re actually should be very happy because they stop doing a boring work of verifying the releases and start doing really interesting work of make sure of baking quality, speed, compliance, security into the pipelines. It’s much more rewarding its much more fun. So they really, really should smile.
And back to our Alex, if they did everything as we suggest that they do, they really have a very good chance of transforming the entire organization into DevOps and become the Chief Information Officer of Strong Fabric. And then go ahead and now the sky is the limit for their career. They can become a Chief Information Officer in any organization and start transforming more and more organizations into DevOps. With that, a reminder, what we spoke about the coin Bradford influencers authority model, and that you don’t… that you cannot rush it until you know, the model well, and know how to deal with objections with that. Thank you very much. I am @jbaruch on Twitter. This is the AWS summit. Don’t forget JFROG.Com/shownotes, the slides, the video, all the links and amazing raffle thanking you for meeting here are already there. Thank you very much and have a great rest of the conference.
