If you’ve ever wanted to quickly scale your team with remote developers but either had a bad experience with a freelancing site or have always been turned off by the horror stories you’ve heard, then I’d like to take a moment to share the most common myths we hear about remote developers and how our 10 years of experience with extraordinary remote developers tells a different story.
Like any stereotype out there, the myths about remote developers certainly don’t apply to everyone in the profession. So let’s bust those myths, shall we?
Let’s get the big one out of the way first. For many remote developers in places like Europe or Asia, English isn’t their first language. But it doesn’t mean they can’t speak English well.
In fact, many people I’ve worked with from those places have better written & spoken English than Americans I know personally! Don’t assume that everyone outside of North America has poor English, as you’d be surprised.
Since it isn’t always their first language, however, you will certainly come across developers who have poor English or who can’t communicate with you well. But this is where vetting becomes important, and it’s why at X-Team, for example, strong English is our very first screening test.
Imagine that you are no longer chained to your desk at your company and can work from anywhere. You don’t even have a boss looking over your shoulder anymore. What would you do?
Chances are if you went home to work right now, you wouldn’t get much work done (at least if you haven’t done it consistently before). Working from anywhere takes practice and learning a lot of techniques to stay focused, productive and even healthy.
We even wrote a post about ways to stay focused when working remotely to help others out.
So, is it hard to stay productive when working remotely? Absolutely.
But is it impossible? No. And not only that, once you know how to do it, you’re actually exponentially more productive than you are in an incredibly distracting office environment.
Office workers are interrupted roughly every 3 minutes, according to academic studies. What’s even worse about that stat is that once thrown off track, it can take some 23 minutes for a worker to return to their original task.
When a remote developer needs to be productive, they can shut down every distraction (Skype, Slack, e-mail, etc.) and simply focus on their code editor. The result? More focused developers than you’ve ever had on your team before.
I’d recommend checking out our tips on how to focus when working remotely to see all the ways it can energize the way you work.
If you’ve ever worked with one of the many freelancing services out there (I won’t name them, plus they’ve been changing their names lately to rebuild reputation), then I’m sure you’ve experienced this. I know I have!
It’s that classic scenario where a developer tells you, “I’ll get started now and have it ready by Wednesday!” Wednesday, of course, comes and before you know it, it’s the following Tuesday before you hear from them again.
The biggest reason as to why this happens is because many remote developers depend on multiple clients to get by. The result? Your requests suddenly get de-prioritized by fires happening with their other clients. Unfortunately, they often don’t take the time to reset expectations with you.
This is why at X-Team, we only provide remote developers who are dedicated 100%, full-time to your team. It’s the best way for it to work effectively, and we’ve had incredible success for 10 years with this model.
When you have remote developers dedicated full-time to you, they communicate daily, they do things like public journaling to build trust and keep you up to date throughout the day.
Comparing remote developers to Silicon Valley developers isn’t a worthwhile debate, as** location has little impact on one’s ability to write quality code.**
“But the education is better in San Francisco.” Ask all of the most talented developers out there if a school taught them how to code, or if they taught themselves via Google searches.
If you look at the technical test results from developers from San Francisco compared to developers in random pockets of the world, you’ll find that living in San Francisco doesn’t guarantee any advantage. Same goes for commitment, passion and proactiveness results. *(This is based on our own recruiting data).
Your location can certainly provide you networking opportunities you might not get elsewhere in the world, but it doesn’t guarantee you any advantage over a remote developer in terms of your ability to communicate, write quality code, lead & mentor others, or build an extraordinary product.
This myth started due to the freelancer websites which were primarily populated with Indian developers.
It’s simply a numbers situation for why this perception exists: There are 1.25 billion people in India, so naturally there are going to be more developers looking for work than in the U.S.
Another myth is that developers from struggling countries like India are poorly skilled. There are poorly skilled developers in every country, including the U.S. The challenge for India is because they have so many developers, the number of poorly skilled developers is naturally going to be higher than the U.S. And the more poorly skilled there are, the more likely you are to get one if you try to hire one at random online.
But here’s the good news: talented remote developers can be found all around the world, including India. X-Team has incredibly talented developers in more than 25 different countries, and we’re just getting started.
It’s only the companies that take the time to vet developers thoroughly that will have success recruiting remotely.
North Americans talk about this myth often, but a lot of it comes down to cultural differences. Some cultures around the world are simply more eager to please, and in doing so will over-promise and under-deliver by North American standards.
But developers from other countries who have worked with North Americans long enough have learned those cultural differences and how to provide proper estimations, timelines and expectations. You are only at risk for this myth if you hire without properly vetting the developer you work with.
This is why at X-Team we put our developers through an exam that specifically tests for this sort of behavior. The exam puts each developer through a test project that requires them to reset expectations as requirements change and to ensure they understand how to avoid over-promising and under-delivering.
It’s certainly a challenging question: how do you get someone to fit into your culture when they can’t be physically with you and/or your team?
It’s a myth though to say that it’s impossible. Once again I know from first-hand experience of being the CEO of X-Team and having one of the strongest company cultures in our industry, despite being globally distributed.
Great remote developers know how to build relationships with a physical team the same way we do in-person. They know how to be social beyond coding, as well as how to learn quickly about a company’s values, beliefs, inside jokes, branding, and more.
But much like I mentioned in the myth above about communication, this works best when the remote developer is dedicated full-time, otherwise it can definitely be a challenge for them to really get integrated and learn the ins-and-outs of your team.
We’ve heard countless times from our partners that they feel like the X-Teamers on their team (who are remote) are truly part of their team, like anyone else. We’re humbled by that, but it happens because we hire people who know how to be social, build relationships, and adapt to new environments quickly.
This perception can arise when a remote developer isn’t dedicated full-time, as when they are part-time, they end up having multiple clients, and your priorities can take a backseat sometimes. Talented, full-time dedicated remote developers won’t ever make you feel this way.
This belief also comes from a common question: “How can this developer understand the importance of what I need done when they aren’t here to feel the same pressure that I do?”
And it’s a valid question and concern, as well as the difference between a remote developer who truly cares, and one who doesn’t. There’s no doubt that making a remote developer full-time and dedicated is a great way to avoid this, but you also want to make sure that they are aligned with your goals from the start so that you know and believe that they understand your expectations.
This myth is one of the reasons we made X-Team — we know there are truly extraordinary global developers out there. But if you’re going to scale your team with any kind of developer, you should never have to worry about whether you can trust them or not to be there when you need them.
It all comes down to vetting them properly and working with them on test projects until, over time, you learn that you can trust them to be there when you need them.
It’s no different than hiring someone for an office job and never knowing they’re a Farmville addict until 6 months into their employment when you discover they aren’t adding any value.
X-Team developers are vetted thoroughly so that 1.) you don’t have to worry about spending time learning whether you can trust them, and 2.) we know any developer we present to our partners will be there when they need them.
The above scene is what generally happens when developers end up with a little too much face-to-face time with product owners.
There are certainly some scenarios where having a developer in-person is beneficial, such as explaining a design comp or how something is supposed to work.
But those scenarios are really only necessary at companies that write poor documentation. The only time ‘face-to-face’ with a developer ends up becoming necessary is because the information the developer has is insufficient to be able to do their work properly.
Everything from poor design comps, to vague/nonexistent technical documentation, to bug tickets with little information/no screenshares can all lead to someone eventually saying, “You know, this would be a lot easier if the developers were just HERE!”
Rather than just toss developers into projects though, we prefer to work with our partners to help them improve their requirements documentation before a developer ever sees anything. This sort of prep work helps relieve the need for ‘face-to-face’ time as much.
What we’ve found is that when documentation, comps (and even animation demos), QA, etc. are all done properly, developers are incredibly productive, efficient and focus entirely on moving things forward, rather than being distracted throughout the day by in-person obstacles. Each distraction ultimately costs that developer 20-40 minutes of time to get focused again.
What I hope you can take away from this is that when it comes down to it, hiring is hiring; it doesn’t matter the job or the industry. You’re always going to have poorly skilled or unproductive people in any job, both physical or remote. The key is simply to have a solid vetting process in place, or a trusted partner who can bring you developers who have already been vetted by a solid process (such as X-Team).
There are unique benefits to having onsite developers in the same way that there are unique benefits to having remote developers. What I’ve come to admire about remote development is how it brings to light communication, trust and productivity issues that exist in onsite teams that you never really knew existed until you bring in a remote element. The importance of documentation, for example, is never more apparent than when you need to onboard 3 remote developers and realize you haven’t documented any of your processes (!).
So I encourage you to slowly incorporate remote developers into your team to start to see what I mean by that.
Plus, we’re only six years away from when 1/2 the workforce will be working remotely, so today sounds like a good time to start.
Want to work with X-Team’s developers? Our team is your team. Let’s chat.
Read next: 10 Secrets to Becoming a Great Remote Developer
