I’ve been working with remote team mates for more than 15 years.\n\nIt started small, 1-2 works.\n\nGrew to a 15 contractor team in multiple countries.\n\nEventually became 30 employee team in New Delhi.\n\nToday, I manage 16 people in 6 countries with a 13 hour time gap.\n
My advice is mostly for software startups, but everything applies.\n\nBuilding your team is the most important thing you have to do.\n\nI’ve found there’s 2 main challenges when trying to do this.\n
Today, one of the most critical problems we have as founders is recruiting the team that will let us succeed.\n
Hiring is time consuming and can ultimately make or break your business.\n\nYour first hires are the most critical of all - assuming you can make them.\n\nAs the founder, you have to pit the progress you make on a daily basis against the means to produce\n
Although it is not usually our first choice, there are options.\n\nThe world is filled with talented people who can help you build something amazing.\n\nIf you can get past the hurdles.\n
If you’re considering the jump abroad, there’s a lot of things you’ll want to keep in mind (and worry about).\n
First, let me make it totally clear - you absolutely CAN build your business this way.\n\nThat said, most of you may want to stay clear.\n
When evaluating this process, there’s 3 things I like to pay close attention to.\n
You should only consider outsourcing or adding remote resources to your team if you’ve moved the product definition far enough.\n
The rate of change when you are early on in the process is considerably different from when you have finalized your learnings.\n
Products that can be de-constructed into independent segments will have an easier time succeeding\n
The more you can break apart your development, the better your changes to succeed.\n\nInterdependencies are always a challenge. Putting 5000 miles in between only compounds the problem.\n
Building a remote team can be especially taxing on the core members of the team.\n\nCulture cuts both ways.\n\nOn the one hand, if your product is highly contextual to your culture or a domain, it is hard to make it clear why things matter.\n\nOn the other hand, you also need a great culture amongst your local team - and the discipline to pursue this until the end.\n\n
\n
The most important part of this process is the Human Router. It’s the person(s) that will have to be in charge on managing communication with home base and the remote team\n
A successful team knows what others on the team are thinking and can tune in to how they feel. Make use of processes that keep people in “touch”.\n
Different cultures breed different kinds of resources. Depending on what you need and how you need it, some places are better than others. \n
The best way to learn something about someone is to give them something REAL to do.\n\nI recommend testing 3 people out simultaneously.\n
When resting out a new resource, you care more about communication and process than the actual work.\n
You will fail repeatedly. Just don’t get too frustrated too fast, it will only work against you.\n
There’s never just one tool for the job. The best one is the one that everyone agrees to use willingly.\n
In the beginning, you should try and setup a process that is fairly rigid - but not onerous.\n\nSome services like oDesk force a bit more process which is good and won’t seem like an extra demand from your side.\n
The absolute worst thing that you can have happen is for their to be zero communication early on.\n\nIt takes a while before you know how much you can trust someone and what they’ll do or not do.\n
From all the years I’ve been doing this, here’s some of the best tips I’ve learned.\n
Some tips on how to hire the right people\n
Dribbble is a community of top designers organized around sharing the things they’re working on.\n\nIt’s the best place to see what they really love doing since it’s stuff that often hits the cutting room floor.\n\nFind someone with a style you love and contact them!\n
Github is a developer treasure trove.\n\n1MM+ developers are publishing code, following other projects and more.\n\nThis gives you a big leg up in terms of knowing if someone might be excited and capable of building your app.\n
Tips on making your team as productive as possible\n
Dropbox is a godsend for most of your files. Code should be managed elsewhere.\n\nA lot of what you’re trying to do is stay in sync, and that’s the name of the game with Dropbox.\n
A picture is worth a thousand words. Use them as often as possible.\n\nIt’s easier to point and annotate in skitch than any other tool I’ve found.\n
Tips on maximizing communication\n
Common naming conventions are a godsend.\n\nDecide early on how you’ll refer to your files, views, etc. and use them Everywhere you can\n
This is how you build that sense of belonging.\n\nIt’s the proverbial water cooler but also helps people catch up.\n
You will not get everyone to use everything. However, if you can cross-publish updates from any of your tools, you should.\n\nWe use campfire’s api to push in data from all of our tools.\n