How IBM made sense of ‘generic design thinking’ for tens of thousands of people.

Our readers who have followed design thinking’s development in the industry in the last 10+ years might be familiar with this situation: generic ‘workshop design thinking’, which was originally codified by the d.Schools for teaching and less for a 1:1 deployment in the project work of big organizations, is getting scaled up prematurely in big organizations. This comes with typical side-effects. Generic design thinking often faces heavy resistance from influential skeptics, gets misunderstood or not understood at all, or less dire, it gets picked up with an unreflected euphoria and is applied as a “silver bullet” to all kinds of problems and projects (the famous “methodology misfit” we also see with Scrum for example). The big hangover often comes after the first experimentation budgets are expended and at worst a blame game starts.

A forced roll-out of generic design thinking will always fall short of the mark and create frictions, such as the ones described in below infobox. Wise executives, as well as experienced innovation (program) leaders therefore know that the successful adoption of a ‘new’ management concept like design thinking can only be achieved through the hard work of adapting it to the specific context of the industry and organization itself . And even if you are deliberate in your introduction: you will still have to cope with internal adaptation challenges.

Warning Signs

If you still hear the statements below in your company or from your (internal) consulting partner after you went through your first batches of basic trainings, or if your design thinking program has been around for a while, be on high alert …

“Trust/Follow the process.”¹: This emergent mantra, which critically thinking d.School students call the “slavishly-following-the-bubbles” phenomenon, is often used to guide non-design novice learners in their first design thinking trainings by their coaches and tends to hive off, especially in risk-averse environments, as it promises ‘process-security’. David Bland nicely framed it this way: “We can’t change the process for dealing with uncertainty, because that introduces uncertainty into the uncertainty reducing process.” And while it is fine to let the generic design thinking ‘process’ guide you as a learner, you shouldn’t force your whole organization to apply it in a waterfall-ish way in all of your project work (this would be a 1:1 ‘adoption’). It is not without reason that the d.School emphasizes the ability to “Design your Design Work” in their revised teaching mantras. With time and experience, this also includes the adaptation of processes to organizational and project contexts.

“We rewrote our stage-gate process and included a ‘design thinking step’ in the beginning [or somewhere else].”: This phenomenon is closely tied to the one from above. Sam Yen (former Chief Design Officer, SAP) calls this the “design thinking by checkbox” thinking, which views the methodology as a self-contained step instead as a practice that permeates the way people approach their every day (innovation) work also within other agile exploration and delivery methodologies like Lean Startup or Scrum.

“It’s a mindset, ‘they’ just don’t get it.”: It is easy for leadership as well as external and internal design thinking coaches to shirk their responsibility by saying ‘they’ [the poor retrained people in the organization] just don’t get it. No wonder, if you just expose them to the generic design thinking kool-aid à la “this is how Stanford/IDEO/our biggest competitor/the ‘Silicon Valley’ does it.” If you don’t bind design thinking’s (re)introduction to your organizations’ design and innovation heritage, the language your people use, and the context they understand, you should not complain.

[1] This mantra originally comes from Pixar (a company full of creative people working on a very creative product, animated movies): “Trust the Process.” We liked this one because it was so reassuring: While there are inevitably difficulties and missteps in any complex creative endeavor, you can trust that “the process” will carry you through. In some ways, this was no different than any optimistic aphorism (Hang in there, baby!), except that because our process was so different from other movie studios, we felt that it had real power. Pixar was a place that gave artists running room, that gave directors control, that trusted its people to solve problems. I have always been wary of maxims or rules because, all too often, they turn out to be empty platitudes that impede thoughtfulness, but these two principles actually seemed to help our people.”

In this article we therefore show by example of IBMs design thinking adaptation, how a strategic approach to introducing and scaling can look and what hurdles have to be overcome.

IBM Design Thinking 1.0

In the early stages of the IBM Design Thinking program, Adam Cutler (IBM Design Studio Program Director) and Phil Gilbert (General Manager Design) sat down with David Kelley and Tim Brown (Co-Founder and CEO of IDEO) to discuss what IDEO was going through in developing the various design thinking concepts. Remembering the conversation, Adam shared what the two IDEOers said: “We really blew it when we called this thing Design Thinking. […] It works great when you’re doing it in these small workshops at Stanford, but it starts to break apart and fail at scale.”

