I’m pretty sure that I’m not only speaking for myself when I say that I really, really don’t like failing at something. Yeah, yeah – I’ve heard all of the sayings like “fail often, fail fast”, “embrace failure”, “learn from your mistakes”, etc. That does not make failing any easier. I’d much rather forget my failures and move on quickly and deal with the importance of information technology. However, it turns out that would be a mistake. When we fail, what we really need to learn how to do is to put it to work. We need to find a way to make failure a resource that will allow us to become more successful in the future.
Admit Your Failures
It should be fairly obvious, but there is no way that you’re ever going to be able to learn from your failures if you don’t first learn to admit that you’ve failed! A lot of us really don’t like to admit it when we’ve failed because we believe that it’s going to diminish our status. However, it turns out that we’ve got that all wrong.
If we’re working in an IT department where “failure is not an option”, then what’s going to happen is that when there are failures, they are going to get covered up. Ultimately what this is going to lead to is a much, much bigger failure somewhere down the road.
As the person with the CIO job, you need to start things out by admitting to the team that you fail. The reason that you need to do this is to encourage others in the department to become more open. What you’d like them to do is to be more open about any projects that they are working on that may potentially fail in the future. The earlier that you can detect failures, the more time you’ll have to deal with them and minimize their impact on the IT department.
Ask Good Questions
Every failure has the ability to provide the person in the CIO position with new insights. It’s going to be the questions that you first ask when you find out about the failure that will shape what you are able to learn. Specifically, if you start asking “who is to blame?” then you’re going to find out nothing as everyone starts to run and look for cover.
A much better approach is to ask questions that focus on “what, when, where, how and why?” The last thing that you want on your hands is a witch hunt. Instead, what you’d like to be able to foster in your people is a sense of genuine inquiry. In order to prevent things like this from happening again, you are going to have to be able to foster a spirit of openness within your team.
Learn From The Lab
Pick up any publication that is targeted at CIOs these days and you’ll discover an article talking about how we can all invite more innovation into our IT departments. This is something that we all want, but most of us would be hard pressed to show any areas where real innovation is occurring. One of the reasons for this is because we often like to think that we’ve already figured everything out.
It turns out that what we really should be doing is taking more of a lab approach to our IT department’s various projects. Specifically, in a lab scientists realize that not all of their experiments are going to be successful. In fact, failures are all part of the scientific method. Ultimately what is done in the lab is very similar to what is being done in your IT department – a lot of different experiments are being run. As the CIO you need to use each of these IT experiments, both the successes and the failures, to search for new knowledge that you didn’t have before.
It’s All About The Ending
So here’s an interesting question for you to ponder: when one of your IT teams fails, what will the people on the project remember about the failure? It turns out that behavioral economists have asked this very question and the answer that they have uncovered is that your team’s future expectations will be greatly influenced by their memories of how their failures ended.
As the CIO, what you want your IT department to do is to generate innovation and creativity that the company can use to grow. However if your staff starts to develop a fear of failure, then this is never going to happen. One way that you can help to set things right is to celebrate failures. Hold a party, invite everyone. Take the time to point out that although the project was a failure, what has been learned will help all projects going forward.
What All Of This Means For You
It turns out that failure is always an option. As CIOs we need to understand that not all of our IT department’s projects are always going to be successful. What this means is that we are going to be coming face-to-face with failure on a regular basis. It’s what we do when we encounter failure that will determine what kind of CIO we are.
The first thing that you are going to have to do is to admit that you will fail to both yourself and to your IT department. Next, when a project failure is detected, you need to make sure that you ask the right questions. Don’t seek to blame anyone, just ask the questions that need to be answered in order to find out what happened. In order to foster creativity in your IT department, you are going to have to promote a lab type environment where not every experiment is expected to be a success but where there is something to be learned from each project. Finally, people remember what happened the last time that they failed and so make it a positive memory.
Failure should be treated by CIOs as an opportunity to learn more. Work with your teams to not fear failure, but rather to understand that each failure has something to teach you. Become a willing student and you’ll soon have fewer failures!
– Dr. Jim Anderson
Blue Elephant Consulting –
Your Source For Real World IT Department Leadership Skills™
Question For You: Do you think that you should react to very big failures any differently than you react to smaller failures?
Click here to get automatic updates when The Accidental Successful CIO Blog is updated.
P.S.: Free subscriptions to The Accidental Successful CIO Newsletter are now available. Learn what you need to know to do the job. Subscribe now: Click Here!
What We’ll Be Talking About Next Time
As your company’s CIO, one of your jobs is to evaluate the performance of your direct reports as it relates to the importance of information technology. How you go about doing this and how often you do it have been the subject of much debate over the past few years. However, I think that we can all agree that the system does not work that well You don’t like doing it and your direct reports really don’t like participating in it. There has got to be a better way!