Key takeaways
|
Many people work with people from different locations nowadays. And when the people you work with, are not in the same office, challenges occur. I’ve been studying these challenges for over 10 years now and in most situations, it comes down to 5 problems we all face.
What is a distributed team?
Before getting into to the 5 problems (and solutions), let’s first define what a distributed team is. I get this question a lot during my trainings. From my perspective, as soon as the people you closely collaborate with (let’s call that ‘your team’) are not sitting in the same office building, you’re distributed. Some even argue that a team with people on different floors in the same building is distributed. The simple drawing made by Johanna Rothman illustrated 4 variants:
In this article, I’m talking about all setups except a collocated team (although some of the challenges also pop up in that situation).
The top 5 problems...
Here’s what people struggle with:
1. We’re thinking ‘us’ versus’ them’
This is the killer problem. It’s underneath the surface, it grows day by day and nobody is aware. No matter what the setup is (customer-provider, all in one company), we humans tend to flock together. We become friends with the people in our office. So that’s ‘us’. And the people working far away, whom we don’t drink coffee with, are somehow strange. We don’t really know them because we have no chance to truly bond. So the people far away become ‘they’.
The problem here is that this mindset causes the collaboration to get worse over time. When things go wrong, the two ‘sides’ blame each other. People get frustrated about the other ‘side’ not behaving as they want them to.
2. Keeping the team in the dark
Even teams that have collaborated together for years, face challenges on knowledge transfer. In a lot of cases, the ‘development team’ is remote from the product owner or product manager. They’re far away from the users of the software they are creating. Sometimes they don’t even have affinity with the product they’re building.
The key person to enlighten the remote team is the product owner. He speaks to the users and understands everything about the product. And what often happens, is that he’s also the most busy guy in the whole company. He’s always out and has a challenge squeezing in the meetings needed to transfer knowledge.
I saw an interesting video last week of Henrik Kniberg where he explains the product owner role. In the end of the video, he recommends regular meetings of the PO, the team and the stakeholders:
The biggest challenge for distributed teams is to make this picture reality.
3. Culture is a mystery
When the people we collaborate with are from different cultures, things can get worse. We tend to attribute things that go wrong, miscommunications and delays, on cultural differences. We don’t understand how people from the other culture think and what drives their behavior. And if we don’t understand the people we need to perform with, it’s hard to collaborate and bring results.
4. We stop communicating
When a team is collocated, we talk. We meet at lunch, drink coffee together, hold regular meetings or we might even use a chat tool to talk to each other. But when the team is distributed, this doesn’t happen. Even the chat is often omitted. The problem is, a distributed team needs MORE communication, not LESS. The only way to overcome the challenges 1,2 and 3 is to align and communicate. So we need to find ways to have more talk-time and consciously seek out tools and ceremonies that facilitate communication.
5. The black box
The remote team members are far away and we don’t see what they’re doing or even who’s working on our projects. And in a way we don’t even want to. The remote team is a ‘black box’. We send in requirements and expect output.
When a team is collocated, we all know who’s working on our projects and how we’re doing the work. We regularly reflect on the process, on the way we work, on the practices we apply. But we assume that the remote part of our team figures that out by themselves.
What’s needed here is a more open and agile approach. The distributed team members need to be sees as ‘one team’. We need to understand how each person is contributing to the project or process, no matter where he/she is located. The black box needs to be opened up.
...and what to do about them
It’s easy to put the problems in a list of 5. Putting the solutions in such list is a lot harder. Every setup, company and situation is different. I sometimes have people coming to my trainings expecting ‘cures’. The only thing I can deliver is a set of ideas, some of which may apply to their situation. It’s about turning a button here, tweaking a bit there and adjusting step by step. Agile, iterative.
I’ve designed a canvas a few years back, which consists of the 8 building blocks of successful distributed teams. Each of these 8 blocks holds practices and techniques that combined, help solve the problems above.
To counter the above 5 problems, I’ll share some of the things I learned:
1. Culture & team spirit
Problems 1 and 2 are all about behavior, attitudes and beliefs. To change those, we need to consciously work on team spirit. And we need to address cultural differences, so we can organize around them. Here are some of the solutions that worked for me and others:
Culture canvas
A tool I designed to address cultural differences head on is the culture canvas. It looks like this (inspired by the empathy map)
On the bottom, you’ve got ‘perspectives’. These are ways to look at a cross-cultural collaboration. The perspectives are things I found to be crucial in any team. In the middle you’ve got ‘person from culture X’ (for example, I would be ‘person from the Netherlands’). Then we have the pains and gains I have in collaborating with a person from ‘culture Y’ (e.g. Romania). I will use sticky notes to indicate what gains I have from collaborating with my teammates from Romania (e.g. I find a lot of benefits in the creativity they bring to the project we’re working on). I’ll also indicate where it hurts (e.g. I find they are less proactive in sharing their ideas for improving our product).
And I will also fill what I hear from my colleagues (e.g. ‘we always have to micromanage), what I think & feel (e.g. I love working with people from Romania), and what I believe my teammates say & do (e.g. I find my teammates to be very open about their work-life balance). Then, the Romanian team mates will do the same in working with the Dutch.
In the end, we have an overview of cultural issues that we face from both sides. Then, as a team, we’d group the stickies and make a top 3-5. Once we know the issues, we can discuss ways to organize around them as a team.
There’s overlap with culture, but I always see ‘team spirit’ as a separate topic. It’s about how we operate as a team, what we value, what brings us together, what binds us.
From management 3.0, there’s a tool called ‘moving motivators’. This helps a team identify the values they find important. There’s a set of cards which the team can discuss and map out in order of importance. The outcome is a clear understanding of what behavior we as a team value.
Another important and often ignored ceremony is the retrospective. In a retrospective, the team looks back to the last x weeks of work from a helicopter. We identify issues we faced, things we could improve in our collaboration process, stuff we can improve about the project, etc. There’s different formats to run retrospectives. To get a deep insight, check out Ben Linders.
If you’re looking for a tool to streamline the retrospectives, try out Retrium. In this tool, team members can put their ideas into the software anonymously. During the session, the team goes through all the stickies and defines actions to be implemented in the next iteration. The power of the tool is that it stimulates people to share their ideas anonymously (which in turn helps bridge cultural gaps) and it helps to put actions into a framework so they get done.
Another interesting area to uncover as a team is the research done by google. Assess your team’s position of the 5 key traits of effective teams:
2. Knowledge transfer
The goal is to ensure all team members get equal access to crucial information about the product. This relates to ‘talk time’ to the product owner, feedback from users and detailed product information (roadmaps, documentation, vision). Obviously, an online wiki, when well organized, can do the trick. To add richness to such wiki, product videos can be recorded. The product owner could for example record talks he does with the users (and this can be done by asking a colleague to hold his mobile phone up and record!). It also helps to organize video conferencing talks with users of the software. Just invite a few users into the planning session and have the team prepare questions for them. The users can also share their experiences with the software.
These are just some simple ideas, but I believe the trick is to keep working on this. The problem is: a collocated team has way more interactions with users and product owners. With a distributed team, we need to plan for getting that information across. More planned meetings, active involvement of the PO in those meetings and creative thinking to get user feedback and product roadmap across.
3. Communication rhythm
How do you solve ‘communication problems’? By creating an oiled communication rhythm. Meet often and meet well. People don’t like ‘meetings’. Even if we do appreciate them, they become dull, mandatory exercises over time. But in distributed teams, they’re the lifeblood of alignment.
A few ideas to create the oil. If you want to minimize the meetings, skip all of them, except 2: the daily & the retrospective. The daily serves to create alignment + a chance to remove impediments. As a team, we need to move towards the set direction and the daily helps us to stay on track. The retrospective is our platform to improve the way we work continuously. It’s our opportunity to voice concerns about our project, our team, the way we collaborate. And it helps us improve step by step, becoming a stronger team with time.
To make sure those meetings go well, it’s useful to assign a ‘meeting facilitator’. Someone who can keep the talks on track and avoid lengthy monologues. It’s also a good idea to rotate this role, so each team member gets equal opportunity to lead the talks and voice his opinions. The meeting facilitator can also ensure that the agenda is followed (or he can set his own agenda, sent upfront to the participants).
While there’s a lot more you can do to counter the 5 problems, these 3 areas are a good start. They help work the problems from the ground up. By creating a positive team spirit and addressing the cultural differences, we avoid the trap of ‘us versus them’ and we create awareness about how each team member behaves given the cultural context. We also define actions to organize around the differences and benefit from the similarities. Implementing a structure or tool to share the knowledge about the product or project we’re building, helps team members understand what they’re working on. A communication rhythm creates alignment and avoids miscommunication. And retrospectives help open up the black box.
About the Author
Hugo Messer has been building and managing teams around the world for over 10 years. His passion is to enable people that are spread across cultures, geography and time zones to cooperate. Whether it’s offshoring or nearshoring, he knows what it takes to make a global collaboration work. He's the owner of Bridge Global, a global software powerhouse and ekipa.co, the education platform for distributed teams. Hugo has written 6 books about managing remote teams.