IBM Design Thinking 1.0 Process Visualisations and Core Practices

“We really blew it when we called this thing Design Thinking. […] It works great when you’re doing it in these small workshops at Stanford, but it starts to break apart and fail at scale.”

From frank conversations like these and their own observations of (failed) design thinking initiatives at other organizations, the two came to the conclusion that it would be far from self-evident that the engineering-driven people at IBM will instantly accept and embrace the central generic design thinking core tenets (e.g. explore, understand, ideate, make, evaluate), which are emphasized and taught by the d.Schools. On that score, the creation of an IBM Design Thinking (1.0) framework in 2015/2016 was less about branding and more about integrability within the IBM context. The idea behind it was to add a governing structure that would ensure people would work towards the same goals and in a similar direction. This deliberately simple structure consisted of, what IBM calls, three key practices: sponsor-users, playbacks, and hills.

IBM Design Thinking: The Terms Explained In Plain English

When IBM started, they simply took existing generic design thinking processes and modi descriptions and added three governing constructs on top. Until today the process description has changed, but he governing core practices stayed. IBM calls these practices “keys” (for key practices).

Key 1: Playback

Playbacks, or in plain English “frequent (design) critique sessions,” are IBM’s way of eliminating hierarchy and silos. The IBM Design team realized that teams needed a safe place to present their work, tell stories and exchange feedback in a project’s ever-evolving situation. There needed to be a way to reveal misalignment and keep (dispersed) teams and stakeholders aligned and in sync across time. The solution: frequent, open dialogues where, during 10-minute minor team playbacks, concepts and ideas are reflected upon and critiqued constructively. Typical questions are “What did we learn?” and “What is our next best move?”. Beyond such frequent playbacks, so-called milestone playbacks are held, which also involve senior management. This also expands the culture of respectful and constructive critique beyond the core design team and creates alignment with the project sponsors.

Key 2: Hill

Hills, are statements of intent. They were inspired by military commanders who state an intention e.g. “take that hill” to provide troops with a general direction and focus but without saying how to do exactly what they have to do. At IBM design, hills are formulated as max. three sentences per sprint, which describe the main objectives of a release in a user-focused way, helping the team to focus their efforts. Similar to a POV in generic design thinking, a hill frames a problem as an intended user outcome without any predetermined solution.

IBM Hill – Example

Hills bear a certain resemblance to “epic-like” user stories and job-to-be-done statements. The goal here is team alignment around commonly shared micro-missions.

Key 3: Sponsor User

“Sponsor users are a way to measure if we have recruited people against the hills”, says Phil Gilbert. Sponsor users usually are either potential or actual, users from paying clients that are signed to spend 10 to 50 hours to co-design with IBM teams over the course of a release or project. They are added to the team as they not only represent the problem, but can also help in validating solutions, and supplementing the team’s field research and personas with their insights on the spot.

Equipped with this framework, they trained the first cohorts of new hires, retrained people from all over IBM, and started signature projects within their now-famous Hallmark Program. But what happened was nothing less than a culture clash.

‘IBM Design Thinking 1.0’ vs. ‘Agile’ – A Culture Clash

At IBM the concept of ‘continuous delivery’ in terms of speed, quality, and efficiency was already practiced company-wide – a fact that many developers were very proud of. What IBM Design’s change team observed though, was that teams who practiced ‘Agile’ were iterating the wrong problems with data they collected from usually just one source: tracking via data analytics. Or as Phil Gilbert puts it: “Agile [might be an] underpinning execution mechanism, but it has no soul, no compass, no morality .” It was also on that score, that they tried to bring in the sponsor users’ perspective and make their experience the measure of all things.

