👋 Hi there! This article is a response to some comments and critiques on a previous article - I'm Changing How I Review Code. These comments and critiques raised some great questions that I've spent some time thinking about. I hope I've put together a reasonable and seasoned response and one that inspires software teams to think and work together! Lets dive in.
Trust is a complicated topic.
Some might disagree with that. They might say trust is simple: you trust someone, or you don't. Others might think trust is impossible to attain - it's an ideal, not a real thing.
Regardless of what others might think, research has found that trust is vital to a team's success. However, it can be hard to pinpoint what trust is. One of those "you'll know it when you see it" situations. It requires intuition rather than computation.
This leads to confusion about what trust means on teams (especially on software engineering teams where computation is what we do). Trust isn't thinking a teammate will never make a mistake. Instead, it's the assumption of good intent and effort. Trust is about knowing that you are safe to do your best work within your team, that you can depend on one another, and everyone else feels the same way.
Let's dig into this a little bit.
Trust Is Important
Before going further, let's go back to why we need to talk about trust.
In their famous re:work-study, Google found that high-performing teams had a handful of traits in common - and they had nothing to do with individual performers or ability. Instead, they found that other factors about how the team operated were more critical. The top two factors were psychological safety (do team members feel safe to take risks without feeling insecure or embarrassed?) and dependability (are team members delivering high-quality work on time?).
When taken together, these two items form what I think of as trust. If I feel safe on a team and know that I can depend on them, I can trust their intentions and efforts. This makes it easier to focus on my work without worrying about if others are doing theirs. I can feel confident when collaborating with them as I am sure they aren't trying to embarrass me.
Trust on a software team is especially pronounced. We all know the stories of senior engineers that act like dictators towards their team. Instead of collaborating, they force a specific pattern or design. Instead of delegating complicated coding tasks, they don't allow anyone to touch the code but themselves. In my experience, these teams tend to deliver low-quality work behind schedule.
On the other hand, software teams with high trust seem to deliver higher-quality work faster. Why? I have some thoughts...
Why Does Trust Work?
You might have noticed, we've been talking a lot about intention rather than the outcome. Here is why.
If I were asked to trust that my teammate wrote perfect code, I would decline. Why? Because humans are fallible. We make mistakes. I simply can't trust that any teammate will write perfect code with perfect tests (I don't trust myself in this regard either).
But what if I did say I trusted my team completely? What would happen if I genuinely thought that they never made mistakes? That they never fat-fingered an Ansible playbook? That they never confused requirements?
In that case, most of what we have in our modern software development lifecycle would be waste. If we trust and then expect our teams to be perfect, the rigor of our modern software processes just gets in the way. Code it, ship it, move on to the next thing.
We, of course, know that this isn't true! The best software teams are ones that, in a sense, expect themselves to make mistakes. They know no one is perfect. That is why they automate tests, automate deployments with smoke checks, and inspect each other's code routinely.
Now let's go back to that initial question and change it a bit. If I were asked to trust that my teammates have put their best effort forward, I would say absolutely. Imperfect code written by an imperfect person can still be trusted in the sense that it changes how I approach them, their code, and even reviewing it.
If trust is about our teammate's intentions, it opens up a lot of possibilities. We can approach our teammates with humility but with a keen eye for problems or bugs. We can be collaborative since neither of us is perfect.
How To Create Trust?
The obvious question then is this: how do we create trust in our teams? If it is so important, what steps does our team need to take the build it?
Sadly, there is no magic checklist for building trust in a team. It requires a whole range of disciplines and tools.
There are two, however, that I have found to be particularly helpful: humility and willingness.
When we are humble about our abilities (knowing that we can always get better; being open to others' opinions), we are easier to work with than if we were arrogant. We are likely to learn and improve our own skills faster since we know we can always have more to learn.
When also need to be willing. We need to be willing to listen first, extend the benefit of the doubt. We need to be willing to try others' ideas. When we are willing rather than willful (trying to control how every little thing happens), we earn the trust of others by showing them we are more concerned about solving problems together rather than doing things on our own.
Trust Can Be Lost
Trust is also not fixed. You don't create trust one time with a teammate and never have to think about it again. Just like software, property, and physical health, trust needs to be maintained.
This is important because it shapes how we work as a team. You can't create trust with a teammate, start treating them like a jerk and expect them to trust you. You can't continue to be wrong over and over on a technical fact and expect the team to "take your word for it." We have to keep investing time and energy into maintaining trust in our teams.
Aim to build trust with every interaction you have amongst your team. Bring humility and willingness to code reviews, team planning meetings, and even as you have one-on-one interactions. After some time, your intentionality will have a huge impact on how your team trusts you.
In summary, we need to trust each other on a team. High trust also doesn't mean we accept each other's work as-is without additional thought or inspection. In fact, it allows us to continually improve upon each other's work because we trust their intentions and effort vs. expecting code to be perfect.
Happy coding!
Originally posted on dangoslen.me
Cover Photo by Sandra Grünewald on Unsplash
Top comments (0)