Evolving towards Design Thinking

I’ve written before about the important role leaders play in the development of the people on their teams. While legitimate development and change best takes place when employees are intrinsically motivated, it’s vital for leaders to facilitate an environment of learning. While it’s true that you can lead an employee to learning but you can’t force her to learn, you should still lead her to learning.

The [Failed] Solution

Once as a manager of an instructional design team at a technology company I led a workshop on design thinking. We called it “Reimagination Day.” It was fun and seemed to energize the team. Walking away from that day we had a solid list of new ideas the team could try to enhance our customers’ experience and increase revenue. We spent a good deal of time discussing ways to approach problems from a design perspective with quick iterations and user testing. We all patted ourselves on the back and then went back to work the next day.

The Failure

A week later, however, during a quick follow-up meeting, I asked for examples of what they’d done differently based on the experience from the reimagination day workshop. I admit — I felt a deep sense of frustration because most were silent. They were admitting, by their hesitancy to share, that they’d done nothing different. I wasn’t surprised at that response from the bottom performers on the team (maybe my expectations were too low), but those I knew were high performers were silent as well. I couldn’t believe it.

I’d spent weeks planning the workshop. I’d taken ideas from some of the greatest innovation shops and innovation practitioners, facilitated the session to great acclaim by all who attended, and felt energized. But nothing changed.

Introspection

I went back to my office determined to find out why and to put us back on a course that would include creativity, fast failure, and novel solutions. We didn’t invent a better mousetrap or increase revenue by millions of dollars, but we did begin to test, iterate, fail, and create more innovative solutions than before. This is what I did:

1. I coached … over, and over, and over. I encourage, implored, and twisted metaphorical arms so that my team would implement design thinking principles into their development cycles. I found myself repeating mantras like “fail fast” and “if you’re going to run into a wall, make sure you run into it at a sprint” and “I think it’s time to stop kicking against the pricks” (yes, I was referring to IT and Marketing) and “awesome — so what did you learn?”
2. I consulted when coaching didn’t work. For those who really struggled understanding design thinking concepts, I started saying things like “to implement design thinking into this process, you need to …”
3. I manufactured projects that were low risk, so even if we experienced failure the only exposure was to lessons-learned. This helped them build up a callus and even a taste for failure.
4. I implemented our once-a-week failure party during which each member of the team has a few minutes to explain what they unsuccessfully tried and learned during the previous week. Almost everyone seized the idea and started first admitting, and eventually celebrating mistakes they made.
5. Once a month we gathered to discuss the details of experiments we were trying, what the success factors were, and what we were doing differently because of previous experiments.

[Kind of] Innovation Utopia

It wasn’t perfect. No matter what I did or said, there remained those who couldn’t ever admit his own mistakes, maybe partly because I could never motivate them to take a chance and partly because they just either wasn’t capable of grasping the concpets or was too lazy to try. And that one other guy who didn’t care enough to do anything beyond what he was simply told to do. But even with them we made the most of the situation and let them do the simple mundane tasks every team needs to accomplish (i.e., record this audio, review this for grammar, and so on).

The rest made consistent progress. It became second nature for me coach and lead them in their iterative solution design processes. They began to regularly communicate with customers and we developed channels through which it was easy to initiate that conversation.

In the end, as the leader, I found that I had to aggressively change my mindset and let go of long-held beliefs and constructs about how to build training and learning solutions. We started releasing solutions before they’d been vetted by every possible stakeholder, which meant we had to be flexible to respond when learners found errors. But we saw a consistent uptick in our learning results and NPS scores. It wasn’t easy, but it was worth it.