UX Advantage with Jared Spool & Karen McGrane

What does it take to create a culture of design? How does putting user experience first change the way organizations work? At UX Advantage, Jared Spool & Karen McGrane interviewed inspirational pioneers who deliver user experience as a competitive advantage to their organization. The UX Advantage Podcast traces the journey to that event with short bursts of insight.

Episode #14 Building a Design Studio Culture within IBM

January 29, 2016  ·  40 minutes

Listen Now

Download the MP3

Adam Cutler explains how his team has built up the IBM Design organization, delivered a new design system, and created studios all over the world to tackle the world’s toughest enterprise user experience challenges.

Full Transcript

Karen McGrane: You've been in IBM for more than 15 years now?
Adam Cutler: About 15 years.
Karen: About 15 years, that is amazing. What's changed? IBM is a company that has a long history, a long tradition of design. What's been different in your role over the last 15 years? And, what's new with the design studio that you have in Austin now?
Adam: First off, I used to have to fight to even get in the room. When I first started at IBM in 2001, I showed up at my first meeting, and the engineer looked at me and said, "What are you doing here? You're supposed to paint this stuff up on the way out the door. Decorate that."
Jared Spool: Instead of, "Where do you sit?"
Adam: Yeah, exactly. I realized there and then, that part of what was missing was a good articulation about what design really is, and why people should want it. Not to push around people, but to create the pull.

For the first 12 years that I worked at IBM interactive for the consulting arm. I was doing design work for everybody else. I was just a constant proponent of why people should be considering good design, both internally and externally. Really, where it's netted out was, we're the progenitor of that corporate design program, like with Eliot Noyes bringing in Charles Eames, and Paul Rand, [inaudible 01:16] , et cetera, et cetera.
Karen: No pressure?
Adam: Yeah, no pressure. Design was really at the forefront. The original intent was to humanize technology because if you think back, I mean, for most people, their frame of reference is the "Madman" episode where the guy goes crazy and mutilates himself, because the IBM mainframe has been installed in the ad agency. All of these efforts were made to humanize technology.

In the '80s and '90s when IBM lost its way, design was that thing that got forgotten about. In the road to recovery, everything was about pricing and getting it back on solid financial ground. The design, it got lost, so part of what we're doing with IBM design for the past two and a half years has been reconnecting to that design legacy, and then bringing it forward.

For us, it's not about just mimicking or aping the masters that came before us, but what is this look like going into the 21st century, and how do we apply this every day.
Jared: That design legacy...IBM has always been a business that has reinvented itself. It first made calculators, it made mainframes, the typewriter business for a while, it was in the personal computer business and then it got out of the personal computer business. Now, it's building these large enterprise systems. It's always done paying attention to who its customers are. One of the things about IBM is that customers and users were often different groups.
Adam: Correct.
Jared: This design legacy, it was not always about users, right, so you've had to bring that and make that part of the legacy now.
Adam: Absolutely. As we were spinning up the program back in 2013, one of the first conversations that we introduced to the wider body of people was replacing the buyer with the user, because, to your point, the buyer is very rarely the user of the products that we make. There's a mental shift that goes on internally, that you have to get people to look at a different focal point.

There was a very definite progression of getting people to not lose sight of the buyer but to really start paying attention to why the user was the most important. Because, at the end of the day, to humanize it for ourselves and for others, we were saying that nobody sits down and uses an IBM product for 8 or 10 hours a day. They are using multiple things from multiple vendors all the time.

If we can be a part of the change that helps you get home 15 minutes earlier, so that you can make a kid's soccer practice, or spend the time working out or just relaxing, or just making it not suck for that part of your day, that's the intent.

We know that we can't control the whole experience. It used to be that you'd say, oh, they're a blue shop and they have everything IBM from top to bottom, but that's not the case anymore.
Jared: You described the switch of being asked why you were there and then you just make it pretty, to this movement of now having this very large design studio in Austin, and other studios that you're building around the world, and how many designers?
Adam: The goal is for us to have 1,200 designers on the books by the end of 2016 now, and we're almost there, as it stands right now.

