Fail Better: A Q&A with MIT Sloan’s Anjali Sastry

Failure is all the rage. Be sure to do it right.

October 30, 2014

Fail Better author Anjali Sastry

Fail Better author Anjali Sastry

Failure will happen. It’s what you do with it that counts.

In a new book, Fail Better: Design Smart Mistakes and Succeed Sooner, MIT Sloan Senior Lecturer Anjali Sastry and Kara Penn, MBA ’07, chart a better path both to failure and away from it. It’s about not just acknowledging failure, but also planning for action, experimentation, and iteration to ensure that projects are completed in the best way possible.

In an interview, Sastry discussed the difference between good and bad failure, developing a habit of planning and assessment, and how her own work with MIT Sloan’s GlobalHealth Lab helped her and her students test the fail better method as they confronted unforeseen challenges and, inevitably, failure.

In the book you talk about useful failure. Tell us what you mean by that.

A slew of recent books and articles—not to mention TED talks and graduation speeches—advocate failing early and often. Perhaps that’s because it’s become clear that these days, nobody can always get things right the first time, no matter how smart they are or how carefully they plan. Globalization, climate change, shifting political and financial systems, new technologies, and other developments are reshaping the world and the workplace in ways that can’t be fully anticipated. And things will continue to evolve. Amid this complexity, at some point we’re all going to get something wrong.

Few would disagree that we should learn from mistakes. But usable knowledge for exactly how to do so is often lacking. This is something we take on in Fail Better, drawing on our own experience to explore the practical aspects of the techniques we describe. For instance, right after the 2010 earthquake in Haiti, I worked closely with a team of my own students, the U.S. Military’s Joint Task Force, Lincoln Lab, and MIT’s Humanitarian Response Lab to address emerging needs on the ground in Haiti that could inform the humanitarian response and direct relief effort. Our collaboration used a method described in the book called after action review. That technique can be applied in many other settings.

But it’s important to go even further by figuring out how to orchestrate better failures. Useful failures can be proactively designed to teach us something new about the world, rule out an idea, or suggest a new direction, in ways that are faster and cheaper than the alternatives. This idea is not new, as any expert in software design or product development knows—or as anyone trained in the scientific method, process improvement, real options theory, or advanced project management will tell you. Our book provides a broadly applicable practical approach that has been missing: a menu of specific steps that can be customized for everyday work projects in all sorts of industries, including settings where early testing, rapid prototyping, and iteration are not yet common.

Besides the tools, to make this method work we need to cultivate the ability to differentiate useful failures from dumb ones. Such knowledge can help prevent failures due to poor planning, inadequate analysis, or insufficient research, and enable them to be called out when they do occur. So the message is twofold: first, rethink how you plan your projects to ensure that the failures you generate are useful; and second, as you go, test your ideas, looking for and carefully assessing the feedback at every step. The tools of systems thinking are essential for both, because they help explain the relationships between actions, results, and impacts.

What is the most critical mistake a manager can make in trying to implement the Fail Better approach?

A crucial danger arises when people pay lip service to the notion of embracing failure without supporting the practices, leadership, and culture needed to enable and support effective failures. In this regard, what managers do is incredibly important—if managers advocate our approach but then sidestep a difficult conversation about a visible failure, they will undermine the entire effort. They need to call it when a failure is not acceptable. Managers also need to protect the investment of time required to plan and learn from failures, and they need to invest in the right amount of data collection and analysis so that early tests and initial results are appropriately assessed.

You put a lot of emphasis on self-reflection, both for individuals and for teams. But that’s time-consuming work. How can people get in the habit of making time for reflection?

There’s an old saying: “If you think education is expensive, try ignorance.” I’d advance a new version of it: if you think reflection is expensive, try ignoring the lessons of experience. But perhaps the term “reflection” is leading us astray here. It doesn’t mean navel-gazing. Instead, what we need is a data-driven approach to extract the lessons from experience. Individuals and teams may need to cultivate new habits to do this and then support their use, even when things get busy. Managers may need to protect their teams’ time to allow them to both plan and assess their efforts, and also help them get the resources they need to do better.

While researching Fail Better we found many effective practices, from a venture investor managing his weekly schedule to retain an hour for planning and reflection, to teams that embed five-minute drill-down discussions in their standing meetings. Readers will find varied examples, many featuring MIT Sloan alumni and their startups, in our book, and discover how the ideas apply even more broadly—including in the case of the U.S. civil rights movement and Bangladesh’s remarkable global non-governmental organization BRAC.

Building the habit of regular planning and assessment is the essential first step. Once you’re looking at plans and results systematically, you can figure out how to do it better and correct shortfalls in your data and analysis. But this only happens if you keep checking your results and asking what it means.

With its constant iteration approach, the Fail Better method invites rapid change. How can managers sell this approach to nervous superiors who want to see a project run smoothly and without surprises?

Too many projects plod along as instructed, only to generate results that fall short of delivering the innovation or change that is most needed. When I looked at the research, I found evidence of the well-known phenomenon of projects running over budget and coming in late, but I found scant data on a problem that I think is equally damaging: projects that check the boxes and appear to meet the set requirements, yet fail to have an impact. Oftentimes, even before they wrap up their efforts, the team itself knows that the project they are working on will miss the mark in some way. I wanted to address two key reasons behind lackluster performance in such projects: first, the world keeps changing after project plans are set (even if plans don’t adapt); and second, working on the project itself reveals new facts that the original plans did not accommodate. Either way, if teams are not allowed or equipped to shape their work as they go, they risk becoming cynical and disillusioned. The end result is pretty much the opposite of innovation.

How have you seen the Fail Better approach employed in GlobalHealth Lab, either by student teams or in your own work developing and conducting the course?

I am constantly inspired by my students. As I mentored my students over the past decade, so many of whom were generous and honest in sharing their project experiences, I could see the dangers, along with the frustration, that came from either extreme—projects that took so long to define and sort out that little was accomplished, or projects that avoided dreaded “scope creep” at the cost of inflexibility and eventual irrelevance. We developed the methods in the book to support student teams at MIT Sloan taking on challenging projects, but as Kara and I worked together, we realized that they applied inside companies and to all sorts of other organizations.

Naturally, these ideas influenced my design of GlobalHealth Lab and guided its evolution over the past seven years. Improving how we design, run, and make sense of projects became all the more important to me because the stakes were so high in this class: after all, in GlobalHeath Lab students travel to distant locations, and throughout the process it’s inevitable that we impose on our partners, all of whom are organizations serving the health needs of the poor in low-resource settings. MIT Sloan and its supporters invest much in each project, too. I was very driven to seek constant improvement in the course design, how projects are run, and in student learning. I used the techniques in the book at every step.

The book draws on GlobalHealth Lab in another way. In a research study I am just wrapping up, we went back to the hosts of our first 40 projects in sub-Saharan Africa and South Asia to study, one or two years later, whether and how we had made a difference. The strongest finding was that partners wanted more—including the methods and tools that enabled students in their projects. I am hoping that the book proves useful to many: not only students, but teams and their managers and leaders across the world.