Distribute my team, reinforce my company

A while ago, I wrote about distributed teams. A while ago, I had the privilege of working with all my team members in the same location. I think it’s time to share some learnings from my new company. I think it’s time to take on another perspective to distributed teams and maybe an even broader take on remote companies.

One thing Dominic didn’t tell you in our last blog post is that our teams works at a couple of different locations. There are four major offices and two minor sites with one and two developers. In the past, this was no problem. Every office had kind of their own projects and they could work along side by side without impacting one another. This independence brings some advantages, e.g. you can have team members sitting next to each other working easily together in agile frameworks such as Scrum. But in the long run it also creates some disadvantages that can eventually harm your company.

This one digital nomad nobody wants to have in their team. Photo by Humphrey Muleba on Unsplash

Let me introduce you to redundancy. Our teams built three different platforms over the last couple of years with roughly the same functionality and roughly the same tech stack. There is a desktop-oriented version, a mobile one, and even an app (which is becoming more and more hybrid, therefore aligning with the desktop/mobile stacks). Since it’s economically not too sound to have so much duplicate development for quite similar use cases, we decided to work towards a shared code base. Along with this strategy, it makes sense to shuffle the location-based teams, too. This will hurt in the beginning, especially since agile frameworks don’t work too well with distribution if not adjusted accordingly. But in the long run it will provide your company with the magic of asynchronicity. Information will get placed were people really need it. Not at the coffee table and not in between two meetings but rather within pull requests, issue tickets, or Confluence pages. This helps a lot to dive into projects quicker and to get relevant information more reliably.

Since information and — in its broader sense — knowledge is distributed more asynchronously, people become enabled to share what they know. This won’t work from day one but improve over time while team members get used to the new remote structures. Building a shared codebase might start with some fights and endless discussions about which way to go but might develop from a compromised mush to a timeless and stable architecture. Be aware that you might face some tough decisions not everyone will be happy about. But be also aware of people suddenly striving for perfection once they soak up knowledge unleashed by other team members. It’s a cultural thing and it should be all about giving and taking.

So imagine the situation to have finally started a shared project throughout all locations and to be on the verge of getting rid of knowledge silos. There is at least one more thing you must work on. Being creatures of habit, it will be a tough way for each team member to adjust to working with people from somewhere else. Even though our team members are warm-heartedly welcoming, there are differences in work mentality and in how to approach problems. There are people planning the details and there are other people building a couple of rapid prototypes until something productive emerges. They might run into one or another confrontation. And they will need help to cope with these new situations of clashing views. But it’s far from impossible to solve these problems.

Being in the middle of these challenges I can only provide tipps that are still a little hypothetical. But we’re working on getting more data and, as for now, it looks like most of our experiments might bear fruit.

1. Let your team create a team manifesto. Let them write down what they think shared values and common ground are. Make it public. Have them provide feedback. Make it an iterative process, maybe work with pull requests to add, edit, or remove content.
2. Create transparency and explicitness where ever possible. Make visible which team member has which role and what to expect from whom. Create a single source of truth for information and make team members aware of contributing to everything.
3. Alles kann, nix muss. Provide formats for every team member to contribute to the whole organization. But don’t force them to. Let them decide whether to only work in the team or also work on the team. But welcome them, whenever they need to process a tension.
4. Meet in real life. Even though you might work with people hundreds of miles away, it’s important to have the team meet in real life at least once or twice a year. Maybe a hackathon, maybe some team building, or even just a staff party.
5. Don’t be dogmatic. It’s always fun to wave the Scrum guide and shout “I told you so!” when things go wrong. But be aware that remote teams need different tools and that some tools are beyond what agile teaches us.

There might be other tools I will use in the future. But right now these are the things I try to collect data from. I think the team has a long way to go but we’re making the first steps in the right direction. It’s not a question of being agile enough. It’s a question of being brave enough to take a couple of steps further and pioneer in this new way of working together.