Managing distributed teams. The future is now, old man!

You wake up in your bed, make some coffee, grab your stuff and go to your office. You spend all day in a single working space with your entire team. You convince your boss to work remotely on Friday, but they always regret having allowed it. If you are really lucky, you can get a day or two a week at home.

That’s how it used to be. But today, in the new post-COVID normal, working remotely is no longer a distant dream. It’s a norm you often have no choice but to follow.

The New Normal – end of an optional distributed team

Maybe you can go to your office if your company still rents it but… “where team”? They work remotely, wherever, and whenever they want. One of your teammates moved to Asia to live on an island far away. Another one starts his work at 1 PM, because he needs to take care of his kids.

You have to change everything in terms of managing tasks. The Daily Scrum can no longer be done in a one-room office environment, sharing one JIRA board on a big plasma TV and speaking face to face. You can’t even count on all of your distributed employees being available at the same time. All of that means that you have to urgently learn more about project management for a distributed team. That’s because a distributed company needs a different kind of project management.

Introducing a client to the distributed team

Coaching your client is a fundamental part. Different time zones provide you (at best) just a few hours of common time. 

You have to make your client aware of some limitations that you need to overcome together. Start by defining what a distributed team is in the context of your cooperation. Show your business partner that you have the same goal and all of your ideas on adjusting to the current situation are for the purpose of successful project delivery.

It’s vital to know that this is never a single action. It is continuous work. You have to inspect and adapt it within the process, or it may become obsolete and useless. Search for improvements, ask people about their points of view and last but not least – try! 

Familiarize all of your stakeholders with this approach.

My dear friend, before you start…

Successful remote cooperation requires your attention from the very start, even before the project actually begins.

Party time!

I will not lie to you – I absolutely hate working remotely, but it is what it is. Typically, I can’t talk to anyone during my work. Based on my experience, the most efficient Agile teams were built when they had an occasion to at least lay the foundation for a good relationship between them. One of the best methods to do that is simply to organize a party – nothing better brings people together than some good food, drinks and music or whatever else that you like. 

Anyway, if you have the opportunity to organize a get-together for everyone before a project starts – just do it! If meeting with everyone at the same time is not viable, you can organize it only for some of your teammates and connect with the rest online. It’s still worth it.

You may think that it is not worth spending money on that. After all, “we outsource our project to a distributed team to save money”. Not a good approach. Speaking from my experience, keeping your team motivated is very important for productivity. There are a lot of hidden costs when working with distributed teams (trust me!) and in my opinion, having a party budget is a must today.

Core hours for distributed team members

It’s a banal thing, but a very crucial one. You have to agree on core hours dedicated to working (most probably 8-16 or 9-17). The client must be aware of them. They should not expect you to be available outside of them. 

It should be set to fit the needs of the team living in different countries. Consider discussions (to be performed during a call). Your core hours should cover them.

Your core hours mustn’t cover 8 hours. You can set them for even 3 or 4 hours (e.g. 11-14) and let people work during the rest of the day as they wish – asynchronously.

Last but not least, don’t hesitate to react according to the situation. You can change your core hours whenever you want. All you need to do is to agree on that with the rest of your team (and the client as well). Perhaps, you have a special period in your project and need to start your work later every day – move them! Maybe you have to be available during a standby. Shorten them so that every team member would start at different times.

Each team member gets to “share the pain”

Let’s say, one team stays late after the core hours, because another one wants to start their work at 10 AM so they can sleep longer. Perhaps you can meet in the middle? Maybe you can somehow rotate the pain (on a daily or weekly basis)? Or maybe you can divide it between the teams? Try to share it somehow. 

Failure to share the responsibility evenly will lead you into trouble and hard feelings among team members.

Managing distributed teams in practice

It all sounds nice in theory, but what can one do to actually put these tips into practice?

On distributed team size – the composition

One of the biggest challenges is to compose software development teams properly.

If the team is small enough (about 5/6 people), dividing it into smaller pieces can kill the transparency of communication. In my opinion, it makes more sense to stay as one team, even if teammates work in different time zones.

But if the team is bigger (above 10 people), consider dividing it into smaller teams. Such teams are more productive and communicate better.

Reducing team size can in turn decrease the number of communication lines. What if I tell you: “We have 8 team members, let’s add one developer more to the team, so we can deliver it faster” – it sounds innocent and somehow reasonable, right? But what if I told you that it would increase the number of unique communication links by 8? The more people, the more data, but the more data, the less useful information for team members.

