The vice president of the consulting firm I worked for once asked me about failure. I promptly replied, “I never fail.” What an overconfident, asshole-ish thing to say, right? He looked at me with a very puzzled look and politely replied, “Really? I fail all the time.” before walking away. That small interaction stuck with me over the next few days. The individual leading my division and making major strategic decisions for a multimillion dollar organization openly admitted that he routinely failed. Aren’t leaders supposed to be highly educated individuals paid to not make mistakes? What I came to discover after quite a bit of research, reading, and contemplation is that we viewed failure differently. I viewed failure as the opposite of success. He viewed failure as a growth opportunity. The difference though is that he studied every failure and adjusted his efforts based on what he had learned. I, on the other hand, rarely examined the root issue of why I didn’t succeed outside of the technical aspects. Don’t get me wrong. I did learn from my mistakes, but not in a thoughtful manner.
Technology professionals can be a stubborn people. We find something that works well and we stick to it. The ironic thing about this group of tech enthusiasts is that even with the constant stream of innovations that occur, we still do things a particular way because that’s the way we’ve always done them. I would bet there are things you do in your daily routine only for the reason that it’s the way you first learned how to do it. You never consider changing your methods because “if ain’t broke, don’t fix it.”
Now that I understand failure, my philosophy is more like “If it ain’t broke, it is the best?”. By that, I mean even though something is working well, could there be a better way to complete the process? I am always looking for new ways to perform routine tasks in an effort to be more efficient. In some cases, I stumble upon a unique solution that never crossed my mind or an application that can help accomplish my goal. I then implement the idea and find that it cuts minutes or hours out of a process. Other times though, I more forward with a new concept that backfires all together.
For example, I was looking for a solution to prevent staff members from getting malware prior to a recent laptop deployment. Looking at the work order data, it was clear to me that we were spending too much time cleaning up or imaging infected laptops. I needed to find a way to reduce the amount of time we spent on those device. Logically, I wanted developed a plan to prevent unwanted applications from being loaded on the laptop. At the same time, I wanted to maintain their administrative level access to the machine so they could install applications without asking our department to do it for them. I explored several antivirus/antimalware solutions without finding one that blocked the unwanted programs to the extent I was searching for. I decided to take a different route altogether. We used a package on our lab machines that reset the system back to the frozen state upon every restart. For the staff laptops, I modified the package to only freeze the system drive while leaving their user profile untouched. The package was deployed on about sixty brand new laptops. It worked well for the first few days, but then problems began to arise. Lots of them. The idea was a complete disaster and created quite a bit of work to clean up.
To quote Thomas Edison, “I have not failed. I’ve just found 10,000 ways that won’t work”. I don’t look at the freezing idea as a failure. It’s just an idea that didn’t work. I learned more from that mistake than just the obvious. I learned that I can’t have the best of both worlds. If I want to allow our teachers to use their devices with little restrictions, some are bound to get infected with unwanted malware. I needed to adjust my strategy to account for this. Since I was not going to be able to completely stop the infections using software, I needed to do a better job at educating everyone on how to avoid potential malware infections. For those machines that still managed to get infected, I needed to figure out a faster way to remove the infection or wipe the machine. While I am still working at refining the process, the amount of time spent on those devices has dropped dramatically this school year.
If you don’t take the time to understand what specifically caused you to fail, how can you expect to truly learn from it? In the example above about the laptops, understanding why the plan didn’t work was more about the underlying issue of end user development and my beliefs about laptop privileges than it was about any technical malfunction that occurred. By taking the time to isolate the real cause, I was able to get a better handle on the next steps. Instead of attacking the problem with another malware scanner or application, I am approaching it from an entirely different angle.
Like most people, I do not set out to fail. When I do though, I’ll openly admit the mistake. I’ll also spend the time digging deeper to better identify the keys to what didn’t go well and how I can move forward.