Jim Guckin

I’ve talked several times about learning the lessons from every leader that I’ve ever had, good or bad. I was recently talking with a mentee, and they had an issue at their work and their boss berated the entire staff for making a mistake that brought a system down. From the description of the incident, it was an honest mistake and wasn’t intentional, but they asked about the best way to deal with it.

Digging further into this incident, I learned that there were no defined processes for updating or making changes to the systems they were managing. They got their tickets and they made the changes accordingly. So obviously the simple fix is to start to build processes and policies in place to have a more vetted approach. Yet that’s not what I want to discuss here, that’s management 101 and while they wanted to take a stab and fix it, my focus became on the manager’s behavior. I’ve had these managers, and my lesson learned from them was to try and never be that way.

Now I will start this out, by saying this isn’t a blanket statement, that processes always need to be fixed, and sometimes it is the employee. Sometimes no amount of process is going to fix all your problems and every organization has its own ability to self-police its processes or add checks and balances in place for every step. These are given flaws in the processes.

Now that is out of the way, let’s talk about what your thought process should be. As a leader, your first response to any type of incident, shouldn’t be “who did it?”, it should be what broke in the process, that allowed the thing to happen. When you focus on the WHO and not the WHAT, you start to impact your team. You end up not empowering your team and taking their confidence down and making them afraid to act. I’ve talked before about ending the fear of making a mistake so that you can encourage your team to try new things. Yet under these leaders, teams end up dissuaded from making even the basic of decisions or improvements.

Plus, I don’t think that blaming an individual or team, really gets to the root of the problem. The more constructive and beneficial thought will be what went wrong, for this to occur. For one, it doesn’t assume that it’s a “people” issue, and maybe there is a gap that needs to be filled. For example, when there have been disasters with the space program, you don’t see, “Bob was supposed to connect this wire to the space motherboard, and it was done incorrectly that’s why it happened”, the figure out what caused the issue and put processes in place, or sometimes even backup procedures in place to avoid the issue from occurring in the future.

Blaming a person or team only corrects it for that one person and makes it hesitant for that part of the process again. Instead try figuring out if the process can be improved, where everything is documented, the risks listed, and the approvals documented. In some cases, having a simple thing like another staff member reviewing the change before committing the change, to make sure they don’t see any mistakes or the logic is thought out. I had a leader early in my life, that use to have me check configurations before he committed it.

I always want my teams to grow intellectually and where I can try not to stifle their innovations. I want to put in place processes that allow innovation, but also allow for someone to review and make sure that it will work. While nothing will be “perfect”, this gives your team confidence and a check and balance system. Even if the HotWash/After-Action/Post Mortem says that your process is missing altogether.