12 Tips for Building a Remote Team

12 Tips for Building a Remote Team

At Build Online, our dev team is 100% remote, with developers in the United States, a team and office in Uruguay and one lone rockstar in Romania.  We love remote teams, but we’ve also experienced the dark side.  I’ve personally lost thousands of dollars and precious time by hiring the wrong remote developers.

Here are my top twelve tips for hiring remote developers:

1. Hire through upwork (at first)

When you are first starting, do not try to work with foreign developers directly.  You need to use a service like Upwork (or a competitor) for several reasons:

  1. Upwork will help you find qualified talent.  There are thousands of freelancers available to hire on upwork.  Many of them good, many of them terrible, but it is the easiest place to find the talent you need.
  2. Upwork handles payouts and disputes for you.  This is both a protection for you and a protection for them.  Yes, they lose a small percentage of what you pay them to upwork, but they also have the abilty to build a reputation through upwork.
  3. Speaking of reputation: Upwork gives you the only recourse you have when working with foreign developers - the ability to leave a bad review. This is (in my opinion) the number one reason to stick with upwork.
  4. Upwork allows you to see timelogs for your freelancers.  Although I would suggest that after they prove themselves trustworthy, don’t make them use this feature.  It’s invasive.

In our case, we eventually stopped using Upwork (for new hires) and now hire people referred to us by our current team members.

2. Avoid foreign agencies like the plague

There are hundreds of dev shops in India, the Phillipines, eastern Europe and Latin America that are going to try to convince you they have the manpower to handle your whole project.  In my experience, this is the surest way to lose money on Upwork.  They will run up the hours and produce terrible code.  Everything will likely be run through an interpreter.  
Just stay away at all costs.

3. Insist on video chatting with the developer

When we hire people, we let them know a video chat is a regular part of the job (and we mean it, we usually video chat several times a week.)   Video chat will help you see things you’ll miss in text.  Like:

  • Are they likable?
  • Can they speak english?
  • Do they know their stuff?
  • Do they actually want this job?

4. Have someone on the call who actually knows how to code

Anybody can create an Upwork account and pretend to be a capable programmer.  When you are interviewing a candidate, it’s good to have a programmer on the call with you to make sure that this person actually knows their stuff.
There are a few red flags I watch out for on these calls:

  • Do they look puzzled when you talk about important workflow things (like git, scrum, ssh)
  • I ask to see their github profile (almost all developers have one, if they have to create one that’s a bad sign)

5. Look for specific keywords

We use the Laravel framework for backend work and Vue on the front end. So of course, we wouldn't just search for “web developer” we would search for “Laravel” and “Vue” and there are hundreds of programmers available.
I’ve found that further refining the search with another, less well known keyword like “tailwind” (the name of the css framework we use) helps us find people who can jump right in.  Here is my reasoning, if they know Laravel and Vue and Tailwind, chances are they are into the same development crowd that we are.

Along the same lines, I like to ask prospective developers if they go to any conferences, read any blogs, follow any developers or listen to any podcasts.  In our niche, there are several of these and if they are really interested in programming, they will probably watch/listen/attend at least on of these.  If they’ve never heard of them, it’s a red flag.

Example, we recently hired a Full Stack Developer to work on our team from another country.  I was really impressed by his communications skills and excitement to work on our project.  But one of the things that sold the deal was his enthusiasm for talking about Laravel.  He even had a Taylor Otwell bobblehead on his desk (Taylor is the founder of Laravel).

6. Look for people who are a good cultural fit

At least 30% of working with developers is communication.  As a project draws on, you are going to have to talk to these people.  It helps if you actually like them and can find common ground to talk about things.

This is another reason to avoid developers from halfway around the world. Very often they will have nothing in common with you culturally.  But its also something to think about even with in-country developers.  We’ve found good people before that we’ve decided not to work with just on a gut hunch that we wouldn’t have much in common.

Example: we were once thinking about hiring a guy in England who seemed like a very talented developer but decided not to because he seemed like he was into the party lifestyle, and just about everyone who works with us are raising families.  It just wouldn’t fit.

7. Give the interviewer a small test job (and pay for it).

Even after you talk to someone and feel them out, you won’t know how good they are until they actually do work for you.  So we let new people know that their first task is a bit of a test and we pay them to do something that isn’t mission critical.  We are looking for how well they communicate, how they think through problems, how difficult it was to get them setup, etc.
We would never ask people to work for free.  It’s absolutely worth it to pay for a small job to see how people actually work.

8. Find someone with at least a couple hours of workday overlap.

One of the first developers I worked with in another country (not for Buildonline) was in India.  He is a good guy and a talented developer who has become a friend I still talk to him from time to time and have him help me with personal projects.

But nothing critical - because the only time I can talk to him is early in the morning.  When it’s 9am for me, it’s 11pm for him.  Our days are litterally flipped.  It just doesn’t work for us.

On the other hand, one of our best developers lives in Europe and there are at least two hours of workday overlap.  He’s finishing up his workday as we are starting ours.  It works out perfectly.

Just know that it’s really difficult to work with people who are asleep while you are working.  Especially when something is urgent.

9. Value communication and organization over technical skill.

Being a developer is about a lot more than being a technical wizard.  At least 50% of it is about being a good communicator and being organized and self-motivated.  Hiring a brilliant developer who doesn’t get his work done or who can’t carry on a conversation and explain what he’s doing isn’t going to help you.

Good developers know how to write more than just code.  They know how to write good questions, how to write comments in their code, how to write tests, and how to write a quick overview of the trip they took over the weekend.

10. Look for undervalued prospects, then pay them more than they are asking for.

In the past, I've had really good results looking for guys on Upwork who are just starting out and who haven't developed a reputation yet.  In my experience, some of the best people to hire are people who are young (finishing university) and who aren't super busy yet.

It takes time to find these people and time to find out if they are a good fit, but once you do, I suggest paying them much more than they are asking for.  Why?

  1. It lets them know that you recognize their value.
  2. It engenders loyalty and lets them know you aren’t trying to rip them off.
  3. It helps them stay with you longer and not use you as an immediate stepping stone to higher paying projects.

11. Try to give them around 30 hours of work every week (but not more)

I don’t believe that most programmers can actually work more than 30 hours a week on one project.  Programming is just too intense.  Six hours a day, five days a week is a lot of programming.

But at the same time, you'll get your most value from team members who work almost solely for you.  We don't hire anyone who doesn't look at buildonline as their full time job.   So our aim is to provide 30 hours of work each week, and to pay them well enough so they don't have to do more work than that.

12. Protect Your Code

I know at least two entrepreneurs who have spent over a hundred thousand dollars on software, only for their remote development team to delete the code they paid for or hold it hostage to some ridiculous demand.

If you are hiring good people, using the steps above, you shouldn't run into this problem.  But just for your protection, you should still protect your code.

There are two things you can do to avoid this:

  1. Hire in an open market (like Upwork) where you can challenge them and leave a bad review.
  2. Setup a Github organization account, make the repo private and add developers with write but not admin access.  Every change they make needs to go in that repository.  You can kick them off at any time.  Be very careful about who you give admin access to for GitHub, for your server, etc. because this can come back to bite you.  Especially if you are working with devs in a foreign country where you can’t or won’t take them to court.


Those are my best tips.  Do you have any remote team tips (or horror stories) share them in the comments.