Trust is the foundation of any healthy relationship. This is true of family, friendships, teammates, even military units. Without trust, any relationship can become dysfunctional.
When considering professional relationships in jobs with a high threat of physical danger, such as the military or police, trust takes on a clear physical component—the safety of the individuals and the group is dependent upon the trust between its members. When considering professional relationships in software development teams, though, the role of trust may be less obvious but no less important.
In fact, trust is one of the most important working agreements a team can have. For instance, as a software developer I trust that my teammates have the best interests of our product and customers in mind when we approach a problem. I trust that my team will build software that meets my level of expectations with regards to quality. And I trust that if I need assistance learning a new topic, researching an issue, or handling an emergency, my team will be there to help.
Trust in the mob
The team responsible for New Relic Insights spends a lot of time mob programming, and this level of trust is particularly important when working in the mob. When only one person is on the keyboard, and the rest of the team is working collaboratively to solve a problem, you need trust to make it possible.
- I trust that my teammates will respect my opinions and listen when I am providing input.
- I trust that when I am driving, my teammates will provide me with guidance and input, not dictation and categorical instruction.
- I trust that when I am not driving, the driver will be open to my input.
- I trust that if I think we have diverged from our priorities or wandered down a rabbit hole, the team will listen when I express my concerns and be open to changing course.
- I trust that if I am having trouble understanding what we are doing, why we are doing it, or how we are doing it, my team will take the time to explain it to me.
- Finally, since I have given my trust to my team, I have to honor those same commitments and be trustworthy in return.
Symptoms of broken trust
Working on the Insights team has given me a unique perspective on trust. From speaking with developers on other teams in the industry, I have learned that the lack or loss of trust can have dramatic detrimental effects. Some symptoms of broken trust are easily recognizable:
- Us vs. them
- I’ll do it myself
- Don’t tell the others
- If it weren’t for them …
Let’s take a closer look at each of those systems of broken trust, and how to address them.
Us vs. them
The presence of an “us vs. them” mentality is an immediate indicator of broken or lacking trust. In a healthy team or organization, there is no “them,” there is only “us.” That’s because we are all working together, and we trust that everyone is contributing to our common goal. However, if the group has competing or divergent priorities, a rift is created, and sub-groups with opposing needs begin to grow. This results in mental walls that begin to separate team members from one another.
So what do you do when you recognize an “us vs. them” mentality developing in your group? I think the best solution is to face the situation head on. First, everyone has to accept that there is no “them.” Then you all have to work together to break down the walls and reorient the group’s goals toward common outcomes. I have found the MMF concept to be a powerful tool for this since it automatically aligns the group behind a single goal.
I’ll do it myself
This mindset occurs when team members don’t trust that others can do a task correctly, and therefore the only solution is to do it themselves. This can happen when someone doesn’t believe anyone else has the necessary skills, or they don’t believe they will put in the requisite effort. It can also occur when an individual doesn’t wish to share their work, and are building a silo around themselves. The result is isolation and a communication breakdown.
How do you combat this syndrome? If you’re feeling this way, look first at the assumption you made that gave you the basis to decide that only you could do this work. If it’s due to a perception that others lack the skills, then you have just identified a perfect time to teach your teammates and help them become better engineers. If it’s due to an opinion that they won’t put in the effort, you have just identified a perfect opportunity to coach them through the discovery process that you use to identify the level of effort and acceptable quality required to consider the task complete. If you are building a silo, ask yourself why. What are you trying to protect yourself from? And what will happen when you aren’t around and something goes wrong?
Don’t tell the others
This mentality occurs when you don’t trust that the other members of the group will agree with what you are doing. Perhaps the work is so important that you think it’s higher priority than what the group is pursuing. Or you may want to work on something you think is more fun than the group’s goal. Or maybe you just don’t want to work with the group for whatever reason. The justification isn’t necessarily relevant; what really matters is the fact that your priorities and direction do not align with the group.
Fixing this one is pretty simple. Ask yourself why you have different priorities than the group. Then have a discussion with your team and project manager about that very same question. You might be right, and the group may need to pivot its priorities to align with yours. But you might also be wrong, and there may be solid reasons for the group’s priorities. Remember, you are part of a team, and you work together to solve problems. Work together to solve this one.
If it weren’t for them…
We see this issue when a goal is in jeopardy or has been missed, and you need to protect yourself from taking the blame. Your lack of trust in someone else to deliver has lead you to adopt a defensive position. This is actually a lot more serious than it sounds, indicated by your need to deflect blame in the first place. That in itself is an organizational anti-pattern, symptomatic of dysfunction. Cultures that require assigning blame don’t put the focus on the work, but on covering your ass. It pushes team members not to work with others to solve problems, but to instead separate themselves to establish deniability.
Fixing this can be difficult because you may be facing an organization problem. If it’s not organizational, then you need to ask yourself why assigning blame is so important. Blame doesn’t ship software. Typically, blame is used to cover for an unmet dependency. Why exactly did an unmet dependency cause you to fail to deliver on your goals? What can you do to remove that dependency? Talk to the team or individual that you are dependent upon and work with them to alleviate the blockage. Involve your manager and PM; it’s their job to help work through these types of issues.
All healthy teams require trust, and software teams are no exception. The collaborative nature and complexity of our work requires us to rely upon others to help us achieve our goals. When we allow trust to erode, we introduce dysfunction into the team.
Dysfunctional teams cannot work at peak efficiency, because dysfunction and distrust have a cost—an expensive one. You aren’t building software if you are busy thinking up excuses. You aren’t building for quality if you aren’t sharing responsibility. You aren’t delivering the functionality of highest value if you aren’t working together on a unified goal.
Trust—it’s what teams crave!