A few years ago, Google conducted a survey of its employees to determine what’s the main contributor to a high performing team. As I saw the headline I was intrigued to find out the result. I was sure leadership was the number one reason for team success- mostly because I was a manager and I had read a lot about the impact of good leadership. I read eagerly hoping to learn some tips. I even anticipated secondary reasons like: talent, team composition. But when I read the results I was shocked and disappointed by their conclusion- it did not include any of my assumptions. The research claimed that the #1 factor for high performing teams was “Psychological Safety” aka trust. It didn’t make sense to me. In general, I think people are good- especially in a professional environment. I thought in any reasonable organization people dont lie to each other, and are going to get paid on time. I really didn’t understand what this was trying to say- was it just some new fad?
A few months later I finally understood.
The company I worked for at the time had reorganized. Within a few weeks my team’s work quality started to suffer or so it seemed. Almost each time after we released a new update of the software to our operations team, there were issues. They were typically small and easy to fix but the issues escalated quickly. It went from the operations person who discovered the issue to their manager, to the VP, to the President of the company, to my boss (The CIO) and then it hit my desk as the VP in charge of that area. If you’re counting, that’s 7 steps. I knew where to go to get it fixed and involved an 8th person, Carla. She had recently switched from the operations department to my team in IT and understood the intersection between technology and operations well so was well suited for her new role. But it seems she started making a lot of mistakes all of a sudden. While the fixes were typically minor (e.g. change a number from 100 to 1000), each time I’d need to write up a full report on what happened, how it happened and how it was fixed etc and send it around the organization. It was very frustrating to say the least. Sometimes we needed to meet about it- wasting even more time. Of course I put in preventative steps to ensure that root cause wouldn’t happen again. I reviewed processes and put in more checks and balances. But the next time a different small issue would crop up and trigger a large chain of events. It was reflecting badly on the team, especially Carla as her mistakes came to light. As I worked to close gaps in the development/testing process, I tried to understand how quality tanked and so quickly. Finally in one discussion with Carla, she admitted that these mistakes were always happening. In the past her friend in the operations department would call her with the issue directly. They both came in early so they typically solved issues before others noticed. What had changed was that her friend moved to a different role. With new people in new roles in the organization no one reached across to solve issues and instead went up and down the chain. A small issue became a crisis.
When I rehashed this episode I realized that admitting mistakes early could have solved the issue early when Carla was starting out in her new role and saved countless hours of CYA emails and wasted meetings. Trust is important. Trust that a person won’t get in trouble for making a mistake. Trust to go across the organization. Trust that an issue is being taken care of appropriately. Trust that a manager will have appropriate solutions.
I realized I needed to do two things: first I had to make her comfortable enough to admit mistakes and gaps in knowledge so we can learn from it and prevent it from happening again. I also needed to give Carla more training. The problems soon went away and Carla succeeded in her role, but first came trust.
As I build a new team I know what I need to start with- Trust me.