From startups to large tech firms, outsourcing is common practice when developing software products. I myself worked as a contract designer and developer until 2007 when I was recruited to work for a game development company, who happened to be one of my clients. They relied heavily on remote developers and it was there that I discovered the good, the bad and the hideous of the employers side of things – managing remote developers.
Over the years I've witnessed a lot of chaos creep into remote teams that were't carefully managed, and I've discovered there's a bit of an art to keeping them on track. For some projects, the experience of working shoulder to shoulder with developers can't be replaced, not just for maintaining quality and accountability, but for maintaining your sanity. Large companies are starting to take note as well. In 2013, Yahoo's Marissa Mayer ended the company's remote working policy.
From Mayer's memo published by AllThingsD:
Beginning in June, we’re asking all employees with work-from-home arrangements to work in Yahoo! offices. If this impacts you, your management has already been in touch with next steps. And, for the rest of us who occasionally have to stay home for the cable guy, please use your best judgment in the spirit of collaboration. Being a Yahoo isn’t just about your day-to-day job, it is about the interactions and experiences that are only possible in our offices.
In their book, Remote, Jason Fried and David Hansson make the argument against Mayer's position on remote workers by pointing out the value of not restricting your company's talent to one geographic location. Because it can be so difficult to hire high quality developers in some areas of the U.S., I mostly agree with this position. Especially for startups and small companies needing short term help.
However, it's not insignificant that a company like Yahoo is taking steps to move everyone in-house, and I have little doubt that the decision was based in part on productivity issues. There are plenty of grey areas facing managers with remote teams, and in my experience, having worked as a contractor has been invaluable in my own approach to managing contractors. In this article I'll briefly cover five areas that I think can most often cause remote development projects to go south.
1) Geography
Qualified developers are in huge demand. There are few of them, and a lot of us. According to a 2014 CareerBuilder study, 71% of IT companies reported unfilled positions due to a lack of qualified candidates. It's important to note that this is not just a U.S. market problem, so don't be fooled by the notion that plenty of cheap, qualified developers can be found offshore.
The law of large numbers in countries like India does not apply when it comes to available tech talent. Sure, you'll find a lot more people claiming to be qualified, especially if you use contractor sites like Upwork, but I've found most people who apply to postings on sites like this are in no way qualified. In fact, many are there to try to take advantage of people who don't possess an adequate bullshit meter in tech matters. That being said, Upwork can be a good resource if you know how to screen properly.
Without question, the U.S. tech scene is outpacing the world, yet I've generally found there to be little difference between the U.S. and other countries when it comes to the number of available qualified developers in circulation. Good developers in any time-zone are in short supply and most are happily employed at large companies with coding cultures that appeal to them.
In the States, if you're looking for junior developers, we've got 'em. There are plenty of young people with CS degrees or some basic coding knowledge, but if you're building a product with a small team, you typically need more serious coding muscle. I'll attempt to avoid a cultural rant, but it's important for anyone hiring in the U.S. to recognize that the current college crowd arriving onto the tech scene typically has the entitlement-generation attitude built in. There's no shortage of individuals who think they're qualified because they attend meet-ups, yet have little motivation to push themselves unless it comes with a check.
On the flip side, those rare individuals who spend nights and weekends crafting a real skill set, often have rock-star egos and pricey requirements if you seek their greatness. You can see the result of this in the outrageous perks being offered by companies in the Bay Area. These things may not be PC to point out, but it is a reality that we face here, and it's important to factor this into hiring expectations. It may take a little longer to find the right talent for your business.
When it comes to global talent, I typically look to the Eastern European countries first. Many countries in this region are light years ahead of the U.S. in their education programs, and have been pushing STEM courses for more than a decade, so there are some very talented graduates arriving on the scene. I also prefer this region for the cultural alignment to that of traditional America. Many people I've worked with from these regions have been very grounded individuals with great work-ethics, and who valued the relationship.
Don't underestimate cultural differences when hiring offshore. Understanding as much as possible about the person you're working with is a critical component to a successful relationship. We didn't all grow up in the same neighborhood, nor do we all share the same values, so you should be prepared to navigate that.
2) Learn to speak geek
Asking a developer to build an app that does ‘x’, is like asking a mechanic to build a car that’s red. On any given project there are potentially hundreds of questions to answer and components to define. You must speak the language of development to build software products, period. If the language is tough for you, and you still want to control how your product is built, you have basically two options:
Find an awesome product lead. If you don’t have someone that you know you can trust bridging the gap between your vision and the actual technical (and design) execution, you’re taking a huge risk. A great product lead can change your life, and bring enormous value to your organization. It’s worth noting, however, that a product lead/manager is not the same as a project manager. There’s a huge difference, and that topic likely needs it's own article so I won't cover that here. I will just say one thing, don't subject your developers to a freaking project manager.
Teach yourself how to code. You don’t have to be good enough to build the product, but you must be able to understand the challenges that a coder will face. If you’re able to help define the frameworks, plug-in’s, and basic infrastructure of the system, then you’ll be much better equipped to meet a developer on their turf and guide any potential trouble-spots away from disaster. Check out some of the great learning resources at Treehouse Learning, or Khan Academy. It can also be helpful to get involved in your local tech scene. Just hanging out at coding workshops or attending conferences can quickly grow your vocabulary and knowledge of the development world.
My point here is that trust is the key ingredient to success, and it all comes down to injecting an advocate that you know can be trusted, wether it's yourself, or a product lead. Contractors should not be trusted blindly, make them earn it, no matter what their qualifications.
3) Safety in numbers
A valuable thing happens when you add a second senior developer to a project with the same level of ability as the first – competition, and as long as you manage it carefully it can produce great results. If your resources only allow for one senior developer, I get it, but doubling up on the top talent in each area of specialty can help in significant ways.
First, the magic number of brains for resolving a development issue is usually three. A third voice (I include the product lead in that count) can really balance out a conversation when all three people are highly skilled and can pool their experiential knowledge. When you add a fourth or fifth person, it usually ends up being a waste of time for someone.
Second, most developers enjoy having someone else in their league to bounce ideas off of and collaborate on standards. Being able to split tasks can greatly reduce the project fatigue that can build with one person carrying most of the weight.
Third, and most importantly, if something happens to your pilot you'll need someone in the jumpseat to take the controls. The most significant risk you take when working with remote developers is losing one mid-project. It happens all the time, for any number of reasons, so the ability to have another person available to cover, who is already familiar with the product, can be a lifesaver while you restaff.
4) Rates and payments
I can't tell you how much trouble I've watched people get into when they try to build a software product with extremely low-rate contractors. The economy sucks for everyone, but if you're really building a product, do yourself a favor and step into reality as soon as possible when it comes to properly estimating your development costs. Casually approaching development with the notion that you can find a cheap developer to essentially build your business for nothing, is a roadmap to failure. Yes, Kevin Rose did it a decade ago, so if you think you're savvy enough to pull off another Digg for an initial $1,200, go for it. Otherwise, let's break down some numbers.
When hiring contractors in most countries, a good rule of thumb is junior to mid-level developers are typically $40/hr and below. Some of the below $40 crowd may claim to be senior, but they're under-pricing themselves if they are. By the way, multiple years of experience does not by virtue make one senior level. You're likely to come across some people claiming years = qualification. It doesn't always.
I've found that most solid senior developers in any area of the world (who don't need hand-holding) range between $40 to $80 an hour. Sometimes a little less, depending on the region, however, you begin the slide into the junior to mid-level crowd as you go down. If someone quotes more than $80, then ask yourself what qualification that rate is based on, and if your project really requires that level of expertise. If you're working in the areas of security, data science, or specialized integrations, the answer might easily be yes.
Anyone qualified to price themselves at $100+ is approaching if not already CTO level, and would most certainly be courted by the Bay Area crowd, so the fact that they're a contractor may be a red flag. Ask them why they aren't senior level at some large company or involved with a VC backed startup?
To be fair, some contractors in this league may just say they can make more as an independent and prefer working in their underwear. A totally reasonable position, and some contractors that like the home office are worth their weight in gold by the amount they can produce and the quality of their deliveries. It can also be extremely beneficial to work with someone who just "get's it", with the capacity to think multi-dimensionally – tech, creative and business.
However, be very cautious of contractors in any price range who use words like "lifestyle". More often than not, I've found it to mean they like to spend every other day on the slopes and may be only partially invested in your project. Of course they will say they're committed. Who wouldn't? You're essentially funding their care-free life, so listen carefully and don't be shy about pointing out that you expect them to earn their rate and be available when the project requires them. If they flop around on either of those points, run.
Fixed vs. Hourly. If you haven't managed a fixed-price software project before, I'd recommend against it, unless you are highly confident in your ability to define scope and expectations. Developers are notorious for underestimating and not being realistic about their actual skills. If you're light on experience you can run into endless areas of ambiguity and interpretation, and the timeline can explode. In these scenarios, it's easy to end up with a developer who starts flaking out because the work was either larger in scope, or more difficult than originally anticipated, or both. This usually results in either a higher price (and longer timeline), or a partial delivery.
5) Communication and best practices
There's a good chance the developer(s) you're working with will not be in your time zone, so setting expectations for communication is key. Don't hide behind email or task management tools. Talk regularly even if not much is happening, and share a calendar for time off or vacation schedules that may have been planned before your project started. It's a really good idea to check for long-range schedule conflicts in your initial interview.
Language may also be a factor. I live by one hard and fast rule regarding language, you must speak fluent English, not just type in English. There are droves of offshore contractors out there who love the protections language barriers and chat-only scenarios provide them. My advice, don't fall for it. You'll be tripling the time it takes to communicate even the most mundane thing. It's simple, if a contractor is claiming to be a professional provider, then they must speak the language of the country they are doing business in.
Stay on top of production tools and don't let anyone work in a black box. If a developer is late on a delivery and they're not talking, it usually means they're stuck, so get in quick and help them through it. Platforms like Pivotal Tracker, Trello, and Slack provide instant monitoring of every task, build, test and deployment without having to annoy everyone with constant Skype calls. With tools like this it's extremely easy to maintain insight across the team.
The bottom line is that everything about working with remote development teams comes down to good management, which means this article is more about you than the developers you hire. If you have no ability to empathize with, or sense what a remote developer may be dealing with, even in the smallest detail, then you have little ability to effectively manage them and you should consider hiring local.
It's important to remember that even though you're the one writing the check, working with developers, remote or in-house, should always be a collaboration. If you're not able to roll up your sleeves and become a teammate when needed, respect for you as a leader will quickly dissolve, and the project with it. So, don't be afraid to jump in. There really are no experts in technology, just people who keep up. Hopefully, these points will provide a good framework for hiring your remote team, and building a great product.