Learning from failures and the need to debrief projects
The tech sector, which was built on start-ups and ruthless competition, brought forward a whole new style of doing business. The ability to experiment, fail fast, learn from mistakes and continue to innovate in beta has re-written the rules of business for everyone. Even using the category of “tech sector” is a misnomer as technology is a tool that is present and used by businesses to innovate and disrupt in all sectors. Last week’s news that the Microsoft update performed by Crowdstrike causing a service outage that impacted many businesses reliant on their technology demonstrates the problems with this approach. There is probably no going back to the slower pace of change, which means that mistakes will become ever more frequent. My argument today is that legacy companies have adopted some, but not all, of the practices that make this style of business effective. Specifically, an internal process to fully debrief and learn from mistakes is still absent and company execs prefer to focus only on successes.
Over the last fifteen years I have heard the same discussion filter down through internal comms and expounded by many more companies in their outward facing messages. Internally companies tell their staff that they have permission to take risks, or that they have earnt the right to experiment. Externally companies talk about making strategic bets and embracing innovative new business models driven by technology (the fashion for blockchain has given way to AI). Companies do this to signal to shareholders that they are positioned for long-term success in an evolving marketplace and the best way to do this is to demonstrate that they are quickly adapting their business through data-driven insights and experimentation. This disruption and new technology costs money. The risk from these large investments can be mitigated through minimum viable product (MVP) rollouts, beta testing enhancements and scaling up into new opportunities rather than doing a fully featured big bang launch. In this environment mistakes are a feature and offer real-time feedback on what is happening. Understanding, tolerating and even celebrating these failings are not yet part of the work environment outside of Product and Technology teams. Fully debriefing projects to fully understand and learn what went right and should be replicated and what went wrong and should be adjusted is not part of the corporate muscle memory of most established businesses.
Why is this? We don’t need to look much further than the system of staff appraisal, the politics of organizations and the personalization and associated fear of failure.
My first observation is that we tend to group failures together rather than distinguishing between different types of failure. If a company has experimented with a new a product that doesn’t meet customer requirements, should it be treated the same as a regulatory failure that was foreseeable? These two things are not the same. There are learnings from both, but the former was greenlit with an acceptable level of risk that was approved through the relevant layers of the organization, the latter is a judgement call or an oversight. If we could separate out failures between those that are acceptable and those that aren’t, the organization would signal to itself a greater permission to experiment. I find it interesting that businesses often find it easier to learn from competitors mistakes than from their own. This means that having taken a risk, experimented and failed, an organization will retreat and allow its competitors to build off their hard-won knowledge. Some of this will be down to the capital availability, but I would guess that some of this is due to embarrassment and fear of further failure.
My second observation is that careers are built on success. This statement feels reasonable and probably not that controversial. Yet, we know that all projects are team efforts. There are individuals who are vocal proponents or critiques of plans and their opinions, if well-formed, are helpful when you initially decide to move forward with a project. When a plan is in motion, then it is more helpful for everyone to support the project through to its conclusion. If a project starts to waiver, some staff will start to distance themselves. Without widespread support, the project fails. Even if it miraculously succeeds, the project’s reputation will have been dealt a significant blow. Going back to the original comment that careers are built on successes. If someone is only associated with successes then this is either due to an extreme run of good luck or, more likely, they have isolated themselves from projects that have failed. If a leader succeeds this way or worse, all leaders succeed this way, where did all the valuable knowledge from failure go? Is this career plan something that should be rewarded and emulated? Wouldn’t it be better to build a career on a portfolio of successes and failures where you have experienced and learnt from both? If a leader supports a team that has had a failure and helps that team through the learnings and debriefing, that would reinforce the culture of experimentation. I think this is why we admire individuals who have overcome challenges and adversity and used the experiences to go onto future success.
My third observation is that companies tend to personalize failure. The worst cycle I have ever witnessed is in the movie production business before Covid, when the business was still controlled by the big US Studios. The uniqueness of this business model is that every movie is a new product launch with a limited window to make money. Most businesses launch a product and can then scale up production to sustain it over its lifecycle. Their product line is a portfolio that includes an existing line of established product and this helps to manage the risk of any new launch. Studios have a back catalogue, but only a relatively few properties generate a significant return after their initial windows, and the total return is far outweighed by the potential of a new blockbuster. The cycle of failure goes something like this. A major summer release bombs at the box office leading to a significant write-off. Change is demanded and the studio chief and their top team are publicly fired from their jobs. A new studio boss and management team is appointed and starts to greenlight new projects that will be launched 3 years later. The following year the new studio sees the green shoots of recovery on the slate greenlit by the previous management who were fired the year before. The next year they have a huge box office success on the third and final slate greenlit by the previous management and the management are toasted, paid huge bonuses and are re-signed on generous contracts. Finally in year three the first slate that the new management team greenlit at the start of their tenure is released, and the major summer release bombs. The new management team are fired and replaced by a new leadership team and the cycle continues. The personalization of success and failure in the movie business has resulted in certain studios getting into a cycle that prevents new leadership from learning from mistakes and improving on their performance. To break that cycle, new management either need to be lucky or poached from a rival studio where they have been through their learning curve. The opportunity for internal development of staff is frustrated by the risk profile of this business.
Most businesses are not as extreme as some elements of the movie business during the 2000s. But the process of tying failures to specific leaders and removing them from the business is a well-worn path. If we can separate out the failures between those that are acceptable and those that aren’t and avoid firing execs for the former, then the culture of business may start to change.
To summarize, technology and disruptive business practices have taught organizations to prioritize speed and nimbleness for competitive advantage. Any time you increase speed, you increase the risk of errors and failure. If this risk can’t be mitigated without compromising on speed, then there needs to be a general acceptance that errors and failures will happen and that they are opportunities to learn, refine and develop future plans. Project debriefing and widely sharing the learnings amongst staff should be a core feature of a successful business. It should be wired into the DNA of every company in the same way that it appears to be wired into the DNA of the technology sector. Without this, companies are missing out on information that can help inform future success.
Let me know your thoughts. I have tried to wrangle something that I have been pondering for a long time into a coherent post. I might have failed, if so, I intend to learn from that failure. Next week I want to address how to deal with setbacks and rejection.