Distributed Teams?

Building the team is one of the most important factors that will determine the project success. This post is not about how to use the last and coolest technology to work in a distributed team, but to show that although staffing a remote team could be a valid alternative, it hurts the team and we need to learn how to manage it.

Note: there is no need to explain why, just google "team collocation".

Staffing people in remote locations is like going into debt. Yes, I'm using the famous technical debt concept developed by Ward Cunningham. OOPSLA 1992
As a PM you can decide to hire a remote developer and take on that debt, but you also need to think that every day that developer is assigned to your project, you will keep on accruing interests and it will be harder to replace that person/team and recover from it. 



So, everytime you decide to use a remote team, you need to have a plan. For example:

• Key players shouldn't work remotely. But, if there is no alternative, a plan to relocate that person or to train someone else in the team should be considered from the beginning.
• Include in your plans travels to collocate the team for the project kickoff and key milestones. It should be a must. 
• Create an aggressive new staffing plan if you have more that 4 time zones, if you are planning meetings at 5am or 10pm or if you have more that 80% of the team distributed.

Finally, paying your debts will give you more room to take on new debt :)