Patterns to build trust and cohesion on distributed teams
Summary
Teams needn’t be groups of BFFs. Trust and cohesion are far more important attributes. You don’t build trust and cohesion by accident though. Leaders must employ attentive design and intentional actions.
Staff teams right by focussing on roles and skills. Make expectations clear using boring, but efficient job descriptions.
Use collaboration techniques such as pair programming to build work relationships.
Make information and work transparent so anything that anyone knows, everyone knows.
Adopt a remote-first mindset to building trust and relationships. Leverage 1:1s, IM channels, social calls, local outings and virtual events as ways to build working relationships.
Most importantly, if relationship building is important, fund it. Create time and find the budget for teams to engage in such activities.
Last week, I wrote about why it’s OK not to have best friends at work, regardless of how employers may promote such relationships. Today I want to nuance that argument. More than friendship, teams benefit from trust and cohesion.
“Trust is the most fundamental element of a winning team. If people think their teammates are lying, withholding information, or plotting to knife them, nothing valuable will get done.” - Geoff Colvin.
Colvin’s quote may resonate with most of us. Even if we don’t have close friends in our teams, there are a few things we must be able to trust about them.
They’re skilful and capable.
They share their knowledge without restraint.
We can count on them when it matters.
So in today’s post, I want to address what it takes to build trust and cohesion in a distributed team.
Form your team right
Work teams are professional teams. Professionals benefit from clear roles, clear measurement, and clear expectations. Here are a few questions to ask when you form your team.
How well have you defined each role? Do you have a clear job description in place?
How do people’s skills match the role they’re playing? If there’s a gap in skills and expectations, how will the team support such people’s growth?
How many people have overlapping responsibilities? How well do they understand, when and how they must work with each other? Where have you defined these expectations?
Who are the leaders of the team? How clearly does everyone understand their role? How do you ensure leaders are more supportive and less overbearing?
Forming a team right is an act of rigour. When you take a skills-focussed approach, much like a sports team does, everyone feels convinced of the other person’s value to the team. Sports teams will often have inexperienced team members, who others take under their wings. But this inexperience or relative incompetence must be explicit. Let me give you an example. Trust in work teams often suffers when people come with years of experience, but pretty awful skills. If these experienced individuals aren’t self-aware, then they don’t seek personal development or support from their colleagues. Their colleagues see them underperform and become resentful. After all, why should someone rake in the big bucks, if they can’t do their job well? Before you know it, there’s a wedge between different people in a team. Think skills first when staffing teams. Avoid taking shortcuts, where you staff people without writing a job description first. Be clear about skill gaps, regardless of experience.
Bond over work
Martin Fowler once told me that relationship building for professionals often works better by working together than with artificial team-building activities. I agree. No amount of team parties, trust falls and games can substitute for collaborative work. Teams that follow extreme programming, often pair with each other. There are many benefits to this, but I’ve also found this to be an excellent tool to build relationships. When you pair with someone on a task, there are many things you learn. For one, you learn about the level of skill someone brings to work. You also expose yourself to the other person’s perspective on solving certain problems. You teach each other while being in the flow of work. Few activities build more trust than this kind of deep, problem-solving activity.
I admit, pairing is a tiring exercise. Where there’s a difference in skill between two people, one person may feel like pairing slows them down. As my ex-colleague, Akshay Dewan has noted, pairing sometimes preempts the struggle that’s a natural part of learning. After all, if you’re working with someone more skilful, then you can lean on them to get a solution fast. Sometimes the problem is too straightforward to merit a pair-programming approach. All this said, if you can balance paired work with a mix of solo work, you’ll have a reliable way to build strong working relationships in a team.
Make information transparent
Anything that anyone knows, everyone must know. This is a fundamental premise for high-performing teams. If you build a team environment where knowledge and information live only in people’s heads, you’ll have a perfect storm of wicked problems.
Your team’s bus factor will become dangerously low. It’ll take one resignation, one illness, one accident, to slow you down, or worse; bring you to a halt.
People will often hoard knowledge, because of the associated power it brings. This’ll lead to information silos.
The more information silos you have, the less transparency there’ll be. The less transparency, the less trust. When you answer every other question with a shrug, it’s a terrible place to be in a team.
Turns out this is amongst the easiest problems to solve in a team, but it needs two executive decisions.
First, track everything you do, on a central task board everyone has access to. This helps answer the question of “What’s Sumeet up to?”. Your rigour around the task board should be so strong, that you should assume that if a task isn’t on the task board, it didn’t happen. As simple as that. Your task board should become your team’s nerve centre of activity.
Second, you must document everything you do. No exceptions. Maintain a team handbook that has everything a team member must know. If you don’t have a handbook already, organise a barn-raising activity to create it. From that point on, follow the DEEP mnemonic to document your work - decisions, events, explanations, proposals - you must document them all.
I’ve noticed that teams debate the tools they’ll use for their task board and handbook, till kingdom come. Some discussion is fine, but beyond a point, you’ll hit the law of diminishing returns. This is where decisive leadership comes into play. Don’t wait for consensus. Use Jira, Asana, Trello, Monday, Confluence, Notion, Google Sites or whatever’s the best combination of tools you have access to. That you use a tool matters more than which tool you use.
Be intentional about building relationships
When people wax eloquent about how easy it was to build relationships in the office, because it was like “magic”; I cringe. I cringe because that “magic” also led to cliques, favouritism and squeaky wheels getting the oils. I also cringe because you can’t run companies on “magic”. Even in fairy tales, the magic eventually fades. You want more enduring results.
High-performing distributed teams leave nothing to chance. Everything is intentional. So if building relationships is important, then that must be intentional too. Forget about what you did in an office. Think about new possibilities, instead of carrying the baggage of the past. Let me give you five ideas you can implement in your team at a very low cost.
I’m sure that curious, active minds will generate even better ideas to help teams be cohesive. The trick remains the same though. Think about your purpose first, and then experiment with a mechanism that can help you achieve that aim.
Put your money where your mouth is
It’s easy to talk about building team relationships. All that talk remains empty if you won’t fund this goal. Companies that are distributed by default, recognise that the costs they save on office space, shouldn’t just go back to the bottom line. Some of those savings should indeed go into helping teams function cohesively. You’ll notice that most remote-native companies organise regular retreats, at the team and company level. That’s an example of putting your money where your mouth is.
But it’s not enough to fund once-in-a-blue-moon events. You must build these costs into your operating model. The more you force teams to ask for approvals for every cost they incur when trying to organise team activities, the less teams will value such activities. Every bit of friction adds up. Give teams a reasonable sum of money as part of their quarterly budgets and give them the autonomy to spend it the way it makes sense for them.
New teams must get even more of such funds. It’s easier to get past the storming phase in a team if you can spend some time together. If you’ve assembled a brand new team, I strongly recommend flying them all into one location for a week or two. Use this time, not to deliver software, but to agree on ways of working, roles and responsibilities and team rhythms. Here are a few benefits of such an exercise.
When you set aside this time to focus on non-delivery activities such as ways of working, you elevate the importance of these activities in the team’s mind.
A team’s ways of working need agreement, if not consensus. Being together, in one place, when you can observe each other’s body language makes this agreement easier.
You’ll also notice that being in the same place will help you timebox this act of reaching an agreement. One week is plenty, even if you throw in long walks and extended lunches into the mix. You can do this online, but you may need to stagger the exercise over several weeks, depending on the trust levels in the team.
The short, co-located time you spend at the start, will help create the foundation of trust that the team can build on when they deliver software. Don’t think of it as a week of wasted productivity. It’s an investment in a healthy team.
And last, don’t expect people to work for 40 hours a week and also, build great work relationships. Let’s be honest when we make comparisons with the office. If people walked in at 9 am and left by 6 pm, did they work the full 8 hours a day? They spent a lot of time at the foosball table, in the cafeteria, by the coffee machine, chatting at their work tables or in the office corridors. It’d be conservative to say that people spent at least 5 hours each week socialising with each other; besides lunchtime. You can’t wish this away on distributed teams. Ask yourself, how you’ll create those few hours each week. Intentionality is key here.
Over the next few years, I believe two kinds of companies will emerge. Companies that are distributed by default and companies that are location-centric. The former will have significant advantages over the latter. They’ll have access to a wider pool of talent and they’d have mastered time-independent work. It’s also likely that they’ll have scaled their business through process rigour and transparent knowledge sharing.
As we collect data comparing these types of companies, I guess that location-independent firms may do much better than location-centric firms when fostering trust and cohesion. If that guess proves right, then I’d like to hazard another guess. The secret to success may well be attentive design and intentional actions.