← Design Better
Design Better
Phil Gilbert: Making a 114-year-old, 400,000 person company care about design
00:44:09
We talk with Phil Gilbert, former General Manager of Design at IBM, about treating change like a high-stakes product, why IBM’s transformation was opt-in rather than top-down, and what it takes to win over engineers who’ve spent decades deeply entrenched in a technical worldview.
Loading summary
Transcript45 lines
- [00:02]
A
At the companies that exhibit great design. The non designers all talked about design and all valued their designers at the companies where it didn't translate into the marketplace. You didn't feel that great cultures are not great cultures because they contain an attribute. They are great because they value the attribute.
- [00:29]
B
Changing the culture of a 400,000 person company isn't just hard, it's the kind of transformation most leaders wouldn't even attempt. But when Phil Gilbert joined IBM as General Manager of design in 2010, that's exactly what he set out to do. And remarkably, he had a lot of success. Phil led one of the most ambitious design transformations in corporate history, hiring over 1,000 designers, creating IBM's design thinking framework, and embedding a new way of working across nearly 180 countries. Now with his new book Irresistible Change, Phil is sharing the blueprint of how he did it and more importantly, how you can apply these lessons to your own organization.
- [01:13]
C
In this episode we talk with Phil about treating change like a high stakes product, why IBM's transformation was opt in rather than top down, and and what it takes to win over engineers who spent decades deeply entrenched in a technical worldview. We also explore the design thinking boot camp that became legendary within IBM, the intentional design of physical studio spaces, and what happened after Phil left the company. Phil's insights aren't just for those leading massive organizations. They're for anyone trying to spark meaningful change, build enthusiasm without mandates, and create work that actually matters to the people doing it. This is Design Better, where we explore creativity at the intersection of design and technology. I'm Eli Woolery.
- [01:53]
B
And I'm Aaron Walter. At DesignBetter, our primary mission is to produce work that helps people like you refine your craft, improve your collaboration skills, and get inspired by the creative process of others. If you enjoy what we do here, the best way to support us is to become a premium subscriber atdesign better podcast.com subscribe.
- [02:21]
We'll return to the conversation after this quick break.
- [02:28]
Design Better is brought to you by WIX Studio, the platform built for all web creators to design, develop and manage exceptional web projects at scale. Learn more@wix.com studio.
- [02:44]
And now back to the show.
- [02:51]
Phil Gilbert, welcome to Design Better.
- [02:54]
A
Thank you so much Aaron. Appreciate it, Phil.
- [02:56]
B
Before we hit record, we were just chatting about how our worlds were sort of adjacent for some time, that we know a lot of your former colleagues at IBM and when Eli and I were working at Envision, we you spent a lot of time just chatting with your team about the Work that you were doing there because it was pretty huge. You were building the largest design team on the planet at the time, undergoing a pretty major transition and change inside of a company that's been around for a long time. We all know IBM well and it's had a number of different businesses. You had your hands full and in fact, I think that there was something like 400,000 employees across 180 countries at IBM when you were there. And you've got a new book, a new book that is documenting change, the change that happened there. It's coming out in November of 2025 as we're recording this. In the book, you describe treating change like a high stakes product. Most people don't think of change as a product. How does that shift in perspective shape leadership priorities and how you think about what you're doing?
- [04:01]
A
Well, it kind of changes everything because when you start thinking about change and transformation as a product and you bring that whole product mentality to your work, you start realizing that it's on you if it fails. One of the reasons, probably the key reason that most transformation efforts fail, and there's a lot of tactical reasons, but probably the single biggest reason, is that they're mandated. Somebody says, thou shalt change, you will come back to the office, you will adopt Agile, you will adopt design thinking and the team that's put in place, typically under those conditions where it's mandated by the CEO or by some senior person over an organization, the team that's bringing the change to that group then is primarily usually an enablement team, because the mandate is to adopt this. Well, for a number of reasons, human nature probably being the most important one, most people resist things that they're forced to do, or at least they initially do. When you bring a product mentality to something, what you say is, I don't need a mandate. What I need to do is I need to deliver this thing in such a way that the teams that need to adopt it want to adopt it. A person bringing a product to market, the market most of the time has no mandate to buy that product. You have to be humble. You have to build a product that not only solves a human's problem, but does it in a way that they actually will change what they're doing in order to adopt your new product. Bringing that mentality into the notion of culture change really flips the script on the leadership team because all of a sudden you it's my fault if you choose not to adopt my product. If you choose not to change, that's on me, it's not on you. And by flipping the script like that, it changes everything about the decisions you make, about how you implement and try to get teams to adopt the change that you want them to adopt. And oh, by the way, if ultimately they don't, there's only two explanations. One is the change you propose is useful, but you have failed to communicate that in a way that resonates with people. Or number two, the change you propose isn't useful because nobody shows up to work to do worse work. Nobody shows up to work to spend more time at work. And so if they don't adopt what you want them to adopt, it's either because the idea is just not a good one or you haven't delivered it very well.
- [06:41]
C
Phil, you mentioned the book we mentioned just now that your product background, your product guy, and you explicitly said you're not a designer, you don't have a design background or a background in organizational behavior. So what led you to come to the conclusion that human centered design or design thinking was a good way to maybe implement some of these changes?
- [06:59]
A
Well, the way I came to design thinking was way back in my first startup. I was during the day trying to sell the software, trying to sell a solution, and getting a lot of pushback for various reasons. And at night I would be translating that feedback and recoding the product. I didn't call it user centered design, or I didn't really call it anything. I just thought that's what founders had to do. You tried to sell your thing and if people didn't buy it, you had to change the thing in order to induce them to buy it. Well, that doesn't scale very well. So in the early 1990s, I ran across the work of both Alan Cooper, who was one of the first people to do Persona driven design, and, and David Kelly and the work that he was doing, which would later be called design thinking. And it was like a light bulb went off when I realized, oh my gosh, the formalism of design, that's what I was trying to do. There is a formalism to it and I can scale that because there's a rigor behind it. There's design behind it. And so for me originally, it was a way that I could scale my business and deliver quality results. It was that simple. And that's still how I think about design thinking, is it is a way to get higher quality outcomes at scale because there's a method behind it. So that's how I came to it. And over the years, in the Second startup, I used it for product design. And then in our third startup, Lombardi Software, which was what was bought by IBM, we designed the entire company that way. Every single person, from the CFO to the services people to our product people, were all design thinkers. And we had mental models of our users and the people that we served and we tried to understand them better. And so that was how I came to it. And when we got acquired by IBM, I was asked to lead a relatively small part of IBM, which was about 1,200 people, and they didn't know what I did. The person that asked me this couldn't spell design thinking, had no clue that that's what it was. But what I was asked to do was make this division into which you've been acquired, make this division more like Lombardi and less like IBM. And so I brought these practices into that group and that took about 18 months or so. And as a result of that, the story of the improvement there, which is we went from 1200 people to 700. We took market share, we took about 50% market share. We were growing at about 20 or 30% a year in a space that was growing 10%. Those business outcomes are then what caught the attention of Jenny Rometti, who was the new CEO in early 2012. And she said, okay, can you do what you did there everywhere? That's kind of how I got to design and design thinking at all. But that provocation of can you do what you did there everywhere? That's really where I had to figure out what ultimately became this product thought, which is when I was president of a startup, I could tell people what to do and I could bend the culture at will. In the group of 1200, I was the one who was in charge. So I could again, pretty much bend the culture to my will over time. In a company of 400,000, none of whom reported to me, that was the real magic trick that I had to try to solve. And that was when it hit me that how do you get any market to adopt something product 101? You design a product that is so much better than their current solution, they choose to adopt it.
- [10:29]
B
What was happening at IBM at that time, internally and strategically, when you were given this mandate to change more broadly.
- [10:39]
A
Throughout the company, morale was pretty low when we got bought. IBM had been run by a fellow who was pleasing Wall street and was committing to five year plans of numbers. And the first five year plan, the company hit all of them more and more, hitting the numbers not because of revenues and growth, but more and more hitting the numbers because of taking costs out of the business. When I got to IBM 2010, I was shocked at the state of the physical plant. My startup didn't have fancy offices by any means, but they were nice and we were proud of them. I walked into the space in Austin and it was dreary. I mean, holes in the carpet, lights out in the hallway, doors closed, and rubber plants and trash cans in the hallway. I mean, it was a dreary place and the morale was similar. And in 2012, when I was asked to start this, we were just beginning the third year of a second five year plan and they were going to hit those numbers and make the shareholders happy even if we gutted the company. That was my opinion at the time. That was the backdrop. And what Ginny inherited when she became CEO and one of the bravest decisions I think that the company made was actually not the transformation, but actually when she told Wall street, we're stopping this financial plan nonsense, we need to invest in the company, we need to address the morale issues, we need to address the physical plan issues. And the company will need to succeed on its own, not because of some predetermined number that we're supposed to hit. So that was kind of the business backdrop to what we needed. The technical backdrop to what we needed was as a result of some of that and other things, we were missing massive moves in the marketplace. IBM had completely missed the cloud by 2012. Right. When we were bought in 2010, the iPad was about six or eight weeks away from being launched and we were building one of the first purpose built apps for the iPad. And when we got bought in January, the executive who we were reporting to scuttled that project and told me that business to business SaaS will not be a thing.
- [12:55]
C
Just slightly wrong, right?
- [12:57]
A
A little bit. But ultimately the reason was, is because the culture had become so insular and so we didn't have the sense making out in the marketplace that companies need to have forget the highfalutin concepts behind human centered design. We weren't even talking, much less listening with our users. And so we were missing massive moves in the technical marketplace as well as this strategic backdrop of gutting the business more and more. To me, that was the strategic setting into which Jenny arrived and said, what's going on right there is good. Can we do that everywhere? And again, it wasn't because she thought design thinking was good at the time. She didn't know it was design thinking that was the primary catalyst for what I had done. It was just the outcomes that she was seeing and the engaged people and the excited customer base.
- [13:49]
C
Phil, I'm curious about maybe some of the early challenges you faced, kind of implementing the strategy. When Aaron and I were at Envision, we talked to a lot of different companies that often struggled to implement more design thinking with their organization. I think one of the things was that maybe a team would come together or a consultant would come in and they'd do some design thinking and there would be post its and essentially maybe felt a little bit like theater and then everybody went off and they just kind of forgot about it or maybe they tried it for a little while and abandoned it. So what about your strategy at IBM? And maybe you faced some early challenges, let it become successful over time.
- [14:26]
A
I'll preface that by this story. When I was asked to do this everywhere, one of the first things I did is I went on the road and I talked with a lot of client companies because IBM has obviously most companies in the world buy something from IBM. And I was able to go to some very design forward companies and also visited a lot of design laggard companies, but that I knew had some designers. And I came away from those meetings in that summer of 2012 with a real epiphany as I was thinking about how we needed to think about this program. And what I found at all those companies was that the design teams across the board were frankly excellent. And there was really not a lot of difference between the design teams at, you know, a Coca Cola or an Apple with the ones at the time, maybe at other companies who weren't known for design, right? Or Nike, the design teams weren't that different. But what was different was all the non designers at the companies that exhibit great design. The non designers all talked about design and all valued their designers at the companies where it didn't translate into the marketplace. The non designers. You didn't feel that? You didn't feel it when you walked in the door. I kind of came to this conclusion that great cultures are not great cultures because they contain an attribute, they are great because they value the attribute. And what that meant all of a sudden is that yes, I needed to focus on bringing design thinking skills into the company and I needed to focus on bringing designers into the company. But what I really needed to focus on were all the non designers and getting them to value this thing. And so that became a key part of the product that we ultimately built and delivered. What were very intensive experiential moments as well as lower intensity but still kind of moments where we would touch the teams and we constantly had the lens of trying to get the non designers to value the designers and the outcome of the design process as opposed to worrying too much about the rigors and practices of design thinking itself. And that's what I think most change efforts get wrong. You can use the word design thinking, or you can use the word artificial intelligence, or you can use the word return to office. In all of these efforts there's too much of an emphasis on the thing and not nearly enough emphasis on what does it mean to value the thing and how do we not only plumb the people to value the thing, but how do we plumb the systems and processes around the people so that it reinforces that value?
- [17:16]
B
We'll return to the conversation after this quick break.
- [17:22]
Clients want it all. A slick looking site that can run their business and scale with their success. Well, wix Studio is built just for that. Plan out your client's whole site in seconds with AI powered site mapping and wireframing. Then when everyone's on the same page, you can jump into the creative stuff. Starting off in Figma or in WIX Studio Editor with super precise layout tools like Grid Stack and Flexbox. Go above and beyond the brief with no code, animations, custom CSS and built in business solutions make your whole vision responsive in just a single click. It's super easy and there's zero need to break a sweat when clients grow fast. A dynamic CMS with global design settings and reusable assets lets you turn one page into hundreds, design smoother and deliver sooner. Go to wix studio.com that's Wix Studio.
- [18:27]
And now back to the show.
- [18:34]
Can you give us an inside look at some of the specific methodologies that you employed? I'm very curious because I've talked to a number of IBMers and I've heard a few times the challenges of someone who's been at IBM for 25, 30 years. They're sort of intractable. Like we've always done it this way and you're coming in as, you know, young upstarts, idealists, and how do you convince someone who's so entrenched in the way that things have been done before?
- [19:10]
A
Yeah, what I believe, and certainly what we saw time and again, is you can't convince them. So evangelism was never a part of our program. I believe that for any change to be adopted, it has to be experienced and it has to be really taken on as a good thing from that experience. And so this is an oversimplification but we basically designed the onboarding of the program. Well, the first thing we did is we branded it and we had a set of values associated with that brand. It was a real product. It wasn't just called design thinking. In fact, it was called the Hallmark program. And a lot of people didn't even know what all went in the Hallmark program. But it gave us a vessel into which we could not only pour the values that we wanted to pour, but it also allowed us the freedom to also bring in. As we saw things that got in the way of adopting design thinking and interdisciplinary teaming and design, we could change those. So it might be tools. It might be tools like Slack or like Mural or whatever they might have been. It allowed us to change environments. So we brought environments into the program as well. And all of this was kind of under this Hallmark premium brand umbrella. So that was the starting point, was we had this brand, this product, and you could only get in if you wanted in. If you didn't want in, you didn't have to come in. And we only had capacity of X amount per year. So only so many teams per year. Now, it grew. The first year it was just 7. The second year it was about 20 or 25. The third year it was 60 or 70. Our capacity grew, but we always had more demand and capacity. So that was kind of the first thing. We had this brand, we protected it. And within the context of that brand, we had freedom to do anything it took to get teams to adopt these new ways. The way we did that then is if you were accepted into the program. The first thing that we did is we required you, your whole team at the beginning to come to Austin, Texas, to the studio. And we put them through a one week, very intensive immersive course, if you will. But it wasn't a generic design thinking course. It was their product. We would spend weeks getting ready for one of these boot camps. And during that week, I would walk in on Monday morning and I would tell the team, thank you for your time this week. If, when you leave Friday, you haven't had about a 10x advance in your product from where it would have been on Friday, you should not ever do this and you'll never hear from us again. That was the promise. And that kind of woke everybody up of, wow, this is different. And that entire week was meant to shock them into being different. But we were constantly working on their thing and we were doing whatever it took to get their thing better. Well, at the end of that week, people were so excited that we then did the second thing, which is we got everybody on tape at the end of that week, full of enthusiasm, and we recorded two or three questions that we would ask them. And over the weekend we would put together about a four minute sizzle reel of the best them telling their own stories. And we had a space on the corporate intranet for all 400,000 IBMers to look at. And on Monday or Tuesday.
- [22:32]
Some of those hardest skeptics who had been overcome with enthusiasm on Friday were exposed to the world as loving this thing. And that not only told the story to the masses, but it also kind of glued the fabric of change onto them. Now they were heroes for embracing change. The third thing we did then is we had a set of people that I called the psychiatrists who stayed in touch with each team for somewhere between three and six months. And the psychiatrists were put in place for two reasons. The first was as the teams went through their problems and got stuck. The psychiatrists were there to help them get unstuck. They were doing performative empathy maps or they were doing performative user journey maps or whatever it might be. The psychiatrists were there to help them with that. But what they were really there for in the early days was to understand back in the real world, where are the managers and the systems and the processes of the company pushing them back into the old world. And as we came across those obstacles, we would tick them off one by one by one. If it was a senior leader in their division, we would have to go figure that out and work with that person and get them on the right page. More often it was the processes of the company. HR processes, for example, career ladders, what gets you promoted. A lot of times the things in those career ladders are antithetical to the new things that you actually want in the culture. So you've got to go HR system by HR system, career track by career track, step by step by step, band 8, band 9, band 10 band and make sure that all those systems and processes are reinforcing the new behaviors, not the old ones. And then there was a set of dashboards that we created for the senior leadership above these teams where we would collect all of those operational behavior characteristics of the teams, which are things that most HR systems don't capture. Or even product systems, they don't capture behaviors, they just capture artifacts. And we would communicate the behaviors of teams to the very senior leadership in the company that very much wanted this to work, including Jenny, who had a quarterly call with me. So those were the things that we put in place. It was a very specific branded offering. Once you got in, your first week was very clear and then your subsequent, like I say, three to six months, kind of depending on release cycles of how long we would stay in frequent touch. To give you a sense of the high touch nature of these psychiatrists. A single psychiatrist could only handle about three teams. So they were spending a day or two with each team. They weren't doing any of the team's work, they were observing and would help teams do their own work. But there was no central office doing design thinking or God forbid, running design thinking workshops and turning it into a workshop exercise. We weren't super dogmatic about what you had to do to practice human centered design because again, the more emphasis you place on specific artifacts, the more likely, especially an engineering company like IBM, the more likely that company will turn it into a checklist and it'll become useless. It was more about getting people really thinking about what their users needed and wanted.
- [25:51]
C
I like this term psychiatrist. Both my parents are retired psychiatrists, so I'll have to share that story with them. They'll make that piece of that. One of the takeaways in one of your chapters you say to design your team to spread a virus, not just deliver a skill. That's provocative, but it's an interesting metaphor. Can you talk a little bit about why you use that one?
- [26:10]
A
When I realized that it was a culture issue and not a design issue, you know, I talked about the non designers are the things that really made it work. At design forward companies, you just look at the numbers. Roughly speaking, for every hundred designers I would add, I would need to affect about 5,000 other IBMers. There was no way to do it unless this thing became really plumbed into the DNA of the company. Companies of any size at all, you don't have to be IBM scale. Companies of any size at all have got systems in place that are specifically built to keep what they're doing, doing systems and processes and HR is the simplest one. But even product systems and what have you, they are specifically built so that practices and procedures will be replicated across the company in uniform ways. That's how you scale. So by design, the systems of the company are built to maintain the status quo. They're built to scale the status quo. When I started realizing, okay, this isn't about my initial back of the envelope number that I had given Jenny was we need to hire about a thousand designers to make a difference in products, which at the time was mind blowing. No Company, this was 2012. No corporate enterprise really had a thousand designers. So even that was kind of provocative. Today it's almost 5,000, just by the way. But that's what I thought the problem was when I realized it wasn't a thousand, it was 400,000. I needed to really rethink kind of how to architect a program to get 400,000 people on the same page. And it's not something you do overnight. Once that kind of notion was out there, then I started thinking about how does a virus work? And the protein in the middle is kind of what I'd always been thinking about is the virus is concealed by a protein. That's true, but that's all related to the thing. And when I started thinking about the systems that would ultimately dictate the behaviors, or at least reinforce the behaviors of the 400,000, those had nothing to do with the thing. And so that's when the notion of, okay, I need to put kind of a capsid shell around the design and design thinking thing. I need to protect that thing. And while I'm protecting that thing, I need this outer shell to start dealing with these massive systems of scale that drove IBM. Whether it was the HR systems, the management reporting systems, the, the product reporting systems, all of those things were going to need to be changed. And that was going to require a set of experts and expertise and leadership that had nothing to do with design and design thinking. Our designers were delivering to the hallmark teams. And the rest of my leadership team was actually interfacing with the scalable part of IBM. So my talent person, yes, there was a person on the talent person's team that was responsible for designer recruiting. But the real function of my talent person on my leadership team was to interface with corporate HR and to start getting into those systems, the things we needed into those systems. My communications person, yes, she was helping the comms around design and design thinking, but what my comms person was really doing was interfacing with the communications apparatus of IBM globally. So that was how that all came to be. And as I started thinking about it for the book, as I've done in consulting since then, where what I call the design provocation is not design or design thinking, it's agile or it's AI or it's something else. The structure of what we built is actually quite transferable to any change problem. The change provocation, the tactics of the change, the technical part of the change can be swapped in and out. But this interface that you have, protecting it and also learning from it and changing the upstream systems that drive long term and global behaviors, all that can be in place. In fact, my leadership team was seven or eight, something like that. Of the seven or eight people, five of them were not designers. And we could just as easily have been doing an AI initiative. As a design initiative.
- [30:27]
B
You had three pillars that were kind of the guideposts, the structure for what you were doing. People, practices and places. Can you tell us how you arrived at those three and how they functioned?
- [30:40]
A
Well, again, it gets back to this culture. Satan. Our mission statement was to create a culture of design and design thinking at IBM. And so I started thinking about, and look, I'd never worked at this scale before and very few people have. One of the very senior leaders in the company who is a famous guy in the software business, guy named Steve Mills, at one of the very early meetings, you know, he was properly skeptical of whether this thing could work and whether I was the one to lead it. A very early meeting, he said, what's your formula? He goes, I get what you've done over here in this small division of 1200 people. He goes, I get that you did it, but what's your formula? And that was a real interesting question. I didn't, I didn't really think of it as a formula. It was just how I worked and it was how I influenced the people that I worked with. And so I came back, I was in New York and I flew back and I was noodling on this and I went to my office and I started thinking about what is the formula? How do you generate different outcomes? And I really believe, and I kind of started with a hypothesis that culture equals outcomes. If you give a team of winners a problem and you give them hammers or screwdrivers, they're going to solve the problem. Some people are just going to solve the problem. But how do you scale this thing that we were trying to do? And I started just thinking about how do we think about cultures? How do we come to understand cultures? What are the levers that an anthropologist would look at to figure out the outcomes that a culture made? And I started noodling. And long story short, I kind of came up with these three primary things. You study the people, you understand their attributes, you study the practices of those people, and you look at the environments that those people lived and worked in. And those three things really resonated with me about the culture of an enterprise or an organization. It's the people and their skills, the practices, including the tools and the places, the physical places, as well as the, at IBM, even Back then we were none of our teams really were all in the same office. So environments to me has always been more than just physical space. It's the environment in which we're working. And the alliteration didn't hurt either, to be honest. I mean, people practice as places. It was a memorable phrase, but it did become the thing by which my team, in our semiannual goal setting, each one of my team had a people practice in place, part of their mission. And once again, I think it kept us thinking very holistically about the problem because everybody had all three things on their agenda. It didn't allow anybody to rat hole too deep in one specific area and miss something big that was outside.
- [33:29]
B
Could you go a little bit deeper into the places part that is particularly interesting? You talked about arriving at IBM, it being a dreary place, and I know that there was a great deal of thought and effort that went into designing that studio, especially the one in Austin. What was the thinking behind that and how did it change behavior?
- [33:49]
A
We wanted to knock down walls. I mean, we wanted to symbolically not have silos as well as in reality, we wanted to not have silos. And so it led to this first notion of a lot of open space and a lot of openness to it. We also had some very specific criteria. A lot of people would come to our studios and their first thing, especially in the early days when they had a certain notion of IBM, a lot of people would come to our studios and go, oh, cool, cool, cool. And it was all cool. It was like one of our design tenets was we aren't going to have Volkswagen buses sticking out of the wall. This isn't going to be just exposed brick and exposed ductwork. It was going to be a space where work happened and work was going to be the centerpiece. When you walked through certainly that studio, but I think virtually all the studios, it was amazing the amount of just work that were in people's faces. And that in itself was a cultural hurdle. I mean, IBM had this big closed door policy, oh my gosh, if any work is exposed, you have to have a badge reader and only certain people can access. We just blew through that requirement. We said, you know what, just like a startup, if we have to be worried that somebody sees a wireframe on a wall walking through our office and all of a sudden they're going to beat us. If that's our concern, we've already lost. There were a lot of cultural norms that had to be broken down to create a physical space that reflected the modern world and reflected startups more than reflected a hundred year old company. The other main thing is that the space had to be less precious than the work. You know, if you spilled anything on any, all of that had to go away. So it forced some of those issues. But we also architected them for what one of our designers, Adam Cutler, called intentional serendipity. And we would do little things. The details that we thought about were kind of at this level. The kitchen that was in the studio was on one side and we locked the doors from the elevator bank to that side so that in order to get to the kitchen, you had to walk the perimeter of the studio and walk through all the teams and witness all their work and interact with all those people. We forced situations that reinforced this notion of interdisciplinary teaming over and over and over. And then finally, what I would say in our physical spaces is we also said this is, we're not going to use traditional IBM branding. You know, that doesn't do any good, but we can use this space as a place for propaganda. And so what we did in the early studios is we reveled in IBM's past design history. And we had people on the wall like Ray and Charles Eames and Elliot Noyes, massive pictures of Paul Rand. And that was really a signal to the company, hey, we've done this before. It's going to feel really new right now in the year 2013, 14, 15, 2020. But back in 1967, we had a constellation of designers at IBM that nobody's ever had. So we can do this. So place as propaganda also was a big thing. As we matured and we didn't need the old folks anymore, we started celebrating our current generation designers in those spaces. And that was its own morale thing. We're doing this, we have heroes. So the use of place is again, look at ancient civilizations. What is it we visit? We visit the places they lived in. Why is that? It's because the place was a part of who they were. And if you can really get into the skin of a place, if you really understand it, well, it is a very powerful mover of culture.
- [37:40]
B
We recently published a piece on Design Better about the ephemerality of the work that we do as designers, as software designers especially. Sometimes it feels a little bit like we're making sand mandalas where there's a gust of wind that comes by and blows it all away. And I'm curious, I mean, you had 12 years at IBM. I think that's a spectacular run and just phenomenal. Organizational change. And since your departure, IBM has gone through additional changes since. How sticky have the ideas and the philosophies that you and your former colleagues put into place? How sticky have they been?
- [38:23]
A
Incredibly sticky. I mean, it looks different. As I said earlier, the last I heard, which was just a couple of months ago, the designer count was between 4,500 and 5,000. That has grown significantly since I left. I'm getting ready to be interviewed for an internal thing there. Y' all will appreciate this. It's the 10th anniversary of the Loop and the Loop, which for those of you who don't know, most of you on the call, the Loop was how we reimagined the visualization of IBM in terms of its graphic representation. But the Loop also was kind of part and parcel to how we implemented design thinking. And the Loop is observe, reflect, make, reflect. Observe, reflect, make, reflect. And how many times you get through the Loop? Or trying to get through the Loop as many times as possible for a given release of a given thing is kind of the goal. If you only have time to get through it three times, okay, then release it and then keep going through it and release again. If you can get through it a hundred times, even better. And the Loop is now part of the official product canon at IBM. So it's no longer thought of as design. It's now part of product management's methodology for how a release is worked. And obviously all of the interdisciplinary teaming. We made over a billion dollars of investment in real estate. I mean, if you look at the design language, what started in that Austin studio, which was originally one floor, then it grew to two floors. If you walk into any IBM facility in the world today, you will see remnants of that original design language, whether it's a design studio or whether it's where engineers work or marketing works or HR works. When we released the book, the official release parties at IBM's new flagship at 1 Madison Avenue in New York City, there are a lot of very direct cues to all. I don't know how many floors, 20 floors or whatever it is, there so massive impact. It unleashed the flexibility and creativity of the community. And when Arvind came in and I think gave it a little more focus on the products that it would major in, it's just flourished. But today, if you see the number of design awards that IBM is still winning in the AI space, if you look at their implementations of AI and AI transformation and the enterprises that are its clients, you'll see that through the IBM garages, which were established as a part of the program. All of this stuff, the design workshops, the iterations, it's all still in place. It looks a little different, but yeah, very, very proud of that.
- [40:57]
C
Phil, you've got a bunch of books on your bookcase behind you there. Normally I do too, but my office is being remodeled right now to become my daughter's bedroom, so my bookcase is.
- [41:05]
A
In here for now. Right.
- [41:07]
C
But I'm curious, is there anything you're reading right now? Or it could be something you're watching or listening to that's particularly inspiring you?
- [41:14]
A
I just read Stan McChrystal's book on character. I'm a big Stan McChrystal fan and he's just released a new book called On Character and it's really a series of relatively short essays, three to five page essays that he wrote to his granddaughters and it's a really wonderful book of just talking about values that matter. I think in terms of being inspired lately, that's probably the one that's great.
- [41:39]
B
I've seen some wonderful interviews with him lately and just admire the way he comports himself.
- [41:44]
A
Yes. Yep. Yeah.
- [41:46]
B
So the book is Irresistible Change, coming out in November. By the time our audience is listening to this, chances are it might be out already. So if anyone is confronting challenges in a large scale organization and change needs to happen, this is the blueprint. This is the book to consult. It's Irresistible Change. Phil, where can people learn more about the book and more about you?
- [42:11]
A
You can go to gilbert.com and you can probably learn more about me and the book than you want to know.
- [42:17]
B
Phil Gilbert, thank you so much for being on the show, Aaron.
- [42:20]
A
Eli, I appreciate it. It's been a fun conversation.
- [42:27]
B
This episode was produced by Eli Woolery and me, Aaron Walter, with engineering and production support from Brian Paik of Pacific Audio. If you found this episode useful, we hope that you'll leave us a review on Apple Podcasts, Spotify or wherever you listen to finer shows. Or simply drop a link to the show in your team's Slack channel designbetterpodcast.com It'll really help others discover the show. Until next time.
- [42:56]
A
Sa.