Building Trust

[Part 3 of a three-part series.]

Agile retrospectives often start with this Prime Directive:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand. -- Norm Kerth

But what if people on the team don't truly believe it? How do you build trust on a team where people don't trust each other?

The retrospective Prime Directive is intended to shift a team's focus from blame to problem-solving. People need to feel safe in communicating honestly what they see as problems on the team, and this can mean admitting their own mistakes, or pointing out failures that others were involved in. They shouldn't have to fear retribution for being honest. But "being honest" in this context needs to mean objectively identifying problems and their causes.

People often think that blaming or imputing hidden motives to others is the same as identifying the cause of a problem. Most of the time, however, blaming someone means that one doesn't understand the issue deeply enough.

Toyota uses a technique called the Five Whys to identify the root cause of problems by asking a series of "why" questions. A true root cause should be some kind of process failure:

The real root cause should point toward a process that is not working well or does not exist. Untrained facilitators will often observe that answers seem to point towards classical answers such as not enough time, not enough investments, or not enough manpower. These answers may be true, but they are out of our control. Therefore, instead of asking the question why?, ask why did the process fail?

In the same way, if a person is seen as the problem, then the solution will require that the person change, something the team can't control. Even if the team is capable of getting rid of a person, having team members thinking about how to oust others poisons the atmosphere and undermines trust, collaboration, and productivity. In the "Five Whys" perspective, on the other hand, "People do not fail, processes do."

Building trust on a team requires moving from a blaming focus to culture in which the team collaborates in solving problems. Anyone can bring up a problem, people don't keep problems to themselves, and they feel comfortable asking for help. All this requires the ability to communicate safely.

Now suppose some team members truly do not in fact believe the prime directive in a retrospective or other problem-solving activity. Nevertheless, it's important that they put that belief aside for the duration of the exercise. This is one place where "fake it till you make it" applies. If some team members don't think beyond the fact that Person X is blameworthy, they won't consider other win-win approaches to attacking the problem. For example, what systems can be put in place to prevent the problem from occurring again, or to mitigate its effects?

Seeing problems as process failures allows you to address their causes systematically and in a robust way. "Shoulds" aren't very reliable motivators--just promising to do something you haven't been doing, or to be more diligent about doing something you were already supposed to be doing, generally doesn't lead to dependable results. Effective change requires changing something in the process to support the new behavior.

At Stack Builders we've been talking about "safety nets" recently. We don't like it when people make mistakes, but more important is the ability to minimize the harmful effects of mistakes and to recover from them easily. Establishing these sorts of safety nets is one example of focusing on process rather than on blame. And once these safety nets are in place, team members begin to feel more secure, and blame becomes less important. It's a virtuous cycle.

That said, at times on a team there will be discussions "where (1) stakes are high, (2) opinions vary, and (3) emotions run strong." These exchanges can threaten the safety that's needed for honest communication and problem-solving. Some people are particularly sensitive to criticism, while others can be abrasive even when they intend nothing personal. To top it off, there's always the chance that a comment can be interpreted in a way that wasn't intended.

For these situations I recommend reading Crucial Conversations, by Kerry Patterson, Joseph Grenny, Ron McMillan, and Al Switzler. The center of the book is a pair of chapters on "How to make it safe to talk about almost anything," and "How to stay in dialogue when you're angry, scared, or hurt." These are skills everyone on a team needs to have. Software development is almost always a collaborative enterprise, which means that being a good software developer requires more than just technical skills. Team conflict can torpedo a project just as easily as poor code can.

Ultimately, trust flourishes in an environment where team members believe they are all working together for a common goal. But if the team's goal is perceived as at odds with team members' individual goals--for example, if they are asked to sacrifice their family lives to support unrealistic deadlines--trust will not last long. Consensus and win-win solutions are the soil from which trust grows.

If you are a manager, this means that in the final analysis the members of the team are not there for you, or for the project, but for themselves. For some people, it can be a big shift in perspective to acknowledge that others' self-interest is legitimately their primary motivation. However, it's an essential part of treating others as peers, with respect. Ricardo Semler explains how this works at his company, Semco:

For a company to excel, employees must be reassured that their self-interest, not the company's, is their foremost priority.... At Semco this is considered a form of corporate alignment. Without it, a company has to institute programs to pressure, exhort, and compel people to do their jobs. Soon you're roping employees into singing company songs, organizing support teams, and reporting to assemblies for pep talks. What lubricates the process for us is faith--faith supported by experience--that employees can pursue their self-interest and fulfill the company's agenda at the same time.

The alignment Semler talks about has a huge impact on satisfaction and happiness at work. Being on a team where everyone trusts everyone else is not only productive; it is a joy. Make it a priority to establish the conditions for trust on your team. It's one of the most rewarding things you can accomplish.