Trust in Distributed Teams
Remote Engineering is not as easy as it looks
I'm sure everybody would agree when I say how essential Trust is for modern teamwork. Building trust within and between teams is one of the most critical tasks of a leader. A trusted team, after all, enables its members to do their best work. Trust is equally important across teams — since most teams in today's world work collaboratively with other teams and are dependent upon their partner teams to achieve their goals.
Distributed teams have become par for the course in today's environment. I would be surprised if you could find a serious software company that has all of its engineering in one location given the costs and constraints of trying to find talent all in one location as you scale. Small teams either go all remote or end up starting a remote engineering office in India, Toronto, Eastern Europe, Austin - take your pick - very early in their lifecycle as compared to ten years ago.
However, one of the challenges I have observed is when teams have to collaborate with other teams which are not in the same office - it may be a remote engineering site - and the complexity of building trust suddenly increases manifold. While Covid has been the great democratizer when it comes to working remotely, there are still challenges of time zones, cultures, and languages. This is even harder when the teams don't have past experiences of working together, or it is perhaps a new site planned for future expansion. Very often teams don't work well together which manifests as missed deadlines, low quality, or poor velocity.
This begets the question - what is trust in this scenario, how do you detect these issues, and how do you help the teams to rise above them?
I usually break trust down into two areas: (1) I know what the other person can deliver and they will deliver what they promised, and (2) if I need something I won't be afraid to ask (and they will listen to my needs) - and vice versa. It's easy to stay on the same page if you have this basic understanding and trust with your coworkers. I'm sure issues with this are not hard to detect. You'd have a lot of people complaining. When you see two teams that have to collaborate but face missed deadlines, unexpected dependencies, and unresolved challenges that you as a leader have to step in and correct often and repeatedly - it's a clear sign that two teams are unable to find a good working relationship.
The reasons can be many - the quality of talent, work pressure, etc., but after solving for the obvious, the root cause oftentimes ends up being that people across these two regions have a transactional relationship and have not invested the time and mental bandwidth to build trust with each other. They are interacting purely over email, JIRA tickets, or code reviews (or insert your favorite tool) and fail to see the other side's context, constraints, challenges. This is anathema to modern collaborative software development.
At least in my experience, there have been two areas that need immediate focus. The first is that the teams need to build a strong relationship. They need goal alignment and frequent face time. I have found that ensuring leaders meet frequently and have mutual 1:1s helps a lot, but there's also a lot of value in getting the whole team in a single forum (like a periodic meeting) where people show up and realize that the others sitting at the other end of the world are also human, just like them but in a different geographical milieu, have ambitions and vulnerabilities, desires and challenges. Their kids go to school and they have torrid rains or biting snow today, and look forward to a beautiful sunny day tomorrow. This needs a lot more effort when teams are distributed. The journey to trust starts with this. That's the reason why a lot of companies do "fun offsites" - understanding your counterparts in a social setting builds a lot more trust and understanding and the next time you need something, you won't be afraid to ask.
The second is ensuring that there's strong person-to-person (or engineer-to-engineer in software teams) collaboration. I have found that breaking projects up between members located at the two sites where they have to interact frequently helps calibrate expectations and build a shared understanding of expectations, deliverables, quality, and attention to detail. It does come with a toll in terms of crazy hours - so it's definitely not recommended as a long-term option, but doing this for a couple of months really helps people gel together. When Sarah in the Bay Area HQ says, "Jake should be able to take care of this easily", Jake in London should be able to say "I got this" and Sarah should know exactly what Jake would do. This is harder than we think and needs both Sarah and Jake to invest time in understanding and calibrating each other. The whole team in HQ can rely on Sarah's understanding with Jake now to know exactly how the team in London is going to respond to their requests and everybody in London becomes a part of a trusted circle.
The next time you have to work with teams geographically distributed, I hope this helps. This is by no means an extensive treatise and I wanted to explore just one concept. For something a lot better thought through, read my friend Joydeep's far more detailed blog post.
Random Readings on the Interweb
Good documentation is so critical to building software these days, esp as a lot of software is targeted to developers. I found this to be a great framework to use and clarifies between Tutorials, How-to Guides, References, and Explanations.
Developer Experience is a new word that's catching on in recent years. What is it, and why should you care?
I enjoyed reading this article on whether managers are responsible "to" or "for" their people. It's a subtle difference but a world of learning between our understanding of how we support and empower our teams.
Google's legal victory over Oracle over the Java APIs has far-reaching consequences. I was looking for some more detailed explanation and ultimately found this article.
Coinbase is the big news this week. I’m still trying to come to terms with the fact that we can still not understand the upside potential of big winners. Math from 10 years ago (or even 5 years ago) doesn’t apply anymore.
Great Twitter discussion on "inheriting a hot mess". Lots of stories worth reading through.
Brandon Sanderson is one of my favorite writers and prolific is a very good adjective for him. Writers often get completely consumed by their work. See how he compartmentalizes his time to achieve work-life balance. Lots to learn for us as creative professionals.
A great example of a negative User Experience. Trump campaign made a decision to automatically sign up people for subscription donations (flipped the default) around June and see how their refunds soared. You bet that they collected more money but I wonder how it impacted voter trust in the campaign.
