It was that advice that has guided me ever since. It is very easy in the euphoria surrounding the triumph of solving a difficult problem or pulling off the near-impossible project to not spend the time questioning just why you succeeded. To do so seems to be diminishing the success and even doubting that you actually did succeed. On the contrary, an objective review of how you succeeded will greatly help you in continuing to succeed.

When we succeed, we can become victims of three biases, according to Gino and Pisano (April 2011). There is the attribution bias in which we overestimate how our knowledge and actions contributed to the success and we downplay any external factors that could have just made us more fortunate. We also become overconfident in our abilities as we tackle the next challenge. The third bias (and which I believe is most important) is that we don’t ask why we succeeded because the success is proof enough.

To illustrate this last bias, Gino and Pisano (April 2011) recount a study in which students were given a set of math problems to complete. When the students submitted their answers, they were only told if they had the answer right or wrong. The students were given time to reflect before they were given a second set of math problems. The second set was designed so that a key concept in the first set of problems was needed to solve the second set. The students who successfully solved the first set of problems generally spent much less time reflecting before they started on the second set of problems. Thus, many of these students failed to find the answer for the second set of problems. Reflection, whether the student succeeded or not, is the key to continuing to be successful.

So, how do we best learn from success? We should celebrate success but also examine the causes of success. For every project, we should hold a systematic review. Gino and Pisano (April 2011) give the example of Pixar’s review process. Even though Pixar has had eleven hit animated films in a row, the company still goes through an exhaustive review process to determine what made the film successful and how to repeat that success.

Another point to keep in mind is to fully investigate the feedback. Was it immediate or at least can be connected to the actions taken? Is the feedback a true indicator of success or just a random event that looks like a successful outcome? Feedback is an important concept and I explore it in greater detail in this discussion posting.

Two final points. First, “[r]ecognize that replication is not learning” (Gino and Pisano, April 2011). Blindly following the same formula again and again can suddenly turn against us as the nature of the problem changes and what worked before doesn’t work now. And, second, we should always be experimenting. We can always improve how we do something. Plus, we can create variations on our actions that may not apply to the current situation but can apply to a challenge in the future.

Failure is a great teacher but so is success. Learning from our successes will keep us from becoming “one-hit wonders” and give us the string of successful “hits” to be “rock stars.”

Reference:
Pino, F., & Pisano, G.P. (April 2011). Why leaders don’t learn from success. Harvard Business Review. 68-74.

The latest issue of the Harvard Business Review and before I talk about an interesting article, I want to express how much I like the redesign.  The look needed to be updated and I found the magazine more readable.  Great job!

One of the new features is the “Idea Watch” which is a great roundup of interesting roundup of new ideas for management.  One section, “Neuroscience,” reported on how success causes the brain to change in response to successful stimuli.  What was surprising is that failure has no effect on the brain.  This makes sense in one way because you want the brain to change to repeat successful actions.  But, this also prevents learning from failure.  And in many cases, that can be more beneficial.

For example, when I build a program, I will spend some time debugging the program.  I may try several different approaches before I find the right coding to fix the issue.  I will remember the successful fix but I will quickly forget my unsuccessful attempts.  These attempts may be useful in other instances or may help me in generalizing the problem so that I can create an ever better fix.  There are numerous examples of failures that  turn out to be successes in other ways (think about Post-It Notes).

Thus, you should be just as attentive to your failures as your successes.  Keep a failure log and go through it on a periodic basis.  Instead of beating yourself up over past failures try to find ways to turn them into successes in a different way.  After all, failure or success is in the mind of the beholder.