One of the first things that we had to do when we started the program was, we had to figure out who was calling themselves a designer in the company, and we reached out to every single one of them personally, and evaluated whether or not they were actually doing design work. After we normalized that, we understood, here are the number of existing designers in the company, and now here's how many we have to hire to get to that 1,200 number.
Karen: How do you manage the hiring process at that scale? How do you screen people? Honestly, Lou Adler said nothing about hiring 1,200 people.
Jared: That's a lot of proudest accomplishments.
Adam: [laughs] When he was saying, "Maybe you'll get three this year," I was like, oh, all right, different scale. In two weeks, we have a class of 75 designers all starting on the same day. The previous class of 68 is just finishing up their on-boarding process right now. How do we manage this? Currently, and these numbers are rough, but we've had over 10,000 applications from designers from all over.
Karen: You just take the first 1,200?
Adam: Yeah. Well, if we did that, we would be done, but it's not about taking the first 1,200, obviously. We have a very robust recruiting and talent management group. Their sole focus is just building the pipeline and creating the demand and getting people to take their experiences that they've had with us at IBM Design, and bring them back to where they've been.

It's worth mentioning that, in stark contrast to a lot of what we've heard so far today, two-thirds of our hires are right out of school, so either right out of a graduate program or out of an undergraduate program. For a lot of them, we send them back to their schools to do the recruiting and to show the things that they're working on, the responsibilities that they're being given.

10,000 applications, 7,000 portfolio reviews, 5,000 phone screens, about 750 fly-downs, in which we take those people that make it through that first barrier, and we fly them to Austin for an intense, three-day interview, in which they're given exercises. They're asked to work with each other, so we can actually see how they behave working in a group and not just as a lone wolf. Then, from there, we've hired about 450 out of those 750.
Jared: How do you then integrate them with all the different product groups that are throughout Design? You've got all these folks coming in, and they're coming in through the Design Center, but eventually they've got to get out into product and service groups, right?
Adam: Yeah. We have a Design boot-camp program, where it would be thoroughly unfair to take a group of people and just say, "Welcome to IBM. Now go work," because there's no discipline or rigor behind bringing the work and the profession of design to the organization.

We created a Design boot-camp program, which I was referring to earlier, in which, if you come directly out of school, you start with a cohort of between 45 and 75 people.

It's a three-month program where they come to Austin. They have their own space. They work with one another. For the first six weeks, they're taught basics, like, "Here's how you work within the company. Here's how the company works," which is fairly large as it is.

Then, they're also taught principles around inclusive design, so bringing accessibility to the forefront instead of tacking it on at the end, learning basics around front-end development and being able to code within the JavaScript framework, and some basic stuff like that, with small micro-projects sprinkled throughout to apply that training.

In the second six weeks, they're actually given real projects that are sponsored by the business, and these projects that they work on, and the domain associated with it, are where they will end up being deployed. Then, after their three months, they're deployed out into the various business units.

For professional hires, they have a bit more of an accelerated time line, where they're brought in, they get three days of a Design camp, and then they're placed on their team after that.
Karen: Can you say a little bit more about these boot camps, and how you get people up to speed with the domain knowledge? If you're taking people right out of undergrad or at school, they, I'm quite certain, walk in without the level of insight into security or cognitive computing that you need them to have. How do you train them?
Adam: Sure. Part of that is done through that second six weeks in their Design camp experience. We also recognize that if they've just spent somewhere between four and eight years becoming the best designer they can be, they're not going to have that deep domain expertise in something that we specialize in, like security or cognitive or social or something like that.

Part of it is that we work with the receiving team that takes on the designers, to help them create a program that helps to on-board the designers, and give them an overview of what they're going to be working on, because even cognitive computing is a little broad, but it is about them learning on the job.

What I've seen from my consulting background, as well as many others who are consultants here, we've done and seen so many different types of business, whether it's pharmaceuticals or financial services or whatever, and we seem to pick it up rather quickly. It's a little combination of each. It's give them a running start, give them a program that gives them the basics when they get there, and then let them learn as they go.
Jared: Some of these folks are going off and working on the Watson team. Do you make them watch "Jeopardy" episodes?
Adam: [laughs] No, I don't make them do anything, actually.
Jared: [laughs]
Adam: Everyone says, "Your designers," "Your designers." They're actually not my designers. I have a team of about 15 or 20 people that are responsible for everything that you would see publicly around IBM Design, but everyone else goes to their business unit. When they arrive at the business unit, the business units, at the product level, will have a Design team lead, and at the portfolio level, there will be a Design executive that oversees the Design team leads.

