The Risk in Sending Your Startup’s Technology Offshore
karllhughes.com
karllhughes.com
Some of this is basic talking and listening; phone conferences will suck! Think about your typical (dysfunctional) phone conf and then slash the quality of the phone line/Skype connection. Add in the variable accents of the offshore team. Their English is 1000% better than my command of their language: if I can't understand what they say and everything has to be repeated or translated by a co-worker, meetings slow to a crawl.
You will run into cultural differences in communication as well. The off shore folks want to do your work and they have the can-do attitude of most IT workers. They may indicate understanding when that isn't really the case. They aren't going to be able to casually wander by your desk and raise questions later so you are more likely to get stuck with their assumptions. This has happened even when we have brought off-shore developers to our offices for face to face meetings.
Finally, I have found that we are often unprepared to send work to a developer in a coherent manner. That will lead to rework, increased cost and even more communication overhead as you painfully hammer out your actual requirements.
But yeah, the inability to extract the words "I don't understand" or "I don't know" from foreign workers drives me utterly batty.
That's a cultural thing, and you're doing it wrong if you are trying to extract admissions out of people. That's the totally counter-productive approach. I understand that from a 'western' background admitting to failure, a lack of knowledge or even downright incompetence does not have to be a problem but in other cultures this can be a near impossibility.
I would like to suggest a different approach. Assume the "I don't know" or "I don't understand". Simply go over the thing for your understanding. This will take care of the problem in an elegant and face-saving way without having to torture co-workers.
There is an upside - anything I can fix and deploy for them during my work-day is effectively zero-downtime for them.
Great guy, don't get me wrong! But there's lots of hurdles to an overseas relationship.
Disasters happen everywhere, including home. An ice storm could knock out your power for a week, or a hurricane or an earthquake depending on where you live.
I learned to code last fall and consider myself to be a semi-technical founder (php - laravel, jquery). I live in a small town in Montana and I knew I could not complete my MVP entirely by myself. With nearly no developers in my town I knew I would be working with someone over the internet to complete some of the project features.
I talked with roughly 10 freelance developers (half in U.S, one in Denmark, one in Belgium and a few in India).
I chose one of the developers in India because he seemed like the most capable of the group and immediately understood the project. He has been fantastic to work with and taken "ownership" in the project. I wouldn't hesitate to hire him full time if the project gains steam and he was willing to move to the U.S.
A couple of things to note: I would have much rather had an in house developer, but that just wasn't an option in my rural location. Also, my project is a marketplace of sorts, so it isn't a very complicated project from a coding standpoint. Going into this project with no sense of what I was after or how it would get done would have been a horrible idea, regardless of where the developer was located.
I had the offshore developer work on very specific modules that were organized through a shared trello board. Before I talked with him, I knew exactly what I wanted him to work on and the timeline for each project. He works some odd hours, so our usual schedule of talking was around 10am - noon and 9pm - 11pm.
He spent about 110 hours total on the project.
Just something to consider, these are all different cases, and as with anything it's never a one-size-fits-all.
My questions, specifically due to common complaints:
Where did you find the 10 leads? What were your criteria?
How did you, as a semi-technical cofounder, interview/approve him?
How do you guys work together regularly?
Finally, if you're willing to share, what's the rate at which he is employed?
Communication is huge in technical organizations, and small stumbling blocks like accents over shoddy conference line quality can have long-lasting impacts when (as you've stated) incorrect assumptions are solidified in implementations. In a lean atmosphere those can be often be corrected but it's costly. When you're looking to offshore you're looking to save money and it's not always easy justifying re-writes purely from a monetary standpoint.
That said, there isn't something magic about geography that makes people suddenly better at programming. Good programmers live all over, you've just got to know enough about your business to be able to judge talent based on more than geography or color.
One rule I've found useful: don't ask people to do things you can't (potentially badly) do yourself.
Almost by definition this means that they will need a (very) competent project manager on the side of the hiring party. Alas, this is often also outsourced and that's when you get interesting phone calls at 4 am.
Its important to make sure that is in your estimate. It can eat up a fair bit of time but it makes the relationship stronger.
"well, I don't know anything about construction but I can draw pictures of buildings"
There is a hybrid field called 'architectural engineering'.
It's not just about relative ability, it's a question of motivation - few engineers truly enjoy putting on their tie to pitch 100 potential investors in a row, or convincing the first few clients to pony up for the product, with 95% of cases ending in a painful rejection.
In fact, if a non-technical founder (I'm looking at you MBAs "interested in entrepreneurship") wants to increase his chances with the better engineers, he can always do so by closing a sale and presenting the evidence to the technical people he is trying to hire for the job. "I've gotten a written commitment to $100,000 if we build this relatively simple piece of software, and I have another four watching, we won't need seed funding" is a considerably more attractive proposition than "hey, please build this for free and according to this PowerPoint from my Tech Ventures class we'll own a billion dollar market next year".
The key to being successful for a non-tech founder is to have solid domain experience. A Realtor acting as a "paper general" stands a much better chance than a dentist.
If someone is looking for an offshore team, follow this approach: look for a outstanding, talented person. A single person, who you can develop trust with, and ask him about his core team and colleagues. If they are for your liking, go with them as the offshore team: they may not have all the people at the time of the discussions, but usually they are able to build a team in a short time.
That way, they are really committed to your project, and you won't be just another client that has some meetings with them.
What I miss is that the article places the weight of the potential problems with the party that is being hired.
More often than not the real problem is the inability of the outsourcing company to mange their relationship properly, to adequately spec what it is that they need and to do sufficient quality control on the result to make sure they get what they paid for.
This can result in lots of drama down the line.
Expect to refactor everything before it makes it to your baseline. Use what they produce as a starting point, not the end product.
Cheaper does not mean bad code and bad practices, and more expensive does not mean better code and better practices. The simple fact is that someone has to take responsibility and implement stuff right.
> 1. It’s extremely difficult to judge the quality of outsourced work without your own local engineer
It can be difficult measure any quality if you do not have the knowledge to do it. As this article is aimed at the "non-tech" founder, I have to question how that person would know good quality code or bad quality code without a technical advisor.
> 2. Prepare to work some odd hours and deal with communication issues
Some outsourcing companies work the hours of the client. If not then planning just needs to be done to organise communication. Even in the US (I am not in the US), there are different time zones which need to be compensated for.
However I do realise a 12 hour difference can be difficult.
> 3. Things will get lost when you transition to a permanent local team
Bring on any new developer to an established codebase and they are going to need time to catch up.
> 4. Each feature can become a line item in your technical debt
This point does not even make sense. Technical debt is not related to offshoring it is related to poor design and implementation.
> 5. Hiring and retaining local engineers could be more difficult
Well this might be true, but then again it would probably be true of any bad codebase whether developed in house or outsourced. I am sure there are in-house projects with massive God Objects also.
Also, if you hire cheapest programmers you can find, they will be crappy no matter what country they're working from.
It's not, but most of the non-techs who are interested in outsourcing are interested in optimizing for cheapness, so the result is what you'd expect.
I'd say that the real arbitrage is to work with extremely talented people (who'd go for $250/h here) at $30-40/hour (plus investment in their career, assistance with immigration if they want it, flights to conferences, and profit sharing... it's still a huge arbitrage after throwing that in) but the sorts of sleazy non-techs who "just need a programmer" and have heard there's cheap labor in the third world are not going to play that way (and they can't assess that upper level of talent anyway). They tend to work with El Sleazo outsourcing shops that charge $20-30/h and pay $4-6/h to the workers. Some of those workers, even at low wages, are quite intelligent and talented... but they're not going to care about long-term issues (e.g. tech debt) if they're just being used for temporary, low-end commodity work, with no managerial interest in their advancement.
In fact, if you're looking for clueless people ("I just need a programmer to do all the work for almost zero upside") your best bet is in Silicon Valley. There are plenty of 22-year-olds who buy into the VC mythology and will work 90 hours per week despite a lack of upper-management interest in their own careers. In the developing world, that cluelessness is rare because frank poverty, corruption and outright stealing (by well-positioned officials and common thieves alike) are more common and having that trait would mean that you starve. Working 90-hour weeks because "maybe after two years, he'll introduce me to his VC buddies" is a clueless young white boy's game.
- If the product is a success, I'm going to get some money/benefit?
- Do I need to maintain the software?
- I got a good salary?
Usually offshore developers don't have stock in the company, don't have to maintain it and they are poorly paid. So their incentive is to finish the product as fast as they can and just get the money.
If you work in-house you are more aligned with the interest of the company. You'll have to deal with this software every day(nobody wants to maintain spaguetti code) and problably you have some stock, also if the company does well you can get a raise.
It's about incentives, people optimize for its own hapinness.
If you really have to outsource then try to find the best engineers and hey, why not offer them equity if they are really good? Nothing like long term incentives to motivate people think long term.
Avoid outsourcing houses where you never get to speak to the guy who is actually doing the work, just find talented individuals. Appreciate this might be tricky for startups who don't have a clue about code reviewing but generally HN freelancing threads would be a good start.
If you optimize for cheapness, you get poor work, abroad just as here. It's not that the talent level is the problem. There's plenty of underemployed talent overseas. It's engagement. There are a zillion sleazy outsourcing shops that charge U.S. clients $30/hour and pay $6/hour on the other end. If you go cheap, you're getting people paid the same damn wage they'd get if they walked across the street to a different low-paying El Sleazo outsourcing shop, so they're not going to be engaged. This is especially true if it's obvious that you plan on replacing them with local developers once you raise an A round.
If you paid $30/hour (to worker; the cost to US client would be higher) in India or the Philippines you could attract top talent, assuming you know how to recognize it. (As in the U.S., paying highly doesn't guarantee you get good people. Look at the crap that Corporate America gets for CEOs despite paying millions per year. You actually need to be able to assess the talent, and few can.)
If you're a non-tech, not a chance. Non-techs can't tell the difference between people like me and the 99 who convincingly (to a non-tech) say they're like me within the same country, so how are they going to do it across cultural and language barriers?
Outsourcing can be profitable and, done well, it's a good thing for the world. However, nontechnical founders looking to play this first-stage-abroad game are going to lose. To get good foreign talent, a first prerequisite is to treat it with the same respect as good local talent. That means investing in their skills and careers, flying them to conferences, and treating them as (and, in fact, making them) a permanent part of the team. If you're just using them for temporary cheap labor and planning to hire permanent engineers locally once you raise a Series A, they'll figure it out (they're not stupid) and it will show in the work produced.
Personally I'd much rather have 1 ace developer than 10 of questionable value. at the corp I work at they have the luxury of going both ways, just hiring a pool of expensive devs & seeing which ones turn out to be the aces. I understand thats not feasible for startups. & lack of a technical co-founder makes singling out an ace very difficult. I'd try to get a programmer friend to pick out a likely monster programmer & start from there. Having non-technical people hire/negotiate for tech talent is just not feasible IMO. So much money trickles down the drain like that. Corps can survive it, startups can't.
These places all had in common heavy interest in outsourcing when timelines were tough. They just wanted stuff done quickly, and didn't put importance on the execution. What that does is frustrates the developers that have to fix the bugs and refactor the heavily coupled code, and ultimately makes good developers want to leave.
it's cool, it lets you keep to some level of personal standards once you have management's trust (took me about a year & a half i think? to be able to oppose a conservative architectural recommendation & win)
If the article author has been there before, wouldn't that mean someone does want to come in to a team like that?