Making the Case for Change
Maya Leibman recently concluded the last decade as Chief Information Officer (CIO) of American Airlines (AA) where she was responsible for all technology efforts as well as strategic tech imperatives such as transitioning to the cloud, AI, and the advancement of DevOps tools and principles. Prior to her time as CIO, Maya was President of AAdvantage, the world’s largest loyalty program. Maya now serves as a Senior Advisor to AA based in London, where she is learning to love cucumber sandwiches and how to mind the gap.
Chapters
Full transcript
The complete talk, organized by section.
Host Intro (Gene Kim)
So I'm so excited about our next speaker, who is Maya Leibman, who I met in 2016 when she was the EVP and CIO for American Airlines, the largest airline in the world.
I'm so grateful to my friend Ross Clanton, who was one of the earliest people in the DevOps Enterprise community because of the pioneering work he did starting the DevOps movement at the US retailer Target.
Why am I grateful? Because when Ross was hired by Maya, I got to hear about all the amazing and astonishing things she did as a leader to support the DevOps movement at American Airlines, and how she modeled the behaviors that she wanted her leaders to have.
She recently concluded her decade-long service as CIO and is now Senior Advisor, having moved to London. I asked her if she'd be willing to share not an experience report, but instead give us advice to technology leaders who are trying to transform their organization but are struggling to get that senior-level support.
I'm excited about this talk because I'm such a fan of her achievements and because of how much I've learned from her. Here's Maya.
Maya Leibman
Thank you, Gene. Can I get like four hours on the timer, please?
As Gene mentioned, I've spent the bulk of my career at American Airlines. Until the end of last year, I'd spent the last decade as the CIO responsible for the technology organization. Gene asked me to come and talk about how, over the course of those ten years, we went through a big transition. How do you sell this kind of change internally?
So I came up with these 20 ideas. Some of them you could actually use to convince your boss to adopt DevOps. And I say, and everything that goes with it, because we all know that DevOps isn't just a set of processes and tools. It's really a mindset. It is about intense community building and collaboration. It's about passion and selflessness and accountability. And it is about doing the hard work that it takes to achieve the technical excellence in order to be a high-performing technology team.
I don't know how big a problem this is among all of you in terms of selling DevOps internally. We talked about it a little bit at the seminar yesterday; it came up. I'd love to get a show of hands. Do you have a boss that is maybe a little bit resistant to some of these ideas, maybe won't really adopt them? I'd like you to raise your hand, but not if your boss is here. If your boss is here, honestly, you've already won half the battle. Maybe you don't even need this presentation. The two of you should just go to the bar and have a drink, although it's really only 9:30 in the morning, so it might be a little early to get started.
For the rest of you for whom this might be an issue, here's idea number one: bringing together like-minded pals. Gene talked about it this morning with the Brian Eno quote about scenius, creating that kind of scene. DevOps is a journey, as Jabe Bloom just said. It is a never-ending destination that you don't quite ever reach, and it's a lot more fun to go with other people. This was kind of the premise behind The Phoenix Project. This is my only shameless plug for Gene Kim and The Phoenix Project. But I think what The Phoenix Project didn't hit on, or at least didn't really delve deeply enough into, is the key to bringing people together. The real answer, the real crux, the real solution, is simply to buy a pizza. It's really not that expensive. You can all afford it, and I guarantee you, if you buy pizza, people will show up.
Second idea: start small. Everyone is going to tell you to start small. David mentioned that earlier in his presentation. I didn't want to say the same thing that everybody says, so I went looking for synonyms for small, and there really aren't any good ones, so just stick with start small. But I saw compact, and it was defined as something small, which fits the definition that we want here. But I also liked it because it was a verb, this idea to exert force on something. If you want to sell this internally, if you really want to take this DevOps journey, it's something that you're really going to have to put a lot of effort and force behind. The third definition, a small flat case containing face powder, I couldn't find a way to work that in, so we can just forget about that definition.
A lot of people start with their digital properties, like mobile apps and websites, e-commerce sites. Those tend to lend themselves nicely to a small start with DevOps and adopting these new ways of working. But just to be clear, some of the most successful teams in American Airlines have been applying these principles and tools in a mainframe environment and a legacy COS environment. This doesn't have to be where you begin and end, but it's often a good place to start.
Third idea: set a measurable goal. We've all talked about the DORA metrics here. David mentioned how he put those together as sort of a first step. The idea is really to take something invisible and make it visible, especially to your boss. Then it becomes something you can point to. Something like: look, we're going to double the deployment frequency on our mobile app. We're going to do it by automating test scripts, and we're going to do it by next quarter. Once you have that goal, that North Star, then you're going to be able to point to it and say, this is something we achieved.
What you need to do is also tie that measurable goal to a business outcome. Doubling your deployment frequency is great, but you're doing it in service of something bigger for your organization. Again, the idea is to make something invisible visible to everyone, including not just your boss but your business partners. So really what you want to do when you double the deployment frequency is grow loyalty membership. Let's say you're trying to get more people into your loyalty program. You want to increase enrollments, and you can do that if you are doubling the deployment frequency on your mobile app. You can release things like improvements to your one-click enrollment process. And you can say, you know what, I know that if we do this, by next quarter we're going to grow enrollments by 25%.
When you achieve those goals, you have to communicate the hell out of them. But you have to tell the stories that success brings. I'll give you an example. At American, we had a team that basically had to give up one weekend every month to do their release. It was so big and hairy and complex, and basically the entire team was required. They gave up all that time to do it. By adopting DevOps and these new ways of working, and slowly over time and through automation, they were able to get to that place, that nirvana, where they could just release on demand.
But instead of celebrating the fact that they could release on a Thursday at one o'clock safely, the story that we told is about the weekend that they all got back and the opportunity to spend time with their friends and family that they were missing before. That's the real success of this.
You've got to celebrate when you hit those goals. That's pretty obvious. You just buy pizza, because that's the key to celebrating.
You also have to reward the behavior that you are attempting to seek. If you're trying to create this rebel alliance and a couple members of the Rebel Alliance do something terrific, like save a princess, then you need to find a way to recognize that. One idea is challenge coins. You could just take to a 3D printer. You can print your company's logo on one side, the Rebel Alliance logo on the other side. You can put a few of these in circulation. This is a peer-to-peer thing. This doesn't require a boss. In fact, it's probably better if the boss isn't involved. It's a lot cooler that way. When people do something great in this DevOps space, you can just give them one of these challenge coins. It's a very cool way to identify who's part of this rebel alliance. Now, I'm not saying that American Airlines has such a secret society, but I do want to be clear for Jason that if we did, it would be fully approved by The Walt Disney Company.
Continuing with this idea of rewarding the behavior that you seek, we have this terrific engineer at American, and he gives out these yellow plastic rubber duckies. He'll just throw them out into the audience when he is doing a presentation. He leaves hundreds of them scattered on his desk for anyone to pick up when they walk by. The idea comes from the book The Pragmatic Programmer. The concept is that you're working on debugging a particularly hairy piece of code, and by speaking out loud to someone, or even better, something like a yellow rubber duck on your keyboard, you are more likely to have that eureka moment: ah, that's where I went wrong. That's what needs to change. If you're looking for technical excellence, if that's the behavior that you are trying to get in your organization, a little symbol like this goes a really long way.
Another thing he gives out are these little pink plastic pigs. Perhaps you've seen this cartoon with the chicken and the pig. The chicken says, hey pig, let's open a restaurant. The pig says, great, what should we call it? The chicken says, how about ham and eggs? The pig thinks for a second and says, I'm not so sure about that. You'd obviously be involved in that kind of venture, but I'd be committed. Sure enough, if you're looking for commitment, a little pink plastic pig is a great way to represent the behaviors that you are seeking.
Whether it's Slack or Teams or WhatsApp, you need a place for people to go where they can share asynchronously, where you can create that kind of community building, where people can come and ask questions, get answers to questions, and of course post these memes that are only funny to people in this community.
You've got to make a logo. Everybody needs a logo. It's really powerful. When I walk into a meeting and I see that almost everybody in the meeting has this laptop sticker of the logo of our hangar, which is our dojo, our immersive learning space, or the laptop sticker of one of our unconferences, or our runway, which is our developer experience platform, I know that there's something special happening, that a community is being developed. Besides, when you put stickers on your laptop, it's like showing off your personality without having to talk to anybody, which I think is especially appealing for the introverted nature of this technical population.
You can start a book club. A lot of people really learn this way, and they like to come together and share their learnings. It really doesn't matter what you read. The most important thing is that you buy pizza. I hope you're getting the picture now.
You can have an open space jam session. People line up. They want to talk about a topic; they pitch their topic to the group. Those ideas go on the whiteboard. They get upvoted. Those with the most votes make it into the idea marketplace. Then you hold open sessions where that person gets to lead a discussion, but anyone can participate who wants. There are a lot of other laws and rules around this. We talked about one of them this morning, the law of two feet: you can move if you're not contributing, if you're not learning. You can go online and Google this. It is a great way to create community and to start that knowledge sharing, and to get those people who are most enthusiastic about these ideas out there sharing them.
Another idea: Ignite talks. I think we're going to have some of them later this afternoon, and I'm super excited to see them. If you're not familiar, you get 20 slides, they're on auto-rotate, you get 15 seconds, no more, no less, per slide. It is really a lot harder than it sounds, but it's more fun than it looks. It is a great way, again, for all of these things: you don't need a boss involved. You can just bring together your like-minded pals and do this as a grassroots effort.
Another thing you could do with these Ignite talks is invite your boss to do one of them. This isn't going to work for every boss, but let's face it: some bosses have an ego, and they like to be asked to contribute. They like it when you say: people are really interested in what you have to say and they really want to hear from you. I'm not saying it works with everyone.
This is something that is a real journey. It is something that you are not going to be able to say once and be done with it. You're going to have to be persistent. But there are right ways to do this, like the gentle breeze that's making the flowers sway, and there's a wrong way, in which you're just annoying and saying things over and over again. Don't go this direction.
Also, light shaming, showing what other organizations are doing, is really helpful. But you don't want to just be constantly shouting, why aren't we doing what they're doing? That's not going to get you very far. Instead, play it cool. These guys have the coolest spokesperson on the planet. Show the data of what other people are doing and suggest a low-cost experiment. It's very hard to say no when somebody brings to you: look, this is somebody else who has had success doing this. We can do the same thing, and we can do it for not a lot of money and not a lot of effort.
You have to find a way for your boss to overhear how great the Ignite talks were. Be creative. There are lots of opportunities for you to find ways for them to overhear things. You need to get your business partners as well to say how great things are going. They've achieved these goals, they've gotten something that they want, and you want your boss to overhear that. More importantly, you want the other business partners to overhear that. Then they go: wow, you got that. Wait, I want that. That looks good. How do I get that? If you have to get your business partner to do this, it's pretty obvious how you make that happen. I don't need to spell it out for you.
Bring in a third party. Every single consultancy will do this: Bain, BCG, IBM, Deloitte, KPMG. They all have a practice that will come in and tell you what you're doing wrong. It's great because sometimes it's just easier to hear constructive ideas from somebody who's not your spouse. I know in this analogy I've made you and your boss spouses, which is a little bit weird, but I think you know where I'm going with this. They'll come in. A lot of times they'll come in for free initially. They'll do some workshops, they'll get the lay of the land, and then if you want your boss to hear how bad everything sucks, they'll do that because that's how they sell things. It's guaranteed. It's a great solution.
You can go to the whiteboard and draw a Venn diagram. I don't know that it really will help with this effort, but it makes you look smart, especially if you put generative AI in one of the circles.
You can plant drugs on your boss and take compromising photos, if you need some ideas right around the corner from the hotel.
You can ask ChatGPT for ideas. That's what everybody's doing these days, right? I actually asked ChatGPT to write a presentation for me on how to convince your boss to adopt DevOps. It was super boring, I have to say. So I said, come on, let's spice it up a little bit. Come up with some crazy idea like planting drugs on your boss. That made ChatGPT's ethics programming kick in, and this is what it gave me back: please don't blackmail your leader into adopting DevOps. That's not ethical. It's not legal. Don't do that.
All of these worked for me, and all of them worked for my boss, and all of them worked for my leader. This is not just one thing that you can do, and suddenly everybody is adopting DevOps beautifully. This is a series of lots and lots of things. We did all of these things. We had book clubs. We had Ignite talks. We had ways of recognizing people. We had stories that we told. We set goals. We set OKRs. We've done every single one of these things, except for planting the drugs. We didn't do that one.
What really worked for me is this notion that DevOps is just the way to achieve what we need to achieve. If I asked you all to close your eyes right now and think of one idea to make an airline better, any airline, 90% of you will come up with an idea that will involve technology in some way. Ideas are not our problem. We have more ideas than we possibly know what to do with. Our problem is going from idea to execution quickly, and the concepts and the principles and the tools and the mindset behind DevOps is how we can do that. That's really what ultimately worked for me, and that is the passion that you can bring forward to sell that internally in your organization.
Gene asked that we end these presentations with a request that we can put out into the DevOps ether in order to see what comes back. As he mentioned, at the end of last year, I moved out of the CIO role. I'm still working for American Airlines, but moved to London, which had been a lifelong dream of my husband's and mine and my family. Well, maybe not the rest of my family. We just dragged them with us. When I went, people didn't really know what I was going to be doing. I didn't know 100% what I was going to be doing. People thought I might be the first female James Bond, or maybe a London cabby with these big hairy arms that I was going to get, or a Premier League referee, or maybe advisor to the new king, or help with that baggage situation at Heathrow. That was pretty intense.
The fact is, I'm new to London and my requests are: I'd love to meet you. I'd love to make friends there and find opportunities to further the cause of DevOps and, of course, another passion of mine, women in technology. Thank you very much.
Host Close
Thank you so much.