Loading summary
Transcript25 lines
- [00:01]
A
We've all been through mandated change initiatives more times than we can count. But what if change wasn't a mandate, but an offer or even an invitation? In this episode, how to make Change irresistible. This is Coaching for Leaders, episode 770, produced by Innovate, Learning, maximizing human potential. Greetings to you from Orange County, California. This is Coaching for Leaders and I'm your host, Dave Stahoviak. Leaders aren't born, they're made. And this weekly show helps leaders thrive at key inflection points. One of the key points that's an inflection point for almost every leader is leading change. Leadership is the answer to change and change is ever present for all of us. And yet it is a challenge that really confounds so many of us in leadership of how do we lead change well, and not just do it, but, but do it in a way that it really stays with an organization. Today, I'm so glad to welcome a guest who's going to help us to look at change not just in a way of managing it, but actually to make change irresistible. I'm so pleased to welcome Phil Gilbert. He is best known for leading IBM's 21st century transformation as their general manager of design. The transformation became the subject of a Harvard Business Review case study, the documentary film the Loop, and feature articles in the New York Times and Fortune magazine. He is the author of Irresistible Change, A Blueprint for Earning Buy in and Breakout Success. Phil, what a pleasure to have you on.
- [01:40]
B
Thank you, Dave. It's a pleasure to be here.
- [01:42]
A
I was so captivated by your story and I think it was really interesting that you showed up at IBM because the company that you were CEO of was acquired by them. And you talk in the book that your plan was to stay for a year and then a couple of months in my sense was not only were you thinking of not staying for a year, you were trying to get out sooner after the experience of working there for a few months. What was that like that, that coming to IBM and that those first few months of your career there?
- [02:14]
B
Yeah, yeah. Well, you know, starts with the fact that I view myself as a startup guy there. At least I did at the time. And when we got acquired that was my third startup. And when we got were in the process of being acquired by IBM, I kind of assumed that startup number four was the next thing to do. But at the same time there was going to be a transition period where we needed to kind of integrate ourselves into IBM. And I felt a loyalty, if you will, to my team to the company to help everybody through that period and to also help IBM. It was a great exit and I appreciated the fact that IBM was going to take care of our customers. And so I wanted to kind of make sure that that whole transition and integr worked well. So I kind of made a mental commitment to myself and, and, and, and a moral commitment to the team that I, that I would hang out for the roughly one year that we thought it would take to kind of get integrated into IBM systems. But when I got there I found a culture and a company that was kind of not just big, but really the antithesis of a human centered organization that wanted to deliver new and great outcomes for its users. And yeah, I talked to my team and I said I'm going to get out of here as quickly as possible.
- [03:41]
A
You're a product guy. What was different about your approach to change and culture around change than what you were seen at IBM at that time?
- [03:53]
B
Well, my, my overall approach and it started in the, in the early 1990s actually. But I got introduced to design as a, as a formal practice and its application to digital products back then. And I started to also get introduced to this notion of what we now call design thinking. It wasn't called that then, it was just being formed then by David Kelly and Bill Moggridge and the folks at ideo. But I got, I got exposed to that and I realized the power of design and design thinking as a lever to scale quality. That was where I was coming from. And it was essentially built around the notion of gaining empathy with the people that you were serving, the people that were using your product or service. And this notion of everything is a prototype and nothing in market should be thought of as a static finished thing. There was always, always something that could be made better. There was an innate curiosity about the human condition and about again, the people that you were serving. That spark of everything is centered around the user and their problem and their use case and the curiosity to constantly poke away at it and constantly make people's lives better as opposed to just selling technology was what I found was missing. And I had also kind of walked into a company that had been hollowed out by a bunch of at the time financial engineering and kind of the, a priority of hitting numbers that had been pre committed to Wall street no matter what the cost was to the culture and to the physical plant. And so when I walked into IBM in January of 2010 and we were moved into their offices in Austin, Texas, which is where my company was located, and where we were integrated into, I mean it was kind of out of the movie office space. It was fluorescent lights, about 90% of which worked, locked doors, rubber plants and waste cans in the hallways and ragged carpets. And I was just amazed that not only the, the culture that had been kind of whittled away at because of the need to hit numbers as well as the, the condition of the physical plant, which was just a everyday manifestation of this kind of uncreative environment that I had walked into. And that's what really kind of I, that's when I said, I don't see myself being here too much longer.
- [06:30]
A
You write in the book that change should be regarded as a high value ad product that deserves the same levels of resource support and operational rigor as any of your top performing products. I don't think most leaders think about change as a product. Could you tell me more about why that's so significant?
- [06:51]
B
Yeah. So as I just described the IBM I walked into, I, when I went to actually resign, what the senior vice president actually suggested was he said, you're looking around at things that exist and we need to change, we know we need to change. What can you do to help? And essentially the remit was can you make, originally a small part, but ultimately all of IBM, can you make that look more like your little company, a startup and less like IBM looks today? And as I thought about that problem, you know, here was a company at the time with about 400,000 people and none of whom reported to me, or only a very few hundred reported to me. And I was being asked to change how everybody worked in a really fundamental ways as well as change the environment itself. And as I kind of thought through that problem of how do I get, how do I get a whole bunch of people to do something that they don't, they don't, they don't even know exists. And they may not necessarily have the incentives around them to, to, to reinforce its adoption. How do you make that happen? And it occurred to me that that's the exact same problem that every startup faces. Nobody knows you exist, they don't know your name, they don't know your product. And in fact the, the forces of inertia work against adopting a new thing. And that was when it struck me that this, this remit of how, how can I transform IBM was the identical thing that I had worked on in every one of my startups, which is how do I bring something new into the world? How do I get the world to notice it? How do I get the world to Pay for it and adopt it, and how do I grow, grow the market for it? And as I looked around IBM, I saw 400,000 people, some four or five thousand teams, working on anything at any given point in time. And I realized that that's my market. And this, this notion, all of the things that I had to do or that my team had to do to help transform all of those people and all of those teams, if I approached it just like I approached getting a product into the marketplace and have people willingly adopt it, not only willingly adopt it, but have them pay for the privilege of adopting it, if I could make it that valuable to every team, then we could, we could get this done. And so that was the epiphany of, of this notion of change as a product. And it has a ton of implications once you move into that mindset. All of a sudden there is no mandate, just like for a product in the world, there's no mandate for people that have to use your brand new startup's product. You have to entice people into it. You have to seed the market with a few customers, if you will. And you need to get those customers to adopt it. You need to get those customers to tell their stories to all their peers, and then you need to go sell it to their peers. It flips everything from the traditional change program, which is typically mandated, and therefore the responsibility for the success of it is on the employee. It shifts that responsibility completely. So now if the teams and the employees don't embrace my changes, it's on me to figure out why I made it. I forbid anybody on my leadership team to use the words they just don't get it. Which is typically what you hear from change leadership teams. When people resist, it's like, well, they just don't get it. Yeah, that was forbidden. Because if they didn't get it, that wasn't their fault. It was our fault. And we had to figure out why.
- [10:45]
A
You mentioned kind of changing things from what, from the way they're typically thought about and done to a different way. And I think that's one of the things that's so powerful about your work and your message, Phil, is some of the key distinctions in thinking about change that really struck me as ways, I think a lot of us don't often think about change. And one of them is you write in the book. If there's one thing you take away from this book, I hope it's this. At every critical decision point, the change program must be architected on the mission of sustained cultural adoption. Of, of the thing as opposed to improving immediate competency in the thing. That seems like a really critical distinction to me. Could you say more about that? And what do we often miss in that distinction?
- [11:33]
B
Yeah, the easiest example, you know, I get called in all the time to help coach and consult with companies and CEOs and chief transformation officers. And the typical story is we've been doing this for a year, we've been doing this for 18 months, we've had multiple quick wins, we've been following John Cotter's book, and yet nothing is sticking and everybody's going back to the old ways of work. And when I dig into what they mean by win in this context, and this is just one example of what I'm the bigger issue that you bring up. But one of the things that most change programs get wrong is what is a quick win? Yes, a quick win is for whatever project you're working on to have a great outcome. And you're using the new thing. You're using AI, you're using design or design thinking, you're using agile for the first, whatever it might be, whatever change you're introducing, which I call the change provocation, you introduce that thing and the outcome of the team is better than it would have been. That happens all the time. It typically happens, by the way. Yeah, but the interesting thing is that doesn't necessarily prove anything to the organization about the scalability and the sustainability of the change. And so people typically get wrong that we're going to go make a team's outcome better and we're going to tell the world about that. That's only a subset of what has to happen to prove that the approach is going to sustainably change the organization. And so, for example, one of the chapters in the book then goes into, so here's how you should think about the very first teams that you introduce the change to. Here's how you should think about where the teams come from, what the team's attributes are, where they live, where they're funded, what systems they're impacting, those are the things that, when you start telling the story of that team's success. And more importantly, when, when those people on the team tell their stories to their peers about this new thing, they're talking about it in a context that is going to get their peers going. Oh, that's my world. You know, typically change programs will start oftentimes with tiger teams or innovation teams, or they'll, they'll pop up some part time, part time team and bring in the best people in the organization to kind of do the new thing. All of those things are outside the context of the mainstream teams. And so even if that team gets a win, it doesn't prove anything to the organization about how the new changes can impact the real world and the real systems that they're interacting with every day. So that's what I talk about when, when I talk about, you have to, you have to make sure that you're cultivating the, the attribute in a, in a way that communicates to the organization that you're impacting the mainstream world as a boat as opposed to just teaching a tiger team or an innovation team or the first team you choose. You've successfully inserted AI because that doesn't prove anything to the rest of the organization.
- [14:57]
A
Yeah. And I was really struck by how intentional you and your team were about working with the line teams and organizations that were already existence inside the organization. And also how intentional you were about which of those teams you would select. And also all the teams that you would say no to or the people would come asking for a little bit of support or help or could you spend just a little bit of time with us that you really dedicated time and attention to some very specific teams started there in order to do exactly what you just described.
- [15:29]
B
Yeah. Again, it goes back to this notion of a product and in a startup what you will typically do in a business to business startup. Anyway, it's a little bit different in the consumer world, but in a business to business startup you would pick one or two companies that are known to be friendly and early adopters of technology and products and you would typically give your product away to them and you would work with them very closely for a few months and then it would be their recommendations and their successes in their mainstream world that you would then go market to the rest of the industry. And so it was very much the same thing with the methodical approach that we took to which teams we approached first and then as we started scaling out which teams we let into the program and one of the other kind of failure points in this, as we're having this conversation, one of the other failure points that I see oftentimes is teams will come in and they'll, they'll get the new thing and they'll work with it and they, they'll have their success and then typically they'll be allowed to go back to the old way of doing things. They may have even been staffed with part time people that had a couple of jobs, they had this new innovation team job, but they Also still had some of their old day job that they still had to do. We didn't let anybody have their feet in both worlds. Once you were into our program and we named it, we branded it, it was called the Hallmark program. Once you came into the Hallmark program, you were in the Hallmark program. And from that point forward that team only worked in the new world forever and ever. That one way door was it again is, is very different from the way I think a lot of change programs are architected at the outset. People are a little bit afraid. Sometimes it's fear, oh, what if it doesn't work? We need to kind of have our feet in both worlds in case something goes wrong with us. It was kind of a no net approach which is we're going to come in and with these, with the first teams if it fails and we picked very high profile projects if it failed, it was going to fail in a very high profile way on some very important projects. But at least we would know that it had failed and we could move on. We would get the answer quickly. It didn't. And because they were high profile, because they were mainstream teams, it proved to the organization that this set of changes were effective and we should continue on the path.
- [18:04]
A
You made this point a few minutes ago that you don't mandate change, you offer change and that that really puts the onus of the work on the leader and how they show up and you mentioned that there was certain language you didn't like. It's not okay to say they don't get it. Right. And I'm curious that in the context of that one way door, how do you offer change without mandating it but at the same time have something where you're all in on something. How does that work as far as that being the both and.
- [18:38]
B
Well, yeah, great, great question. And I think it's critical. You know, mandates create compliance but they typically don't actually move the needle on the outcomes all that much. And you get a lot of compliance theater because of mandates. And so I think it's super important that, that individuals and teams have agency and they get to choose whether they opt in. I have a fundamental trust in people and it's been my experience that nobody shows up to work wanting to deliver crappy stuff and nobody shows up to work wanting to work longer hours than they need to work. And so if you introduce a set of changes to people and they don't willingly adopt them, it's probably because the thing you're introducing doesn't actually achieve the goal that you think it's going to achieve. And so you need to work with those people to understand why and tweak it and adjust it at the edges and get it so that they will willingly adopt it. Having that agency makes all the difference in sustaining the change over time. People willingly adopting something, the sustainability of whatever they will of what somebody willingly adopts is a thousand x the sustainability of something that they're merely complying with. The way that we implemented that agency was there was a very specific one week onboarding experience for every team that came into the Hallmark program. In the first few minutes of that experience, I personally walked into the room and said, if at the end of this week your, your project hasn't advanced, we didn't do generic training. All of our, all of our training was in the context of the actual team's project. And I said, if you, if your project hasn't advanced 10x what it would have advanced this week, you should exit the program and you'll never hear from us again. Go back to your old ways of working. Now, nobody ever took us up on that offer, but that was the offer all the way through. You could always exit the program and go back to the old ways. You, every team had that agency to do that, but it wasn't built into the system. In other words, once they, if they. Nobody ever did. But if anybody had exited the Hallmark program, they wouldn't have heard from us. We wouldn't be continually trying to drag them into the program. At the same time, if you were in the Hallmark program, you were in and you had our support all the time. If you ran into roadblocks, you, you were being reported on to the senior leadership of the organization as being part of the Hallmark program. You got all the benefits of doing that. And there were several incentives that were, that were provided for teams that were in, but there was always the agency for an entire team to opt out. And that agency was what made all the difference. And it's why I firmly believe that mandates typically work against themselves as opposed to for them. Even though in the short term there may be measurements, systems that show the compliance, but you don't necessarily get the outcomes that you're trying to get by the change in the first place.
- [21:52]
A
Hmm. I'm so glad you mentioned that onboarding week because obviously how you start is so critical and then what you're trying to do first really matters. And you write on this if you want to learn from the IBM example and lead change that sticks. What I've learned is that you need to do everything, start as small as you like, but cover every base on that reduced scale. And to make this point, you have an analogy which I love, of cupcakes, birthday cakes and wedding cakes. Could you share that analogy?
- [22:23]
B
Yeah, sure. We started it with some of the product teams that we would work with. You know, when you envision a product, a solution, a service of any kind, when you envision it, you envision this end state thing. Think of that as the wedding cake. But in our world, in our agile world that we live in today, we rarely have the luxury. And frankly, just from a humility standpoint, we don't necessarily know what the wedding cake needs to be in the real world. We have a vision for it, but that wedding cake vision is kind of out there. When we actually get to delivery, we have to deliver something this month or next month or this week or next quarter. Whenever it is, we have to pare back that ultimate vision. And when you start thinking about paring it back, you can start thinking about a birthday cake. But even a birthday cake may take several months to finish in the context of a, of a product. And so we have this notion of a cupcake. Now, what typically happens in delivering anything, a service or a product, what oftentimes happens when we start cutting from that wedding cake vision? A lot of times we start, we kind of take the customer out of the equation. And what we start cutting a lot of times are the hardest things to do. And we will deliver something, but we'll deliver something that covers 80% of every use case. Let's say our wedding cake covered 10 use cases of some human. When we start cutting in order to deliver it, when we have to deliver it, what we oftentimes deliver is something that does 80% of, of each of those 10 use cases. And so we came up with this metaphor of when, when we deliver anything, we want to make sure that it's not a half baked slice of a wedding cake. It's actually a beautiful cupcake. It's only a, it's, it's a small version of the wedding cake, but it's a holistic thing in and of itself and it solves a problem. Now we may have to release 10 cupcakes to get to our wedding cake, but every single one of those cupcakes is going to solve a hundred percent of some part of somebody's problem. And so that notion of cupcake, birthday cake and wedding cake became something that was ingrained in our product teams. And it was a useful way for, for everybody to, to really understand oh, I've got to continue thinking about the user's experience. And even though we have to start small and deliver something quickly, it has to completely overwhelm them with love and delight. Which a cupcake can do.
- [25:12]
A
Yeah. Oh, for sure. And this may be a bit meta, but I was thinking about this just in the context of our conversation and what I typically do on episodes of this podcast is there's the tendency always, when talking with someone or talking about someone's book or their work, to try to cover everything in 30 or 40 minutes and. And it'd be like trying to put together a wedding cake, and you'd end up at the end with something that would be pretty lousy, and it might sort of at a distance, look like the cake, but then when you got up close, it just doesn't taste right. It's not. Not satisfying. And the distinction that I think about is like, wow, your analogy makes me think, like, I'm. I'm spending so much time really baking cupcakes is like, let's have a conversation about one really specific part of a person's work, like we're having in this conversation, and do that really well, I hope, at least I attempt to. And by doing that, then someone would say, wow, that was really helpful. Great. They go on. Or they say, hey, I need to get it, and get the book and really get into the details of, like, what Phil's talking about. And I think so often we do. We all, well, meaning, want to create the wedding cake. Of course we do. Like, we want to get to that outcome, but we're doing a lousy version of the final product versus doing something that actually serves the customer, whoever the customer is.
- [26:31]
B
Right. I think you're exactly right. We've spent a lot of time just in the last 20 or 30 minutes talking about this notion of the first teams and just that team selection. What's it take for a team to win? And what does a win mean in the context of a program? But this thing about teams, it really is kind of teams and the notion of change as a product are really, really fundamental to getting to getting it. All right. That is the cupcake, for sure. The first cupcake that needs to be baked.
- [27:03]
A
You talked about branding a few minutes ago, and I think that's such a key point on this as well. And something we don't often think about when we think about change. And you remind us that people respond to brands. People buy brands, they don't necessarily buy products. And there's a strong invitation you make to Correlate that branding into change. Tell me more about that and what that looked like at IBM.
- [27:27]
B
Yeah, you know, I think most, again, kind of looking at reasons that a lot of transformation programs fail. And today we're seeing it. We're seeing it manifest in spades. With AI, everything is branded AI. AI. AI First. AI First. And that does two things. First of all, you're using a word that every single person in your organization think they understand, or at least they know they have feelings about it. And when I started talking about how this came about was when I started talking about design and design thinking, everybody had their preconceived notions about what that meant. And I realized that I could either, as I thought about 400,000 people, I could either try to change everybody's mind, or I could come up with some neutral word. And when I started thinking through that problem, I was like, wait, I'm talking about a product. We have this product mentality. Of course it needs to be branded. And if you. What it. What it then allows you to do is as you. As you get away from using a word like AI or design, it does two things. First of all, it allows you to define what this program means to the individuals you're trying to serve and that you're trying to change and get to adopt the change. It also frees up in your own head all of the things that have to be changed around that thing. When you start thinking about, I'm going to do an AI first initiative, all of a sudden you've already committed to the solution and you've already kind of focused not only the people that you're trying to get to adopt the change, but you've also focused the leadership and the program team that it's all about AI or it's all about design, when in fact, about 50% of the work is going to be on the systems of the organization around that, that thing that will reinforce its usage over time. And so as we thought about the brand, we chose this word, as I said earlier, called Hallmark. As we thought about this as a brand, then all of a sudden it not only freed us up into being able to change things way beyond what appeared to be our initial scope, it also allowed us to insert the values underneath the changes that were actually more important than the tactics of the change itself. That's kind of abstract. So let me make that kind of clear. When you're talking about design thinking, for example, there are certain practices and certain things that you do to help understand your users, gain empathy with them, scale that empathy across teams, et cetera, et cetera. But that really doesn't speak to the values of what we were trying to do at IBM. And at IBM, ultimately, the values underneath the hallmark program became three things. One is the user became our North Star. The second is we were going to continuously iterate, what we called restlessly reinvent. And the third value was we were going to do this through new, diverse, empowered teams. So this notion of the users are North Star, we're going to constantly iterate, and everything is going to be a prototype at all times. And this notion of interdisciplinary and diverse teams that were newly empowered to move quickly, these became values that everybody could embrace. Nobody wanted to refute those values. And then we layered the actual tactics of the practices on top of those, and they became so much more interesting to the people as ways to get to these core values as opposed to just introducing the technologies and methods that we were trying to get them to adopt.
- [31:30]
A
Phil, hopefully we've done a good job of putting together a cupcake for everyone listening. And if you're the kind of leader who is in the process of handling change, and especially if maybe you've been doing it for a bit and had some quick wins, but you haven't quite seen the change happen in the way you want, I hope you'll take our invitation to get into the birthday cake, the wedding cake, pick up the book, and really get into the details of how this happened at IBM. It's a fascinating story. And Phil, one last question for you. You know we're talking about change. There's so many things I know you changed your mind on as you went through this process, as you learned and have grown and now supported other leaders. When you think back to everything you've learned putting together this book, what's one thing you've changed your mind on about change?
- [32:18]
B
Yeah, well, the biggest, the biggest learning I had was the role of middle management, which I had mistakenly. The notion of the frozen middle and that the middle management are the resistors of change. I thought that was just truth. And I learned unfortunately, very late in the process that that was actually not the truth. And it was my own bias and the bias of the program that I architected that prevented us from understanding what was really holding middle management back. And once we figured that out, it was a huge, again, accelerant of this, of scaling the program. And so my, my big learning in the process was the role of middle management is one of the most critical accelerators of change, if you get it right.
- [33:08]
A
Phil Gilbert is the author of Irresistible Change A Blueprint for Earning Buy in and Breakout Success. Phil, thank you so much for sharing your work with us. I really appreciate it.
- [33:17]
B
Thank you Dave.
- [33:24]
A
If this conversation was helpful, three other episodes you should check out. One of them is episode 571, engaging people through Change. Cassandra Worthy was my guest on that episode. We talked about the human aspects of change, the emotion, of course, so much of that, so critical and change initiatives. And yet oftentimes we only think about or we primarily think about the process, the procedure of change. Yes, that's important of course, but without the human parts of it, it does not go very far at all. Episode 571 to really zero in on that. Also recommended episode 650 where senior leaders Can Better Support Middle Managers. Emily Field was my guest on that episode and we talked about the reality that happens in a lot of organizations, which is oftentimes we think a lot about customers, external stakeholders. We certainly think and know about what senior leadership's thinking and we're often thinking about what employees are thinking. What is missed often is middle managers. And middle managers are the heart and soul of most organizations and are also the determining points as to whether or not a change is going to happen successfully. Without getting middle managers on board, you're not going to get very far at all. I think episode 650 is a great complement to this conversation and a reminder of the importance of folks at the middle management level and how to engage them so they can continue to do the great work that they do. And then finally, I'd recommend episode 7 40, how to Lead Organizational Change. Michael Bungay Stainer was my guest on that episode. He's the author of the Coaching Habit and more recently he's been hosting the Change Signal podcast. We talked about the lessons that he has learned from so many of the experts on leading change in the last couple of years. So much gold in that conversation and of course a lot in the Change Signal podcast as well that Michael is hosting all of those episodes you can find on the coaching4leaders.com website. And I'm inviting you today to set up your free membership@coaching4leaders.com that'll give you access to the entire library, so searchable by topic so you can find things quickly that you're looking for. Organizational Change is one of the dozens of topic areas we have inside of the free membership. There's many, many, many other episodes we've talked about on change over the years that will complement this conversation so that it's a great starting point. In addition a lot else inside of the free membership and one of the benefits is the free audio courses inside. One of those free audio courses is titled how to to enhance your credibility, key in the change process and of course in so many aspects of leadership. Five key lessons for me on where to begin, what I've seen work, what I have tried and attempted to use over the years to do this for myself and for others. It's one of the about dozen audio courses that are inside the free membership. Those aren't available publicly, but you can get free access just by going over to Coaching for Leadership and setting up your membership and you'll be off and running in just a few seconds. Coaching for Leaders is edited by Andrew Kroger Next Monday I am glad to welcome Lily Zhang to the show. We are going to be talking about fixing fairness in the workplace. Join me for that conversation with them. Have a great week and see you back on Monday.