They report in through those Design team leads and those Design executives, and we provide support to everybody in the mix. It's about being the best designer that you can be, not about directing them on their product work.
Jared: To follow the tradition here, what's something that you're particularly proud of about the Design camp?
Adam: For one, it's Bluemix, which is our platform as a service. That came out of the very first design camp, and the design really defined what Bluemix is as a product. Arguably, it's as important as Watson is to IBM.
Jared: Say a little bit more about what Bluemix is, for people that don't...
Adam: Bluemix as a platform, as a service, is, imagine that instead of having to go with the monolithic install of a bunch of IBM software on-premise, you can pluck things off the shelf, and use them and pay for them as you go, and by plugging them into whatever you've been using. So, service-ready is really what they are.
Jared: So if you need to check out things, there's a checkout component, if you need a ratings thing, there's a rating's component.
Adam: Exactly, and then there's complicated stuff like secure authentication, and things that you don't necessarily want to try to write yourself, or reinvent the wheel around.
Jared: Really? Everybody seems to write their own authentication apps. Madison did that that.
Adam: We know how that worked out. In coming up with the design of the product itself, it really defined the product. I think a lot of times, what we struggle with as a group is, getting people over the hump that design is not like Photoshop color choices, and typography.

That it is the purpose or intent behind what it is that's being planned. The way that you put it is, design is the rendering of intent. The way that I would say it is, it's the purpose planning and intent behind an action, factor, or object. It's not just about what just gets put up on the glass. It's about why this thing exists, and how it exists.
Jared: A few months ago, you graciously invited me to come by the studio, and you showed me the layout of the space. Can you say a little bit about the design here, because it's pretty awesome.
Adam: Super proud of it. It's 50,000 square feet across two floors. We have over 300 designers working in it full-time. When we were building the first floor, the eighth floor, we were stuck. There were 75 of us crammed into the most basic hallway, with four rooms that came off of it.

We broke the first design camp up into groups of 15. One day, one of the designers came out and said, "Hey, do you have a toolbox?" I said, "Yes, somewhere around here." I didn't really think about what I was doing when I handed it over.

A half hour later, I came back, and they had unscrewed all the furniture, this big heavy boardroom furniture, and they had rearranged the entire room to fit their purposes.

It became this cultural touchstone where, all of the teams would just pick up all their materials, and move it around, and shift it, based on what they were working on, or who they wanted to be working with. Around this time, we were doing the demolition of the eighth floor, and I made a call that all the furniture needed to be on wheels.

Actually, everything needed to be on wheels. If it wasn't on wheels, it needed to be light enough so that two people who were 5 feet tall, 90 pounds, could move it on their own, without help.

Everything on the floor is completely reconfigurable. That's the picture of one of the security work space on the eighth floor. That space changes on a regular basis. They all do. What we learned, what we were looking at before with the hanging light boards...
Jared: Can we roll back one slide? Yeah that.
Adam: Phil and I had both visited the Stanford D School, independently. We both came back saying the same things like, "Did you see that hanging white board system that they had?" If you haven't been there, they have these rails drilled into these huge oak beams.

These white boards, you can take them off and put them on, and you can subdivide the spaces as you need. There are hooks for these personal light boards that go on there. We both fell in love with them, and we found out that because IDEO, Steelcase, and the D School are so tied to one another, that Steelcase had actually come up with this idea in the first place.

We called up Steelcase. They did this. This is the first of its kind for us, so we worked with Steelcase in the prototyping. The entire seventh floor is based on this model, where there are four large quadrants that can be split into four smaller quadrants, or split in half.

We also have the ability to pull those white boards down, and use them as table tops, so that you can write on top of them. Really, what this space is all about is being non-precious. It's not about being neat and clean. What we say is, "You better worry about what you drop, than what you drop it on."

There's sharpies, and post-its, and X-Acto blades, and stuff all over the place. It's about people doing their work and getting their hands dirty.
Jared: Those hooks, the black dots on the boards, those are hooks for these personal white boards, and there are hundreds of those.
Adam: Hundreds.
Jared: People sort of bring them into a meeting, and they mark them up, and then they take them back to their desk, and they work with them?
Adam: Yeah. We also have them all stored on these like, Home Depot hand carts, so that the whole point behind this is...
Jared: ...You raided a Home Depot.
Adam: [laughs] We actually paid for them.
Jared: It's like throwing out a trash can. You go into a Home Depot and say, "I want three of the carts and..."
Adam: And just load them up.
Adam: Shoot, I should have thought of that, but with the hand carts, the idea behind these spaces are the rapid construction and destruction of space. What we found is that, people work much differently when they're standing up, vertical, and next to one another.

