Why Addressing Errors Effectively Lies at the Heart of Team Performance

No one wakes up in the morning excited to go to work and look ignorant, incompetent, or disruptive. While it's not true of everyone, I think it's fair to say that anyone who gets a job wants to be there and usually wants to do well--for the purpose of self-respect. Look at how elated most people are when they accept a job after getting an offer. It's when they enter into the "systems" at a particular company, that everything usually takes a left turn.

In established companies, it's sadly common for employees to be habituated in a context of fear of failure, especially if there is a lot of pressure from management to perform at a high level. There are ambitious goals, often coupled with a lack of clarity on how they will be achieved. In practice, employees focus on looking busy (however that is defined). They end up fearing failure, of not living up to expectations.

As a manager, there is a fine line to draw here. You don't want to set the bar too low and cause everyone to just slack off. The starting point here is one of psychological safety; according to the research, this is one of the main factors driving high performance in teams. In particular, how you handle errors, failures, or surprises in a way that keeps the team accountable while enabling them to believe that they will be listened to--if they speak up.

Common Error Types

According to Amy Edmondson in The Fearless Organization, there are 3 different types of errors which happen professionally, and their meaning is largely driven by context:

1. Mechanical errors in a highly repeated process that just need to be minimized in frequency: this is what Modern Times parodied
2. Interaction errors which result from highly complicated relationships, especially in a larger company
3. Thwarted expectations around a goal in the context of experimentation, often a surprising result of an experiment

A large part of the challenge of large companies is that they treat all errors as if they were all #1 by default. This approach may be tied to political gamesmanship. But not everything is just a deviation from a standard (regardless of who actually decides and imposes that standard). Especially in knowledge work like software, where completing something requires you to learn something you don't know up front. Edmondson quips, “For knowledge work to flourish, the workplace must be one where people feel able to share their knowledge!”

In my software experience, most of the problems encountered, especially around people and process, were due to #2. Company systems were wrong, inadequate or just misaligned. Unfortunately, this typically meant that a person or department was singled out and blamed. I tried hard to bring the discussion back into a discussion around how the work was done, and if something could be done to prevent a similar problem from re-occurring.

The last type (#3) is essentially an opportunity to improve the company, the product, or the workflow, packaged as an intellectual surprise. Sometimes, the team would come across a much better way to solve or define a technical problem than they had originally wanted to do otherwise. This was particularly common in the early days of designing a large system. The same can be true on the business side, if the company is open to experimentation on that end. These are so valuable, that most innovation circles try to maximize the number of these errors through structured experimentation and record-keeping, in order to speed up overall progress.

Be Open to Taking Ownership and Admitting Mistakes

From the perspective of psychological safety, it's critical to start with assuming any error is a #2. This includes assuming that the leader in the system is responsible for the system. More importantly, he is also part of the system. Which means that the manager needs to be open to letting their ego be bruised, and be willing to admit mistakes in front of their fellow team members, in the service of improving life for everyone. Once I did this enough times with my team, they realized and eventually believed that I was genuinely interested in optimizing how the team worked.

Essentially, the way to solve the misaligned expectations problem (bar too high vs too low) is to view the work as a system. And that way, you depersonalize the work enough, that fears become less of a driver for action. Instead, employees follow their genuine interest in improving their own work life. This allays fears of failure. And gets everyone more involved and excited.

Ultimately, you care about the output your team produces, so focus your management on that, rather than on policing individual effectiveness. Paradoxically, it produces better results.

Key Takeaways

• Psychological safety lies at the heart of high performing teams.
• Most commonly, errors are assumed to be individual mistakes, rather than the result of complicated interactions gone wrong.
• Get the team excited about improving the workflow.

CodeProject