Over the years I have come to appreciate how trust is the key ingredient to any effective engineering organization. The presence of trust enables all sort of things to magically happen, while its abscence can torpedo almost any effort. Patrick Lencioni, in his book The Advantage places trust as the base principle amongst five that he identifies as the keys to any healthy organization.

Types of trust in the org

The basic types of trust are the trust between peers, and trust up and down through the org chart. In larger orgs these basic types can mix into trust between whole groups, but the basic rules will apply.

Symptoms for a lack of trust between peers

The challenge of missing trust is that it will manifest through lots of symptoms that people will describe in other terms. It isn’t often that the participants in a conflict recognize that mistrust is at the root.

“Bob is an idiot”

This is the classic signal between engineering peers. I know that Alice is a quality engineer, and so is Bob. And yet Alice thinks that Bob is an idiot with regard to some technical question. What Alice is really trying to say is “I don’t trust Bob, and so I don’t trust his technical judgement on X.”

“Bob has his own agenda”

Alice thinks that her motivations are supporting the company, while Bob has some ulterior motive. Besides being a sign that Alice probably needs to ask Bob more questions and understand his point of view, Alice also needs to understand why she doesn’t trust Bob to have good motivations, and how she could build that trust.

“Bob doesn’t communicate well”

Oftentimes Alice will complain that she suffers repeated misunderstandings with Bob. She thinks that Bob just doesn’t know how to communicate effectively. And Bob probably thinks the same thing about Alice. But often these “failures to communicate” are not actually about effectively transmitting information. Rather they indicate low trust between Bob and Alice. Like the trust required to ask “dumb” questions for more clarity. Or the trust to assume good intentions on the other side, so that if Alice doesn’t like Bob’s argument she can keep asking constructive questions until she gets to a fuller understanding.

Building trust between peers

The basic recipe for trust between peers is time and familiarity. The more that Alice and Bob get to know each other, about work and personally, the more they will naturally develop a level of trust. For co-workers sharing an office over a period of time this will likely happen naturally.

However, in a larger organization, or between peers that work remotely or don’t interact that often, there often won’t be easy chances for trust to develop. In this case leadership should be thinking about continual practice to increase trust:

  • Develop, communicate, and teach a strong set of core values. This gives everyone in the org a shared value system and something they will naturally have in common.
  • Train people for better communication: “Seek first to understand…”, “Assume good intentions”, “Play back what you hear”, etc…
  • Find ways to help people get to know each other personally - basic “team building” exercises.

These are great long term strategies, but when I find myself mediating a conflict that I trace back to a lack of trust, then I look to these tactics:

  • Ask Alice and Bob to meet face to face. Text-only comms (Slack battles, PR comment threads) are a breeding ground for mistrustful communication, which can often be fixed with a simple high-bandwidth meeting.
  • Mediate the meeting yourself.
  • Point out to the participants that you perceive a lack of trust. Ask why they don’t trust the intentions of the other side, and how can we work together.

Trust up and down the org

Team members earn trust upwards in the organization in mostly obvious ways: demonstrating committment to the company and its values, delivering on time, and “doing what it takes” rather than narrowly interpreting their responsibilities.

Another great skill is transparency - are you helping me understand what you are working on and how you are making decisions? Being transparent like this goes a long way toward making your manager’s life easier. I’ve had excellent engineers who worked for me, but their work was very opaque. They might promise to deliver a feature in two weeks, and I could count on that timely delivery. But along the way I would get minimal insight into the project. This isn’t the best way to build trust. I want to know enough detail to know if there’s a problem with the spec, or some particular technical challenge. It is a skill to learn how to broadcast those details at the right level of abstraction upwards in the org.

For leaders, earning trust with those reporting to you is all about transparency and collaboration in decision making. People don’t like to be suprised, and they like to have a voice in any decisions that affects them or their work. This doesn’t mean resorting to the holacracy, but it does mean explaining how and why a decision got made, and reading folks into the decision as early as possible.

One of the persistent challenges I still encounter is the trade-off between quick decision making and transparent decision making. Speed of decisions is one of the critical inputs into your overall velocity as an organization, but quick decisions may erode trust in the people affected. It’s critical to build up a high level of trust in the org that will enable you to make fast decisions.