I just (about) finished reading The Right Kind of Wrong, by Amy Edmondson, and it’s doing what a lot of my favorite books do - it’s making me think.
The extremely brief summary of the book for context is that there are three common types of mistakes:
Basic mistakes - I forgot to validate an input variable
Complex mistakes - our system deadlocked because a connected system changed configuration and exposed a concurrency issue that had been hidden for months
Intelligent mistakes - while implementing a new transaction system, I made a lot of mistakes while learning what does, and what does not work.
No Blame
None of these mistakes is blame worthy, and all have opportunities for learning. I used to lock my keys in my truck all the time. I made a mistake, but because humans make errors, I repeated my mistake. No amount of blame (or self-blame, because I felt stupid every time) is going to fix the mistake. Basic mistakes are solved by mitigation (I kept a coat hanger in the bed of my truck and could get into the car in less than a minute if it was locked with the keys inside), or prevention - subsequent cars I’ve owned have made it impossible to lock the car with the keys inside.
Complex mistakes are also blameless learning opportunities. Drift Into Failure by Sydney Dekker is a fascinating look at some of the most complex failures, and points out that assigning blame to individuals after an accident oversimplifies the issue and may not lead to safer systems. It's more productive to understand how the system's complexity contributed to the failure.
Intelligent mistakes are rarely blameful, but are prime places to learn. As a self taught programmer who has written thousands of lines of code in production systems, a huge amount of what I’ve learned has come from intelligent mistakes. The famous quote attributed to Thomas Edison below has a lot in common with the time I implemented debugger features in x86 assembly.
“I have not failed. I've just found 10,000 ways that won't work.”
-Thomas Edison
The Leader’s Guide to Human Error
As I stated above, human error is inevitable, and the best remedy isn’t to fix the human, it’s to fix the system. As a leader, what do you do when an employee makes a mistake? What do you do when you make a mistake?
One way, I guess, is to ignore the mistake. I just said that human error is inevitable, so why make a big deal out of it? The answer (obviously?) is to focus on learning. Instead of asking, “why did you check in code that caused an error?”, ask, “what did you learn from the experience of that mistake”, or “what do you think we could do differently to make that type of mistake more difficult?” It doesn’t matter if the mistake was tiny and easily fixed, or the junior dev deleted the production database - if you focus and emphasize learning, you both win.
I’ve (unfortunately) worked with some leaders who imagined themselves as infallible and a sign of weakness to admit mistakes. Not quite as bad as a certain US ex-president, but definitely in the ballpark. As you can imagine, in the organizations they led, that culture permeated the org. Nobody would admit mistakes, blame was constant, and nobody learned.
As a human, you will make mistakes. As a leader, you must admit to those mistakes. Celebrate those mistakes. Instead of blaming finance, tell your team how you screwed up the budget and they now have to cut travel. Instead of blaming a vendor for not delivering a product, take responsibility for not communicating a clear plan and expectations. Every mistake presents a learning opportunity, and leaders need to be role models for admitting mistakes and finding learning opportunities.
Learning from Complex Mistakes
When a change in a third-party system causes a web service to change request rates in such a way that another service increases error rates by 25%, the learning opportunities are less obvious. Questions I often ask in situations like this are, “what did we learn?”, and “what - if anything - could we do differently?”. Often - especially when these questions are new, I will get answers like, “we learned that systems are complex”, and “there’s nothing we could do differently”. In this case, my assigned homework is to ask them (individual or team) to come up with at least three things we learned, and at least three things we could do differently. I don’t care how wild or weird the ideas are, but I’ve found time and time again that ideas come from other ideas, and this exercise gives us a start. Sometimes there aren’t any actionable ideas. Sometimes the ideas aren’t feasible. Sometimes, there’s something real we can implement. In the end, it doesn’t matter - the discussion promotes learning, and that’s what’s most important.
Rather than summarize (yet again?) The Fifth Discipline, I’ll tell you from experience that organizations that focuses on learning have a competitive advantage over everyone else.
Building a Learning Organization
As critical as it is, too few leaders focus on building a learning organization. It’s often seen as too important to focus on factory-style delivery above anything else, rather than focusing on building a learning organization that can ultimately deliver and adapt at a much more rapid pace.
Of course, a building a learning organization is the more difficult path. For some mangers, leading by command-and-control, spreadsheets and tickets is just easier. It requires minimal thought and a small number of skills. Building a learning organization requires systems thinking, growth opportunities, psychological safety, diversity, shared vision, team learning, steward leadership, and continuous evaluation and learning.
What do you get for this effort? Is it worth it? The answer to any sufficiently complex question is, “it depends”. But - if you embrace everything in the last paragraph, my experience tells me that you’ll merely end up with an organization that adapts quickly, solves problems at lightning speed, are empowered to make decisions, have deep trust in one another, have low turnover, increased engagement, and produce better quality outcomes.
One path is more difficult, less traveled, but does more.
"Two roads diverged in a wood, and I took the one less traveled by, And that has made all the difference."
Robert Frost
We know all too well what the right path is. Which one do you choose?
-A