But instead of embracing design thinking, IBM engineers were skeptical about it, or even rejected the generic explanation models of IBM Design Thinking 1.0. And these were not just those teams who were still running on waterfall. Instead, the critique came from the above-mentioned agile pros who took the process visualizations verbatim and claimed: “This feels like going back to waterfall.” So, instead of complementing existing approaches and frameworks for agile software development, IBM Design Thinking 1.0 all of a sudden found itself at odds with groups who already subscribed to other ‘iterative’ ways of working (Agile, DevOps and PMOM). The knowledge codification challenge for the IBM Design team thus had to be reframed. Instead of asking: “How can we teach design thinking to the [IBM group]?” they now asked, “How can we integrate design thinking as a general philosophy into all of the existing practices, into project teams already running at speed, and without causing any turf or religious wars around methodologies?”

The Reasons for the Pushback in Detail

IBM is not alone in the struggle to make sense of an apparent oversupply of agile innovation approaches. In many organizations, groups simultaneously started experimenting with different methodologies like Effectuation, Design Thinking, Lean Startup or Scrum, to name but a few. Add to this the confusion about the similar terminology across these concepts (e.g. iteration, fast cycles, sprints, ‘Agile’ as an umbrella term, etc.), which can mean different things in different projects stages: just think of the differences between an exploration sprint (GV Design Sprint, Design Thinking Sprint) and a delivery sprint (Scrum). So, however much the change agents are forced to sweat bullets to do it, they will have to make sense of all of this and adapt these concepts. This includes their specialist terms, jargon and explanation models of the prevalent mental models and parlance of their organization. To the IBM Design team, this meant the following homework:

Engineers already believed they work in an iterative manner. So, first the waterfall-like visualizations of design thinking had to go. But more importantly, the difference between ‘thick data’ (talking to a small number of real sponsor users) vs. ‘big data’ (tracking user behavior via analytics) had to be emphasized somehow.

The many mantras, principles, and abilities of generic design thinking buzzing around were too much for people. IBM had to deliberately choose a subset of basic principles, which made the most sense for their context, namely diverse empowered teamwork and a (re)focus on user outcomes, not technology. The selected few then had to be phrased in a way that would eventually resonate with IBMers.

There also emerged the task of teaching designers the humility to smoothly forge in at speed with running teams. One particular challenge was training designers, who had a bias towards (design process) perfectionism, new mental models and to encourage them to work more on gut e.g. with imperfect, messy data.

In essence, the task for the team was now to adapt IBM Design Thinking 1.0 even more to the language of the organization in order to make it more ‘IBM-specific.’ Only then could the team really help newcomers and practitioners in getting up and running quickly.

Reduce to the Max:
The Becoming of IBM Design Thinking 2.0, ‘The Loop’

It all started in June 2015, when Adam Cutler (Design Practices Director) and Miroslav Azis (Experience Design Practice Lead at IBM) decided to learn from a group of extreme users: four Irish visual communications interns (students of Dun Laoghaire Institute). The four knew nothing about software, had never worked in an enterprise, nor had they ever heard of design thinking. Miroslav clearly pitched them the IBM Design Thinking 1.0 problem in, well, … IBM lingo: “People think PMOM, Agile and DevOps are at odds with IBM Design Thinking, and they don’t know how Hills map to Epics and User Stories.” What followed was silence, perplexed looks and then an introduction to the groups’ persona: “Sarah,” the 5th grader. “If it doesn’t work for Sarah,” the students said, “it doesn’t work at all.”

In their search for a better explanation and visualization model for design thinking, Miroslav and his team had already analyzed dozens of team interactions and were continuously looking inward at their own process. But coming back with “Sarah” in mind helped him gain the courage to be more extreme in reducing current explanation models to an elegant maximum. If it works for Sarah he thought by himself, it will also work for skeptical engineers.

Early sketches of IBM Design Thinking 2.0 in formation.

When Miroslav first drew the infinity loop after hundreds of process model iterations, it began as two separate circles observe and act. While rhythmically tracing the path of a figure-8, he was delighted by its simplicity and elegance. He decided to put it to an immediate test with his internal sponsor users, and they set up a little experiment.

They chose two new intern groups. One group got onboarded the old way, the other with “the loop.” The experimental group got a brief 30min explanation on a paper napkin instead of slides or any other prepared material. They then observed the teams. It came as no surprise that the experimental team got it faster and more intuitively. Within just 24 hours, a language of ‘observing, reflecting, and making’ became not only part of their everyday speech but also henna tattoos on their skins [sic!]. One of them even said in the post-mortem: “We were always taught […] to save making for last. The Loop gave us the permission to make, and fail, and try again in a way I don’t think I’ve ever felt before.”

