I don't think you can over-emphasize the challenges in communication with off-shore teams. I have worked with several in corporate IT and just reaching a minimal baseline of understanding has proven difficult.<p>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.<p>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.<p>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.
Non-technical founder is a weird catch all. You never really hear about non technical founders in other industries, right? You don't start a construction company and say "Well, I don't know anything about construction but I can draw pictures of buildings, so I'll just hire someone that does (barring for a moment that I lack the knowledge about the profession that would allow me to judge talent in the first place)."<p>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.<p>One rule I've found useful: don't ask people to do things you can't (potentially badly) do yourself.
Main problem is that someone in US just can't get the relevant info on 99% of the overseas teams out there. The ones that you first google out are usually the ones who advertise the most and who generally always oversell their resources, and thus produce really bad results. Experienced small teams usually already have a number of clients, work hard and are not that visible or fast growing. So try playing smarter and avoid corporate outsourcing channels, and instead reach out to overseas developers' communities on twitter and conferences and contact developers and teams directly. You'll get much better results.
That's a pretty good article. (If you're reading this, there is a 'they're' where it should be 'their' in the 2nd bullet).<p>What I miss is that the article places the weight of the potential problems with the party that is being hired.<p>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.<p>This can result in lots of drama down the line.
Always remember - outsource developers have "no skin in the game" and thus will likely not make that little bit of extra effort that pays off long term. This can be horribly frustrating when you care about such things as efficient communications, consistent code style, or code that has even a remote chance at long term maintenance. Naming (classes, variables, functions) is everything, and don't expect much here. Having even in-house contractors gives you a chance directing them toward better quality software.<p>Expect to refactor everything before it makes it to your baseline. Use what they produce as a starting point, not the end product.
The majority of these points relate to all outsourcing development whether if it's onshore or offshore. In fact it applies for in house development.<p>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.<p>> 1. It’s extremely difficult to judge the quality of outsourced work without your own local engineer<p>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.<p>> 2. Prepare to work some odd hours and deal with communication issues<p>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.<p>However I do realise a 12 hour difference can be difficult.<p>> 3. Things will get lost when you transition to a permanent local team<p>Bring on any new developer to an established codebase and they are going to need time to catch up.<p>> 4. Each feature can become a line item in your technical debt<p>This point does not even make sense. Technical debt is not related to offshoring it is related to poor design and implementation.<p>> 5. Hiring and retaining local engineers could be more difficult<p>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.
I don't like how this article makes offshore development equal to hiring developers that make spaghetti code full of technical debt, like having someone in-house magically stops that from happening.<p>Also, if you hire cheapest programmers you can find, they will be crappy no matter what country they're working from.
Benefits to physical co-location at a startup stage (where you want to be moving very fast) are not to be overlooked. There's a reason people go to the lengths of living in the same house when working on a startup.<p>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.<p>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.
Nontechs like outsourcing because they think it's cheap. This makes them bad at playing the outsourcing game to win. If you go for the cheap, you lose.<p>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.<p>If you paid $30/hour (to worker; the cost to US client would be higher) in India or the Philippines you <i>could</i> 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.)<p>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 <i>within the same country</i>, so how are they going to do it across cultural and language barriers?<p>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.
<i>Nobody wants to come into a team with five overseas developers, two servers, and no version control, but I’ve been there before.</i><p>If the article author has been there before, wouldn't that mean someone <i>does</i> want to come in to a team like that?