Bedrijven mogen best fouten maken bij hun zoektocht naar successen. Maar ze moeten dat wel op een slimme manier doen.
Pixar-CEO Ed Catmull zei: ‘Fouten zijn geen noodzakelijk kwaad. Ze zijn helemaal geen kwaad. Fouten maken is een onvermijdelijke consequentie als je iets nieuws doet. Zie het als iets waardevols.’ Toch hebben de meeste bedrijven een hekel aan fouten. Hun managementprocessen zijn gebouwd op voorspelbaarheid en efficiency. En hun executives worden geacht alles onder controle te hebben. Hier wringt de schoen: met te weinig tolerantie tegenover fouten smoor je de innovatie, en met te veel tolerantie riskeer je verlies van controle en in het ergste geval je ondergang. Om de juiste balans te vinden, hebben Julian Birkinshaw (London Business School) en Martine Haas (Wharton) een raamwerk voor smart failure ontwikkeld: een zichzelf versterkende leercyclus in drie stappen.1. Reflecteren op feedback
Als iets fout gaat, hebben mensen vaak de neiging om het terzijde te schuiven en verder te gaan. Geen goede tactiek, want dan leer je er niets van. Met ‘smart reviews’ kunnen bedrijven fouten op een systematische manier zichtbaar maken en analyseren. Ze duren kort, zijn actiegericht en worden geregeld uitgevoerd:- Wees consistent en gedisciplineerd: het reviewproces moet in slechte én goede tijden zorgvuldig worden uitgevoerd. Blijf dus ook goed lopende initiatieven systematisch, bijvoorbeeld elk kwartaal, reviewen: Hebben we iets fundamenteel verkeerd gedaan? Hebben we een denkfout gemaakt? Enzovoort.
- Maak fouten zichtbaarder en daarmee inspirerender. Het Indiase conglomeraat Tata Sons heeft een Dare to Try-award voor ‘de meest vernieuwende, gedurfde en serieus uitgeprobeerde ideeën die niet de gewenste resultaten hebben opgeleverd’. Reclamebureau Grey heeft een jaarlijkse Heroic Failure-award. Google heeft champagnefeestjes voor opmerkelijke maar mislukte projecten.
- Houd een portfiolioperspectief aan. Evalueer projecten niet geïsoleerd maar als groep. De meeste high-risk innovatieprojecten mislukken. Kijk naar de grotere lijnen van de mislukking – analyseer de projecten gezamenlijk op één niveau hoger dan waarop ze worden uitgevoerd.
2. De toon zetten
Als leider is het je taak om je mensen te laten weten dat slim falen geaccepteerd en zelfs waardevol is.- Zorg voor ondersteuning van peers. Psychologische veiligheid is cruciaal: er moeten normen op teamniveau zijn die maken dat mensen zich vrij voelen om dingen te doen die misschien niet werken, of te communiceren dat er iets niet goed gaat.
- Zorg voor de juiste incentives. Als je wilt dat je mensen innoveren maar je geeft de bonus en promotie aan wie géén fouten maakt, dan wordt het innovatiestreven alleen met de mond beleden. En het hele team weet dat. Beloon mensen die slim hebben gefaald voor hun capaciteiten. Jean-Claude Biver, CEO van de Zwitserse horlogemaker Hublot: ‘We willen actieve mensen, en mensen kunnen alleen actief zijn als ze fouten maken. Het is de taak van een leider om het falen en de fouten van zijn mensen te accepteren en om ze te vergeven. Laat ze echter nooit dezelfde fout twee keer maken.
3. De sandbox bouwen
Een sandbox is in de IT een afgeschermde ruimte waarin computerprogramma’s kunnen draaien zonder andere processen te verstoren. Hier houdt het in dat je je mensen figuurlijk de benodigde ruimte geeft (richting en ondersteuning), terwijl je de kosten en input onder controle houdt.- Creëer snelle feedbackcycli. Dat doe je door lean te werken, met snelle, iteratieve experimenten: je maakt een grof prototype, krijgt feedback van gebruikers, past dingen aan en herhaalt dit.
- ‘Ont-riskeer’ projecten. Zo voorkom je dat de kosten uit de hand kunnen lopen. Bij sequentiële de-risking wordt er stapsgewijs vragen gesteld: Kun je aantonen dat er een klant voor is? Kun je aantonen dat het product werkt? Heb je een levensvatbaar businessmodel? Bij elke stap wordt bepaald of er verdere financiering komt. Paralelle de-risking is mogelijk als er meerdere potentiële oplossingen voor een (bijvoorbeeld technisch) issue zijn. Je zet dan niet van tevoren vol in op één oplossing maar voert meerdere kleine projecten uit die de verschillende opties onderzoeken.