So, the loop was a first hot lead towards a model that “Sarah” might understand. But a next step for Miroslav was integrating the chosen few principles, which the Design team observed, as the ones that had to be most pronounced in an IBM context: a focus on user outcomes, diverse empowered teams, and restless invention. Looking at both the loop and the principles, it dawned on him. He had basically described a continuously evolving conversation between IBM’s users, their evolving needs, and the teams that solve them. The puzzle pieces finally came together.

IBM Design Thinking 2.0: Early Sketches
IBM’s design thinking principles.
IBM Design Thinking 2.0

Today IBM Design Thinking 2.0, which is now called ‘Enterprise Design Thinking’, consists of above-mentioned principles, the loop as a kind of mental model (which serves as a stand-in for a ‘process’ model that IBM tried to circumvent), as well as the keys, which stayed the same in comparison to IBM Design Thinking 1.0. The loop now also clearly emphasizes the aspect of utmost importance to IBM. Between every make and observe cycle there has to be a point to reflect and align upon what has been done in the team and with the sponsor user. While this might sound obvious for readers of this blog or the agile community in general, it isn’t yet in an IBM context, thus the emphasis. The new framework, the company hopes, provides a lens that now helps IBMers understand that offerings are not just the code they ship but they are mediators of relationships with users.

IBM Design views also this current state of their sense-making as an ongoing conversation. Thus the further making of the IBM Design Thinking framework will literally stay in ‘the loop’. Having codified it to such an extent now also enables the company to offer ‘Enterprise Design Thinking’ advisory services to its clients and other industry players.

Learnings for Organizing Agile Change Programs

What can we learn from this peek into IBM’s design thinking adaptation journey? First of all, that adaptation work will probably never be finished (it took IBM nine months to arrive at their simple revised framework) – sticking to a static ‘roll-out plan’ or roadmap will hardly be possible without forcing people into a mental model to which they don’t want to subscribe. So, if organizations want to become more agile in their every day (innovation) work, they will also have to become agile in organizing their change process and change communication.

Secondly, that generic design thinking might not be the silver-bullet innovation process your organization needs. It is up to you, to do the hard codification work for your own innovation approach. And this means meshing generic design thinking with other and partly already existing approaches, which in turn demands that you need to be ready and able to explain the different connotations of similar terms across a multitude of innovation methodologies.

Thirdly, it is a matter of an organization’s cultural imprint whether you dislike process-like depictions (like IBM) or favor them, like lots of German-speaking companies do (a good and felicitous is SAP’s design process). It does not matter so much for which route you decide. What is important, is that it works for your industry and organizational context and that your people can make sense of it easily without friction or methodology turf wars.

So, make your leaders and C-level ‘design thinking sponsors’ read this, get yourself some time and space … and then happy adapting and codifying!

How Other Organizations Codified ‘Their’ Design Thinking

Other organizations have successfully codified their own design thinking and innovation frameworks too. Here are three examples:

Intuit’s Design For Delight Program’s Principles And Corporate Brand Values

Intuit developed its ‘Design for Delight’ program, which merged design thinking with Lean Startup. The principles they found worth emphasizing are deep empathy, go broad to go narrow, and rapid experiments with customers . The process visualization that resonated most with them was the double diamond, which then became manifested in one of their principles.

Instead of just proclaiming generic design thinking principles as their new corporate brand value statement (a development we observe across many industries), they also forged it by carefully selecting those inherited principles that made them great in the first place. They added just a few new ones that had the potential to foster behaviors that weren’t already existing at Intuit.

If you liked "IBM > Enterprise Transformation by Design", these stories might also be of interest to you:

Image Sources

IBM Design Thinking 1.0 Process Visualisations and Core Practices: IBM
Intuit’s Design For Delight Program’s Principles And Corporate Brand Values: Intuit / Jan Schmiedgen (Collage) | © Traditional Copyright