FAIL BETTER: DESIGN SMART MISTAKES AND SUCCEED SOONER
Authors: Anjali Sastry and Kara Penn
Publisher: Harvard Business
Price: Rs 1,095
The trap of escalating commitment plagues high-risk projects, particularly when they are visible and long-term. People tend to become identified with the course of action they are taking, and can be loath to give it up, even if it is not paying off. Within organisations, social factors can worsen this tendency when people are identified by others with the project, and their reputation and social identity becomes entangled with the project's existence. Another contributing factor comes from behavioral economics: the sunk cost trap is created when someone invests so much in a course of action that the past investment itself becomes a reason to continue the investment, illogical as it seems.
Imagine you work in a pharmaceutical firm, charged with developing a new drug. Your team has been working on it for months, maybe years. What if your action-loop tests show that the drug is a bust - that it will never work as planned ? The fact that you have the budget, the team, the time frame, and the job title that line up with the drug can tend to make you continue with its development, even when it is not in the organisation's best interest to do so.
How will you avoid the trap of escalating commitment?
One antidote is to develop a set of critical questions about the project's timing to revisit at key points. Plan and schedule project check-in meetings where you examine these issues. Referring to the project impact map and problem statement can help to highlight clues that your work is not heading in the direction you seek.
Simply being aware of the trap is also going to help. To tackle the implications of these negative clues, you'll also need the mind-set to enable open discussion and a receptivity to negative results, other aspects of your 'Fail Better' mind-set that we've already described.
Adapting work modes and focus
In projects, as in most of life, the secret to success lies in balancing countervailing tendencies. Instead of engaging in a constant tug-of-war or a simplistic splitting of the difference between two seemingly opposing needs, the wise manager shifts focus according to the needs at hand. A concentration on details is important at the close of the launch phase, in the thick of the iterate phase, and in the mid-stages of the embed efforts. But to shape the overall project and share the insights it generates, you will need to look at the big picture, too. You'll consider broader perspectives early in launch, then during project check-in points during your action phases, and again at the start and end of your embedding activities.
As your project evolves, be attuned to its shifting needs and adapt your work style to them. Let where you are in your project's cycle guide your focus as well as your responsiveness to feedback. In the mid- to later parts of a project, if the tendency is to continue with a course of action, you may want to impose stricter discipline to weed out bad ideas or stop an ineffective work stream. Knowing how to respond to your team's investment and experience with the project and to adjust decision making criteria is another aspect of time frame management.
All of this advice is useless if you are not open to an even bigger shift in approach - to cancel or pivot the project if all the signs tell you to do so. It may be counterintuitive, but pulling the plug on a foundering project could be the best thing for your company-and even enable the aims behind the project to be reached sooner. To succeed, every leader calibrates personal persistence with adaptiveness and willingness to learn and change course as needed. Even if politicians are sometimes criticized when they change course, we know that excellent battlefield leaders and CEOs change plans when the facts on the ground shift. You'll need to do the same with your team.
|It is important to cultivate a mindset that supports smart mistakes and learning: Anjali Sastry & Kara Penn|
How do you proactively design and orchestrate better failures?
Anjali Sastry: First, understand the problem at hand. List questions related to your ultimate real-world goal. Then, narrow in on a problem statement. This will anchor your attention and focus your team’s activity.
Next, identify how your work will address the problem, linking planned actions to the outcomes you seek. This provides a rationale for your workplan and helps prioritise the steps that could shift the team’s direction or reveal something new, early enough to avoid taking the wrong path.
And, as you set out, define your parameters for what we call ‘good’ failures or mistakes — risks that are small-scale, affordable, linked to broader goals, and designed to reveal key insights quickly. Once you swing into action, gather and examine data as you go so that you can pull back on less effective options, or even switch course, if needed.
No one wants to repeat the same mistakes, yet this happens surprisingly often. Once the work is in, instead of rushing on to the next project, set aside the time and effort to extract lessons. Some questions to explore: What are the few critical things you learned from this project? What are the one or two things you and your team should continue or stop doing?
What are some of the key mistakes start-ups commit when implementing the ‘Fail Better' approach?
While some startups go off track because they move too slowly, we have seen more struggle when they underinvest in the necessary rigour to the start of their effort (this is not about work ethic, but about being scientific and smart). Some jump in without mapping out how the team’s actions will lead to the desired end result, while others fail to design in experimentation to test critical assumptions.
The ideas in Fail Better are key to launching a business that succeeds, but they are also essential for launching any project that aims to innovate within a company, nonprofit, or governmental organisation. The same need for planning, mapping, iterating, and learning exist. The best part? You only need the sandbox of your own work and the practical methods we describe.