Our findings were later published as Project Aristotle. The biggest finding was that the number-one indicator of a successful team wasn’t tenure, seniority or salary levels, but psychological safety.
Think of a team you work with closely. How strongly do you agree with these five statements?
Teams that score high on questions like these can be deemed to be “unsafe”. Unsafe to innovate, unsafe to resolve conflict, unsafe to admit they need help. Unsafe teams can deliver for short periods of time, provided they can focus on goals and ignore interpersonal problems. But eventually, unsafe teams will break or underperform drastically because people can’t introduce change.
Unsafe teams will break or underperform drastically because people can’t introduce change.
Let’s highlight the impact an unsafe team can have on your team’s individuals, through the eyes of a recent, fresh-faced and enthusiastic graduate who finished top of their class.
This imaginary graduate, we’ll call her Karen, was reading about an optimization that could reduce low-level locking in distributed databases, and realized it could be applied to the service her team worked on. She decided to test it out, it resulted in a 15% CPU saving on the test cluster, and in her excitement, decided to roll it out to production. Because it was a change to a database configuration file, it didn’t go through the usual code-review process.
Unfortunately, it caused the database to hard-lock-up, causing a brief, but total outage of the website. Thankfully, her more experienced colleagues spotted the problem, and rolled back the change inside of 10 minutes. Being professionals, this incident was mentioned at the weekly “post-mortem” meeting.
At the meeting, the engineering director let everyone know that causing downtime by chasing small optimizations was unacceptable. Karen was described as “irresponsible” in front of the team, and the team suggested ways to ensure it wouldn’t happen again. The engineering director forgot about this interaction quickly after. But Karen would never forget the exchange. She would never try to innovate without explicit permission again.
The impact on Karen was actually magnified because no one stood up for her. No one pointed out the lack of code reviews on the database configuration allowed this to happen. No one pointed out the difference between highlighting one irresponsible act and labelling someone “irresponsible”. The team was so proud of their system’s reliability, defending their reputation was more important than a new hire.
Karen learned that her team, and manager didn’t have her back.
As Karen was new to “production”, she had no formal training in incident management, production hygiene, let alone troubleshooting distributed systems. As her team was mostly made up of people with decades of experience, they had never needed training, or new-hire documentation. There were no signals that it was OK for a new graduate to spend time learning these skills.
Karen developed Imposter Syndrome. She didn’t understand how she passed the hiring process, and frequently wondered why she hadn’t been fired yet.
Karen’s background was in algorithms, data structures and distributed computing. She realized the existing system as a whole was suboptimal, and would never handle load spikes.
The team had always blamed the customers for going over their contracted rates, which is like blaming weathermen for rain during an Irish barbecue.
Karen proposed a new design, based on technology she’d used during her internship. Her co-workers were unfamiliar with the new technology and considered it too risky. Karen dropped her proposal without discussion. She wanted to write code and build systems, not have pointless arguments.
When a large customer traffic spike caused the product to be unavailable for a number of hours, the CEO demanded a meeting with the operations team. Many details were discussed, and Karen explained that the existing design meant it could never deal with such spikes, and mentioned her design. Her director reminded her that her design had already been turned down at an Engineering Review, and promised the CEO they could improve the existing design.
Karen discussed the meeting with one of her teammates afterwards. She expressed dismay that the Director couldn’t see that his design was the root-cause of their problems. The teammate shrugged, and pointed out that they had delivered a really good service for the last five years, and had no interest talking about alternate designs with the director.
Karen decided to head home early, and look for a new job. When she left, the company didn’t miss her. After all, she was “reckless, whiny and had a problem with authority”. They never realized she had the design that could have saved the product from the customer exodus that follows repeated outages.