When the day is done, and it's time for you to clear up, we've made it so that all of these components are removable. They can put them back on the cart, and basically tape them together, and put a post-it on there that says, "This is Adam's set of whiteboards. Do not erase."

Then if you want, you can come back, and set it up in one of the other spaces, or the same space. You can use all of the material all over again, because what we really determined was, the more we work on whiteboards and vertically, this is the externalization of our minds.

This is our collective brainpower that's being spewed out onto the walls. Often times we get spatial with this that. In a space like this, an idea will get thrown up on the wall, and you'll do a whole mess of drawings around it, and you sort of remember, "Oh, it's in that lower back, right corner, over there." People have the tendency to go back to the physical space, to remind themselves of what they've worked on.
Jared: "Spewed out onto the walls," is my new favorite band name.
Adam: There you go. I managed to make the list.
Karen: I would love to ask you some of the structural questions around where the designers sit, and report into, in the organization. Some of them are reporting through the design studio, but many more of them are actually distributed out through the individual business units.

How do you ensure that they have the right level, title, career path? How do you ensure that designers, or performance, is being reviewed and evaluated appropriately?
Adam: Similar to what Samantha was talking about with GE, we have a set of values and what we call personal business commitments to IBM. We're all evaluated against the personal business commitments. Some of them come from Ginni, at the CEO level.

Some of them come from down below, at the Senior Vice-President level, but we set the PBCs for all the designers, and they're sent out to anybody who sits... Jared: PBCs are...?
Adam: ...Personal business commitments, sorry. I work at IBM. Everything gets crunched down into three letters.
Adam: We write those personal business commitments for the designers, and then they're distributed. One of the things that makes this quite easy to do is that, my wife Jodie, for the first two years of us doing IBM design, she wrestled the HR system to the ground, and made it so that we have an official job title and job code in the HR system, with an associated career path.

For the first time ever, designers have a seat at the table, along with engineers. They have the influence over the way that the business is run, whether it's at the portfolio business unit, or company level, and that they have a path that they can look at to become an IBM fellow, just the same way that an engineer is. This is the first time that this has ever been.

This allows us to maintain equal pay, and then because everybody is in that job code, we actually know who is a designer, so that we can line up all of their evaluation criteria together.
Jared: This is a big deal, right?
Adam: Huge.
Karen: Huge deal.
Adam: Yeah, a huge deal. Yeah, absolutely.
Jared: Because years ago I remember working with designers at IBM, and the designers were sort of lost in the HR system.
Adam: When I was hired I was an IT specialist, if you can figure that out. It didn't make any sense, and I don't know how many different phone-calls and emails I had to send just to get switched to consultant, and they grudgingly did that after 10 years. Now that we can all be slotted into a designer job code makes life a lot easier for a number of reasons.
Karen: How's that effect performance evaluations that are being done? Not by you, but by people in all the various other business units?
Adam: Again, it's through those personal business commitments that these are the criteria that we're all evaluated on. As a designer they're being evaluated on the contribution that design makes to the business.

We're brought in as consultants sometimes to the business units, if they have a harder time making a determination between things, but for the most part they have the framework in place already, and the designers that are there are the ones making the judgment calls.
Jared: How did you get executive buy-in to do all of this?
Adam: There's a long story, and the shortened version of it is that my manager who is the general manager of design, Phil Gilbert is, prior to the formation of IBM design, was talking with his manager and they were joking and the said, "So what's next for you Phil?" And Phil sort of said jokingly, "Well if it were up to me I would redesign every single last piece of software that IBM made."

It became one of those "Be careful what you wish for" moments. After a few discussions and some planning with Jenny herself, Phil is dotted line to Jenny.
Jared: He's the general manager of design for IBM?
Adam: That's correct. Across the whole company. We have a charter from her, the funding from her, so we explained and justified what we needed to do in order to do this right, and not have it be a halfhearted attempt that falls flat six months down the road.
Jared: When you say you have 1200 people, and you're dotted line to Jenny, do they ever see her?
Jared: Yeah. When we opened the studio, she brought the entire senior leadership team to Austin and spent half a day with us and sat with the designers, made herself available, and then she came back maybe two or three months ago, where she interviewed Randall Stevenson the CEO of AT&T in the studio.