(n^2 – n) / 2
where n == the number of people in a team


Making the team smaller can also eliminate the tendency for individual team members to become gradually less productive as the group size increases, known as the Ringelmann effect. 

Have you ever played a tug of war? When I was a little boy, I played it a couple of times and even then I noticed one thing – the more people were in my team, the less strength we had. We would always win when I had in my squad only two friends of mine. When we wanted to play it in school (10-15 people per squad), it was a lottery. That’s because everyone relied on others and didn’t put enough effort into that.

On distributed team location

Let’s assume that you have two teams working in two different locations (e.g. one in Poland and another one in the U.S.). You can:

• Divide them by their locations.

Then you have one team working in Poland and another one in the U.S. It works only if the time zone difference isn’t enormous (you can cover 2-3 hours in your core hours on both sides). In this case, you have two separate objects – they need to synchronize anyway (e.g. during the daily Scrum).

• Consider creating a mixed team made up of people from different time zones.

This is a good approach If the time difference between them is much bigger. Then, the knowledge would be distributed as well. As a member of team A, you don’t have to wait for an answer from team B for 8 hours. There is a team A member working in your time zone and they can answer it immediately.

Adjusting the size of your team, dividing it properly, and taking location into consideration can all make a difference in the productivity of your team. Follow the guidelines above to achieve the best results.  

SPOC (Single Point of Contact) – eliminate the bottlenecking funnel

My grandfather once told me: “You have to learn from your mistakes, but it would be best if they were someone else’s faults”, so here is my fault which you can take a lesson from.

When I started one of the projects in the U.S., I wanted to be a good parent to all team members. Basically, I’ve killed a good idea of sharing the pain. I was the carry-pain guy. I stayed until midnight every day to discuss all details with the Product Owner. I supported him in discussions with stakeholders. I gathered requirements or even discussed technical approaches. I just wanted to make the whole process as comfortable for my teammates as possible.

It ran me into enormous trouble. I didn’t have time for my private life (I was working for 12-15 hours per day). As a result, I even thought about leaving my company to find a new employer. Worst of all, despite my efforts, the early phase of the project was not a success.

Being Project Manager serving as a Scrum Master to a team of developers (which had above 10 people), I wasn’t able to gather all of the data, process it into useful information, and pass it to the team.

After a few months of such workflow, it was changed to distribute the communication between all of the team members. My mental health got better. The team was informed properly. And they now really understood just how much impact they had on the product they developed.

Can anyone hear me?! A thing about communication

Few people realize just how much of a difference good communication makes. What makes it good?

Kill the “mum effect”

When I was 9 I broke my grandmother’s sewing machine. I took it apart to see how it works. Unintentionally, I broke one of the parts inside. I was afraid that I would be punished for that. I decided to say nothing.

The sewing machine worked – for one week. Then it stopped working. My grandma called a repairman. He immediately discovered what the problem was.

A couple of years later, I pleaded guilty. My grandma simply answered: “I know that was you”. “Weren’t you angry with me?”, I asked. She calmly said: “No, because I saw how afraid you were, punishing you was not a lesson”.

This is an example of just culture – the idea that most mistakes are primarily the result of a faulty organizational culture, rather than the actions of individual people alone.

You have to build a just culture if you want your team to go in the right direction. When you work with distributed teams, no one should fear being punished (or even fired) when they admit their mistakes. It is much easier to deal with minor ongoing defects than the gigantic problems they may evolve into when they remain a secret.

Asynchronous communication – don’t wait to tell something, leave a report instead

When you work with distributed teams, it is often impossible to find a slot suitable for everyone. Does it mean that you don’t communicate or your communication is doomed to be terrible? Of course not! All you have to do is to perform communication asynchronously and use a variety of project management tools for a remote employee.

There is an easy way to provide all team members with equal access to essential information. Even if cases such as those below:

• You have a call with 15 attendees. Only 3 of them are actually involved in the discussion. The rest are just waiting for a decision to be made or simply they can’t wait until the discussion finally ends. I’m sure you experienced something similar.
• The second case is when a minor part of the team works in a different time zone and simply can’t attend the meeting. 

There is a solution for both – providing a quick written summary of all decisions and topics raised.

