Learn to fail fast? Technologists fail all the time
From time to time, organisations attempt to learn new ways of working. They attempt to become digital or agile or data-driven or innovative. These attempts come with some familiar ideas: that we should execute through cross-functional teams who are empowered to experiment. One of these ideas is that we should not be scared of failure, and that we should learn to fail fast.
These attempts sometimes elicit eye rolls from the technology teams, especially the idea that we should embrace failure. This is not because these ideas are invalid: in fact, they are welcome to technology teams, and reflect their preferred ways of working. However, technologists have a different relationship with failure than non-technologists.
For non-technologists, being willing to fail fast typically means that they have the appetite to conduct some experiments and try some things out, with the knowledge that not all of them will work. They accept that some of them will fail, select the ones that they are confident in, and get on with implementing and scaling them. Failure is a fleeting visitor at the beginning of the lifecycle: it is welcomed, accepted, and shown the door.
For technologists, failure is a constant companion, from the first day of a new project to the day when the system is decommissioned. If they roll their eyes at the suggestion that they should learn to embrace failure, it is because they live with failure all the time. Projects go wrong. User needs are poorly expressed and poorly understood. Partners let each other down. Writing code is a continuous, humbling demonstration of human fallibility. Hardware fails and software fails. When it doesn’t fail of its own accord, bad actors try to make it fail for us. Users subvert interfaces, and developers subvert data structures and APIs. More than half the work of designing and building any system is anticipating what can go wrong and setting up measures to deal with it - and then something goes wrong anyway.
Failure is so deeply embedded in the practice of building and running software, that, for technologists, the notion of being willing to embrace failure becomes meaningless. What would be more meaningful would be a willingness to embrace unpredictability. Experimentation in the early stages of a project is useful because, without conducting experiments, we cannot predict which approach will be most successful. But this unpredictability does not go away when experimentation is over: it continues through all stages of the lifecyle. We do not know how long software will take to build until we try to build it. We do not know how many bugs it has until we run it. We do not know exactly which bit of hardware will fail until it fails, and we do not know how we will be attacked until the attack takes place.
领英推荐
Well designed systems and processes tolerate failure and unpredictability. Organising work in a backlog, and releasing on a regular basis allows us to make progress, even though we don’t know exactly what will be in every release. Spreading workloads across hardware and across regions allows us to survive crashes and disasters. And making our post-mortems blameless enables us to learn from what went wrong without losing the faith and dedication of our teams.
For technologists: when our non-technical colleagues declare a new found appetite for failure, we owe them a more useful response than simply rolling our eyes. We should take the opportunity to share the realities of building and running systems, and the ways that we deal with failure all the time. We should take in good faith the willingness to consider new ways of working - and explain just what that means.
For non-technologists: when you embrace failure at the experimentation stage of the lifecycle, you should regard it as a step on a journey. By recognising the need for experimentation, you are acknowledging one part of the inherent unpredictability of building and running systems. If you listen to your technical colleagues, they can show you how this unpredictabilty runs through all their work - and what it means to live with it. It may change how you react when things go wrong later in the project.
We can make better systems, better teams and have a better time at work if we understand failure and unpredictability - and take the trouble to understand each other.
(Views in this article are my own.)
Test Consultant at Fujitsu
1 周Great article David, unbelievably I’ve had to battle hard for years against cultural walls of resistances to persuade middle managers (so called technologists) and yes even stalwart test managers in clients that psychologically safe, fail fast environments are essential to successfully sailing through acceptance into service. There are so many still stuck in the Taylor-Ford linear thinking. #Agile #Culture
Chief Data Architect at HM Revenue & Customs
1 个月Thought provoking as ever David Knott, the teenage optimism that architects and engineers have “this time it’ll work” as we think through the problems, write the code or explain the solutions is what can make ours the happiest of careers. When we try and make everything certain: if only we had more plans or less change or more sign offs, our ability to explain why and deliver goes down and so does our enjoyment. Finding problems, solving them is what makes it all worthwhile. It’s not failure, it’s the 1000 ways not to make a lightbulb.
Strategist | Conference speaker | Course Director - Global CIO Leadership Certification Program | Executive Coach | Global Focused Leader | WOFuture ASEAN Judge | SCS Supply Chapter Executive Committee
1 个月Thank you for these ideas as we move into a new year and some significant updates to technologies David Knott. In Asia, we (at least at CXO Connect) use a different terminology because the huge loss of face that occurs when something doesnt work as predicted. It's 'learn fast' which is what you are talking about when we do that necessary experimentation. Managing executive sponsor's expectations is a critical part of a senior IT leader's role even when its not on their job description. After decades, it is still an issue in most organisations. Again terminology can help. Incubation and experimentation rather than proof of concept. We need to engage our colleagues in this process, as a team process. The risk with AI is that many of these are seen as IT projects with IT desparately searching for Use Cases. Post mortems must be lessons learned and not a search for the guilty. This is where the culture of the organisation is critical. A search for the guilty will never be as productive as continuous improvement supported by in depth reviews and lessons learned. This culture has got to come from the top - the Board and the C suite. Research money needs to be in the budget with the understanding that the aim is to LEARN not ROI.
Helping companies harness the Power of Third-Party Master Data to Drive Transformation and Profitability
1 个月Musk used the fail fast learn faster philosophy he learned from his software companies for Spacex. Remember the uproar when rockets exploded! Imagine what the technologists were saying back then! Especially those from rival companies and NASA! He perserveered and look at the success they have had since! As a luddite in IT, harking back to my coding, testing days of 30 years ago, I found it hard to accept at first but the proof is there for all too see! Of course Musk has money in abundance which helps!
It sounds David Knott that you are all for Agile, SCRUM/ Scaled Agile practices, working on spikes or POCs. If I may highlight something I see on job adverts. I am unsure of software engineers then designing the systems, as this is really stating that the engineers are then marking their own work so is this ethical.