Did a 25 minute Q&A with all the designers in the studio, and is keenly aware of what we're doing. It's not like we're something that's sort of off to the side. She's directly involved, not all the time, but she does come by.
Jared: When she brought the senior staff, explain that thing? There's a noun in there, but I don't want to.
Adam: The thing. [laughs] Because we're designers we can't do anything straightforward. When we opened the studio, rather than simply have her cut a ribbon, which is sort of cliché, I don't know, probably over 500 discarded post-it notes from various sessions and arranged them on this giant board.

Then because these designers were particularly masochistic, they took these bigger post-it notes and they projected each of the senior leadership team's names, individual names, in "Helvetica" up onto these things and then hand-drew their names in Helvetica so that it was brand appropriate and all that.

Instead of having them cut the ribbon, they all autographed their own post-it note. Each post-it note was based on one of our company values. We had that framed in this massive glass frame thing.
Jared: Did senior leadership appreciate that they had traced Helvetica and not "Arial?"
Adam: No. No, they didn't know. They were just like, "Oh, that's neat."
Jared: We have some great questions that have come in...
Karen: Should we ask? Let's see, Michael. Michael, you know your last name.
Jared: You can tell us your last name, so that everybody knows we're avoiding pronouncing it.
Karen: Right there? So you ask a couple of questions. One about how they get deployed into the business units, and then what sort of support gets provided after?
Michael: It's kind of a follow up to a question that I want to ask, what actually happens to these designers once they leave boot-camp, you mentioned that they get deployed. I assume that means across the country, or across the globe maybe.

The follow-up to that is, once they are deployed in these remote places, what kind of tools do they have to phone home to the design group to discover what the other business units are doing. Are there any tools for collaboration once they're in these separate places, things like that, and do they ever see each other again like do you have [inaudible 23:55] .
Adam: All right, three part question. I hope you were keeping track. The first thing is the reason for the creation of the studios was to house designers together. Most of the people that we hire, they actually, when they get deployed, they simply go upstairs to the eighth floor and join their team up there.

Some people will go to Astor Place in New York, some will go to Hursley, England, or Dublin, Ireland, or Shanghai. For the most part they're sitting with other designers, and partially this is for a couple reasons. One is, as we were starting the program, engineers didn't know what to do with a new set of designers that they've never worked with before.

Sometimes that was like grinding gears a little bit. By co-locating them with other designers, they're able to support one another sitting near one another. Some do end up going remote, for the most part, though, they're in a studio. However, their teams are spread out all over the world.

There's 388,000 people in IBM in 171 countries. Most of their development teams are in at least two or three different time zones, and probably four or five countries.
Jared: IBM already has a culture of working remotely?
Adam: Absolutely.
Jared: This is just utilizing that existing code. You didn't have to do something new for designers to work remotely with their team?
Adam: No, in fact, some of this stuff from a collaboration perspective, after we were doing some of the design camps for the product teams when they would fly down, they would say, "This is great, but how do we do these post-it note things when we sit in three different places?"

We formed a partnership with Merrily, which is a cloud based sticky note tool, which everybody loves and we use all the time. The teams all use that together. Engineers, project managers, and designers, regardless of where they sit.

We use Slack an awful lot, which is why you've seen me pretty active on Slack today, it's just constantly going in the background for all of us. There's also been some pretty interesting homegrown solutions. I had one team that they lost one of their designers, they had to go to North Carolina while they were selling their house.

They were sitting at RTP in the Research Triangle Park location, but they missed the face-to-face interaction, so they went on eBay and they bought a used IV pole, and then they bought a little clamp that they stuck an iPad in, and they turned her on, on FaceTime, and left her on all day. When she was sitting at the desk with everybody else, they lowered the pole so she was at head height.

They said. "Hey Erin, do you have that...?" "Oh yeah," and she would just do a file transfer instead of handing something over. When she wanted to talk to somebody else in the studio, they would just raise her up to standing height and wheel her around.

She came back to visit, and the same thing, we all laughed the first time we saw it, and it was kind of ridiculous, and then she came back and she said, "Well I have to personalize this," so she left one of her shawls and tied it around the iPad. Then other teams just started doing this on their own.

There was one team that had a Canadian product manager, so he brought down this big tube with a big pompom and a maple leaf on it and he stuck that on top of it, so you could tell whose iPod was who.

