Create a Team Environment of Safety
There’s a bit of a chicken-and-egg problem with interpersonal skills. Teams need safety to build their skills. And building the skills helps the team members provide a safe environment for each other.
Amy C. Edmondson, in Teaming: How Organizations Learn, Innovate, and Compete in the Knowledge Economy [Edm12], discusses the need for psychological safety in interdependent collaborative teams. Safety allows the team members to discuss, explore together, and learn.
What's the Big Deal About Safety?
by Jim, VP, R&D
Jim
I initially pooh-poohed the idea of psychological safety. Then I realized that some of our teams had substantially more throughput than other teams. I had lunch with different team members and found a significant data point. Every single team with less throughput had at least one person as a "lead" of some sort.
I had created architectural leads, development leads, even test-architecture leads. I even called them my "indispensable" people. What a mistake. Those people imposed their agendas on the teams. No one else on the team felt safe to say something that disagreed with those leads. They were concerned about other peoples’ possible negative perceptions of them.
I realized my mistake. I had one-on-ones with the leads and explained the problem. They agreed to each try experiments that removed them from the know-all position. One architect told me it was such a relief—he no longer had to know "everything." I explained the difference in how we thought about people. We created "communities of practice" and ways for these people to explore their influence on the business value of the architecture, automation, refactoring patterns, everything.
In addition, I focused on learning early. What small experiments could we run that would allow our teams to learn together, safely? That changed the culture over time. It took about six months before I saw a fight between an architect and a tester. I was thrilled. That meant these two people felt comfortable enough to disagree and still be able to work together.
As a by-product, I have many more "indispensable" people now, but I no longer have a bus factor of one. Our entire organization is more adaptable and flexible in the work they do and in what they understand.
I now understand the need for safety. People have to be able to ask questions, challenge assumptions, and find new ways of working together. I’m not big on the kumbaya nonsense. I want results in the best possible product as early as we can deliver it. Psychological safety allows the teams to do that.
In agile terms, safety allows the team to manage the ambiguity and uncertainty about anything: the stories, the architecture, the tests. Safety allows the team to learn early by creating small experiments. Safety helps people admit and look for mistakes.
We create safety when we
- encourage learning from small experiments,
- use clear and direct language,
- admit when we don’t know,
- acknowledge when we fail, and
- set boundaries for what is a personal or team decision and what is not.
One of the best ways to create team safety is to create an environment in which team members feel safe to take risks.
Safety Helps the Team Evaluate and Recover from Risks
In more traditional projects, the project manager or the manager manages risks. That risk management often takes the form of “This could happen. How will we guard against it?” Sometimes the team learns (late) that it didn’t manage a risk. Safe teams mistake-proof their work. Sometimes the leader leads the mistake-proofing. Sometimes team members do. It doesn’t matter who leads it, as long as teams create ways to mistake-proof their work.
We Learned About Mistake-Proofing the Hard Way
by Trevor, Technical Lead
Trevor
We were rolling along, releasing features into the code base every two weeks. We high-fived each other at every retro, because we were so freaking awesome. I didn’t realize that we each had specific roles in the release and we didn’t know each other’s roles.
Joe put together the release notes. He also did some manual checks, which I didn’t realize. He went on vacation during the summer and we released as normal. We had Susie write the release notes.
The release notes were fine. The release didn’t work. We had to back it out and we had egg on our face. It didn’t matter that the previous 20 releases had gone well. This one didn’t. I looked into what happened.
Joe had been doing manual checks for several items. He hadn’t documented them. I hadn’t realized and neither had Susie. We decided to re-create the manual checks with automation so we wouldn’t make the same mistake again.
We didn’t blame each other. We acted to make sure this problem didn’t happen again for releasing. We took this opportunity to mistake-proof other areas in the team. We’re so much more robust now. We have a side-benefit, too: we can release more often and faster.
In agile projects, team members are more likely to ask this question: “How can we recognize risks when they are small, and if they do occur, how can we recover from them?”
Those are two different attitudes about risks. More traditional projects want prediction and control. Agile projects provide resilience. You will find ways to build resilience into your projects. Consider these two ways to build resilience: the team’s ability to manage its team membership and its ability to learn early.
Teams Manage Their Own Membership
Many organizations have a defined process for hiring: The manager fills out a requisition. The manager writes the job description. The manager phone-screens candidates. The manager decides who will interview the candidate. The manager decides who to hire.
If you want a collaborative, high-performing team, ask the manager to facilitate the hiring process, not manage it. Instead, ask the team to manage the hiring process. The more you want a collaborative team, the more the team has the ability to decide who is—and who is not—on the team. When managers decide, the team has less power to manage itself.
Teams who can manage their own membership help the team grow and deliver. They already know they want these people. The team is willing to invest time and energy into providing feedback and coaching to the team members.
Teams who don’t have a say in their team membership might try to collaborate. However, I don’t see these teams sustain their collaboration when team members don’t fit.
Too often, we hire for technical skills and fire for interpersonal skills. See Hiring Geeks That Fit [Rot13] for more information about how to hire the for interpersonal skills your team needs.
Learn Early Instead of Failing Fast
One of the common phrases about agile is “fail fast.” The problem with “failing” is that it is an emotionally loaded word. We have decades of experience in organizations that require us to not fail.
Instead of failing fast, consider learning early. I find that learning early creates a different mindset for me. I now create small, safe-to-fail experiments. I manage my ambiguity around the entire deliverable by creating small steps.
I might be unique with my concern about the “fail fast” metaphor. If your team members have trouble with the idea of failing, consider asking them what they can learn and how early they can learn it. When teams decide to learn early, they might select more small experiments to provide them information. That information builds resilience in the team.
Team collaboration and learning helps the team build safety and resilience. No one “bets the farm” on any one idea or one feature.
Safety Allows the Team to Build Respect
Feedback, coaching, and managing team membership helps the team create an environment in which people can work together, including experiment together, with safety.
One way to think about safety is to consider David Rock’s SCARF model (SCARF: A Brain-Based Model for Collaborating with and Influencing Others [Roc08]). SCARF stands for Status, Certainty, Autonomy, Relatedness, and Fairness.
Here are some anti-collaboration patterns in terms of SCARF:
-
When the team’s status is uneven, such as when the manager is part of the team. People are reluctant to take a risk in front of their managers; see Weird Ideas That Work: How to Build a Creative Company [Sut06].
-
When the team feels uncertain about its next steps. The larger the feature is, or the more uncertainty around a feature, the less certainty a team has about how to do the next work.
-
When the team has insufficient autonomy to work the way it wants to. The team might feel bound by decisions from outside the team.
-
When the team doesn’t know or can’t manage its team membership—the team’s relatedness. If managers pluck people from or add people to a team, the team members don’t have the ability to develop their relationships.
-
When the team members sense unfairness in how they are treated, as individual members or as a team. Agile approaches invite team recognition and rewards to address this potential unfairness.
It’s not just management status that can reduce collaboration; it might be other hierarchy, such as technical architecture. Architects can help keep the codebase coherent. Good architecture practices can help with refactoring and improve the performance of the product. The problem arises when the architect is external to the team.
When the organization creates an architectural career path where the architects don’t work on teams, the organization creates a hierarchy in the product-development organization. That creates safety issues and often code (or test) issues. Agile teams move fast, building just enough for now and verifying that what they built works. The team can’t safely do that if they have to accommodate someone else’s (well-meaning) architecture or design.
The reason architects exist is that they know a tremendous amount about how systems work. That expertise might be quite helpful to the team members. Consider building communities of practice, open to whoever is interested. You might need these to start:
- Architecture
- Test automation
- Technical practices that increase collaboration
Help your team increase its safety with equality on the team, certainty about its next steps by having small stories, autonomy for the team around its management and membership, and fairness in how the team members treat each other and how the organization treats them.
The more the team can provide each other feedback and coaching, and manage their membership, the freer the team will be to collaborate and build a safe environment for itself.