In some cases, it is impossible to perform a Daily Scrum with a call. You can make it in a written form instead. The goal is the same – to synchronize, inspect the progress and adapt a sprint backlog if necessary.

The product vs managing a distributed team

There are a couple of product-related communication guidelines project managers can follow in pretty much any scenario in a distributed team.

One vision, one product, one distributed team!

Working with distributed teams requires you to ensure every day that you have the same vision of a product. There is no space for guessing! When I worked as a Scrum Master in the office, I had multiple discussions with my teammates about what PO’s expectations are and the real Product Goal (the actual name for the goal only appeared in Scrum Guide in 2020). 

I always coached them to ask the PO if they have any doubts – just to make sure that we are on the same page. It was easy then because I had a big space to inspect if it is shared between the team members.

If you don’t want to turn your project into the swing tree from a very popular meme, you have to collaborate with the team. The objective here is to share a common product vision, coach team members, and create a space to collaborate on product goals. 

Define your requirements

Imagine you have two teams distributed in two time zones. The difference is about 6 hours. You have started your sprint. Everything is on track and then, suddenly, developers need to clarify something, despite the fact that it previously passed the Definition of Ready (DoR). Now what? How to set clear and realistic expectations?

The way I see it, there are two courses of action:

• You need granular acceptance criteria to avoid such situations – including main and additional flows, data sets, designs, etc. Check out the Kuśmierz-Polak Method for more clues.
• And/or you may need to hire a proxy-PO – it would be someone responsible for close cooperation with a Product Owner. Craft with them high-level goals of a specific feature. They would also need to have a sense of product so that they can make minor decisions for product development. That way, the team is not forced to wait for the Product Owner’s decision

How to reward your distributed teams?

Do you think that rewarding your team is a minor concern? Think again and…

Party, party, party!

In the first paragraph, I have described how to start the project with your remote teams. Remember? Party!

In most cases, distributed teams are less motivated and teammates are not very integrated. You have to make a space for them to make relationships, drink some beer and play a ping pong game. Sporadic face to face interactions can be very beneficial for the productivity of distributed teams. Your remote employees need it much more than a team that works on-site because they don’t have much space to talk about off-work topics.

Fill gas tanks – vacation!

Your remote team members might need vacations more than any other workers. For example, in the form of extended weekends. Working in a distributed team poses unique challenges. When you work for a long time with moving core hours (which is a good approach from the project point of view), you may be exhausted. You just need to rest. You can’t go on like this for a long time… Try to use public holidays to recharge the batteries. Take days off in between to create extended weekends of 3 to 6 days or so. It is a norm in most organizations that actually know how to successfully manage a distributed team. 

A good start to that is to make an anonymous survey on how your employees feel, including how their work impacts their personal lives.

You can do it!

And last but not least – motivate your entire remote workforce. It is one of the most underrated aspects of successfully managing your remote team. Tell them that you appreciate their work. It costs you nothing, but it has huge power in terms of driving employee engagement. Just do it.

It would be best if you can involve higher management in that. It makes for a really productive work environment. It is a serious signal to all the distributed team members that their work is valuable and important.

Managing a distributed team – conclusions. Think different!

Let’s sum up all the most important tips for managing distributed teams and making sure that your remote talent :

• Take care of your remote workers from the very start by good time management (establishing core hours), sharing responsibilities evenly, and giving them the opportunity to relax. Work-life balance is of utmost importance for a distributed workforce.
• Adjust the size of your team and consider mixing team members from different locations.
• Allow everyone to contribute to the communication of your team – that way they will also better understand the impact each of them has on the project. 
• Create a company culture that communicates to your distributed workforce that the mistakes of individuals are not the end of the world. Remind employees of that often.
• Use various communication channels asynchronously, including written communication, video conferencing tools for team meetings, a variety of collaboration tool apps, virtual meetings and other right tools. Face-to-face interactions are not necessary to pass information.
• Make sure everyone is on the same page when it comes to the vision of the product and all the related requirements. Clear expectations are essential.
• Make sure your remote employees and other team members feel rewarded. Do not refrain from giving them any positive feedback they deserve.

Working with distributed teams isn’t easy. In the past, it was something new, something different. In the new post-COVID reality, it forced us to adjust. The entire team and every remote team member individually has to adjust their behavior to make it work.

You can disagree with it, glorify it or vilify it, but the only thing you can’t do is ignore it. Because then you just ignore the world. 

Still have doubts? Steve Jobs himself vouched for it!