You would have these design competency meetings or town halls, and you'd look across a crowd as big as this if not bigger, and then you'd see there's a person on an iPad stick, and there's a person on an iPad stick. It got to the point where there were no longer giggles, it was just, "Oh, there's Jared and Karen, but they're not there."


We've done a lot of homegrown stuff with that too. There was a third part to the question, and I can't remember what it was.
Jared: It's "Do the teams have a chance to see each other after," but since they're co-located...
Adam: Yeah, for the most part they are co-located, and then they do come back. We also have our designers go into other studios as well, so they do get to see each other.
Karen: Let me ask a question on somebody's behalf. When you are doing performance evaluations or setting up a framework for performance evaluations, do you have a way of measuring the contribution the design, or an individual designer makes to the business, and can you separate that out from...
Adam: It's very difficult. I think something that needs to be said in general is, at least from my point of view is, we need to let go of ownership of design. If design is just the rendering of intent, we choose to work in certain media. Whether it's a wire-frame or a set of requirements, but code is just as important. I don't know how you would split apart like, "Oh, the reason why this thing succeeded was because of the design."

I think if there was a year over year release upgrade to some product, and that the only thing that was done for the next release was something that was user centered and more about the user interface, or the user experience and sales went up by 20 percent, or whatever it is, I think you can point to it that way, but it's very difficult to split out, this was designs contributions.

It's more about "Did they work together as a team?" As soon as we start saying, "Design's over here, engineering's over here, product managing's over here," we run into the same problem that we've all been talking about to one degree or another, which is like "How do you deal with them? Who's your favorite?" and "Why do we butt heads?"

It's because we're not thinking about approaching this as a team, we're thinking about coming at it from our own disciplines, and then we're sort of forced together as a team.
Jared: This idea of working with the engineers, and sort of changing that part of the culture, and we've talked a lot about culture over the last two days. IBM being more than a hundred years old and having a deep history and being very engineering driven for much of that, but also having the marketing ethos of the guys in the blue suits and the white shirts.

There's always been a very strong culture at IBM, but design's contribution to that culture has always been sort of backstage, and how've you change culture in particular with putting all these designers into the world and having them work with these teams? As part of the boot-camp are you training them to be cultured change agents in the regard? Does that happen independently?
Adam: It's a little of both. I wouldn't say there's a deliberate, like we're training you to be a culture change agent, but we are training them on how to behave, that people want to be treated a certain way. If designers come in saying, "Oh, everybody, you've sucked for so long and we're here to save the day," that doesn't really go over very well.

There's a part of it which is especially if they're coming right out of school. You've never really worked with these individuals before, so you what their expectations are versus what your expectations are may be here and here, and this is why I thought, yesterday Karen just hit the center of the bulls-eye.

It's all about alignment. Internally it is all about getting our efforts aligned properly, and understanding that we all are trying to do the same thing. Nobody shows up to work saying, "I'm going to make a really bad decision today." Everybody thinks they're making the right call.

We talk so much about building and gaining empathy for our users, and yet designers are the worst when it comes to using our own tools to solve our own problems. What about empathy for engineers and what they go through, or product managers? A lot of times it's just about having them use the tools that they already have and applying them inwardly.

Culture-wise, I think at the beginning there was a lot that had to do with very high touch with us, and the folks in the core IBM design team really working closely together with these teams to show the value of what we were doing.

Now it's all shifted to "How do we do this at scale? How do we do this when we're not in the room?" It can't be just "Here's a video that we recorded," and watch this video. It has to be that we're passing it down to the practitioner, so by putting the same capabilities into the hands of the design executives, and the design team leads. Their responsibility is to then take these ideas and spread them further.
Karen: I think one of the themes that's come up in a number of our interviews is, design moving from the hit it with the pretty stick, to actually influencing the product road map, or the vision, or the direction, of the product. To moving into a more strategic role, actually influencing the future direction of the company. Can you talk about how that's happening at IBM? How your team's doing that?
Adam: Yes. The very first thing we did was that we developed and introduced IBM Design Thinking. The reason why the IBM is there, is not to necessarily brand it as our own, but we sat down with David Kelley, and with Tim Brown. We talked to them about what they were going through when they were developing the concepts of Design Thinking. The one thing that they both said was, "We really blew it when we called this thing Design Thinking."


The second was, "It works great when you're doing it in these small workshops at Stanford, but it starts to break apart and fail at scale," and so what we did was, we took the core tenets of Design Thinking. Exploration, understanding, ideating, making, and evaluating.

