Tips for managing technical people – Embrace Failure
25 April 2016, by Zoe Cunningham
The following is an excerpt from my new book, “Galvanizing the Geeks – Tips for Managing Technical People”. You can buy the full book on my website, here.
Whatever we do, whether it’s software development, building cars or policing a city, we are all trying to do it well. We are all trying to succeed. We set our sights on the end point, and aim towards it. We do everything in our power to avoid failure. We carefully manage a list of risks so we can deal with the unexpected and stop it from throwing us off course.
Some organisations go further. You’ll have heard the expression ‘failure is not an option’. This seems like a reasonable way to go about business, surely?
It does – until you examine the concept more closely. What would you do on a project if failure really wasn’t an option? First, you’d make sure you got the easiest project you could. Let someone else take the risk of failing. Then you’d try and find a role that you’d done before and stick with that. If you were a developer, you’d use the coding language that you’ve always used. You’d never question the company standards that have delivered successful projects in the past. In short, you would never try anything new. Worst of all, you, and everyone on your team, would try to tidy up after a project to make it look like the best project that you’d ever run. You’d hide the things that could have gone better. You’d ignore the niggles that made you slower.
Is that so bad? You do it well, everyone feels good about it. What’s the problem? The problem, which may at first sound somewhat tangential, is that the world doesn’t stand still. You are always competing with someone else. If you’re a software development company, you have competitors. If you’re an in-house team, you might lose your jobs to people who have new and better ways of doing things. You might start to lose work to external companies who can deliver more efficiently. New companies will start, new ideas will develop, and new ways of working will change the competitive space.
Planning to avoid failure is the antithesis of learning. If ‘failure is not an option’, you need to reduce risk. New things are risky. Furthermore, improvement comes from looking back at what could have been done better. We learn from our mistakes. If we churn out perfect, identical project after perfect, identical project, we learn nothing. But if we can identify where we have failed, we can deliver a better project next time.
In order to truly embrace failure, you need to detach it from blame. Often in management, the trick is to do the opposite of what comes naturally. If someone has screwed up on your project, of course your instinct is to blame them. If someone points out that you weren’t so hot yourself, of course you get prickly and defensive. It takes work to overcome these emotions.
In order to lead a team, you need to start by modelling the behaviour that you want to see. Be open about the things that you personally could have done better. Encourage people to tell you when they spot something that you didn’t do so well. Say ‘thank you for the feedback’ (see Rules for accepting feedback). As you practise being open to the fact that you could have done better, it gets easier and easier. As people see you reacting in this way, they’ll find it easier to try it themselves.
Tags: galvanizing the geeks
Categories: Technical, Uncategorized