Guiding principles for a thriving remote team
The one thing that gets me out of bed in the morning is a chance to help those around me to accomplish great things. So when I found myself in a struggling remote team I couldn’t resist the opportunity to make improvements. This article outlines the principles that guided me along the way.
Backstory
Along with about 5000 other employees, I work for a global enterprise software company. Although the majority of employees is based in one of many offices, I’ve been working remotely from my home office for the past three years.
The opportunity to lead a remote team arose when, about a year ago, my department was going through major changes and team reshuffling. For the first time in the department’s history, a fully remote team had been established.
Our department consists of 50 or so employees that have always been colocated in a single office. Now I found myself in the first remote team next to four other developers, all of us equally far away from the office. All product managers, designers, analysts and pretty much every other role was seperated from us by a time zone difference of eight hours.
You might say that we weren’t quite set up for success, but honestly I think we did pretty well overall. In our first year, we went through some up and downs together. Although we had to cope with an overwhelming amount of change (new managers, new team members, new priorities), we still completed a fair amount of projects.
Perhaps it is now time to shine some light on my role in in the remote team. Although I have never been the team’s official manager, I’ve often found myself acting as their leader. I think this was a result of being the team’s biggest fan, acting as glue between the individuals and helping those around me to succeed.
To me this last year has been a whirlwind of emotions. By assuming the best of everyone, by staying curious and humble, and by devouring related books like a madman I’ve learned a lot about teamwork.
This article is my attempt to distill what I’ve learned into five guiding principles:
- Form strong relationships
- Leverage high-bandwidth, low-latency communication
- Strive for autonomy
- Keep looking for better ways of working
- Practice whole systems thinking
1. Form strong relationships
Because of our department’s distributed nature, a good amount of collaboration takes place in writing. Typical examples are chat messages, pull request reviews and decision pages. All of these work nicely across time zones, but they also all share one problem: a lot of context is lost when communicating exclusively via text.
Have you ever woken up to a wall of messages that left you upset? Have you ever tried to convey urgency in a pull request, only to one day later find out that no one even looked at it? Or perhaps you have left a few questions on a decision page that triggered an angry response?
I would argue that these are all caused by a lack of context. In the overwhelming majority of those cases your colleagues don’t actually mean any harm. It’s just that text leaves a lot of room for assumptions.
The kind of assumptions we make depends a lot on the quality of the relationship: If you and I had a great working relationship, we’d automatically be assuming only the very best. If you and I were total strangers, we’d probably give each other the benefit of the doubt. If, however, you and I had a bad working relationship, we’d probably fill the gaps in understanding with the most negative thoughts. Those thoughts and assumptions can have a huge impact on how we interact with each other. So they better be positive.
While of course it is possible to train yourself to overcome all of these negative assumptions, it requires plenty of practice and effort to do so. A better approach is therefore to focus on forming strong working relationships right from the start.
I like to compare the quality of my relationship to a bank account. If you make many deposits over time, your investments into the relationship will start to pay dividends. There’s many ways to make deposits. For example, you could spend time together, talk about non-work-related topics or be vulnerable. You could learn something new together. Even if you’re part of a distributed team, you can arrange for these kinds of conversations.
The one thing not to do is to sacrifice your relationship by withdrawing too much from it at once. Don’t destroy everything you’ve build up over time for the sake of the current project or piece of work. People are more important than projects.
2. Leverage high-bandwidth, low-latency communication
Imagine for a second how there’s a piece of code you really want to get rolled out today. As you raise a pull request, a slow trickle of feedback in the form of comments rolls in. You resolve some of the feedback immediately, but other feedback triggers a lot of forth and back. When you realize that your pull request has a hundred comments on it already, it dawns on you that there’s no chance to get it merged anytime soon.
Now imagine the same situation in a distributed team. Hours of waiting become days of waiting as your colleages in a different time zone end their day when you start yours.
To mitigate against this problem you might decide to “overcommunicate”, to put as much information into every comment you’re making. As you don’t exactly know what sort of questions your readers might have, you have to guess which pieces require more detail and which ones don’t. Wouldn’t it be a pity if your message is not understood just because you forgot to explain this one little detail? As a result, the time you spend writing your message increases significantly. But not only that. The time your readers need to spend goes up too. If you sum up the amount of time everyone spent on this process, you will discover a lot of waste. So maybe “overcommunication” is not the answer then. But what could be?
Thinking of text as a low-bandwidth, high-latency medium can help to find a better approach. Why not switch to a high-bandwidth, low-latency medium instead? Even a distributed team can minimize their usage of text with a stable internet connection, a video conferencing app and techniques like mob programming.
If your team’s time zones don’t overlap that much it’s crucial to make the most out of the overlap you have got. Don’t waste this valueable time reading emails or coding on your own. There’ll be enough time for those activities once your colleagues have gone to bed.
There’s nothing wrong with using text-based collaboration tools of course. Just make sure that it doesn’t become your primary form of communication.
3. Strive for autonomy
At the beginning, when our remote team had just formed, no piece of customer value could be delivered without us waiting at least a day for our colleagues in the other time zone. We found ourselves working a little bit on some project, then getting stuck, then switching to some other project. As a consequence, it took a long time for anything to get done, even if it was just a trivial amount of work.
This experience convinced me that an effective remote team needs to be autonomous. Only then can it deliver customer quickly and frequently. Otherwise the team will mostly be waiting for input from the rest of the department.
However, autonomy without alignment will lead to chaos. Imagine what could happen if teams work towards opposing goals or perform uncoordinated database migrations. To prevent this sort of things from happening, you need to teach every member of your team about the business strategy, about technical standards and about the company’s values. Only then can they make the right decisions on a day-by-day basis. Instead of telling your team what to do, you need to focus on showing them why something must be done. Then leave it up to them to make it happen.
This brings me directly to my next point. Don’t just put a group of developers into that team. Mix in a product manager, an analyst, a QA engineer, a designer, a content writer or whatever skill is required to make the team successful. Only with a diverse set of skills the team can take control of the full process from inception to delivery.
With a diverse set of skills in place you also want to make sure that the remote team can release the results of their work on their own. Your architecture and processes should make this possible. With that freedom, however, comes responsibility too. When things go wrong, the team must always act as the first responder. Don’t duck out of the on call rotation.
4. Keep looking for better ways of working
One thing was clear right from the start: we could no longer stick to the same ways of working. Being both in a different location and time zone brought a new set of challenges. So we began looking for better ways.
We knew that we couldn’t just pick a standard methodology off the shelf and expect it to be succesful. Instead, we decided to adopt a process of running a few small experiments, evaluating the results and keeping what worked. We decided to dedicate a few hours of time for this process every second week.
There’s just one problem: not everyone likes change. It takes a while before we adopt to it. Introduce too much change at once and all progress will grind to a halt. There’s a limit to the amount of change one can cope with. Furthermore, I found that people really dislike any kind of change being imposed on them.
Keeping this in mind, we decided to introduce a Kanban board to manage our experiments. Everyone on the team could propose an experiment, create a virtual index card for it and place it in a column titled “things to try”. The team would then vote for the experiments they liked most, pick no more than two experiments and place them in the “in proces” column. After a few weeks, experiments got moved into “things to keep doing” or “things to stop doing”.
This process helped us to uncover better ways of working and it gave everyone a right to participate in the decision making. Over times many of those small changes added up to something larger. These days I consider this process to be critical for our success.
5. Practice whole systems thinking
If you’re commited to uncovering better ways of working,at some point you’ll realize that most of the issues you’ll encounter are only symptoms. Addressing the root cause requires an understanding of the big picture and context around you.
A good way to start is to ask high-level questions: How do decisions get made? What is the business trying to accomplish? How much time does it take to go from project inception to value delivery?
You might also visualise the way work flows through the system, track down dependencies and lift constraints.
A lot can be learned by taking the time to talk to your colleagues in different teams and departments. What problems are they facing? Is there a way you can help each other?
For a while you can make improvements in your team only, but at some point there’s no way around it: you have to address the root cause.
Conclusion
Form strong relationships and leverage high-bandwidth, low-latency communication. Help your team to strive for autonomy and keep looking for better ways of working, all the while practicing whole systems thinking.
It’s these five principles mixed with a team of outstanding individuals that led to our success. They might or might not apply to your team, but they helped us to create an environment where everyone could excel. Although they originate from our team’s unique situation of being the first remote team in an otherwise colocated department, they might be of use to you to. I certainly hope so.
References
The following books have shaped my thinking on the topic (if you know more books that I should read please send your recommendations to me):
- “Who moved my cheese?” by Dr Spencer Johnson
- “7 Rules for Positive, Productive Change: Micro Shifts, Macro Results” by Esther Derby
- “The Phoenix Project” by Gene Kim, Kevin Behr, and George Spafford
- “Team Topologies” by Matthew Skelton and Manuel Pais
- “Agile Software Development: The Cooperative Game” by Alistair Cockburn
- “Drive, The Surprising Truth About What Motivates Us” by Daniel H. Pink
- “Project Retrospectives” by Norman L. Kerth