Operating a distributed software development team is like investing in stocks: It can give huge rewards, but also carries risks. Here are 10 lessons to increase the chance for high returns.
“Bangkok or Krakow? That´s the question!”
It was the summer of 2011. Our manager in Schibsted Norway Digital, a joint development unit for four subscription newspapers in Norway, had just announced plans to set up a tech hub outside Norway.
The software developers in Oslo stared at him in disbelief. How could programmers in Bangkok or Krakow possibly understand all the intricacies of creating products for traditional media houses in Norway?
Fast-track almost seven years until today: In Schibsted Tech Polska more than 150 software developers in Krakow and Gdansk work closely together with colleagues in Norway, Sweden, London and Barcelona to create innovative products for more than 20 companies, units and departments in the global Schibsted Media Group.
The nearshoring center and tech-hub has grown far beyond the initial plans.
Not without risk
Has it all been a success? Of course not! Some teams have failed massively and others have delivered mediocre results. Yet, most of the teams have excelled and surprised their Scandinavian colleagues with the superb quality of their work.
The reason for the mixed results is obvious. Operating a successful distributed team, where some colleagues are in Poland and some in another country, is not without risks. Many things can go wrong: Lack of communication, different expectations, cultural misunderstandings, professional disagreement, wrong organizational set-up, the remote members feeling left out, etc.
But as for investments: With risk comes also the potential for much higher rewards. A successful distributed team can deliver results and quality that goes beyond what a purely local team can achieve. Why is this? Because a distributed team across cultures by default will usually be more diverse than a single-location team. And diversity in itself leads to higher team results. The potential is especially high if the different parts of the team succeed in making each other better.
What we have learned
Being part of building Schibsted Tech Polska from 0 to 170 employees has been an amazing journey. I have not counted, but probably I have worked with close to 50 different distributed software development teams so far. Their partner companies, mostly in Scandinavia, have included as diverse businesses as media houses, e-commerce startups, marketplaces sites, infrastructure providers and food sites.
Let me add a disclaimer right away: I am not a software developer. Neither have I been part of the daily operations of any of the teams. My role has been as a facilitator when we start working with a new partner company and later, as one of the managers in the company, to ensure the best possible conditions for a smooth cooperation between our Polish and (mostly) Scandinavian colleagues. I have also done numerous surveys to identify what works well and not so well in the teams.
But having been a close observer of all these distributed software developer teams over the years, I have tried to reflect on what makes some of them succeed and other fail.
10 lessons for success
This article includes 10 important lessons. It is basically my blueprint for what you must take care of to ensure that your distributed team succeed.
But first: What do we mean by a distributed software development team?
In this context, we think of a software development team where the members work from two or more physical locations.
In Schibsted Tech Polska the typical team has from 3 – 8 software engineers in Krakow or Gdansk. This team works closely with a team of colleagues in Norway or Sweden.
The set-up can vary from team to team:
- Sometimes all the software engineers are in Poland, while the product owner and maybe a tech lead or UX designer are located in Scandinavia.
- Other times the bulk of the team members, be it software engineers or product people, are located in Scandinavia, and with 2-3 engineers in Poland to support them.
- We also have some teams that are fully distributed, sometimes even over 3-4 locations – and where tasks are delegated with no or little regard to who is located where.
Is there a golden model? We thought so in the beginning and eagerly tried to identify best-practice. Later we realised that several models can succeed. But there are certain principles you should follow.
Therefore my 10 lessons:
Lesson 1: Be ONE team!
This is, in my experience, the most crucial advice! A successful distributed team must be set up and run in such a way that all members feel they are in the same team, no matter where they are located.
Obvious, you say? No, it is not! In many near- or offshoring operations there is a strong and mutual tendency to think of each other in terms of “client” and “service provider”. That leads to a “we” and “they” way of thinking, and ultimately the sense that there is an “A team” and a “B team”.
Of course, distributed teams often are a mix of people from companies that define themselves as “client” or “service provider”. Yet, for the team itself to work well, it is crucial that the members look at each other as equal participants in the project.
The words we use do matter! To achieve a good team identity, it is better to talk about each other as “colleagues” rather than “clients”. The word “colleague” signals a peer relation, a feeling of “we are in this together”. And one should talk about one team, not the “Norway team” and the “Poland team”.
Being one team also means that all members have access to the same information and have the same opportunity to influence the project.
One of the biggest risks in a distributed team is that some of the members feel left out. It is crucial to avoid this. Rule number 1 is to consistently treat everyone as part of ONE team.
Lesson 2: Balance the team!
It is crucial that all parts of a distributed team have a fair chance to succeed. You achieve this better if you make sure there is a certain balance between the different geographical parts of the team in terms of competence, number of people and level of responsibility.
An example:
One of our teams was working with a software development company in Scandinavia. The partner company already had around 20 software developers at home, but needed extra power. After having visited us in Poland, they decided to try it out.
“But we want to start small and see how it works out,” their manager said.
Eventually, we hired two software engineers for them, both highly skilled and very motivated to do great work.
After a little more than a year, the company decided to close down the team. The manager said they had not been able to utilize their Polish engineers fully and that it was better to concentrate all software development at their main office in Scandinavia.
We analyzed what went wrong. Our conclusion: The team never had a fair chance to succeed! It was just too small compared to the many colleagues in Scandinavia. As a result, the team lost out on much information and were sometimes forgotten when decisions were made. It was also hard for them to make their voice heard.
The “let´s start small and see how it works” attitude essentially became its own enemy.
After this experience we started warning potential partners against setting up teams of only 2-3 people in Poland. A better approach, we said, is to recruit at least 4-5 engineers. In that case the team has a much fairer chance to stand up and excel. They will more easily make their voices heard and will be counted on to a larger extent.
There is no “one size fits all”, though, and we still have a few two-person teams. But so small teams usually work best if the Scandinavian part is also small, or if the small team owns a core part of the project, for instance all the native mobile development.
Therefore: Make sure that each location in a distributed team matters – and that the different parts of the team are truly dependent on each other.
This goes both ways, of course! One of our most stable and successful teams is Stream, which has developed the platform web-TV runs on in Schibsted´s media houses in Scandinavia (see for example VGTV) . This team has only two members in Norway (the product manager and a UX designer) and six software engineers in Krakow. But because the division of responsibilities is so clear and there is a strong inter-dependency, it works well with only two team members in Oslo.
Lesson 3: Trust the remote part of your team!
Companies setting up remote software development teams in Poland often struggle with what tasks to start with.
Typically there are two approaches:
- Some companies think the best strategy is to start with smaller and not so important tasks, for instance maintenance, and then move on to bigger projects if the team performs well.
- Other companies decide that it is better to give the team a big and important project right away.
In my experience the latter approach has a much higher chance of success. In Schibsted Tech Polska we have seen that the teams that are given the highest responsibilities consistently are more stable and perform better. Polish software developers are very ambitious and highly skilled – and will usually go the extra mile to ensure that a project is a success if given the chance.
On the other hand: Teams that are not trusted enough to be part of the important projects will soon experience lack of motivation. Especially we have learned that this is crucial in Poland. The team members start worrying about the future roadmap of the team – and soon they might consider resigning.
This learning is in line with lesson 1 and lesson 2: Mutual trust is crucial for distributed teams to work well.
When given explicit trust and responsibilities, most people, not only software engineers, will perform better. Lack of trust, on the other hand, is a recipe for failure.
Lesson 4: Have a strong product owner!
One role is more important than any other in making a distributed team succeed: The product owner.
The product owner is responsible for defining WHAT should be developed and WHY. This includes laying out a credible and inspiring roadmap for the next months. A good roadmap is important in a Polish context, where employees might actually decide to resign if they do not see clear and interesting plans for the next months.
One particular challenge in a distributed team is that not all team members will have the same understanding of the market the product will operate in. Let us use as an example a Norwegian-Polish team that is asked to develop a news application for Norwegian consumers. Living in the target market, the Norwegian software engineers obviously will more easily understand the customer needs than their Polish colleagues.
Enter the product owner! He/she has a crucial role in making sure the whole team understands the business goals, customer needs and what it is actually trying to achieve.
The product owner role must not be underestimated. A weak product owner, or a product owner that does not have sufficient time to focus on the project, is a prescription for failure. Similarly is a product owner that does not match the experience and competence level of the software developers.
A strong product owner, on the other hand, is the glue between the different parts of the team. He/she sets the vision, makes sure everyone understands what are the business needs and helps the team focus on the core tasks without being dragged into endless and irrelevant discussions.
Lesson 5: Hire people fit for a distributed team!
There are many reasons for this. As already mentioned, distributed teams usually introduces more diversity, which in itself increases a team´s performance. To put it shortly, we both work harder and are more creative when we are around people who are different from us. This relates to both gender, age, cultural, political and religious background.
But not all software engineers are fit to work in a distributed team, no matter how competent they are in programming. How the team is composed, is one of the most important factors in creating success. Only hiring developers based on their technical skills is therefore taking a huge risk. You must also find the people who are suited to the special environment of working with distant colleagues.
What should you look for, assuming the candidates have checked out on their technical software engineering competence?
- The candidates must be have higher-than-average communication skills. They need the confidence to honestly offer their opinions and the ability to communicate clearly when working together with colleagues from other cultures.
- This includes emotional intelligence – and sensitivity to people of other cultures and backgrounds.
- They must be true team members, who love creating results together with others and see it as a natural part of their job to make their colleagues better.
- You should look for people who are eager to share knowledge. This can be through blogging, be a mentor, contribute to open-source, run workshops, etc. Why? Because professionals who share their knowledge also tend to be better at what they do. But even more importantly: It is a strong indication they also like to help their colleagues excel!
- A member of a distributed team must also be flexible. There will often be more surprises in such a team and unexpected turn of events or situations.
Hiring people with the right social skills and personalities is important in any team, but even more so in a distributed team. You need people who love being challenged by their colleagues and who take pride in making diversity work to the benefit of the team.
Lesson 6: Notice the cultural differences!
Our cultural background influences how we behave in a distributed team and what we expect from each other.
It is easy to think that cultural differences do not matter in the modern multicultural world. That is wrong. But sometimes it takes time before the differences become apparent in the team dynamics.
In several internal surveys we found that the longer people had worked together, the more they reported that there were misunderstandings due to cultural differences.
Would you like to quickly compare the work cultures between two countries? Here is an excellent tool that lets you do just that.l It is based on one of the most comprehensive studies of how values in the workplace are affected by culture. The study was done by the Dutch professor Gert Hofstede.
There are some interesting differences between the Polish and the Scandinavian work cultures that can easily influence how the team works together. The biggest difference is in what Hofstede call masculine versus feminine cultures. In his study, Poland is one of the most masculine work cultures in the world, while Scandinavian cultures are considered the most feminine. There are also significant differences in how hierarchical the cultures are and how well we accept uncertainty.
These differences easily influence how a remote team works together. Of course, there is no “right” or “wrong” in cultural traits. But it is important to be aware of the differences and to try to make them work for the benefit of the team. The best approach is to be open about the differences and adapt practices accordingly. And do not hesitate to study this topic right away as you start with a cross-cultural team!
Lesson 7: Have great kick-offs!
So you are about to start a new project. The team is in place, half of them in Norway and the other half in Poland. They are all highly skilled, but do not know each other beyond some video meetings.
What to do?
Organize an amazing kick-off! Bring the whole team physically together for a few days. Spend this time to make sure everyone is on the same page.
A successful kick-off could include the following:
- Walk-through all the business goals of the project and what the team is expected to achieve.
- Have the team members tell back what they perceive to be the goals. This ensures that all have the same understanding.
- Run mini-workshops to gather initial input from the team members. Make sure that input from everyone is collected.
- Work on the values of the team and how you best shall work together in daily life.
- Do team-building activities to give the members a better chance to get to know each other personally. Choose activities that forces the members to interact, for instance a fishing trip, cooking together, hike in the mountains, etc.
- Throw a kick-off party with food and drinks.
A kick-off is a great way to jump-start the team-building process. It is not free, of course, but letting the team members get to know each other personally is an investment that will pay off quickly. Do it early, before bad habits have time to settle.
But a kick-off alone is not enough. It is very beneficial if the team continues to meet regularly in one way or another. My advice is to gather the whole team physically in the same place at least once per quarter.
Even with the most modern communication tools: Nothing replaces meeting face-to-face. Therefore: Giving the team members the opportunity to get to know each other well is a smart investment that ensures better cooperation, communication, innovation and efficiency.
Lesson 8: Set joint objectives!
A distributed team will only succeed if all members work towards the same goals. The goals should be clear and transparent, leaving no room for misunderstanding.
In Schibsted, many development teams use Objectives and Key Results (OKR) as the framework to plan their work together.
Each quarter the team identifies 4-6 objectives for the next three months. For each objective some measurable key results are set to indicate if the objectives are reached. The objectives and key results are open for everyone to see.
Individual team members may then set their personal OKRs for how they will contribute to reaching the team objectives.
OKRs is one of many possible frameworks. We have found it to be a very useful tool.
However, the most important is not which tool you use, but that:
- The team has common goals
- The process is fully transparent and all team members know what are the goals
Lesson 9: Communicate! Communicate! And then communicate again!
Several of these lessons boil down to this: Communicate!
One of the biggest risks with distributed teams is lack of communication. This easily leads to misunderstandings and poor team performance.
From our experience, we see that the best teams have frequent video stand-ups, use Slack continuously throughout the day and have agreed on a set of rules for how they will communicate and work together.
It is extremely important to send clear messages and repeat important information to ensure all team members have the same understanding.
Pay particular attention to the roles in the team. You need to make sure they are clearly defined and communicated. Be aware that expectations may be influenced by cultural background. For instance, the Scandinavian work culture tends to be less hierarchical than the Polish. As a result of this, work roles are often less clearly defined than in Poland, a fact that can lead to misunderstanding and frustration.
For a long time, we did internal surveys after each project. Colleagues in both Scandinavia and Poland took part in the surveys. One standard question was: Who did you perceive had the role as product owner in this project?
One would think all the team members would know who was the product owner, right? But we quickly discovered it was not always so. In fact, in one of the teams, the members named no less than five different persons in Sweden as the product owner.
Needless to say, the team satisfaction after this project was very low. The team members were frustrated and de-motivated and felt they wasted energy on chaos.
It was purely caused by poor communication,.
You simply cannot communicate enough in a distributed software team!
Lesson 10: Use modern tools to collaborate!
During the last years, numerous new online collaboration tools have emerged, enabling teams to work together smoothly.
Use them!
However, good processes and communication is much more important than your technical tools. Focusing only on the tools and not the human interactions and processes, is like trying to fix a sports team´s performance by spending more money on equipment.
But you need them. The tools enable all your good processes – and make it easier for the team members to do their daily work together.
In Schibsted Tech Polska we use a large number of different tools to collaborate with our Scandinavian colleagues. Some of the most important are:
- Video conference systems from Cisco in most of the meeting rooms.
- A number of other online video conference services, such as appear.in, Bluejeans and Google Hangouts.
- Slack for chatting about issues and projects
- Google for sharing documents and calendars
- Jira or similar tools for planning developer sprints
In addition, many teams use more specialized tools for specific needs, such as project management, sharing design proposals, etc.
Study: Why teams fail
There have been done many studies on why some distributed teams succeed and other fail. One of the most interesting was done by professor Karen Sobel Lojeski. As an organizational behaviorist, she introduced the concept of Virtual Distance. And she documented that high virtual distance caused both performance, innovation, team satisfaction and trust to drop dramatically.
In her model virtual distance is composed of three factors:
- Physical distance: How far is the team from each other geographically and organizationally
- Operational distance: Size of the team, how often it meets and how skills are distributed
- Affinity distance: How the team shares values, communication styles and values of work
A successful distributed team must work hard to minimize all these three distances. I hope that my 10 lessons give you some hints about what to do.
More to read about this topic
Here is a selection of interesting articles about how to make distributed teams work best:
- How to collaborate effectively if your team is remote
- How diversity makes us smarter
- When Teams Fail: The Virtual Distance Challenge