Loading summary
A
Welcome to the New Books Network.
B
Hello, I'm Dan Hill.
C
And I'm Julie Annixter. And this is Real Transformations where we talk about change from the inside out.
B
And what's your first key question here, Julie?
C
My first key question is let's talk about the transformation that Phil is pretty famous for leading. So Phil, you, you covered this transformation in your book Irresistible Change, which is all about making change irresistible. Tell us, why did you write the book?
A
You know, I wrote the book for two reasons. I would tell the story of how we did things at IBM and to CEOs all around the world, to chief transformation officers, to chief human resources officers. And everybody was like, this is a different take and you got to write these stories down. So it was kind of a result of that. But then as I was thinking about it and I left IBM and started working directly with these folks as clients and I realized that everybody hadn't has internalized the strategic language of change or transformation. You know, iconically the, the John Cotter book Leading Change. Everybody would talk about quick wins, they talk about overcoming hurdles, talk about burning platform. And yet when I would go deep, you know, two questions deeper about how they interpreted these strategic imperatives, the execution models behind them were often lacking. And generally speaking, it wasn't the strategy of transformation that was always wrong, it was the execution of change and how they thought about it, how they introduced it to their people. And I realized that, at least as far as I know, what was missing in the literature was a, was a side by side companion with Cotter's book that had nothing to do with strategy, but just was the tactics of execution. And how do you take Cotter's principles and how do you translate those into implementations that work and that matter and that cha and the move the needle for people. And so that's really why I wrote the book, was to be that companion to the strategic. A lot of good strategic work on transformation that's been done, but I didn't think anybody had ever documented from the inside every critical decision that was made and the outcomes of all those decisions in the context of real change at scale.
C
Yeah. And I notice that in what you just said, you did not use the word design. And one of my favorite moments in your book, listening to it on audible again this week was when you said, you know, the word design was a problem. And having come from the design field, as you know, you know, the design field globally was enthralled with what you did because you ran a global design office, later called the Hallmark Office but you struggled with the word design. And so right up front, I want to ask you why.
A
You know, words, words that have been out in the world, have baggage, and everybody brings their own, kind of brings their own biases to and for and against words. And so when we would go out and we would talk about design, you would immediately get this pushback. Either engineers thought a different profession was kind of a set of softer skills and maybe didn't warrant, you know, that seat at the table, or they would say, oh, we tried that before. I had a designer on my team and didn't work out. And so this, this constant struggle of being on our back foot, having to defend the word design and the concept of design thinking really got me to thinking about language and about the impact of language on transformation and on bringing people to the table instead of immediately alienating them with something that they think they understand. And even if they don't, they don't have the openness of mind to kind of reset themselves. So for that reason, we didn't shove design in people's faces initially. We chose a neutral word, as you said, the hallmark. That was the word that we called our program. And the minute that we did that, the amazing thing was it actually unlocked many other things that we could do with the program, way beyond just design, things that would, in fact, reinforce design in ways that we really hadn't even considered at the beginning.
C
Yeah. And if I could, I want to do just a little bit of history quickly. For those that are not familiar with IBM and the story, and what's interesting to me is the only other person that I know that did a program at enterprise global scale like you was Claudia Kotchka at P and G for AG Lafley. And she wasn't a designer either. And you're not a designer by training. You led. You ran a number of startups. Startups including Lombardi Software in Austin. You were Chief Technology Officer, later president. You sold it to IBM in 2010. And then when Ginny Roamedy came on as CEO in 2012, she said that she wanted IBM to rethink and reimagine the experience of IBM's customers. And she asked you, this is the lore, at least, what would it take to get our massive company to move more quickly and invent new things and fast? And that's where you started. You. So can you talk a little bit at sort of the meta level for, again, for those who aren't familiar with the story, what did the program office do? What was your mandate from Ginny Yeah,
A
you nailed kind of the initial remit. She had seen I had been. Shortly after we had been acquired, one of the senior vice presidents had said, I'd like you to take over this small as small at IBM was about a 1200 person team. Take over this small unit within IBM and make that unit act more like Lombardi acted, like your startup acted. And so we did that. And over the next 500 days, we, we pruned the product portfolio. We went from 44 products down to 4. We took massive market share. We grew at about 30 to 40% per year in a market that was growing at maybe 10% per year. And our customers loved us. And quite frankly, just as important, our employee engagement within that unit was by far the highest inside IBM. And so when Ginny became CEO, that's the story she heard. And she said, can we make all of IBM look like that? Part of IBM again?
B
Smart woman.
A
Neither of these folks knew that design was actually the critical lever that I had brought. They simply knew the business outcomes that had been achieved. And so when I, you know, obviously she said, how did you do that? And I started talking about the, the tactical things that we did around design, around design thinking, around changing the nature of teams and the content and the makeup of teams, et cetera, et cetera. She said, let's go. And so that was the, that, that was the backdrop. The backdrop was always on, wow, this, this business, this startup that we bought, this unit that you took over, both of these achieved way beyond market returns. That's what the objective always was. And so as we, as we started the program, the focus was always on achieving those outcomes. And the fact that design was the, was the 80% lever that we used was immaterial in a sense to those business people.
C
And you know, I gotta tell you, I've read a lot of business books and I picked up yours for the first time. And I think it was in the first paragraph where you said we treated change like a premium product. And I just stopped right there and then when I read on, and I think this is a really important point to underscore. You didn't roll out some massive global design thinking training at scale. You made it a premium product that people had to pay for. So talk a little bit about what, you know, what was your implementation like? You go from where you were, please.
A
Yeah, yeah. So again, once I once, you know, when Jenny, when, when the senior vice president asked me to do that smaller unit that 1200 and put me in charge, I was in charge. And so it was fairly easy to implement change and roll out change and bring people in because I was in charge. When Jenny said, okay, make these 400,000 people look like those 1,000 people, I was like, okay, how do you, how do you Even think about 400, 000 people, none of whom report to you? They don't owe me anything. And in fact, the only single person that they reported to if you rolled them all up was Jenny herself. And she had a day job that was not design and design thinking. So I was kind of struggling with this. And then it hit me that this was exactly the problem that I had tackled with all three of my startups. If I thought about IBM of 400,000 people as a market, then the thing I'm peddling to that market, it's a product. When a startup comes out with a new product, nobody knows you exist. They don't know if the product will help them. And so that was kind of, oh, we need to think about this like a startup thinks about a product. And when you start going down that train of thought, then you start thinking, okay, how do I roll it out? Well, what does a startup do with a new product? You go to some friendlies and you give them that product and you work really closely with them for a month or two months or six months. And if they, you don't charge them for that, but if they actually change their workflows and adopt the thing, then they're your references. And after that you sell the product. And by the way, if nobody buys it, if nobody pays you money for your product as a startup and you go out of business because your product isn't worth anything, the market will determine its worth. And so that became a very real kind of constraint that I put on our team that after our first, we chose seven. We worked with seven teams for the first six or nine months. We gave them the product of change. We worked really closely with them and they all adopted it. They all loved it. They became our reference customers. And then we started opening the gates a little bit. And in year two, we had a capacity of 25 teams and we charged those teams for entry into the program. It turned out that by the end of the 9th month, we had a waiting list of 75 teams that wanted in. By the end of the 15th month, we had a waiting List of almost 200 teams that wanted to pay for the privilege of changing. And I'm. When I say pay, I'm not being metaphorical, I'm. They literally allocated business budget and transferred it to my group. To cover the costs of bringing them into the program and buying the new tools that they needed, adding the people that they needed to their team, etc. Etc.
C
And let's be clear. And then Dan, I'm going to turn it over to you. When you say work with them, you're talking about working on actual IBM products that were going to customers. Software, cloud, you know, the work of IBM. It wasn't some design project that was branding something, it was the actual products and services.
A
Yeah, yeah, yeah, yeah. One of the tenets of being in the hallmark program of any, any, any work that my team touched was it had to be a funded IBM project, would go ahead with or without me. It was a, it was a project that the business had green lighted and was paying for. You know, most, many transform. There's several anti patterns to transformation efforts that fail. Two of the biggest are you form a tiger team. You get a special team of people and you tackle some project, some special project that's kind of on the back burner and you use some, you know, you use agile, you use AI, you use design, whatever you use and you come up with some win. And then everybody goes back to their day jobs. That's completely useless. In the context of proving that change can be done inside the organization. The same thing is true for innovation centers. You know, in the early 2000s it was all the rage to open some cool place out in San Francisco with brick walls and expose ductwork and, and put people in and they would come up with these ideas and then you'd ship the idea back into the mainstream business and the mainstream business would essentially give you the middle finger because they knew that you had incubated this thing in a, in a, in, in a fiction. And so it's really important that change take hold. In fact, one of the key proof points that will bring new teams into the program is that it was a mainstream team working inside the regular processes and systems of the company that was actually able to change.
B
Oh, I love that and I think that's so true. So I want to go back to something a bit ago you mentioned the word design and it had some baggage in terms of lexicon, but you didn't back off on some other words that I don't think are always well accepted. Emotional intelligence, emotional courage, maturity. That seemed really important to you and you're stuck to your guns there. How did you sell it in? At times I imagine there had to be some people who resistant to that concept or approach.
A
Yeah, you know, we, first of all we didn't do a lot of selling just to kind of lay the groundwork for how we would bring a team in. We didn't do marketing, we didn't do a bunch of evangelism of this big transformation program inside IBM until years into it. Okay. In fact, we started in 2013. Jenny didn't make a public statement about it until the shareholders letter in the annual report in 2016. This was a very intentional communication strategy that we were going to work with teams, mainstream teams, funded teams, every single touch point. We never ran a generic, for example, design thinking workshop. When we onboarded teams, that team brought their product to the boot camp. And the promise was if on this is Monday morning, the promise was if on Friday you haven't moved 10x what you would have moved, you should leave this program and you'll never hear from us again. Their work was always preeminent. And so when we, when we did that work, to your point, you know, one of the things that we really got across to them in that boot camp was empathy is not a word that you hear around IBM very much. In fact, a lot of you probably think it's a very soft word.
B
That's what I was, I was trying to get to. Yep.
A
But we think it's the hardest word you'll ever learn. Gaining empathy with your users and then scaling that empathy across your team is probably something you've never done in your career. That's by definition hard. And that would kind of sit people back in their seats.
B
Yeah, I'm sure.
A
And, and then they would see it in action and through some very simple exercises that as designers we would understand them. Empathy maps, user journey maps, user research. But it was a real eye opener to the, the vast majority of those 400,000 people. When we went to our sales teams, which were some of the last teams that we actually engaged with, when we went to our sales teams and started talking about empathy, you know, they thought they had it in spades and they realized very quickly that even they didn't really practice intentional empathy at scale. Sure.
B
Yeah. And what did an empathy map look like or looks like?
A
Very typical, you know, two by two of how does it, what does a person say, what do they do, what do they think and what do they feel? And you really try to turn the table into, onto. And of course the first pass is you projecting what this particular Persona might do. And that's a good, that at least gets you in the state of mind. But then we would bring in those people and we would actually interview them during the Boot camp, we would bring in the real users of the real team's products and we would spend a day interviewing those people and they would be, no, that's not at all what I think. That's not at all what I think. And it was a real eye opener to, you know, to engineers who, you know, they were out in the field, but they didn't really have the skills. The, the, the, those, you know, I hate to, I don't want to say they were ethnographers, but those kind of ethnographic skills of intentionally working to understand and observing people in their environment as opposed to projecting what I, I feel like you're doing in thinking and feeling.
B
Sure. No, I love that. But I'm gonna turn it back to Julie. I think I'm gonna have one more question for you before we get down here.
C
In the sort of language of design, once you've listened with empathy at the point of pain, and you've really listened, then it's time often to start prototyping or creating concepts. And I remember Doug Powell first told me about cupcake, birthday cake, wedding cake. And I know, you know, there's a lot of fear among certain groups of people in corporations when you ask them to sit around a table and prototype something. It's like, what do you mean? Well, you did it as a kid, we can do it again. But tell us about cupcake, birthday cake, wedding cake.
A
Yeah. So our, the culture I walked into at IBM, it was within a first week or so, I had an engineer call me and talk to me about one of our products that we had. We had brought in the Lombardi, the acquisition that company I'd been president of brought in. And he had this idea and it was like, there's no. It was a fine idea. And I said, well, you know, prototype it and let's see how it works. He goes, well, let me have access to the source code. It was like, access to the source code. Why don't you just draw it on a napkin? He goes, no, no, no, I'm just going to write in the source code. And that's when I realized that the, the culture was one of immediately moving to solution, putting it in the actual cope, getting it to code quickly. And of course, once it got into code, then it was there, it was baked. The other tendency was in any given project, you might agree on objectives up front between design and product management and engineering and marketing. But then at some point in the project, the real world of implementation bumps into you and engineering has to make some decisions and priorities. And historically those decisions were completely left up to engineering. And they would typically cut features in preference to building a more robust engine or whatever it might be. And so we were struggling with how to communicate this notion that if you just lopping off a feature so that you make a date to ship a product, it, it doesn't work if, if that feature was, you know, it doesn't work if that feature was critical to somebody completing a particular task. And too often at the time we were delivering software that did 90% of every task and we were trying to come up with a way to say that's not the same thing as delivering 90% of a, of a release, because if a user can't complete any task, the product is essentially worthless. And so we came up with this metaphor that said, as we scale down, the vision that we all have when we go into a project is usually kind of like a wedding cake. It's a, it's got everything on it and by the time we pare it down and we kind of commit to releasing something, it's more like a birthday cake. It's still great and it's on our way to the wedding cake, but it's not quite as big. But when we really get to cutting features, when we get, when push comes to shove and we actually have to release something in an agile world very quickly, we don't want to release a half baked slice of a wedding cake or a birthday cake. We want to release a cupcake, which in and of itself is just a small part of a birthday cake, but it's a whole thing. Whatever you can do with a cupcake, you can do all of the things within the cupcake. And so we had this metaphor and as we rolled it out, that metaphor became baked, sorry to, no pun intended, but breaked into the, into the product language. And so we would talk about releases, we would talk about visions as wedding cakes, we talk about essentially desired releases as birthday cakes. And what was actually released in a given Sprint or in a given Agile development cycle was always had to be a cupcake. And it was a metaphor that everybody could get around. And when you analyzed the trade offs of what features were in and what features were out in the context of that metaphor, everybody could, everybody could pretty much figure out what was, what was the right thing to do.
B
Well, my sweet tooth is getting pretty hungry here, but I'm going to try to stay on focus. I'm a dangerous man because I can read people's faces. I'm trained in facial coding, so I looked at your back flap photo. And I even more looked at the photograph that you sent of yourself with a blue sweater. And I must say you look like a man who's been in the trenches and put in the good fight. Because you're described on the book flap as saying that you have dealt firsthand with changes and overcome skepticism, doubt and reluctance. And you show all three of those emotions in your face, quite honestly. Yeah.
A
Right here. Usually that middle part right there, that
B
is part of it. Yes, indeed. So I was curious what it really felt like to go through this because this was arduous. It must have been exhilarating, it must have been amazing. I mean so many things must have gone on for you. This is such a crowning achievement that you've, you've managed to pull off.
A
Yeah, you know, it was, it was a joy. It was by far. When I went to IBM, I thought I was going to put in a year to help my team through integration. When I, as I, as I write in the book, after about two months, I couldn't even imagine being there for half, half that time. And it turned out to be 12 or 13. The 12 or 13 best years of my career. It was, the project was fantastic. But I will tell you that working at scale was a ball. But most important, the relationship that I created with Jenny Rometti. This entire thing. I wrote the book, I led the program. Jenny is the person that is responsible for all this. She took a company that, where the morale had been decimated through years of meeting shareholder mandates and cutting, cutting way to the bone of a culture that had been pretty good. When I got there, it was not. The physical plant was in shambles, the morale was in shambles. And Jenny had the foresight and more importantly had that backbone of steel that, that led to, to the turnaround and the re engagement of a global workforce that I think today is doing. I think today is doing the best human centered work of any B2B company on the planet. And you know, all credit to her and that really to me, that relationship and the relationships that I built with several of the folks on her team and on my team, of course, that's really what I remember today most and cherish most. And the fact that when I go out in the world and I'm able to run across IBM in the world, it's incredible to see as they engage with clients, they're still running design sprints. Designers are now on sales teams. Designers are at the forefront and more importantly than designers, capital D. But a human centered approach to problem Definition and solving is still at the forefront of how they tackle challenges. That wasn't the case in 2010, but it is the case today. And so if that's my legacy, that's all right.
B
That's a pretty good one.
C
It's a very, very good one. I'm so glad you brought Ginny up and I want to say something and ask you something about her in just a moment. But in terms of legacy, having done this kind of work myself in the business world for most of my career and in the military, what I know about it, Phil, is it, it enlivens people, it wait, you know, people get to bring their best selves, they get to get hands on. It is the most phenomenally great way to work and yet most of the business world still doesn't understand it or employ it. And so your example at IBM, and particularly because IBM is doing so well right now too, is such a profound one. And I think it's important too that the teams you worked with were also working with customers. So you were sharing this with customers and people like me. There's an enterprise design training program that's free. I think it's still free. That's free. That is available to anyone. And it's interesting. I did a lot of research before we talk. How many companies are talking about enterprise design? Not too many, you know, because it's still. Claudia Kotchka said when she got there, people thought of design as. What did she say? The decoration station on the way to the market. And you and Claudia and others have infused. Mauro Porcini is another one who have infused design into the way people work. And I remember way back, I think Interbrand wrote a blog article that said design makes everything go faster, design makes everything easier. And so I think we want to hear about what you're doing now and kind of what you would advise people who are just starting out and the master class is there, there's a documentary people can see, they can read about you. Ginny's book, by the way, is phenomenal.
A
Yeah, fantastic book.
C
Oh my God. And the chapter where she says she got rid of the college degree requirement. I almost cried.
A
Yeah, yeah, she, she, she's been on a, a very skills, skills based, not, not, not education based kind of train of thought for, for many, many years now. Yeah, it's fantastic.
C
So, so you were at IBM for over a decade, right? And you worked at an enterprise global level with 400. Eventually it went into the water system and there are 400,000 employees now. You're out you wrote the book. What's it been like to go out into the rest of the world and what kind of reaction have you gotten? And just how's it going?
A
Yeah, no, it's going good. So most of my clients are enterprises that are, you know, today struggling with AI. A couple of years ago, it was the RTO issue and all of these, all of these things are even, even reorgs. I've worked with a couple of military units, have gone through reorgs, you know, a lot. Reorgs are kind of very interesting transformation statements because those are things that, you know, people like McKenzie and others work with you for two years in advance and the day you announce the reorg, you think you're done, and that's the day I think you're started. So it, it's working with, it's working with organizations around the world that are struggling with. I typically get the call after a year or two of something not taking and, you know, why didn't it take? And it's usually the same things, whether it was design or agile back then or whether it's AI today. It's that you're leading with that thing. You know, it gets back to, I think, the very first question you asked, which is why not the word design? It's the same reason why today the strategy shouldn't be AI first, it shouldn't be AI everywhere. That limits you. It also, it brings the baggage of that thing, but it limits you to just by human nature focusing on that thing. And it turns out that whatever thing you're bringing to provoke the change that you want in your organization, in any successful transformation effort, that is ultimately going to be less than 30 or 40% of the work of the transformation team. And when you put that thing as the lead, what typically follows is you then put your best AI person as the leader of the transformation effort. Well, that's not right. That's not where that person should go on the leadership team of transformation. Kind of like you mentioned, Claudia and me, who led these design transformations, I think one of the reasons they were most successful is because they were led by business people. But the designers that we had on our team were full time working in design, not half time working in design and halftime running a program. So these are the same. These are the kinds of things I'm working on and looking at companies and how they're bringing AI into their organizations and they're making the same mistakes. They're. They're either bringing it in specialty teams with tiger teams working on special projects. Or they're not even thinking team based at all. They're just telling all these individuals, typically developers, we want to see how many tokens you're using every month. These are irrelevant metrics. And they're also irrelevant in the sense that individuals don't generate outcomes for an enterprise, they contribute to outcomes, but it's teams that generate outcomes. And I see very few AI efforts today that are focused with the team as the atomic unit of the change effort. So these are kind of, this is what I'm doing, this is what I'm out seeing and these are the kind of challenges that we're, that we're working on today.
C
Well, I have one more question, but Dan, I want to see if you have another question.
B
Well, I, I did. We kind of, I've been on this language thing. We went from design to eq. I got one more for you. You said you sent psychiatrists into teams that were having problems. What's the backdrop? What were they trying to do? What's, what was going on there?
A
So let me just correct one thing. I didn't send them on the teams that were having problems. I, I sent them onto all of the early teams.
B
Ah, you did okay.
A
Yeah. So part of, part of the transfer part of my program office, I had some individuals who were, who were experts in interdisciplinary design and using design thinking to solve problems. And I need, I knew at the beginning, as I just said, I did have a, I knew that design and even design thinking as a, as a method were only part of the issues that we would have to tackle with any transformation effort we're seeing with AI today. Whatever you insert into a culture, you not only have to, you not only have to adopt that thing, but you also have to understand all of the systems and processes around the teams that are going to reject the thing or at least not reinforce the thing. You know, most transformation efforts with respect to a lot of things I'm seeing a little bit differently on the engineering side right now. But with respect to AI, well, I'll talk about IBM with respect to design and IBM and design thinking, we ended up changing every single function, every single career ladder in the organization for all disciplines were impacted by Agile and design thinking. If you were in sales at a, at a, a band eight level, which is a, you know, five year experience level, if you were in sales at a band 8 level to get to band 9, there was a certain expectation of how you would work with these tools and these methods. If you were in engineering, there was a certain expectation certainly if there Was design you an expectation in marketing all of those systems. We didn't understand what they were and where they were. And so I had this idea that we would have a set of a few people. Each person would be assigned three teams and they would, they would essentially live with those teams. During the early days of the change program, they didn't do any work of the team. The team did the work. They would just observe. They would observe the team. The team leaders would come to them if they ran into roadblocks. These people would observe when the tools that IBM supplied didn't actually reinforce the work. And we needed to think about new tooling. That was how the program office got the feedback. So these people that I ended up calling psychiatrists, they were out there to help the teams get through roadblocks, but they were really there as the intelligence seeking arm, as the user research arm of the program office to understand all of the ways in which the company, the antibodies of the company were going to try to reject the change. And they'd bring those back to us and then we would go attack those systems. So for example, if we were seeing people get promoted and nothing in the promotion chain had anything to do with Agile or design thinking in our context, if there was no criteria that reinforced that and people could still get promoted, that's a problem. So I had a person on my team, one on my leadership team that had a connection into HR and we would start to work on that career's career ladder. I had a person with the CIO that was a liaison with the CIO office so that as we brought in new tooling for these special teams, we were very transparent about that and we had their approval and we worked with the CIO office to bring in new tooling. Same thing with the CFO office. When we had these funding issues when teams weren't in the program, they didn't know how to go get funds necessarily. So I had somebody working with the CFO's office to teach them how to allocate budget and what have you. So all of these learning, all of the antibodies in the system that will reject change were the real work of what I called the psychiatrists. Yeah.
B
Fascinating, fascinating stuff.
C
Well, you know, I was leading AIGA in 2016 and 2017 and 2018 and that's when you guys started to go public. I got, I had the pleasure of visiting you and visiting the Austin Design center and, and really I want to say that a lot of people have contributed to this, but IBM serves as a role model for the transformation of the design profession and what a designer can be. And I think, I won't speak for the whole profession, but many designers I know wanted a seat at the table, right? That was the big term. Want a seat at the table. And the partnership between you as a business leader and the rest of the enterprise and the designers is really a role model situation for really the world. So it's so great to be able to talk to you about this transformation. And my last question is maybe I'm opening a can of worms, but how could we bring this to high schools?
A
Oh, you know, I, I don't know enough about high school curriculums, but there are some that are. Try trying it. We worked with many in Austin and some of our other studios, worked with some in, I know in North Carolina and other places. But I, you know, I, I think in many like we found teachers, many teachers are doing some of this intuitively, especially this notion of interdisciplinary kind of working. A lot of places are doing this intuitively. We gave them a structure. One of the reasons that we opened our entire, what we call enterprise design thinking curriculum and, and, and approach to the world was really to stimulate academia at all levels. We all also worked even at the kind of grade school level, elementary school level with, with some programs and it worked really well. You know, I think right now, I mean again, I don't know enough about the educational system to how to infiltrate it. I do know that, you know, teachers right now are so overwhelmed and the thought of more tooling is kind of an issue right now. But I think, you know, I guess where I'd move the conversation is our enterprise design thinking platform is completely open and to the extent that people are involved in any part of academia as a parent or on the inside, take a look@IBM.com design and go to the design thinking curriculum and you'll find that the first badge is completely online and it's totally accessible to people of all levels from sixth grade up probably. And it will give them a framework of interdisciplinary teaming and thinking and empathy that I think is powerful. We released that in about 2018 and I just had an update a few months ago from where we were internally to IBM. And of course a lot of these people have moved on, but internally at IBM, over half a million badges, digital badges, digital certificates have been awarded for completion of the of enterprise design thinking. What's more, kind of what I take even more pride in though, is that almost 400,000 non IBMers have successfully completed the enterprise design thinking course. And so there's almost a million people out there in the world that have at least this introduction to empathy, interdisciplinary teaming, and a value system that values the user as the North Star, that values iteration and reinvention as, you know, critical and finally, that values diverse, empowered teams and diversity in all of its respects, which leads to better outcomes and better answers. And so I think that's a good place to start.
B
Well, I have to say, almost a million people, better luck next time.
C
I am so glad I asked that question. And I want to make sure that anyone who's listening knows that they can find your wonderful book, Irresistible Change, A Blueprint for Earning Buy in and Breakout Success, which has happened at IBM in such a an incredible way. Published by who is the publisher for Wiley?
A
John Wiley and Sons.
C
Yeah, by John Wiley and Sons. And it's also available on Audible. You can find more of our podcasts on Substack under Real Transformations and of course, on the New Books Network. Phil Gilbert, it has been such a pleasure to talk to you.
A
Julie Dan, thank you so much. I really appreciate the opportunity. It's been great to talk to you guys and let's do this again sometimes.
C
Sam.
Podcast: New Books Network – Real Transformations
Episode Date: June 4, 2026
Host(s): Dan Hill, Julie Annixter
Guest: Phil Gilbert, author of Irresistible Change: A Blueprint for Earning Buy-In and Breakout Success (Wiley)
This episode explores the groundbreaking transformation of IBM’s culture and operations, led by Phil Gilbert. Interviewed by Dan Hill and Julie Annixter, Phil shares inside stories from his new book, Irresistible Change, revealing how IBM reinvented itself by embedding human-centered design and emotional intelligence at scale. The conversation goes beyond strategy, diving into the tactics and execution models that allowed real change to happen within a 400,000-person global enterprise. The episode is a blueprint for anyone interested in organizational transformation, practical change management, and making innovation truly irresistible.
On why change fails:
"It wasn't the strategy of transformation that was always wrong, it was the execution of change and how they thought about it, how they introduced it to their people."
(00:36, Phil Gilbert)
On “design” language:
"When we would go out and we would talk about design, you would immediately get this pushback...So for that reason, we didn't shove design in people's faces initially."
(02:58, Phil Gilbert)
On treating change like a product:
"...if I thought about IBM of 400,000 people as a market, then the thing I'm peddling to that market, it's a product."
(08:18, Phil Gilbert)
Empathy at IBM:
"Empathy is not a word that you hear around IBM very much...we think it's the hardest word you'll ever learn."
(15:12, Phil Gilbert)
On scaling meaningful change (on tiger teams and innovation labs):
"...it's really important that change take hold...it was a mainstream team working inside the regular processes and systems of the company that was actually able to change."
(11:39, Phil Gilbert)
On the power of metaphors in culture change:
"We would talk about visions as wedding cakes...what was actually released...was always...a cupcake."
(18:04, Phil Gilbert)
On transformation legacy:
"If that's my legacy, that's all right."
(22:37, Phil Gilbert)
On “psychiatrists” in the program:
"They would just observe...they were really there as the intelligence seeking arm...to understand all of the ways in which the company...were going to try to reject the change."
(31:06, Phil Gilbert)
On open education:
"Our enterprise design thinking platform is completely open...from sixth grade up probably."
(36:07, Phil Gilbert)
Phil Gilbert’s story is a rare, detailed look inside a large-scale, successful transformation—showing that while vision matters, embedding empathy, smart language choices, and tactical real-world execution are what truly shift a culture. This episode should inspire leaders in any sector to re-think how they champion, structure, and execute change—by treating transformation as a product to be earned, not a mandate to be imposed.
For more: Phil Gilbert’s Irresistible Change, IBM’s open enterprise design thinking curriculum (ibm.com/design), and the Real Transformations podcast on Substack/New Books Network.