Building Distributed Teams – Why The Model Fails

This is the last post in my series on Building Distributed Teams. So far, we’ve covered why you need to be building a distributed team, what makes an ideal distributed team member, individual vs pods when hiring, team leadership and team communication. As a reminder, this series is focused on building a distributed technology product team. While the principles here might apply to building a distributed sales team, it is not the focus.

In this post, we’re going to cover the most common reasons why the distributed team model fails. If you manage to avoid most of these, you’ve got a great shot to build a successful distributed team. These are in no particular order.

Hiring people who like going to work – Don’t hire people who like going to an office every day and need that social interaction. If you do, make sure you find them a place to work that isn’t their house.
Hiring people who can’t work independently – Some people have to have others around to ask questions to and talk things through. While everyone needs this some of the time, distributed team members are on their own for large chunks of their day. They have to be self-sufficient
Lack of systems – You can’t run a distributed team without the right systems being in place. Whether it’s Slack for communication or ensuring everyone has the access they need to your cloud provider, it is your job to make sure that the team has everything they need before they need it.
Lack of planning – Often times in the early days of a company you’re winging it and, if you have people sitting next to you, that can be easier. Running a productive distributed team means that everyone has a full work queue and is not sitting around waiting for you to make decisions. You should have weeks of work prepared for every team member, even if the priorities change. They have to be able to start the next task without asking you what to do.
Too much control – Which brings me to my next point. If you have an iron grip on all of the work being done, you’re going to fail. This is true whether distributed or local team, but it’s especially true of a distributed team. Hire people you trust and then trust them to do the work.
Underestimating time zone issues – If you’ve never done it before, managing work across 3-4 timezones (to say nothing of 6 or 8) can be a real challenge. Coordinating people’s schedules and delivering reliably will start to eat into productivity. If you’re not prepared to work weird hours at times, don’t bother.
Underestimating language issues – If you build a team of any size, you will inevitably hire someone who speaks a different primary language than yours. This can be incredibly frustrating if you’re not prepared for it, or if you hire the wrong person. You have to test your potential hires during the interview process for their ability to communicate with you in your primary language. You shouldn’t be scared to hire someone because they aren’t fluent, but you have to understand the impact of balky communication at times and be ok with mistakes.
Unrealistic expectations – Of all the things I could talk about, this is probably #1 on the list. Distributed teams have their own set of distinct challenges. It’s really hard to make this work. Not harder than building a local team, but certainly different. The myth is that you can hire people from anywhere, add them to your Slack and be off and running. It doesn’t work like that. If you want to pursue this path, start by working on a very small project with a small team and working through all of the kinks. Don’t make the decision after you’ve taken investor money and have real deadlines. The pressure of having to deliver, combined with having to learn a brand new way to lead a team, will most likely be your undoing.

I hope you’ve enjoyed this series. If there’s a topic you’d like for me to have covered but didn’t see along the way, hit me up. I believe strongly in this model as the way to get the best people on the bus, but it’s not for everyone. It’s my hope that you’ve learned enough in this series to make an educated decision about building your own distributed team.