When I worked for Google as a Site Reliability Engineer, I was lucky enough to travel around the world with a group called “Team Development”. Our mission was to design and deliver team-building courses to teams who wanted to work better together.<\/p>\n
Our findings were later published as Project Aristotle<\/a>. The biggest finding was that the number-one\u00a0indicator of a successful team wasn\u2019t tenure, team leaders, seniority or salary levels, but team\u00a0psychological safety<\/strong>.<\/p>\n Think of a team you work with closely. How strongly do you agree with these five statements?<\/p>\n 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\u2019t introduce change.<\/p>\n Unsafe teams will break or underperform drastically because people can\u2019t introduce change.<\/p>\n Let\u2019s highlight the impact an unsafe team can have on your team\u2019s individuals, through the eyes of a recent, fresh-faced and enthusiastic graduate who finished top of their class.<\/p>\n This imaginary graduate, we\u2019ll 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\u2019t go through the usual code-review process.<\/p>\n 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.<\/p>\n 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\u2019t 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.<\/p>\n 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\u2019s reliability, defending their reputation was more important than a new hire.<\/p>\n Karen learned that her team, and manager didn\u2019t have her back.<\/p>\n 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.<\/p>\n Karen developed impostor syndrome<\/a>. She didn\u2019t understand how she passed the hiring process, and frequently wondered why she hadn\u2019t been fired yet.<\/p>\n 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.<\/p>\n The team had always blamed the customers for going over their contracted rates, which is like blaming weathermen for rain during an Irish barbecue.<\/p>\n Karen proposed a new design, based on technology she\u2019d 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.<\/p>\n 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.<\/p>\n Karen discussed the meeting with one of her team members afterwards. She expressed dismay that the Director couldn\u2019t see that his design was the root-cause of their problems. The team member 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.<\/p>\n Karen decided to head home early, and look for a new job. When she left, the company didn\u2019t 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.<\/p>\n So, what is special about Engineering that leads us to drive away so many promising engineers, and allow so many others to achieve less than their potential?<\/p>\n We need to balance respect for our culture, with an openness to change it as needed.<\/p>\n We know that a strong sense of culture, shared understandings and common values are required to succeed. So we need to be able to balance that respect for our culture, with an openness to change it as needed. A team that is initially happy to work from home needs to change how they work if they take on some interns. A team proud that every engineer is on-call for their service may need to professionalize around a smaller team of operations-focused engineers as the potential production impact of an outage grows.<\/p>\n We need to be thoughtful about how we balance work people love, with work the company needs to get done. Good managers are proactive about moving on an engineer who is a poor fit for their team\u2019s workload. Great managers expand their team\u2019s remit to make better use of the engineers they have, so they feel their skills and talents are valued. Engineers whose skills go unused grow frustrated. Engineers given work they are ill-equipped to succeed, will feel set up to fail.<\/p>\n It’s hard to give 100% if you spend mental energy pretending to be someone else. We need to make sure people can be themselves by ensuring we say something when we witness disrespect. David Morrison (Australia’s Chief of the Army) captured this sentiment perfectly, in his \u201cthe standard you walk past is the standard you accept<\/a>\u201d speech.<\/p>\n Being thoughtless about people\u2019s feelings and\u00a0experiences can shut them\u00a0down. Some examples where I\u2019ve personally intervened:<\/p>\n It\u2019s essential to challenge lack of respect immediately, politely, and in front of everyone who heard the disrespect. It would have been wonderful had someone reminded Karen’s director, in front of the group, that the outage wasn\u2019t a big deal, and the team should improve their test coverage.<\/p>\n Some companies talk of 20% time. Intercom has “wiggle weeks<\/a>“, in between some of our 6-week sprints<\/a>. People often take that chance to scratch an itch that was bothering them, without impacting the external commitments the team has made. Creating an expectation that everyone on the team should think outside the box, and ensuring that the whole team can go off-piste at the same time, is a powerful message.<\/p>\n Be careful that “innovation time” isn\u2019t the only time people should take chances. One company in the transport industry considers “innovation time” to be 2:30 p.m. on Tuesdays.<\/p>\n Imagine how grateful Karen would have been, had a senior engineer at the Engineering Review offered to work on her design with her, so it was more acceptable to the team. Improve people\u2019s new ideas, rather than discounting them.<\/p>\n I love how my team writes goals on Post-It notes at our daily standups and weekly goal meetings. These visible marks of success can be cheered as they are moved to the “done” pile.<\/p>\n But we can also celebrate glorious failure. Many years ago, when I was running one of Google\u2019s storage SRE team, we were halfway through a three-year project to replace the old Google File System.<\/p>\n We can also celebrate glorious failure.<\/p>\n Through a confluence of bad batteries, bad firmware, poor tooling, untested software, an aggressive rollout schedule and two power cuts, we lost a whole storage cell for a number of hours, and though all services would have had storage in other availability zones, the team spent three long days, and three long nights rebuilding the zone. Once it was done, they – and I – were dejected. Demoralized. Defeated. An amazing manager who was visiting our office realized I was down, and pointed out that we\u2019d just learned more about our new storage stack in those three days, than we had in the previous three months. He reckoned a celebration was in order.<\/p>\n I bought some cheap sparkling wine from the local supermarket, and with another manager, took over a big conference room for a few hours. Each time someone wrote something they learned on the whiteboard, we toasted them. The team that left that room was utterly different to the one that entered it.<\/p>\n I\u2019m sure Karen would have loved appreciation for discovering the team\u2019s weak non-code test coverage, and their undocumented love of uptime-above-all-else.<\/p>\n Rather than yelling at an engineering team each time they have an outage, help them build tools to measure what an outage is, a Service Level Objective that shows how they are doing, and a culture that means they use the space between their objective, and reality, to choose the work that will have the most impact.<\/p>\n Ask for a specific commitment, rather than assuming everyone agrees on its urgency.<\/p>\n When discussing an employee’s own fallibility, they need to feel safe to share all relevant information, with the understanding that they will be judged not on how they fail, but how their handling of failures improved the team learning, their product and the organization as a whole. Teams with operational responsibilities need to come together and discuss outages and process failures. It\u2019s essential to approach these as fun learning opportunities, not root-cause obsessed witch-hunts.<\/p>\n I\u2019ve seen a team paralyzed, trying to decide whether to ship an efficiency win that would increase end-user latency by 20%. A short conversation with the product team resulted in updates to the SLO, detailing “estimated customer attrition due to different latency levels”, and the impact that would have on the company’s bottom line. Anyone on the team could see in seconds that low-latency was far more important than hardware costs, and instead drastically over-provisioned.<\/p>\n If you expect someone to do something for you, ask for a specific commitment – \u201cWhen might this be done?\u201d, rather than assuming everyone agrees on its urgency. Trust can be destroyed by missed commitments.<\/p>\n Karen would have enjoyed a manager who told her in advance that the team considered reliability sacred, and asked her to work on reliability improvements, rather than optimizations.<\/p>\n If you are inspired to make your team feel more psychologically safe, there are a few things you can do today:<\/p>\n Treat psychological safety as a key business metric, as important as revenue, cost of sales or uptime. This will feed into your team\u2019s effectiveness, productivity and staff retention and any other business metric you value.<\/p>\n\n","protected":false},"excerpt":{"rendered":" The top indicator of a successful team isn’t tenure, seniority or salary levels. It’s psychological safety. Here’s how to build it into your organization.<\/p>\n","protected":false},"author":432,"featured_media":12890,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"category":[12898],"tags":[115,335],"coauthors":[20532],"class_list":["post-12891","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-engineering","tag-company-culture","tag-engineering"],"yoast_head":"\nEvaluate psychological safety with these 5 questions<\/h2>\n
\n
1. \u201cIf I take a chance, and screw up, it\u2019ll be held against me\u201d<\/h3>\n
2. \u201cOur team has a strong sense of culture, and it\u2019s hard for new people to join\u201d<\/h3>\n
3. \u201cMy team is slow to offer help to people who are struggling\u201d<\/h3>\n
4. \u201cUsing my unique skills and talents come second to the goals of the team\u201d<\/h3>\n
5. \u201cIt\u2019s uncomfortable to have open, honest conversations about our team\u2019s sensitive issues\u201d<\/h3>\n
How to build psychological safety into your own team<\/h2>\n
Make respect part of your team\u2019s culture<\/h3>\n
\n
Make space for people to take chances<\/h3>\n
Make it obvious when your team is doing well<\/h3>\n
Make your communication clear, and your expectations explicit<\/h3>\n
Make your team feel safe<\/h3>\n
\n