Learning From Your Mistakes

Problem

One of the things that I’ve found to be true over time is that we don’t always learn from our mistakes. Some people are content to simply fix a bug and to call the problem solved. The customer is happy, and service is restored. Some companies fall into the same trap. They don’t learn from their mistakes, they simply fix the mistakes that they’ve made previously.

While keeping the server running is important, something that is often forgotten is how the team got there in the first place. How do mistakes like this occur? How can they be prevented in the future? They say that every defect is a treasure if you’re able to go back and to find the root cause.

Actions taken

Once the root problem has been found, you can take a closer look at how the issue got involved in your project. How you manage the problem matters more than anything else. We want to always be learning from the mistakes that we’ve made.

All people are human. All people make mistakes. It’s not about management reports and all of that. It’s about the people who surround the issue and the conversation that they have as they try to understand the mistake.

Learning from this and learning about the impact of their mistakes should be a top priority. So often, the people who work directly with the product are disconnected from the actual business side of things. They may have refactored some code without telling anybody or have made some sort of last-minute change that felt like a good idea at the time, breaking something inadvertently in the process.

Sometimes, these things find their way into production and cause a problem. The person who was refactoring code likely had good intentions, not realizing that what they were doing could break the business. Shielding people from their mistakes and the pain can be a natural instinct when leading, but in life, people learn by doing.

Now, the root cause of the problem can finally be addressed. It’s easy to blame the messenger. The reality of the matter is much more complex. Rarely is a loss completely pure; there is usually some situation or factor that could have been prevented or accounted for.

Lessons learned

• In QA, you tend to get a lot more flack. We’re supposed to be the ones responsible for catching mistakes before they get too far ahead of us. Creating visibility and transparency when it comes to the nuance of the domain helps executives see through the noise and contend with the heart of the problem. Hindsight is 20/20. It is never simple to make the perfect decision at the moment.
• Once you have had a chance to examine your mistakes, you can begin thinking about how you can do better in the future. By bringing it to the Scrum team, everybody gets a little better. You remove the management telling you what to do and it puts the onus into your hands to learn and to improve. I think that everybody wants that, in a general sense.
• The bottom line: we all make mistakes. Let’s learn from them. I try to avoid making the same mistakes over and over again. There are always new ones waiting right around the bend.