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.
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.
I'm always confused why companies don't invest more in better teleconferencing tech. I mean, for a small fraction of the money being saved with offshore work you could have a meeting room full of screens and networked whiteboards and wearable high-quality mics and wall-mounted cameras and crystal-clear VOIP and whatnot, to put you "in the room" with your counterparts. None of this technology is science fiction.
But yeah, the inability to extract the words "I don't understand" or "I don't know" from foreign workers drives me utterly batty.
> 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.
In fact, Sococo (I work here) is a work collaboration tool; its developed in part by an Engineer from the Ukraine. Another hurdle not mentioned in the article: on day in our morning mtg (his evening mtg) he said "I have to go; we're having a revolution today". Apparently his apartment overlooked that square with all the burned couches and embattled soldiers. So, no contact with him for a few days.
Great guy, don't get me wrong! But there's lots of hurdles to an overseas relationship.
That's not exactly an everyday event outside of certain worst-case-scenario African countries.
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.
Many offshore teams don't have anywhere to put that teleconferencing equipment. They're often totally slammed for space as it is, they have relatively poor IP connectivity, sometimes they don't even have reliable power. So the cost is really the equipment plus the infrastructure upgrades, to solve only one part of the problem. It might still be worth it, but it's not a slam-dunk by any means.
I have used an offshore developer to help with some specific projects on my startup that is entering our friends and family launch this week. My experience has been fantastic.
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.
I think looking for an offshore developer is a bit different than looking for an offshore team. You likely have a more intimate relationship with your developer than someone contracting out to a team does with each of that team's members. You also talk directly with him, rather than through an intermediate team leader.
Just something to consider, these are all different cases, and as with anything it's never a one-size-fits-all.
This has been my experience as well, very well summarized.
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.
Working with offshore teams is no different than working with <anything new that you haven't done before>. You need to learn it. It is not the same as working with an in-house team. Different tradeoffs, gotchas and benefits.
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)."
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.
Regardless of industry, a non-technical founder can still offer many things, including fundraising (whether via connections or hustle), sales, admin, the boring research like talking to customers, dealing with accounting, legal... (I've also personally found that to have one person focused on figuring out what problems are worth solving, and the other on solving them, works very well, but many engineers are also good at and enjoy figuring out what problems to solve).
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".
"well, I don't know anything about construction but I can draw pictures of buildings"
That's called an architect... and they do start companies that produce buildings. Just like I'm sure there are a lot of construction guys that hire an architect. The idea does not necessarily have to be tightly coupled with the execution. It can certainly make things easier and the road to startup hell is paved with people who had an idea without any concept of how it can/should be implemented - but they can still be successful under the right conditions.
That they do, but they typically farm out the engineering component to an engineering company. This then determines the constraints within which the architect will have to work with respect to design.
There is a hybrid field called 'architectural engineering'.
This happens in construction way more than you might think. From 2005 - 2008 there were thousands of "paper generals" building houses as a way to make a quick $50 - $100k. Most of them subcontracted every aspect of the job and knew little to nothing about construction. Industries that experience a boom attract people that are looking to strike it rich.
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.
Good programmers do live all over, but there are selection effects at work. In the US programmers tend to be people who like to program. In many other countries they are a cross section of smart college grads who do it more because it is a job that pays well and can be done over the internet.
It's mostly a reflection of the ability of the non-technical people to evaluate their prospective partners. Good non-technical people will be able to compensate with effort what they lack in initial ability. You don't need to know enough to do the job, you need to know enough to evaluate whether the other party is able to do the job (and to check up on them as things progress).
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.
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.
Having worked with offshore teams and being in the role of an offshore team, I completely agree.
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.
Completely agree! Please watch out for some of these companies that will email/call you repeatedly and say "we can do Java, Python, C, COBOL anything ANYTHING!" usually they can't. With the prices they offer, it's often pretty tempting but don't be fooled that easily. Do some research into finding good shops.
Reminds of this email I got a couple of months ago from this offshoring company in India. They were claiming they could develop an Android app, no matter how big, for a flat fee of $1000. Sure.
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).
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.
Exactly! Non-technical can also mean no experience with project management. Off shore project management is a whole area of expertise that people take years to learn and perfect. Of course, that can also be outsourced. heh.
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.
Expect to refactor everything before it makes it to your baseline. Use what they produce as a starting point, not the end product.
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.
Also, if you hire cheapest programmers you can find, they will be crappy no matter what country they're working from.
- 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.
I had the same reaction. It's mostly good, but there seems to be an unstated assumption that offshore programmers will create more technical debt. Maybe it's even true. I work with what I'm sure is one of the better teams in Bangalore, and while their code is fine in most regards (no more "spaghetti" than I would expect of US programmers working in the same domain), there has been a bit of a learning curve regarding issues like readability and technical debt. I'm sure the situation is worse for other teams. Nonetheless, I wish the author had addressed the issue up front instead of just making assumptions.
this article makes offshore development equal to hiring developers that make spaghetti code full of technical debt
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.
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.
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.
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.
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.
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.
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.
yea i think this is the point that shadeless's comment misses. it's not like there is no talent in the world at large, but businesses have a hard enough time deciphering talent when they have 2 in-house developers and can read their entire code portfolio... these rubes are doomed as soon as they descend into no-man's-land.
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.
Completely agree - I've been at startups with 20-40 people where I was the best developer in the company...with 1 1/2 years of experience. I left those places quickly, it reeks of not knowing what they are doing.
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.
yep it is messy like that even at corps, but thankfully once you deliver on a few good projects & show you are reliable they will often let you rip up a codebase & re-format the project as you'd like (perhaps while phasing out the previous iteration) rather than inheriting a codebase that you feel is..... beneath you (for lack of a less pompous phrase) :D
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)
1 ace developer will have no communication overhead (internally), whereas 10 will have a ton... no contest if they are of "questionable value". Big companies/organizations do otherwise because of politics (hiring a better developer might cost more than the business manager) and incompetence (if business people are picking, they usually can't tell the difference). But smaller, stronger teams are ALWAYS better, outsourcing or not.
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.