We took those, and then we added three governing constructs on top. The first being a sponsor-user, not just going out and doing standard engagements with users, but signing up users from paying clients already, and people who are using them. Getting them to be co-designing with us, from somewhere between 10 and 50 hours, over the course of a release.

The second thing is a construct called The Playback, which is very similar to what a lot of us would call a critique. It is these open dialogues where just the design work is shown at a high frame rate. The whole thing maybe over and done within 10 minutes, to show the actual work.

It maybe that they're just phone snaps of scribbles on a whiteboard for the first one. Senior executives are invited to every last one of them. Everybody attends these things. They don't always attend every last one of them, but they do attend them.

It gives everybody a chance to look at what's being designed and say, "I think we lost the plot." "I think we were right on track," and keep pushing forward. Or, "Where are we going to go next after this is done?" It gives us a series of checkpoints that allows us to stay honest with each other throughout, so there's no big unveiling, and everyone goes, "That's not what we asked for."

The last one, which is probably the most complicated to understand, or to explain is, this concept of hills. That's a military term taken from commanders' intent which is, you're going to take the hill. You can train for a mission all you want, but inevitably, things go sideways when the mission starts, but what doesn't change is that you take the hill.

The hills are three, and only three articulations of what you're going to provide in any given release, so that we don't bite off more than we can chew, so that we can keep the team's focus on what's necessary to have a successful release. It's always user-focused. This gives teams a way to focus the effort on a per release basis. Those three things. That's a long-winded answer to your question, but that is part of how we're bringing this out institutionally.
Jared: What's the mechanism for getting it out to the rest of IBM, because there's a lot of people who need to know this stuff. What sort of machinery do you have to get them to be a part of that program?
Adam: It's surprisingly simple. There's a pier to the new higher design camp, which is the design camp for product teams that lasts a week. Per team, I think we have like five or six different product teams that attend. They all fly to Austin, they spend a week there, and its two engineers, two product managers, and two designers from the team. They're taught and then they're given all the stuff that they need to bring that back to their larger team.
Jared: It's all Train The Trainer effort?
Adam: Yes, and there's a formal Train The Trainer effort going on within GBS, so that the GBS designers, the Global Business Services, the consultants, that they're being trained on how to use IBM design thinking for client engagements, which requires a few nuanced twists to how we do the work.

Simply enough, we have an internal website that we put all the material up on, that allows people to come and get it. My team is currently working on the first public version of this, which should be out sometime in the first quarter, in which we will share this with everybody, the way that we've done with IBM Design Language as well.
Karen: You are our last interview of the event. What advice do you have for other organizations, other people who are looking to bring about this kind of transformation, or use design as a competitive advantage?
Adam: Let's see if I can remember. One is, and I'm going off of what people asking in the Slack Channel to. The space that you sit in, is what you make of it. For everything that we have in our studio, there is something that is home-made, that does the same job. We've made up 75 whiteboards with Xerox, that you can find the directions in the D School website.

It is about providing your team what they need to feel, that they are prepared and they have what they need. It's not about what you're giving corporately; it's about you making the space what you need. Ask for forgiveness, not permission, as far as that stuff goes.

I already said, let go of the ownership, share design. It's more fun this way when you actually share design with everybody, as opposed to trying to claim it for yourself. What else? Based on what I was saying about Karen's statement yesterday, about she's in the deliverable business, but she's in the outcome business.

Artifacts are not sacred, don't get into holy wars over which artifact, or which method, or which tool you use is better than another. It is about the outcome, plan for your outcomes. That's the most important thing. Get there how you have to.

Wherever possible, I understand that sometimes it is a competitive advantage, but when you come up with something that advances the state of design for your own team, or for yourself, if you have the option, share it freely with as many people as possible.

We all get smarter and better because of this. That's part of the reason why we show up at an event like this, is to hear the stories that everybody else has to tell. When we're networking outside, to be able to listen to how people address certain problems.

If you come up with something new, share it. There's certainly no need to go by the book all the time. If you invent something new, heck how many things did you invent from the clear blue when it came to usability testing, over the course of years...
Jared: We were making all sorts of crap up.
Adam: Still making crap up to day, so if you make something up, share it. It doesn't mean that it's right or wrong, because somebody else has written a book, or a blog post, or something else about it, but just share.
Karen: That went well. Thank you so much. This has been a fantastic ending to our conversation.
Adam: My pleasure, thanks for having me.