How We Led Three Banks Through DevOps Transformations
Banks are the perfect storm of DevOps anti-patterns where Technical, Organizational and Cultural barriers are all stacked against you.
We faced challenges with compliance, tech sprawl, obsolete technologies, and bloated processes. The delivery chain is often split amongst 3-4 organizations. HR, Finance and PMO don’t have the background or process to support DevOps transformations adequately. Culturally, there is fear of change, group overlap and protectionism.
Cultural sprawl is huge. You don’t have to unlock and influence just one culture; you will encounter a half dozen. As an example, the top 4 banks (Wells Fargo, JP Morgan, Citi, & Bank of America) were 35 separate companies in 1990.
It sounds hopeless, right?
This talk discusses how to grow a coalition, anchor behavior, and defend your efforts from those threatened by them. The techniques help incubate your transformation until there is enough critical mass to make it tough to derail.
Through a long, painful journey, we discovered techniques you can use to weather your storms. These techniques evolved over 10 years in transformations which crossed 3 banks and 4 distinct large-scale transformations. Each transformation was unique, but the principles were universal.
This talk focuses on four ideas that can help you successfully scale DevOps: Alliances, Data, Startup Mentality and the Leadership needed to tie them together.
1) In Alliances, we’ll discuss how to identify, create and leverage alliances. We’ll show how this helps bypass resistance, plot your strategy and keep your assembly line of on-boards moving.
2) In Data, we’ll show how to use data to prove success, communicate weekly, and keep your execs asking for more.
3) Startup Mentality keeps your team focused and passionate. I told my teams: “Pretend you are a small company inside a big one. Every day measure our contribution and expect to fold if you don’t deliver.” Acting like a startup means being hungry every day, delivering in increments, focusing on just a couple efforts at a time (80/20), and pivoted rapidly. Deliver small, consistent wins to build a track record and credibility and trust. Focus on customers and their experience.
4) We’ll talk about the importance of Leadership to tie these all together and how it is necessary to transcend the cultural challenges in large organizations. Leaders must be willing to go against the grain every day while providing vision, inspiration and protection.
We struggled, slipped and hit brick walls, but one thing kept us going. Every member of our team believed that what we were doing was the most important thing in the world to our companies. This gave us the courage to keep pushing. We regrouped, came up with new plans, and got back in the game. Every day there were naysayers, politics and occasional sabotage.
Was it worth it? Yes, every minute of it. We ultimately automated over 800 applications. It can be done.
Chris Nowak, Chief Transformation Officer, Kingsmen Software
Chapters
Full transcript
The complete talk, organized by section.
Chris Nowak
I was speaking, I guess, about an hour ago. Who was in that one? I know you guys were, a few. This is going to be a lot faster.
So my biggest fear here is there's a lot of information. It's very dense. So I think what I want to try to do is kind of walk through it pretty quick, and then if we can circle back, we will. So we'll see how this goes. We're kind of testing in prod right now, so you're part of my testing team.
So, alliances, data, and startup mentality. But what's buried in the middle here is the word lead, or led, right? That's really what we're talking about. And I hope you don't mind, I kind of walk around a little bit here.
Three different banks, bringing them through those transformations. I currently work for Kingsmen Software. It's a small startup, 32 people, but that's not what this is about. This is about my 20 years working for Bank of America, Wells Fargo. Before Wells Fargo, it was Wachovia. Before Wachovia, it was First Union. So, same seat, three banks, right?
I know it's right after lunch. We'll try to keep this as engaging as possible. If I fall asleep, wake me up.
All right. So let's see where we go with this. Again, it's going to be fast, so let's move through it pretty quick just to start.
But this is going to be a little bit helpful because those of you who were here yesterday, I'm standing on the shoulders of some giants that have already presented. So Scott Nasello talked about a learning organization, learning culture, a safe place, psychological safety to experiment with things, grassroots efforts. He said that they started at the grassroots.
Dr. Steve Mayner talked. It was great. I was like, "This is cool. You just did the first 10 minutes of my talk. It makes my job easier." Transformational leadership. If you recall, he talked about a few different things: Kotter's Leading Change, eight steps there. And he also talked about, I guess, the grief curve or the trough of disillusionment. We've seen that form in different places.
And Mirco Hering, who was a breakout yesterday, talked about mental maps. This is great because I want to reference a lot of these. I am going to be watching my time pretty quick and maybe speeding up. We'll see how it goes. It's a variable-speed DevOps here.
If you think we're talking about tools today, you probably want to go to another session. This is about the... not that tools aren't hard. Implementing a tool is easy if you didn't have culture and process in the way, at least that's what I believe. If you didn't have to integrate that tool with the ecosystems and the teams and crossing borders and boundaries, it's not that hard. So we're going to be talking about the cultural barriers, the things that I've seen working in these banks.
You've seen this, or some form of this, right? The more you can capture the culture of what you're doing, the more differentiation and the more return you can get. This thing is like a nine-month loop over here. If you aren't delivering something in nine months, returns, your funding just went somewhere else. In large organizations, you guys know what I'm talking about.
So a little background. We talked about it already. It's not about DevOps and my company. I was in the National Guard for 15 years. I tend to bring a lot of my military lessons and ideas. It came with me. Actually pretty helpful.
So, org sizes. Current banks that I'm working for, plus companies that I am working with now, anywhere from 5,000, 50,000. You can see the scale. I've been working with organizations of all different sizes. The interesting thing is that the patterns tend to be the same at some level, which is a good and a bad thing maybe, but it helps us attack things with a pattern.
Banking, right? Everything you can imagine worldwide. Little history lesson: top four banks in 1990 were 35 different banks. So think about that from a culture perspective. The average age of the banks is 175 years old, right? So there's a lot going on.
Let's keep going here. Where I fit, I've typically been at a director or SVP level doing these things, usually a large team, anywhere from 30 to 150. And I had the, I guess, luxury of usually owning most of the teams to get work done, the deploy ops or the automation engineering platform teams, dev, whatever it is.
So where we started and why. Top quote, Arthur Ashe. And those of you that were at the last one, you've heard me say this: "Start where you are, with what you can." Right?
I'm going to go through some of the organizations real quick to show you the different starting points. Wachovia was kind of a startup where we had to very quickly kind of sell and grow the idea internally, right? We treated ourselves like a startup internally.
Wells Fargo, which acquired Wachovia, we had to take that service and then sell it so it was a surviving service in the combined organization. So we at that time had maybe, I don't know, 150 applications automated, went to 350 with Wells Fargo.
I moved to Bank of America. They had about 200 under-control applications. Scaled that up to 800 in the consumer banking division. And it was like 50 tools across the space. So we had a huge tool sprawl.
Bank of America number two, we then went up to the enterprise level. And that's like pro-ball politics at that point. It's very interesting. Whole different set of dynamics.
And then I have general clients like this: small, aggressive teams, mid-size. They might have problems like separate networks. Maybe they don't have any funding to do it. I heard people talking yesterday. We did all these things with no funding, like I think it was Paula, was it Thrasher maybe? She said things like that. So it's cool when you can get that done.
All right. Where we started and why. Real quick, I'm going to go over this, and then we're going to jump into it in a little while.
You start with friendly teams. It's the easiest way to get things done because otherwise you're just going to have a struggle for 12 months and get nowhere.
Find areas where you can focus and measure because the measurements are going to protect you as you go and you grow.
If you can find an executive champion, do it. I think in most cases, I tended to start with the grassroots. Once the executive felt safe putting their stamp on it, we got some money. It's the way it's going to work. At BofA, we actually had executive support, so that worked out.
And you want to be able to innovate, right? Because if you think it's not changing in nine months, it will. You have to have a place where you can adapt as you go and learn from what you're doing.
I would consider those probably the four essential ingredients to think, well, I probably have a better chance than failing 90% of the time like most transformations do, or whatever the measure was.
So we're going to talk a little bit about the problem space and the principles. So this is kind of giving you the breadcrumbs, right? Or the signpost. Why we did... If I could give you the list and say, "This is what you do to build an alliance," it might not work in your organizations. But if I can say, "This is why we did it," take that and use it in your organizations however you see fit.
So again, sounds a little philosophical. It'll start that way, but I'll bring it down to concrete examples of how we built alliances. Trust me a little bit on that, I hope, and we'll see where it goes.
Transformations, you've seen this before, I think earlier. 50% to 75% of transformations fail. So why does that happen? A lot of different reasons. I tend to focus on maybe three. It's either motivation, trust... well, trust drives everything. Motivation, trust, and fear of change, right? And we talked about that before.
There we go. Motivation: how the org behaves. Trust: how leaders are behaving. And fear of change: how we behave. I'm going to focus on the fear of change because I think that's where, when you're trying to do one of these things, you have the most control.
Motivation, for knowledge workers, it's really more about giving you autonomy than it is command and control, the old incentives, right? And in DevOps, we talk about misaligned incentives.
Interestingly, on trust, 51% trust senior management. That's pretty crazy when you're asked to do things and take a risk. But fear of change, again, where we're going to focus. Here's an interesting thing. We are biologically wired to fear change.
There's a book, Wired to Resist, where I'm getting this from, and Dr. Brit Andreatta talks about four different areas of the brain that say, "Don't do that. I'm going to get hurt." Which translates into psychological and emotional reactions. You go through predictable stages of grief, and what they found, further researchers, is that organizations go through these stages as well. So that's where we're going with this.
All this obviously is going to be available afterwards.
Culture. This is great. A four-minute clip, if you haven't seen it. This is The Replacements, "Spiders and Bugs." Right? We lost not because of effort or desire. Lack of leadership, lack of trust. Failed transformation, ineffective leadership, low trust, dysfunctional culture. That's kind of the pattern, right? It all hinges on trust.
Does that look familiar? When you start to hear language that says us versus them, you know that there's something you have to talk about. And we hear it all the time.
How about this? Ops, we want to do something. Change management, we want to do something. "No, no, no, that's not how we do it."
So our goal, or my goal here, would be to create a sustained transformation where we can manage the fear of change through actions of creating trust, providing the right kind of motivators for innovative thinking, and then drive new desired behaviors that are aligned to the business goals, right? If you're doing something that's not aligned to business, don't do that.
What's on your resume? It's not technical. If you don't think you're in DevOps sales when you're doing this, you need to rethink that, because you are. You're selling DevOps every day. You're inspiring, you're marketing.
I was actually a therapist more than I thought I would be, because people would come to me and say, "Hey, we know you can get a message to executive leadership anonymously. Will you do that?"
You're a coach, teacher, motivator, and student. That's really important. As leaders, you need to be able to say, "I don't know," "I was wrong," or "Teach me." You have to have humility. You have to check your ego. If you don't, the whole trust thing goes away, and then nothing goes anywhere.
This comes from, it's 2017, State of DevOps Report, transformational leadership. So DORA and Puppet Labs, it's vision, stimulation, intellectual stimulation, inspirational communication. It's falling in line, and I kind of like this definition myself: you commit people to action, convert them into leaders, and maybe create some change agents. You really want to create people to take your job. Sounds scary, right?
All right. Speed this up just a little bit. Change agent. You're going to be stepping on toes, so be ready for that.
This is Gene Kim: "Transformation leaders often put themselves in personal jeopardy," and I can attest to the fact that that will happen. We caught Gene at a party last night. That's a picture.
You're going to put yourself in personal jeopardy. That's okay. If you're the kind of person, the type of leader that can do that, you're always going to have a better job somewhere. It also helps you operate with integrity when you're doing these things, and it builds your trust.
So your first job, you're going to lead with vision and inspiration. You're going to forge that path. You're going to lead by example, and then you're going to get rid of yourself. Pass the torch. Make your team take on the leadership. And then if you have a movement where it depends on the charisma of the leader, it's not really a movement.
Some key points. We've talked about how culture drives an organization. It's made up of the sum of individual behaviors. Can't really change a culture directly. We can change behaviors that influence culture.
And if I'm in your way, just shout at me. I'm sorry, I keep walking this way.
These are your choices, and it's fearful. We talked about that.
Three scopes of leadership. You're going to lead the organization through change, potentially, either directly or by influence, because you're one of those influential people people look up to.
Usually, you have some kind of a transformation team, DevOps platform services, something. Protect that team. Keep them focused. Let them do their job. Keep management away from them. You have to put points on the board almost weekly, or else it'll end in nine months.
Oops, I skipped one. Probably the most important one. What we already talked about. You have to lead yourself with humility.
All right. Not bad. Now we're going to talk about the principles pretty quick here. And again, this is going to sound like we just talked about some of it. You've seen it in some of the other presentations.
So real quick on leadership. We just talked about this. Extreme Ownership is actually where some of these ideas come from, but it's about humility. The Servant is another book that talks about this. And so those guys, if you haven't seen them, they're US Navy SEALs who now do business consulting. How do you run businesses with team first? It's always about the team.
When I was in the National Guard, I got off the bus in basic training, and the first thing I saw was this big sign, Fort Sill, Oklahoma. It said, "Mission first, people always." And I wasn't really sure what it meant at the time, but now I do. Right? It's about your team.
I take it you've read this by now, but these guys, some of the top guys in the world in the military, and that's what they're saying: "Be humble."
This is one that was talked about twice yesterday that I caught: Turn the Ship Around!. There's not really a military theme here. I just happen to read these books.
Captain David Marquet turned a submarine around in less than a year. And that's what we talked about, right? The practices of the organization, you have to anchor it in the culture and decouple it from the leader.
How do you do it? He tells you a couple different ways, or, well, one way. Create an environment for thinking. Make everybody part of your thought process, not just the leader, because if the leader's gone, what happens? Nothing.
And you do it by doing two things: competence and clarity.
And clarity means you give them the why. Has anybody, Simon Sinek, heard or watched the... either read the book or seen the why TED Talk? If you haven't, you really, really should. And the same thing actually happens in the military. They give you the commander's intent. If you know why you're doing something, and then give them a couple of wide boundaries, let people go and do the work. But if you just tell them what to do, they don't know why they're doing things. That's the clarity piece.
The competence is, of course, you have to make sure they're going to do things safely. It's a constant investment in the engineering skills of your people. So this thing is basically a constant learning dynamic organization. You do these things and then give control and get out of the way.
And when you do that, and he actually talks about this, it's a 10-minute video where this came from. Does that mean that the software programmer can release to production? Yeah, it does. Push the authority to where the information is. In a bank, they won't let you do that probably, but that's the goal, right?
There it is. Create the environment for thinking, give control, create leaders, and then get out of the way.
Hysteresis curve for trust. This is great. Creating trust is hard to do and losing it is very, very fast, right? One bad meal, it's gone.
All right, so this is something you can take away right now. You're going to get measured on this: your integrity, your intent, your capability, and your results.
Do you have integrity? Are you walking your talk? Do your hips match your lips, right? What's your intent? It's okay to have an agenda as long as it's a good agenda. Be transparent about it.
Can you do the job? Do you have the capability to do it? And then are you delivering, though? Just because you can do something and you haven't delivered, right? That happens a lot.
So when people are deciding whether they're going to follow you as you lead them through these things, they're going to look at these four things. They're going to look for probability of your success because they're going to hitch their wagon to you. They're going to look for: are you legitimate?
Thirteen trust-building actions. So this came from The Speed of Trust. Actually, this hysteresis came from this, and this comes from The Speed of Trust, Stephen M.R. Covey, the son of Dr. Covey.
So here's something you need to take away right now. Take these 13 things. So like Ben Franklin's 13 virtues. Pick one next week and say, "I'm going to do this. I'm going to talk straight all week. I'm going to focus on that one thing."
And if you really want to start building trust, tell your teams what you're doing. "And if you catch me not talking straight, call me out in public on it. If you catch me doing it, call me out." That'll build some trust really, really quick because they know you mean it and they know that you want to be transparent.
Real quick on the motivation. There's three parts, right? Your biological motivation: survival. Traditional manufacturing motivation, where it's a carrot-stick approach, right? Reward, if-then kind of stuff. Works great for algorithmic processes. Doesn't work great for knowledge workers. In fact, it actually hurts.
So we're going to talk about this. The intrinsic motivation is really what we want to provide people with: autonomy.
Who here gets paid to contribute to open source? Why do you contribute to open source? Anybody? Because you want to. Does it give you a good feeling? Contributing to the greater society of good. Okay.
Could you, if you spent that time in your organization, get paid for it? Maybe. Not doing the open source thing, but getting paid for extra work, right? But you choose not to.
And you choose not to because there's a few things. You desire to direct your own life. You want some autonomy over these four things: time, task, technique, and team.
You want a piece of the action. Okay, for those folks that are as old as I am that actually saw it the first time around.
You have the urge to make something better that matters, and you know that you want to do something in the service of something greater. So this kind of goes to your startup mentality of protecting your teams, right? You need to inspire them to say, "You are moving an organization, a huge organization, in ways that nobody else can do." Right? Inspiring talk with these folks. Do something that nobody else has done.
All right. Fear of change. Here we go.
I think we all have reasons why we fear change, right? And ultimately, it goes back to trust. I can't trust the organization necessarily that I'm going to get rewarded for it or not punished for doing something, for coloring outside the lines. Right? Big organizations squash innovation.
And frankly, there's a lot of this, right? Fear of not being relevant, fear of losing my job, which is why I went back and said, if you want to be one of these leaders, just don't worry about losing your job. Maybe you will, maybe you won't, but it frees you up to make the right decisions.
All right. Here we go. So real quick, Dr. Brit Andreatta, she took different emotions, and she mapped it on this. This is not just about people. This is organizational fear of change. All these things are happening. And we know this. Think about the last change you went through. How did you feel, or people you know?
Finally, somewhere halfway through this curve, we're accepting what's going on. That's nine months down the road already. Two-thirds, three-quarters of the way, we're finally accepting it and saying, "Well, maybe there's something good here." Think of all that time lost.
You're engaged, you're impatient to get started, you're excited.
Okay, here we go. Let's flip the script. This is where we get into how do you take those principles...
Let me stop there. I got 12 minutes. Let's see. Is everybody okay with that so far? There's some internal, external leadership principles. There's how do you motivate knowledge workers, which is very different than motivating manufacturing. You need trust. How do you build some trust? Right? Now the fear.
So, we want to minimize the impact of fear. I think this is the one, and I picked this one because I think it's the one we have the most control over. The motivations, to some degree you can, but frankly, that's set by HR. And unless you're at the top of the house doing these things, so if there are any CEOs here, start at the top.
Minimize the impact. Shock, denial, same thing. You've seen this. Reduce the negative impacts. Accelerate the change. We can at least make it less painful if we do those things, right?
Looks like that. I would like that curve over the first curve.
How do we do it? Flip the curve.
Now you have commitment on the right, fear on the other side. Swap some happy faces.
Finally, we're getting to the title of the talk. You're going to start by building alliances down here using the principles we've just talked about. You're going to collect data, validation, communication. What you're doing is remaking mental maps. Thank you, Mirco, who brought that up yesterday in a session.
Remake the mental maps and references. What are you doing by doing that? These folks over here that are really afraid, you're showing them it's okay. Now they're like, "Wow, maybe they really do mean it this time."
Sad face goes away. Reducing the impacts. Accelerating the change. Happy campers.
Sounds simple, and you actually probably already do these things. Naturally, you look for folks when you're trying to do things, you're like, "Oh, these folks are with us. Let's try to do this." Just kind of formalizing it. And what you're doing is building trust.
So we flip the script. If you think that looked familiar, you're right. Everything you're doing is a product or service, even cultural change. Your transformation is a service.
So Crossing the Chasm, same thing. You're looking for early adopters. You're going to have to cross at a point where it's painful. You can do this all day long and nobody catches you. That's skunkworks, right? But then how do you actually breach it to management at one point, or broach it to management?
Diffusion of innovation, same thing. Oh, look at that. We're starting to get the change curve in there.
And I'm going to quickly flip through this because I want to talk about this. The way I look at it is you need to create an end-to-end value stream. Don't do a vertical silo of capability because, guess what, it's a theory of constraints. If you do that and you only have testing, but you haven't delivered that code, does it really matter? It doesn't.
Create end-to-end value streams. So everybody who's trying to judge you or decide if they're going to participate is going to feel it. From the operations engineer, release management, production support, testers, developers, right along the borderline, you can take a piece of code, check it in, let it hit prod, and everybody can see that reference model.
Because if you do it in verticals, you don't get that, and that just gives people a lot of time to think, "They're going to fail. I'm not going to help."
Marketing. We're back to marketing all the time. Testimonials, I use them all the time. You need to get beachheads with groups. Find a group, friendly group, and then run with it.
Okay, so here we go. Who are you dealing with?
These folks down here is what you want to do. Let's do it. I don't care what breaks. It's great. I like the enthusiasm, but let's be a little careful what we're breaking.
You have the next group. They want to help you, but they want to see if you're successful first. Should sound familiar because we talked about this.
These folks, they're always busy. It's not that they oppose you, but they've got other things to do, or maybe they just don't understand DevOps, which is common.
And then you are going to have some folks that are always against you for any number of reasons. Guess what? I don't care what the reason is, not going to waste my time there. It's not worth your time there because you're not going to get any return from them.
Start here. And by the way, this is a 25% star. If you get 25% penetration, you have tipped the curve. You now have momentum.
So let's apply that to alliances. Here we go.
Build consensus, trust, legitimacy, and probability of success with small but consistent, meaningful wins. You don't have to have a huge amount of wins, but you can't wait nine months to show something. So if you're in a nine-month tool war conversation, you just lost.
Learn and adapt. And even if you put something in place and learn from it, it is about learning. Learn what you can do in your environments.
Engage and communicate continuously, even if it's bad news. You don't want your executives to be surprised. And guess what? It builds trust. I don't like that guy's message, but I know he's telling me the truth when I need to hear it. Okay. I would hire that person.
Once you get past that, these folks start to hear the message, they see the data, and they say, "Okay, I'll give them my support."
Never ever, and I have down there, continue bypassing teams. Don't, I call it tripwire. Don't ever get caught in there because you just go nowhere.
We hit the tipping point. Now the big problem is these folks. You're going to have to manage this flow, and we had 100 onboards going at any given time. It's a heavy flow. But you have to stay focused, right? Because if you start to try to spread out, it dilutes what you're doing, and then you get slowed down again.
And again, just don't go there. Check with them. Say, "Hey, would you like to join the party now?" But don't spend time there if they're not ready. And it might not be that they're against you, but again, they might have something going on or they're afraid of the change.
All right. Building alliances and coalitions, just a quick review. Get your footholds, get the beachheads, and build legitimacy. Quick results. You have to get quick results over and over and over. Small ones, but always.
Create alliances and support, providing immediate relief if possible. Turn your critics into your friends. Find enthusiastic adopters. I think we talked about all these things.
If you can, do that. I'm going to flip through a bunch of lists here. This is where the list comes in. Pick and choose what you like. We're not going to go through them all, but if I started that way without understanding what the principles were, it may not have worked in every one of your cases. Right? So you can do these things, you can do these things, and you can do these things.
And you'll have all of this available, so don't hurt your wrist scribbling it out.
Adoption curve. So now we're talking about the data and startup mentality.
You want to focus. As early as you can, start collecting data. Baseline, most people aren't collecting data anyway, but you want to do that for two reasons, right? You want to be able to measure honestly where you are and how you're improving as a team, but also so that you can communicate to management and continue to get their support.
Data is all of these things. It is visibility. It's your defense against things. It helps you with internal selling more, right? Sorry, guys. Funding support. And if you have that platform services team, it helps you make that team better, right? High level of service.
Manage the team like a startup. Every day could be your last day, quite possibly. And so I heard this from the first person that ever hired me in IT many, many years ago, and he said, "At the end of every day, I measure myself and I say, 'Did I contribute P&L to the company?'"
And it doesn't have to be necessarily money, but what was my P&L? Did we make a positive change in the company or a negative change? And I always carry that with me. Every day I think that, at the end of every day. Did I do something good for the company? Notice it wasn't for me, it was for the company. Right? Team.
We just talked kind of about this. It's just really a summary. Here's an interesting point. People will buy with emotion and then later on justify with logic. You may or may not believe that, but I've heard that in several places, and I tend to think it's true. When I think I really want something, I'm like, "Yeah, I like it. I feel good about that. Okay. Is my wife going to buy off on that? What logic can I use to justify that?" Right?
Go through this. We talked about those.
So more data tips. Startup mentality. When and why do you need it? It helps in general, but if you have that platform services or transformation team, you have to operate that way. So you need to act in a very focused way and know that almost any time could be the last time you're doing it.
Stay focused. Go for product-market fit. And what I mean by that is what the customer needs. If the customer and the business needs are changing, you have to adapt with it. Don't just say, "Oh, no, we just invested $10 million in IT. This is what we're doing." Won't work.
Just a bunch of words there you can read back on. But we've talked about all these things, right? Attitude, purpose, inspiration, focus, payoffs. And actually, we didn't talk too much about that 80/20, right? There's no linear stuff here. Everything you do, look for the 20% that gives you 80% gain all day long.
And it's telling me two minutes left, so good. We're on track.
Nine steps. So let's pull it together and say, well, okay, if we were going to have a little roadmap for you, this is what it looks like.
Start at a deterministic place with your advocates. Establish a reference transformation, whatever that looks like. What is the reference? An application, a team, a service, maybe a cultural change or a process change, but show that you can do that.
Define the starting point. I tend to like going with core version control, artifact management, build, and then simple deploy. Application, application configuration. Just do that. You don't have to do everything. Don't boil the ocean. You might be making mistakes here, and if you try to do everything at once, you got to backtrack a lot and it costs money. Okay? That's your reference model.
Source to prod. Everybody can see it and feel it.
Baseline it, measure it, report it. Deliver that, report it. Communicate, communicate, communicate. Lock it down. Don't backslip on stuff. It's okay to pivot if you get new information, but don't backslip. And build on that success. Do it again. Move the ratchet forward and broadcast results.
So big ideas. Humility, grow yourself. Be the trust. Vision, inspire. It's your job as a leader to inspire. Communicate everything. Everything, even when you don't want to. Alliances, we talked about it. Focus. Don't boil the oceans. Focus on a couple things and do it well.
Deliver it all the time. Create end-to-end value streams, and emancipate, meaning, and I don't like the word empower. It sounds like I'm giving somebody something. I want to emancipate them. They are the new leaders. I step aside.
So last 30 seconds, right? As you can understand, or probably by now, motivation and getting leaders to understand it isn't just about your teams. It's about the leaders as well. Right? They need to get involved. They say, "Yeah, go teach my teams that." I'm like, "Yeah, no, you got to be there."
They still think they can buy it instead of be DevOps.
Culture is a shadow of the leader. I love that, because it is. Right? Technical challenges, we all know that, right? So that's the end. At least my thing's going off here.
And that's, I'll leave it. So thank you.