Ask HN: Why don't startups outsource/offshore development if salaries are low?
91 comments
A combination of reasons:
1) Most companies are not institutionally comfortable with remote working, to say nothing of remote working internationally.
2) There exist pervasive skill gaps between talented engineers available to work at $150k per year and talented engineers available to work for $12k per year. I respect that many people wished this was not the case.
3) Many investors in the Valley, whose opinions are quite relevant given that one cannot self-fund employee salaries, are of the opinion that outsourcing development work suggests a tech company which will never achieve the path to $100 million in revenue followed by a $N billion valuation, which is what their business model counsels them to search for. They would point out "I cannot think of a single company whose product was not produced in-house in history which achieved that" and they would not be far from wrong.
4) Managing outsourced development is a skill, and its a skill that most companies and individuals suck at, and do not particularly wish to become great at.
5) It is the widespread perception in the American tech industry that BPO companies produce software whose quality is abominable and that the process of dealing with them is pathological, as evidenced by the fact that only companies which institutionally hate software and software people are willing to work with BPO companies. Many in the American tech industry do not hate software or software people, and thus would have a very high bar to be convinced to use a BPO company.
1) Most companies are not institutionally comfortable with remote working, to say nothing of remote working internationally.
2) There exist pervasive skill gaps between talented engineers available to work at $150k per year and talented engineers available to work for $12k per year. I respect that many people wished this was not the case.
3) Many investors in the Valley, whose opinions are quite relevant given that one cannot self-fund employee salaries, are of the opinion that outsourcing development work suggests a tech company which will never achieve the path to $100 million in revenue followed by a $N billion valuation, which is what their business model counsels them to search for. They would point out "I cannot think of a single company whose product was not produced in-house in history which achieved that" and they would not be far from wrong.
4) Managing outsourced development is a skill, and its a skill that most companies and individuals suck at, and do not particularly wish to become great at.
5) It is the widespread perception in the American tech industry that BPO companies produce software whose quality is abominable and that the process of dealing with them is pathological, as evidenced by the fact that only companies which institutionally hate software and software people are willing to work with BPO companies. Many in the American tech industry do not hate software or software people, and thus would have a very high bar to be convinced to use a BPO company.
A large piece of delivering value to a business as a developer is, in the words of PG, "knowing what to build, not just how to build." Day-to-day, an on-site developer might be expected to sift through customers' feedback, join in on customer meetings, visit a customer to watch their product being used, and have the opportunity to overhear what issues the customer service team seems to be dealing with over and over again. He or she may well end up writing fewer lines of code than a remote developer because of these interruptions, but when those fewer lines of code have a greater financial impact on the business, the business is happy to continue to pay 10x salaries.
Also, many startups strive for amazing customer service, which usually means fixing issues on the spot when a customer calls in, American business hours. (I realize many remote developers are in similar time zones, but it is worth noting.)
Also, many startups strive for amazing customer service, which usually means fixing issues on the spot when a customer calls in, American business hours. (I realize many remote developers are in similar time zones, but it is worth noting.)
Seems like the optimal mix of skills and location is; find someone local that is good at doing what you're talking about and teach/force them to get good at #4 on patio11's list.
This one person (or small local team) can then 1) drive the product 2) act as a project manager with a big workforce and 3) stop coding, start reviewing code written by the minions and 4) get them where they need to be on new tech stack etc.
Timezone issues should be minor. Even people in the US should only be in the office 1/3 of the day. You need to rethink your whole management style, prioritization-wise if you run into problems like commonly needing stuff during off peak times. (Or, just hire a rotating shift so you have a 24 hr staff in Asia).
This one person (or small local team) can then 1) drive the product 2) act as a project manager with a big workforce and 3) stop coding, start reviewing code written by the minions and 4) get them where they need to be on new tech stack etc.
Timezone issues should be minor. Even people in the US should only be in the office 1/3 of the day. You need to rethink your whole management style, prioritization-wise if you run into problems like commonly needing stuff during off peak times. (Or, just hire a rotating shift so you have a 24 hr staff in Asia).
> Even people in the US should only be in the office 1/3 of the day.
A Silicon Valley startup /generally/ has most of their customers in the US. Both US businesses and US consumers have a cultural expectation that issues be resolved quickly within business hours, but are usually more forgiving at 9 PM at night. (For example, if I call my bank at 3 PM, I expect a resolution darn near immediately; if I called at 11 PM I would expect to leave a voicemail. In both scenarios I am equally satisfied, even though in the first I received an immediate solution and in the second I did not.)
It's not a matter of having developers on call 24/7, but in having the 8 hours they are online overlap the 8 hours that the customer base expects prompt service.
A Silicon Valley startup /generally/ has most of their customers in the US. Both US businesses and US consumers have a cultural expectation that issues be resolved quickly within business hours, but are usually more forgiving at 9 PM at night. (For example, if I call my bank at 3 PM, I expect a resolution darn near immediately; if I called at 11 PM I would expect to leave a voicemail. In both scenarios I am equally satisfied, even though in the first I received an immediate solution and in the second I did not.)
It's not a matter of having developers on call 24/7, but in having the 8 hours they are online overlap the 8 hours that the customer base expects prompt service.
I'd argue that you're talking about customer service, not software development. That's a different topic, I agree customer service should be responsive and local to customers.
If you notified your bank of some technical issue. They would probably respond thanking you and telling you that they would look into it. I would be very surprised if they followed up with you to tell you when it was fixed (although, that would be great service)
Edit: just to add, the software dev on site can review customer services logs asynchronously, he shouldn't need to be the one actually working the customer service queue
If you notified your bank of some technical issue. They would probably respond thanking you and telling you that they would look into it. I would be very surprised if they followed up with you to tell you when it was fixed (although, that would be great service)
Edit: just to add, the software dev on site can review customer services logs asynchronously, he shouldn't need to be the one actually working the customer service queue
Someobe local with the talent to drive product, mentor technical teams and manage a remote client is probably going to be either very expensive or a hoy commodity or interested in founding their own company. The combination of these skill sets isn't exactly common.
So, if you finding someone like that, how are you going to convince them to work on your problem?
So, if you finding someone like that, how are you going to convince them to work on your problem?
This. Is what I do, exactly!
most of the times, I work _with_ the client's in house dev teams so that they can take over when we are done. I _love_ this model as everybody wins.
Key is to staff with the right people offshore.
most of the times, I work _with_ the client's in house dev teams so that they can take over when we are done. I _love_ this model as everybody wins.
Key is to staff with the right people offshore.
I know of some social media startups in LA that are doing OK that outsource their development to a particular shop in India that specializes in that kind of work.
As for the quality of developers, you will find everything across the board. The best shops in India are process driven and serious about continuous improvement and can be a joy to work with. The dirty little secret of IBM Watson and other commercial NLP systems is that it takes a small army to code those kind of things and you can get the manpower there.
I think the #1 fear about a tech company outsourcing is that you don't really control the intellectual property. This might not matter so much if you are running a two-sided market (Uber could outsource development because anybody who wants to rip them off has to go fight city hall in thousands of places) but if you really are a "tech" company you want to keep your knowledge close.
As for the quality of developers, you will find everything across the board. The best shops in India are process driven and serious about continuous improvement and can be a joy to work with. The dirty little secret of IBM Watson and other commercial NLP systems is that it takes a small army to code those kind of things and you can get the manpower there.
I think the #1 fear about a tech company outsourcing is that you don't really control the intellectual property. This might not matter so much if you are running a two-sided market (Uber could outsource development because anybody who wants to rip them off has to go fight city hall in thousands of places) but if you really are a "tech" company you want to keep your knowledge close.
Why wouldn't you control the IP with outsourced development? Obviously, any competent company would make the outsourced developers / development house hand over all rights to anything they produce under contract so this would be a non-issue.
YM, of course, MV, but I've worked with outsourced teams (plural) before and the decisions I've observed have suggested to me that, regardless of whatever IP agreements you've made, some will obviously be trying to build stuff they can reuse elsewhere. It's hard to enforce an IP agreement when you're in Boston and they're a couple continents away.
Legal threats against ex-employees based in your home country carry an awful lot more weight than legal threats against a subcontractor based in India, Russia or China.
And, surely, they will honor their contracts to the letter.
Your employees might take home your entire code base in the US, while working on-site on an air-gapped network. They can certainly do it when you're set up for remote work, almost by definition. In the US, the payoff for stealing your employer's code is low, and the risk of punishment high, but it still happens. I can't speak for non-US countries, but I would guess that most have a bit more relaxed attitude toward enforcement, especially when it would be on behalf of a US company.
If you think your IP is secure from the software developers who wrote it, you do not understand how they work. If you do not hold the loyalty of your developers, you do not control the IP, regardless of what the contracts say.
Your employees might take home your entire code base in the US, while working on-site on an air-gapped network. They can certainly do it when you're set up for remote work, almost by definition. In the US, the payoff for stealing your employer's code is low, and the risk of punishment high, but it still happens. I can't speak for non-US countries, but I would guess that most have a bit more relaxed attitude toward enforcement, especially when it would be on behalf of a US company.
If you think your IP is secure from the software developers who wrote it, you do not understand how they work. If you do not hold the loyalty of your developers, you do not control the IP, regardless of what the contracts say.
Thanks for clarifying. I actually hadn't thought of them stealing the IP despite the contract, but it makes sense that it'd happen.
Also, HR practices of startups leave much to be desired. I've sent 20 emails more than a month ago to companies who had remote positions for developers (stackoverflow, github and wfh.io). Only two bothered with reply (one interview, one "sorry, no non-us developers").
I think this is common across the board. The exceptions are the HR departments that keep applicants and interested parties updated and answer your questions quickly.
BPO: Business Process Outsourcing
(since I didn't know)
(since I didn't know)
Even though some of patio11's post seems like opinion, he is correct on all points.
Regarding item 3, another perspective is that a lot of the outsourcing/off-shoring happens because it is something that is not a core competency of the company. Think any ERP system (SAP, Oracle, etc.) which is basically a CRUD app on steroids. If your company doesn't make ERP systems then you want the lowest skilled bidder doing the work. Is that the case for a tech startup?
It also requires almost the same count of people to offshore the work as it does to do it yourself. You need someone who can interface with the offshore team, answer questions about requirements (if they are even asked), etc. And deal with turnover.
You might be asking why any sane company would do this then? Simply cost but also accounting rules. When a company buys a service from another vendor (like buying bandwidth) I think it shows up differently on the books than when they have an entire department of people doing that work. That entire department needs to have retirement plans, benefits, vacation time, etc. and they show up in the employee count reported to shareholders. This nuance is probably why the counter-intuitive stock price increase happens after a massive layoff.
Regarding item 3, another perspective is that a lot of the outsourcing/off-shoring happens because it is something that is not a core competency of the company. Think any ERP system (SAP, Oracle, etc.) which is basically a CRUD app on steroids. If your company doesn't make ERP systems then you want the lowest skilled bidder doing the work. Is that the case for a tech startup?
It also requires almost the same count of people to offshore the work as it does to do it yourself. You need someone who can interface with the offshore team, answer questions about requirements (if they are even asked), etc. And deal with turnover.
You might be asking why any sane company would do this then? Simply cost but also accounting rules. When a company buys a service from another vendor (like buying bandwidth) I think it shows up differently on the books than when they have an entire department of people doing that work. That entire department needs to have retirement plans, benefits, vacation time, etc. and they show up in the employee count reported to shareholders. This nuance is probably why the counter-intuitive stock price increase happens after a massive layoff.
Yes, remote working maybe not an option, but founders can visit and open their development office. I have worked for 3 companies so far and all of them are selling product in overseas and doing development here, by putting someone experienced as a CTO in development office.
Ratio between salary ($150K vs $12K ) are too high comparing to ratio of skillset, 10x low salary doesnt mean 10x low skillset, thats just financial state in countries. A lot of guys are working at Amazon, Google, Microsoft and other big corps who took experience here, developers are not bad, they might not have enough experience.
~$300K is avg. spending for 10 developers with office and perks included annually. Compare it to $750K spending for 5developers where each of them has 2x skillset of outsorced developer just for salary and other spendings annually, which I guess will be around $1M/annually.
Ratio between salary ($150K vs $12K ) are too high comparing to ratio of skillset, 10x low salary doesnt mean 10x low skillset, thats just financial state in countries. A lot of guys are working at Amazon, Google, Microsoft and other big corps who took experience here, developers are not bad, they might not have enough experience.
~$300K is avg. spending for 10 developers with office and perks included annually. Compare it to $750K spending for 5developers where each of them has 2x skillset of outsorced developer just for salary and other spendings annually, which I guess will be around $1M/annually.
It's tricky. Being 2x better means 1/2 time to delivery, 1/2 maintenance burden, 2x more flexible software, and 1/2 the management burden, and very often all at the same time. It's also much harder to find cream of the crop workers in cultures you are less familiar with, so the average case (where some people are quite bad at it) is, from what I've seen, a little larger than 2x. Maybe 3-4x, sometimes more? And compounding across all those disadvantages (2x more work to make a change due to worse design, 2x times slower because of lower skill, with every week needing 2x as much management, slowed down by the extra daily operations and keeping-things-going, can be... a lot), it can actually work out to be a worse deal unless you're pretty careful. Personal experience shows that this involves both careful hiring and on the job training.
> I have worked for 3 companies so far and all of them are selling product in overseas and doing development here, by putting someone experienced as a CTO in development office.
That's great (no snark intended) if you have a CTO who wants to move to Central Asia. Most startups probably don't.
That's great (no snark intended) if you have a CTO who wants to move to Central Asia. Most startups probably don't.
(3) is also a significant problem for competent technical teams located in a single city with a substantially lower cost-of-living than SV, possibly even within the US, of course. Locating themselves in SV isn't especially likely to make the core team any better at writing software or generating revenue
(unless writing the software depends on making new hires with unusual skillsets or the revenue model depends on developing partnerships with SV companies) but for business models that will rely on multiple rounds of investment regardless of how frugal they are on salaries, conformity to VCs' selection heuristics is far more of a prerequisite for success than effective cashflow management.
My experience working at a startup that started out outsourced and slowly started adding inhouse developers:
It was mostly a mess.
1) Time/Cultural/Language barriers are inevitably the biggest problem. Want an answer to something critical right now? Too bad, it's 2 AM there and no one's around.
You're going to end up scheduling meetings at insane hours, and someone's going to get burned out on that.
I also had the fortune of watching an email thread where someone used a colloquialism ("Move it over just a smidge") and it took three days to resolve (because of the time differences) what that meant.
2) This is going to sound super snotty, but I'll just say it: There was a definite feeling of "you're still over there because you're not good enough for anyone to sponsor you for an H1B".
In general the really talented developers I met left quickly because they found someone willing to sponsor them. What was left was... well, what was left.
The salary gap is so severe that it becomes a lot harder to say "I want to stay near my family and friends." If someone offered me 100x my current salary to move to, well, anywhere, I'd be packed in 5 minutes.
It was mostly a mess.
1) Time/Cultural/Language barriers are inevitably the biggest problem. Want an answer to something critical right now? Too bad, it's 2 AM there and no one's around.
You're going to end up scheduling meetings at insane hours, and someone's going to get burned out on that.
I also had the fortune of watching an email thread where someone used a colloquialism ("Move it over just a smidge") and it took three days to resolve (because of the time differences) what that meant.
2) This is going to sound super snotty, but I'll just say it: There was a definite feeling of "you're still over there because you're not good enough for anyone to sponsor you for an H1B".
In general the really talented developers I met left quickly because they found someone willing to sponsor them. What was left was... well, what was left.
The salary gap is so severe that it becomes a lot harder to say "I want to stay near my family and friends." If someone offered me 100x my current salary to move to, well, anywhere, I'd be packed in 5 minutes.
"This is going to sound super snotty, but I'll just say it: There was a definite feeling of "you're still over there because you're not good enough for anyone to sponsor you for an H1B"."
Wow this is precious.
Not everybody wants to leave their country for more money. This is the most ridiculous comment I've seen in February.
Wow this is precious.
Not everybody wants to leave their country for more money. This is the most ridiculous comment I've seen in February.
> Not everybody wants to leave their country for more money
We're not talking about $100. We're talking about orders of magnitudes of your salary. That's a shitload of money.
When you start getting into magnitudes of money like that, things like nationalities and being close to your family become extremely malleable.
If you wouldn't make that choice: great. I would, and I would bet a sizeable majority of people would be totally willing to move to another country to make 100x their current salary.
We're not talking about $100. We're talking about orders of magnitudes of your salary. That's a shitload of money.
When you start getting into magnitudes of money like that, things like nationalities and being close to your family become extremely malleable.
If you wouldn't make that choice: great. I would, and I would bet a sizeable majority of people would be totally willing to move to another country to make 100x their current salary.
The financial disparity looks rather less clear-cut when you talk about how you get to actually spend the money though.
If your $12k a year pays for you and your family to live in a spacious villa, and a full time nanny for the kids whilst still leaving enough left over to be able to save up for a biannual new MacBook, you're going to get a rude shock when you realise what $120,000 before tax actually means in San Francisco, especially if you don't intend to leave the family behind.
In that context, staying at home suddenly looks a lot more attractive, especially if you're aware of just how rich by local standards you'll be if you manage to build enough reputation as a remote contractor to triple your rates in future.
In that context, staying at home suddenly looks a lot more attractive, especially if you're aware of just how rich by local standards you'll be if you manage to build enough reputation as a remote contractor to triple your rates in future.
$12k doesn't go that far. Maybe $25k ;)
Perhaps to westerners and perhaps to you. To other people, that is not necessarily always the case. For example, my family has lived in the city where I reside for less than 100 years. This is my home but it's not my ancestral home.
If I were from India, if my family had a connection to an area that went back hundreds or possibly even thousands of years to a region, if I could live similarly to how I live here on the kind of salary the job pays there, I wouldn't be in a big rush to leave either.
Would I leave this area to make 10x what I earn now? Probably. If I left for 5-10 years, I could come back and retire.
Is there any pressing or burning need? No. Not at all.
Even though I could be persuaded to go somewhere else, there are still limits to where I'd go. I wouldn't move to North Korea, even to make 20x my current income. I wouldn't move to any of the former Soviet republics. I wouldn't move to most of Central or South America. I wouldn't move to most of Africa.
I get it, for you, most of these concerns are trivial but that's simply not the case for a lot of people.
If I were from India, if my family had a connection to an area that went back hundreds or possibly even thousands of years to a region, if I could live similarly to how I live here on the kind of salary the job pays there, I wouldn't be in a big rush to leave either.
Would I leave this area to make 10x what I earn now? Probably. If I left for 5-10 years, I could come back and retire.
Is there any pressing or burning need? No. Not at all.
Even though I could be persuaded to go somewhere else, there are still limits to where I'd go. I wouldn't move to North Korea, even to make 20x my current income. I wouldn't move to any of the former Soviet republics. I wouldn't move to most of Central or South America. I wouldn't move to most of Africa.
I get it, for you, most of these concerns are trivial but that's simply not the case for a lot of people.
I would love to know where you can outsource things for 100X less than US?
Two more things, what about cost of living? and do you know how tough it is to get an H1B unless you have studied in US. (my guess, no!)
Two more things, what about cost of living? and do you know how tough it is to get an H1B unless you have studied in US. (my guess, no!)
Can not agree with "you're still over there because you're not good enough for anyone to sponsor you for an H1B".
There are 2 reasons I see now:
1. Living cost ratio. Well, you might get 10x salary comparing to Asian developer, but living cost is not at the same rate. 100x is different story, but again related to living cost, you might jump in there, when you get there you might end up with 101x living cost.
2. Assume every knowledgable person will leave their homes for 10x salary, 7x living cost and they are earning 3x of money and country will end up with idiots, slow development, slow financial growth in whole country. It takes some time for developing countries to be in decent place if professionals do not leave, it takes forever to be in good place if everyone will leave just for 3x or maybe 10x.
There are 2 reasons I see now:
1. Living cost ratio. Well, you might get 10x salary comparing to Asian developer, but living cost is not at the same rate. 100x is different story, but again related to living cost, you might jump in there, when you get there you might end up with 101x living cost.
2. Assume every knowledgable person will leave their homes for 10x salary, 7x living cost and they are earning 3x of money and country will end up with idiots, slow development, slow financial growth in whole country. It takes some time for developing countries to be in decent place if professionals do not leave, it takes forever to be in good place if everyone will leave just for 3x or maybe 10x.
> living cost is not at the same rate
I knew this was going to be brought up, but it's not enough to overcome the monumental salary gap. Your example of developers earning "$2k" just made me think that I invest $2k a month, not even what I save in total each month.
The living cost is obviously much different. There's still really just no comparison, in terms of net compensation.
> Assume every knowledgable person will leave their homes for 10x salary, 7x living cost and they are earning 3x of money and country will end up with idiots, slow development, slow financial growth in whole country
That's all well and good, and you're right, but the individual ends up being much better off by leaving. Brain drain, as it's called.
Rhetoric like "do it for your country" is good in theory, but individuals who leave have an opportunity to help themselves and their families out immensely via monetary gain.
It's really, really hard to ignore that.
I knew this was going to be brought up, but it's not enough to overcome the monumental salary gap. Your example of developers earning "$2k" just made me think that I invest $2k a month, not even what I save in total each month.
The living cost is obviously much different. There's still really just no comparison, in terms of net compensation.
> Assume every knowledgable person will leave their homes for 10x salary, 7x living cost and they are earning 3x of money and country will end up with idiots, slow development, slow financial growth in whole country
That's all well and good, and you're right, but the individual ends up being much better off by leaving. Brain drain, as it's called.
Rhetoric like "do it for your country" is good in theory, but individuals who leave have an opportunity to help themselves and their families out immensely via monetary gain.
It's really, really hard to ignore that.
Actually nope.
Cost of living matters. A lot.
It directly affects the kinds of things you can afford. Out here (in India), I can easily afford: house rent + groceries for a 2 bedroom apartment ( ~2000USD per year ), paying a cook to cook twice everyday ( 800USD per year ), paying someone to clean my house once a week. ( 200 USD per year ) and still manage to save up more than 50% of my paycheck - after paying 30% taxes.
Neither the places abroad offering me to move there nor any of my friends living there have these luxuries. That's why most of my friends working abroad want to come back to India "after making enough money". Especially the married folk, who are expecting babies.
Also the pay difference is really not as high as you'd think it is.Most decent companies (Google, Amazon, etc.. ) here pay you around 40k USD per year for a guy with 3-4 years experience. Most of my freelancer friends here seem to be making more than that actually.
Cost of living matters. A lot.
It directly affects the kinds of things you can afford. Out here (in India), I can easily afford: house rent + groceries for a 2 bedroom apartment ( ~2000USD per year ), paying a cook to cook twice everyday ( 800USD per year ), paying someone to clean my house once a week. ( 200 USD per year ) and still manage to save up more than 50% of my paycheck - after paying 30% taxes.
Neither the places abroad offering me to move there nor any of my friends living there have these luxuries. That's why most of my friends working abroad want to come back to India "after making enough money". Especially the married folk, who are expecting babies.
Also the pay difference is really not as high as you'd think it is.Most decent companies (Google, Amazon, etc.. ) here pay you around 40k USD per year for a guy with 3-4 years experience. Most of my freelancer friends here seem to be making more than that actually.
And:
3. The number of good developers is unrelated to the number of H1-B issued
3. The number of good developers is unrelated to the number of H1-B issued
The truth is that the good developers aren't making 100x less in most of the developed countries. Most of the good developers I know in India are earning in 25-40K range with lots of tax benefits. Expenses are less than 10K even if you live a good lifestyle.
Retained value.
The reality of a lot of development is that you, as a developer, learn about the domain in which you're working, and also grow your skills with each subsequent project you work on.
As an employer, it's desirable to pay someone to do work, and then to have that person do more work for you, and as they know the subject matter better and better and as they progress as a developer, the value they present to you grows. Additionally, this is good for the employee, as unless you're in a moribund steady-state company (i.e. so long as you're in a startup) you're there for the journey, and you develop in step with the company, and get to witness and learn a lot of stuff "at the ground floor".
Conversely, if you hire a contractor, the moment they're "done", that value walks out of the door, and if you want to do further product development, you need to train someone up, get them familiar with the existing codebase, and so-forth - and this is expensive, and if your contractor hasn't documented stuff thoroughly - you're up the brown creek without a propulsion instrument.
Seeing contractors/outsourced dev as a "cheaper" option is a false economy. Sure, it might be cheap in the short term, but it's a hell of a lot pricier in the long term.
The reality of a lot of development is that you, as a developer, learn about the domain in which you're working, and also grow your skills with each subsequent project you work on.
As an employer, it's desirable to pay someone to do work, and then to have that person do more work for you, and as they know the subject matter better and better and as they progress as a developer, the value they present to you grows. Additionally, this is good for the employee, as unless you're in a moribund steady-state company (i.e. so long as you're in a startup) you're there for the journey, and you develop in step with the company, and get to witness and learn a lot of stuff "at the ground floor".
Conversely, if you hire a contractor, the moment they're "done", that value walks out of the door, and if you want to do further product development, you need to train someone up, get them familiar with the existing codebase, and so-forth - and this is expensive, and if your contractor hasn't documented stuff thoroughly - you're up the brown creek without a propulsion instrument.
Seeing contractors/outsourced dev as a "cheaper" option is a false economy. Sure, it might be cheap in the short term, but it's a hell of a lot pricier in the long term.
Someone who want to take advantage of this income gap would probably be better of starting a company in Asia. Since the web is global you can sell to customers in nearly any country. It might be good to target the domestic market first though, and then expand abroad.
I work as an Engineer at a VC backed ($20m from two rounds) product company in the US. We used outsourced Engineers for most of our developers. We are located not located in Silicon Valley but some of our VC's are from the valley.
Our founder & CTO has experience with co-founding another successful startup ($25-$50 million in revenue) with an outsourced engineering team, which I also and many of our team members also worked at.
The engineers we have employed in Kiev are very good. However, working with outsourced engineers is still very challenging. One of the things that allows us to be successful is our experience with it and what we've learned from our mistakes at our previous company. I wouldn't recommend it for your average company.
Our founder & CTO has experience with co-founding another successful startup ($25-$50 million in revenue) with an outsourced engineering team, which I also and many of our team members also worked at.
The engineers we have employed in Kiev are very good. However, working with outsourced engineers is still very challenging. One of the things that allows us to be successful is our experience with it and what we've learned from our mistakes at our previous company. I wouldn't recommend it for your average company.
Outsourcing works if you're able to define the requirements of new features in extreme detail, covering every nuance and edge case. This is the opposite of what start ups are all about: incremental steps and iterations.
The result of outsourcing in start ups frequently ends up with a most of misunderstanding and back and forth. Code not written with potential business needs in mind, and everything that goes with that.
It would be cheaper if it took the same time as doing locally and provided same level of quality. This usually doesn't happen. So what's saved in developer salaries is spent in founder/product manager time and delay of release.
The result of outsourcing in start ups frequently ends up with a most of misunderstanding and back and forth. Code not written with potential business needs in mind, and everything that goes with that.
It would be cheaper if it took the same time as doing locally and provided same level of quality. This usually doesn't happen. So what's saved in developer salaries is spent in founder/product manager time and delay of release.
Remote development is the absolute slowest way to get anything done. Startups need speed, a lot of the time.
I've worked with every arrangement of developer mgmt on websites I've built. Inside, outside, agencies, freelancers, directly managed on agile teams, separate departments on semi-waterfall teams. Outsourcing works best when you have a lot of predictable work to do, for example (these are from my direct experience)
1) upgrading a CMS in an environment with lots of custom app dev. (Say what you will about how much it makes sense to write custom apps in a CMS; I agree with you). When we decided to prioritize the upgrade over new work, we got outside devs to work alongside the local agile team, to do the more predictable, less troublesome work.
2) Retrofitting secure forms processing onto an existing CMS where (to reduce attack surface) the secure site did not run inside the CMS, but used HTML exported from the CMS (for design/nav elements etc.). I actually think this would have been better with internal staff, but the one-off nature of the project meant that hiring FT was not possible.
I just don't see running a startup that either of these situations (or their analogues) will come up. For a startup you need fewer staff, doing less management and more work, as quickly as possible (most of the time). You need people who get code, get security, can manage a server, can set up a heroku app, etc. WITHOUT a lot of oversight because you are just not prepared, or too busy to do it.
I've worked with every arrangement of developer mgmt on websites I've built. Inside, outside, agencies, freelancers, directly managed on agile teams, separate departments on semi-waterfall teams. Outsourcing works best when you have a lot of predictable work to do, for example (these are from my direct experience)
1) upgrading a CMS in an environment with lots of custom app dev. (Say what you will about how much it makes sense to write custom apps in a CMS; I agree with you). When we decided to prioritize the upgrade over new work, we got outside devs to work alongside the local agile team, to do the more predictable, less troublesome work.
2) Retrofitting secure forms processing onto an existing CMS where (to reduce attack surface) the secure site did not run inside the CMS, but used HTML exported from the CMS (for design/nav elements etc.). I actually think this would have been better with internal staff, but the one-off nature of the project meant that hiring FT was not possible.
I just don't see running a startup that either of these situations (or their analogues) will come up. For a startup you need fewer staff, doing less management and more work, as quickly as possible (most of the time). You need people who get code, get security, can manage a server, can set up a heroku app, etc. WITHOUT a lot of oversight because you are just not prepared, or too busy to do it.
I have had both very positive and very negative experiences with outsourcing development. Regardless of country including within the States.
Yes, we can find cheaper labor in other countries. Yes we can mostly overcome language issues, time differences etc. But one thing that is not insurmountable is the number of times the tech I have paid for would wind up in other peoples hands. The problem is not unique to other countries as it happens within the US too, but at least within our own legal system there are ways to protect clients and ourselves better. When dealing Internationally, the chances for a startup to guard their intellectual property and competitive advantage is far less likely.
And honestly, the companies that have been most successful in outsourcing Internationally, generally have a presence in Country. Microsoft, Oracle, GE among hundreds of others (I did this for/with GE for a time period). For a startup splitting a small team Internationally to try and save on what should be a core skillset and competitive advantage just doesn't make sense. Not to mention, the only thing of value for a startup early on is the team they assemble. If that team is not dedicated, is out sourced and worse yet, outsourced Internationally, the startup will struggle to gain the attention of investors if that is what they desire.
Last point, if you are bootstrapping then the equation (and risk profile) can change. It may be to your benefit to try and have some (IMO non-core) components of your software built offshore. Just takes some management and willingness to spend the extra time on documentation and communication. Additionally, for a well funded startup in later rounds they may choose to offshore parts of their development to help move things along because they have the ability to take some risk on there, and their core IP is already developed.
Yes, we can find cheaper labor in other countries. Yes we can mostly overcome language issues, time differences etc. But one thing that is not insurmountable is the number of times the tech I have paid for would wind up in other peoples hands. The problem is not unique to other countries as it happens within the US too, but at least within our own legal system there are ways to protect clients and ourselves better. When dealing Internationally, the chances for a startup to guard their intellectual property and competitive advantage is far less likely.
And honestly, the companies that have been most successful in outsourcing Internationally, generally have a presence in Country. Microsoft, Oracle, GE among hundreds of others (I did this for/with GE for a time period). For a startup splitting a small team Internationally to try and save on what should be a core skillset and competitive advantage just doesn't make sense. Not to mention, the only thing of value for a startup early on is the team they assemble. If that team is not dedicated, is out sourced and worse yet, outsourced Internationally, the startup will struggle to gain the attention of investors if that is what they desire.
Last point, if you are bootstrapping then the equation (and risk profile) can change. It may be to your benefit to try and have some (IMO non-core) components of your software built offshore. Just takes some management and willingness to spend the extra time on documentation and communication. Additionally, for a well funded startup in later rounds they may choose to offshore parts of their development to help move things along because they have the ability to take some risk on there, and their core IP is already developed.
Two things:
1) You don't outsource your core in business, so outsourcing tech is not appealing for tech startups, period.
2) Typically tech startups are more of a growth optimization problem than a cost optimization problem. Outsourcing to cheaper parts of the US, let alone overseas, usually doesn't increase the startup's growth potential.
1) You don't outsource your core in business, so outsourcing tech is not appealing for tech startups, period.
2) Typically tech startups are more of a growth optimization problem than a cost optimization problem. Outsourcing to cheaper parts of the US, let alone overseas, usually doesn't increase the startup's growth potential.
Your [1] is flawed because what is core is continuously shifting as the advantages of the knowledge you can get somewhere else exceed the costs.
An example from banking:
"Morgan Stanley has about 500 people employed in India doing research and statistical analysis. About 100 of Goldman Sachs’ 3,000 employees in Bangalore are working on investment research."
http://www.nytimes.com/2008/08/12/business/worldbusiness/12i...
An example from banking:
"Morgan Stanley has about 500 people employed in India doing research and statistical analysis. About 100 of Goldman Sachs’ 3,000 employees in Bangalore are working on investment research."
http://www.nytimes.com/2008/08/12/business/worldbusiness/12i...
Be careful not to conflate offshoring with outsourcing, which the article does. Some startups will have their own employees overseas, but my point is specifically about outsourcing to other companies.
> Be careful not to conflate offshoring with outsourcing
Ups, thats my fault, lets add offshoring to the title.
Ups, thats my fault, lets add offshoring to the title.
Great clarification
1) the tech is rarely the product (so, rarely the core), does the end user care how nice the code is? what's the stack? or that it just works and provides a valuable service?
2) OP's point is that you should spend less on dev and more on marketing thus, more optimized for growth(?)
2) OP's point is that you should spend less on dev and more on marketing thus, more optimized for growth(?)
Every hire is so crucial early on and one bad hire can really set you back. I know from my experience that early hires are typically done through connections rather than recruitment. I am sure there are very qualified candidates overseas but finding the right guy would be seemingly much more difficult without any prior knowledge or experience with the candidate.
I am sure this is very dependent on the company and technology. But generally every startup I have worked at has depended on a core group of developers early and they usually had some prior history or at least connection.
I can imagine this might be different for founders without a tech background... and anecdotally that appears to be true (non tech founders appear to be more open to outsourced development). That's pure speculation.
I am sure this is very dependent on the company and technology. But generally every startup I have worked at has depended on a core group of developers early and they usually had some prior history or at least connection.
I can imagine this might be different for founders without a tech background... and anecdotally that appears to be true (non tech founders appear to be more open to outsourced development). That's pure speculation.
Finding talent is one of the biggest challenges facing my startup and most at the moment (and most/ all other start ups I know).
I would rather hire someone who I can meet face to face most days as you just don't get the same dialogue working remotely as you do when you're sitting on the same table. This is coming from someone who as worked as a consultant working mostly remotely for the last 6-8 years, and I did a degree remotely.
If I can't find a quality JS dev in London (it's not as easy as you would assume, but then I've only just raised money), then I'm willing to outsource portions. Still have a number of options!
I would rather hire someone who I can meet face to face most days as you just don't get the same dialogue working remotely as you do when you're sitting on the same table. This is coming from someone who as worked as a consultant working mostly remotely for the last 6-8 years, and I did a degree remotely.
If I can't find a quality JS dev in London (it's not as easy as you would assume, but then I've only just raised money), then I'm willing to outsource portions. Still have a number of options!
Here's a question that will help:
Many of the major outsourcing-providing countries have far more developers than even the US, so why aren't those outsourcing countries at least creating a ton of early stage startups?
My answer, as someone currently living in a major outsourcing providing country -- doing developer consulting is EXTREMELY opposite from making a startup, in many of the small but most important ways. Having a ton of raw developer resources, as many of these outsourcing countries have, is not the bottleneck.
Only working strictly as an outsourced developer will teach you to optimize all the wrong things.
Many of the major outsourcing-providing countries have far more developers than even the US, so why aren't those outsourcing countries at least creating a ton of early stage startups?
My answer, as someone currently living in a major outsourcing providing country -- doing developer consulting is EXTREMELY opposite from making a startup, in many of the small but most important ways. Having a ton of raw developer resources, as many of these outsourcing countries have, is not the bottleneck.
Only working strictly as an outsourced developer will teach you to optimize all the wrong things.
In my experience, there are two schools of thought in this area:
1) You want developers in-house because they're creating your product. This generates your revenue, so you want to be intimately involved (not outsourced).
2) You want very, very low overhead and/or aren't in a time crunch to deliver the product or new features. Which gives you more flexibility to handle somewhat lower quality (and more difficult* to manage) outsourced developers.
* Not as easy because they are not in-house.
* Not as easy because they are not in-house.
Totally agree with "intimately involved", this makes development more productive, than calling by skype and saying "Hey we have bug, clients are waiting, just fix it somehow" ;)
Management of remote staff increases management overhead, which distracts from finding product/market fit, growing the business, and other critical tasks. It's about focus.
Management of subcontractors is another form of management that increases overhead. As with management of remote staff, this too increases overhead.
Rapid change is the norm in the early days of a business. Rapid change when the developer is sitting next to you is difficult enough. Doing this with with time differences and across long distances makes it extremely difficult.
Specification is important when working with remote developers. Most startups don't want to invest in detailed spec writing as it adds overhead, slows progress, and may be a total waste if the feature being spec'd ends up not resonating with customers.
Cost. Yes, outsourcing to remote locations is not a savings of 80% during the startup phase. Once you factor in increases in management costs, increases in spec writing costs, increases in integration costs, increases in quality control costs, etc. the cost difference largely fades or even turns negative.
Of course, all of the factors above flip in the other direction once a company has a repeatable business model. Once repeatable, a business' operations can be standardized and process driven. At this point, outsourcing to low cost destinations becomes very attractive.
Management of subcontractors is another form of management that increases overhead. As with management of remote staff, this too increases overhead.
Rapid change is the norm in the early days of a business. Rapid change when the developer is sitting next to you is difficult enough. Doing this with with time differences and across long distances makes it extremely difficult.
Specification is important when working with remote developers. Most startups don't want to invest in detailed spec writing as it adds overhead, slows progress, and may be a total waste if the feature being spec'd ends up not resonating with customers.
Cost. Yes, outsourcing to remote locations is not a savings of 80% during the startup phase. Once you factor in increases in management costs, increases in spec writing costs, increases in integration costs, increases in quality control costs, etc. the cost difference largely fades or even turns negative.
Of course, all of the factors above flip in the other direction once a company has a repeatable business model. Once repeatable, a business' operations can be standardized and process driven. At this point, outsourcing to low cost destinations becomes very attractive.
I've seen international teams succeed and fail. Language barriers are a problem especially when trying to grasp domain knowledge. Most outsourced teams require specs and don't work well without them. Most startups prefer to have some time overlap where they can talk directly and classify problems.
And of course there's also the idea in silicon valley that good engineers are a must if you want your company to be aquired by a Google or Yahoo
There are several factors but the biggest one was India, I never understood why software quality from India was so poor. Honestly, it made no logical sense, here is a population that has a group of individuals that are for whatever reasons fairly strong in STEM. It seemed inconsistent, until one day I met a developer named Karthick, Karthick could code and was a passionate developer, he was everything that India software quality was not. So I asked Karthick about my observations and why software coming back from India was so poor. What I found out amazed me What I thought was a complex problem, was actually a problem of incentives. See Karthick told me that in India, a man is measured by how many people he manages. It is a throw back to the cast systems and it is a source of pride. The fastest way to management, in India, is STEM and specifically computer programming. So what you get is a bunch of would be MBA's, getting engineering degrees, that they do not want, to take a job that they do not want, to get a job they are not educated for and are not qualified for. So it creates a fail up environment.
This was the first wave of problems and honestly after the failures of BoA and several other US companies who lost billions trying to save a buck in that market, US companies are hesitant to enter that market again whole hog. They will pick up a developer or two to augment a team, but not many people are sending whole projects over anymore. Everyone has a horror story and it's enough to make most would be bargain shoppers think twice about trying to save a dollar, by trading it for risk.
The second issue is one of tribal knowledge as I call it. People conduct their lives in very different ways from Central Asia to the US. What we take for granted as common knowledge over here may be a uncommon or not even done in your culture and vice versa. When we document systems, we take for granted "common" knowledge and it does not get documented. For example I worked on a system one time for a large hotel reservation engine that had work done in India. 2/3 of the development staff had never personally booked a hotel room online. It ended up costing more to have BA's and Architects document the system, than it would have to have thrown the BA's and Architects in a room with a bunch of developers. In the end what did we do, well we sent our CTO, our BA's and our Architects to India to sit in a room for 2 months at a time until the project was a success. Basically enough from the VP's to declare victory and get the hell out.
So what does it all boil down to, cultural mismatch. As US business homogeny (I don't mean that in an arrogant sense, I mean it in a corporate culture way) and the Internets global village takes it's hold on the globe, that mismatch becomes less of an issue, but someones is going to have to take the risk to prove it out, and unfortunately the generation that smashed on the rocks in India is now in the decision making seats and not many of them have an appetite to try a do over. Especially startups where project failures or delays can kill a promising idea.
This was the first wave of problems and honestly after the failures of BoA and several other US companies who lost billions trying to save a buck in that market, US companies are hesitant to enter that market again whole hog. They will pick up a developer or two to augment a team, but not many people are sending whole projects over anymore. Everyone has a horror story and it's enough to make most would be bargain shoppers think twice about trying to save a dollar, by trading it for risk.
The second issue is one of tribal knowledge as I call it. People conduct their lives in very different ways from Central Asia to the US. What we take for granted as common knowledge over here may be a uncommon or not even done in your culture and vice versa. When we document systems, we take for granted "common" knowledge and it does not get documented. For example I worked on a system one time for a large hotel reservation engine that had work done in India. 2/3 of the development staff had never personally booked a hotel room online. It ended up costing more to have BA's and Architects document the system, than it would have to have thrown the BA's and Architects in a room with a bunch of developers. In the end what did we do, well we sent our CTO, our BA's and our Architects to India to sit in a room for 2 months at a time until the project was a success. Basically enough from the VP's to declare victory and get the hell out.
So what does it all boil down to, cultural mismatch. As US business homogeny (I don't mean that in an arrogant sense, I mean it in a corporate culture way) and the Internets global village takes it's hold on the globe, that mismatch becomes less of an issue, but someones is going to have to take the risk to prove it out, and unfortunately the generation that smashed on the rocks in India is now in the decision making seats and not many of them have an appetite to try a do over. Especially startups where project failures or delays can kill a promising idea.
There's also the issue where it's considered extremely rude to say "No", so an answer of "Yes" to a question doesn't always mean what you think it does.
I was going to mention that as a third issue, but that seems to be more focused specifically on India. I have not seen the hesitance to deliver bad news from other Asian cultures.
I thought that was what the head bobble was for. It's like the gestural equivalent of telling you exactly what you want to hear.
Take the following with a grain of salt, as I've only seen this in action once.
The language barrier is pervasive even if the consultants speak English fluently. At my last company, we hired consultants from Belarus and besides a small accent there were no problems communicating with them. However, when it came to actually coding, the differences in language were more visible.
It was mostly simple stuff. the difference between an "Order" and a "Subscription". The knowledge about western addresses (we had to explain what a postal code was). You could always tell if it was one of our consultants that wrote a given piece of code.
That being said, it was effective. We accumulated quite a bit of technical debt that we later had to pay off, but by any metric, it was successful. They were very competent programmers (one was amazing!) and I wouldn't hesitate to bring them onto another project. But I would try to micromanage more.
The language barrier is pervasive even if the consultants speak English fluently. At my last company, we hired consultants from Belarus and besides a small accent there were no problems communicating with them. However, when it came to actually coding, the differences in language were more visible.
It was mostly simple stuff. the difference between an "Order" and a "Subscription". The knowledge about western addresses (we had to explain what a postal code was). You could always tell if it was one of our consultants that wrote a given piece of code.
That being said, it was effective. We accumulated quite a bit of technical debt that we later had to pay off, but by any metric, it was successful. They were very competent programmers (one was amazing!) and I wouldn't hesitate to bring them onto another project. But I would try to micromanage more.
I have built one startup on "outsourced" labor in India and would highly recommend it. The folks I hired were excellent, and I'd highly recommend them to any western employer. One of them I later attempted to hire at an American company, we just missed the visa window.
I put the word "outsourced" in quotes because I also moved to Pune. So it wasn't really "outsourcing" in the traditional sense of hiring some of "those people" and throwing work over the wall at them - it was really just building a company with people who happened to live in Pune.
It's a great way to get more bang for your buck. Indian devs are just as good as NRI devs and ABCD devs (which most companies already have plenty of) - just cheaper.
Of course, VC's may not like it.
I put the word "outsourced" in quotes because I also moved to Pune. So it wasn't really "outsourcing" in the traditional sense of hiring some of "those people" and throwing work over the wall at them - it was really just building a company with people who happened to live in Pune.
It's a great way to get more bang for your buck. Indian devs are just as good as NRI devs and ABCD devs (which most companies already have plenty of) - just cheaper.
Of course, VC's may not like it.
Some startup did that. However I do not recommend it.
I'm from China and my perspective is that: Unequalness and conflicts.
Startups doing this usually pays average in the US. When they hires in China. They could afford to pay higher. This often means that they got better people but in a lower position. This prompts tons of bureaucratic.
This does more harm in the startup side. Because it's easier for the startup to blame their oversea colleagues rather than to face the problem in their own hands.
I'm from China and my perspective is that: Unequalness and conflicts.
Startups doing this usually pays average in the US. When they hires in China. They could afford to pay higher. This often means that they got better people but in a lower position. This prompts tons of bureaucratic.
This does more harm in the startup side. Because it's easier for the startup to blame their oversea colleagues rather than to face the problem in their own hands.
If your site is very well specified, static, and small, you might get away with outsourcing it.
A lot of startups need to be constantly iterating. That's how they make their product. Throw something up, see what the feedback is, change it. You can't do that if the devs are not very close to the feedback. And that generally means living somewhere near the customers, with attendant costs.
A lot of startups need to be constantly iterating. That's how they make their product. Throw something up, see what the feedback is, change it. You can't do that if the devs are not very close to the feedback. And that generally means living somewhere near the customers, with attendant costs.
The factors behind building a successful startup are more than an idea or lucrative salaries. Higher salaries doesn't make startups successful, rather building teams with perfect chemistry, culture, mutual trust and synchronization between members. For that, physical presence of team members under a single roof is very important. Hope that explains it all.
My problem is that I actually don't know how to do 'outsourcing'.
How do I look for a dev that speaks my language? How do I pay them? Are there any legal obligations on my behalf? How will my accountant deal with paying an international employee? Am I going to have to pay a consultant to get questions about outsourcing answered?
There are too many unknowns for me, as a startup.
How do I look for a dev that speaks my language? How do I pay them? Are there any legal obligations on my behalf? How will my accountant deal with paying an international employee? Am I going to have to pay a consultant to get questions about outsourcing answered?
There are too many unknowns for me, as a startup.
As someone with extensive experience of working with offshore development teams in India and China (I'm from the UK myself), these reasons spring to mind:
1) Language barrier. Remarkably, still a major issue even in tier-1 cities in China. Not so much of a problem in India, but it's still there to a degree.
2) Quality. This is a big one. I've worked with some great developers and some really, really terrible developers. The former seem to be a rare breed. I can interview dozens of pre-screened candidates before I find someone who is any good at all. Never assume what is written on CVs/resumes as truthful until you've assessed candidates!
3) Culture. Don't underestimate the impact of this one. I'm a seasoned traveller, but working with people from other cultures can still be challenging at times. In my experience, 'face' is an issue when working with Chinese developers, and lack of directness and pro-activeness is an issue when working with Indian developers (sweeping generalisations, I know; just my experiences). These can have a big impact on your projects if you are not on top of it. Something else to consider in India is that it's very difficult to find people with many years of experience, as most people there don't see software development as a career - it's seen as an on-ramp to management positions, and there is a stigma attached to being a developer for 'too long' without being promoted.
4) Time difference. This can work for or against you, depending on what you want. I'm a firm believer than the best way to work with offshore developers is to work together, so unless one side is willing to change their working times, it's certainly a problem for me.
5) Previous failure. I've found many people have tried doing offshore development 'the wrong way', and it's left then disillusioned. Simply throwing a specification over the wall to a remote team will not work. Ever. Failure guaranteed!
I want to finish by saying it can work, if done properly. Over the past few years I've built up a team of 8 good, dependable developers in India. I've done this by working closely with them, spending time with them in India, conducting training sessions, buying Pluralsight subscriptions for them, encouraging direct dialogue and pro-activeness, mentoring, and generally spending a lot of time communicating. Of course, this all takes a lot of time and effort (and some money too!).
1) Language barrier. Remarkably, still a major issue even in tier-1 cities in China. Not so much of a problem in India, but it's still there to a degree.
2) Quality. This is a big one. I've worked with some great developers and some really, really terrible developers. The former seem to be a rare breed. I can interview dozens of pre-screened candidates before I find someone who is any good at all. Never assume what is written on CVs/resumes as truthful until you've assessed candidates!
3) Culture. Don't underestimate the impact of this one. I'm a seasoned traveller, but working with people from other cultures can still be challenging at times. In my experience, 'face' is an issue when working with Chinese developers, and lack of directness and pro-activeness is an issue when working with Indian developers (sweeping generalisations, I know; just my experiences). These can have a big impact on your projects if you are not on top of it. Something else to consider in India is that it's very difficult to find people with many years of experience, as most people there don't see software development as a career - it's seen as an on-ramp to management positions, and there is a stigma attached to being a developer for 'too long' without being promoted.
4) Time difference. This can work for or against you, depending on what you want. I'm a firm believer than the best way to work with offshore developers is to work together, so unless one side is willing to change their working times, it's certainly a problem for me.
5) Previous failure. I've found many people have tried doing offshore development 'the wrong way', and it's left then disillusioned. Simply throwing a specification over the wall to a remote team will not work. Ever. Failure guaranteed!
I want to finish by saying it can work, if done properly. Over the past few years I've built up a team of 8 good, dependable developers in India. I've done this by working closely with them, spending time with them in India, conducting training sessions, buying Pluralsight subscriptions for them, encouraging direct dialogue and pro-activeness, mentoring, and generally spending a lot of time communicating. Of course, this all takes a lot of time and effort (and some money too!).
Argumentative & too emotional - are Indians tough to work with?
http://economictimes.indiatimes.com/magazines/corporate-doss...
http://economictimes.indiatimes.com/magazines/corporate-doss...
The biggest reason is that a solid engineeering team, local or remote, needs to work directly for you and not be a subcontractor. Setting up a remote office and hiring staff is a very, very time-consuming and risky process.
> Setting up a remote office and hiring staff is a very, very time-consuming and risky process.
This could be solved with specialized agencies which finds/tests/interviews/guarantees code quality of candidates.
This could be solved with specialized agencies which finds/tests/interviews/guarantees code quality of candidates.
There is a lot of arrogance in this thread. Thanks to better exposure through HN,Github etc , Indians devs are levelling up fast and I predict that in 4-5 years the quality gap will become almost non existent.
It's not so much as arrogance as it is just being honest about the quality of outsourced work. If you were worried about offending people, you would come up with all sorts of excuses for not outsourcing work. But honesty is not always the nicest thing to hear. I've been working with our outsourced team in Bangladesh and their quality of work is much less rigorous than that of our in-house team.
"Indians devs are levelling [sic] up fast and I predict that in 4-5 years the quality gap will become almost non existent."
You may be correct but the Original Post is talking about now*. Also, you seem to agree that there is a "quality gap".
"Indians devs are levelling [sic] up fast and I predict that in 4-5 years the quality gap will become almost non existent."
You may be correct but the Original Post is talking about now*. Also, you seem to agree that there is a "quality gap".
I completely agree about there being a quality gap.
The reason was that Indian IT was dominated by body shopping companies that bid for grunt work and then threw quickly trained engineers at the problem , some of whom never even studied CS.
This is changing now as we have an ecosystem of smaller companies which hire better people and have better processes and incentives. It will take time for the effects to be felt but I am confident that we will improve thanks to the better exposure we have , and learning from HN and Github.
This isn't restricted to India though. Western developers should brace for a lot of competition in the years ahead. Eastern European developers are already almost as good.
The reason was that Indian IT was dominated by body shopping companies that bid for grunt work and then threw quickly trained engineers at the problem , some of whom never even studied CS.
This is changing now as we have an ecosystem of smaller companies which hire better people and have better processes and incentives. It will take time for the effects to be felt but I am confident that we will improve thanks to the better exposure we have , and learning from HN and Github.
This isn't restricted to India though. Western developers should brace for a lot of competition in the years ahead. Eastern European developers are already almost as good.
Indian devs certainly level up fast, and I wouldn't be surprised if the number of great engineers born in India is already significantly larger than the number of great engineers born in the USA.
But, and this is a big but: large numbers (the majority?) of those great engineers end up moving to the USA anyway. And, just as with evaporation, what's remaining is cooler than what left.
But, and this is a big but: large numbers (the majority?) of those great engineers end up moving to the USA anyway. And, just as with evaporation, what's remaining is cooler than what left.
There are so many anecdotal examples of bad experiences in this thread that I have to chime in with a counterexample.
I used to contract for a startup that was sold to Google a couple years ago for $350 million dollars.
In the beginning, it was just the two co-founders in the Valley and us developers, spread around the world. Later, when the company took VC funding, we helped to expand the engineering team with in-house developers as well (at the time of acquisition the total eng headcount was ~50 IIRC).
The product both took off like wildfire, grew, staid stable, and weathered some serious beatings on AWS just driven by the contractors. Even when there were several in-house teams, the remote ones were by far the most productive and e.g. drove 90 % of all the ops side of the service.
So, a couple of points:
* Retention/ownership: This has nothing to do with whether someone is an employee or a contractor. It's true that most outsourcing companies try to sell you just hired hands, but that's not all that's out there. You can find superb small developer houses that take more ownership in your product and code than any developer you can get in the Valley ever would. They're not 10x cheaper, but they're probably much better than any developer you can reasonably hire in the Valley at the moment, period.
We staid at the startup we contracted for from 2008 to 2013 and only left because Google doesn't do contractors, period. (This is a story of its own but I'm not comfortable telling it until a few more years have passed.) There were not a single employee that staid at the company for longer than us.
Employer shopping is much less pervasive outside US, so considering an employee a more long-term investment than a contractor is an illusion. Besides, you have the exact same means to keep a remote contractor happy as you have with an employee.
* Quality of code: This is a red herring IMO. You can choose whom you hire, even if they're remote. You have the same opportunities to check their level and productivity, and it's even easier to fire them if things don't work.
* "knowing what to build, not just how to build." Most of this isn't really related to remote vs in-house either. If the product is online, much of its clients are as well. I used to spend a shitload of time in the early days helping clients solve their issues from 10 timezones away. And often the clients were in the EU, when in-house people wouldn't have been available to help them.
* "you're still over there because you're not good enough for anyone to sponsor you for an H1B". Sorry, but I rather stay here with pure nature right off the door, 4 real seasons, and no rush, and produce the same (or probably more) output and value as a remote contractor. I might not make the same salary I would in the Valley, but it's not that far off if I contract for an American company. I also have much more flexibility to choose where I am at any given moment and how I structure my workdays. Plus, not all people hold money in quite as high a regard as people in the US do.
So, long story short: it's much more about who you get to work for you than employee vs. contractor. If you go for the cheapest code farm option, of course you're getting cheap quality. But you can also hire expert-level individual contractors or small teams where you know exactly what you're getting. They are not cheap, of course, but still less expensive than senior level employees in the Valley if you consider you can skip all the benefits and overhead.
And of course, at the moment they're probably better than what you can find in the Valley for any amount of money.
I used to contract for a startup that was sold to Google a couple years ago for $350 million dollars.
In the beginning, it was just the two co-founders in the Valley and us developers, spread around the world. Later, when the company took VC funding, we helped to expand the engineering team with in-house developers as well (at the time of acquisition the total eng headcount was ~50 IIRC).
The product both took off like wildfire, grew, staid stable, and weathered some serious beatings on AWS just driven by the contractors. Even when there were several in-house teams, the remote ones were by far the most productive and e.g. drove 90 % of all the ops side of the service.
So, a couple of points:
* Retention/ownership: This has nothing to do with whether someone is an employee or a contractor. It's true that most outsourcing companies try to sell you just hired hands, but that's not all that's out there. You can find superb small developer houses that take more ownership in your product and code than any developer you can get in the Valley ever would. They're not 10x cheaper, but they're probably much better than any developer you can reasonably hire in the Valley at the moment, period.
We staid at the startup we contracted for from 2008 to 2013 and only left because Google doesn't do contractors, period. (This is a story of its own but I'm not comfortable telling it until a few more years have passed.) There were not a single employee that staid at the company for longer than us.
Employer shopping is much less pervasive outside US, so considering an employee a more long-term investment than a contractor is an illusion. Besides, you have the exact same means to keep a remote contractor happy as you have with an employee.
* Quality of code: This is a red herring IMO. You can choose whom you hire, even if they're remote. You have the same opportunities to check their level and productivity, and it's even easier to fire them if things don't work.
* "knowing what to build, not just how to build." Most of this isn't really related to remote vs in-house either. If the product is online, much of its clients are as well. I used to spend a shitload of time in the early days helping clients solve their issues from 10 timezones away. And often the clients were in the EU, when in-house people wouldn't have been available to help them.
* "you're still over there because you're not good enough for anyone to sponsor you for an H1B". Sorry, but I rather stay here with pure nature right off the door, 4 real seasons, and no rush, and produce the same (or probably more) output and value as a remote contractor. I might not make the same salary I would in the Valley, but it's not that far off if I contract for an American company. I also have much more flexibility to choose where I am at any given moment and how I structure my workdays. Plus, not all people hold money in quite as high a regard as people in the US do.
So, long story short: it's much more about who you get to work for you than employee vs. contractor. If you go for the cheapest code farm option, of course you're getting cheap quality. But you can also hire expert-level individual contractors or small teams where you know exactly what you're getting. They are not cheap, of course, but still less expensive than senior level employees in the Valley if you consider you can skip all the benefits and overhead.
And of course, at the moment they're probably better than what you can find in the Valley for any amount of money.
@Jarkko: thank you for the great insights.
How many hours typical developer on your remote team work on?
What is the typical hourly (or daily or weekly) rate for senior developer who is working on the same project full time for months or years?
Hi @dennisgorelik!
“How many hours typical developer on your remote team work on?”
A week? 25-40, depending on the urgency in the project at hand.
“What is the typical hourly (or daily or weekly) rate for senior developer who is working on the same project full time for months or years?”
Our standard rate is €1k/day. Larger projects are negotiated on a case by case basis.
“How many hours typical developer on your remote team work on?”
A week? 25-40, depending on the urgency in the project at hand.
“What is the typical hourly (or daily or weekly) rate for senior developer who is working on the same project full time for months or years?”
Our standard rate is €1k/day. Larger projects are negotiated on a case by case basis.
Jarkko,
Are similar teams in California even more expensive?
Are similar teams in California even more expensive?
Hey Jarkko, been a while, I hope you and the other guys are very well!
A few things from my view, not to take away from anything you said, just to drop in some thoughts from my angle:
* If I was forced to pick favorites, the most productive SWEs we had were actually in-house. This is no reflection on anyone, and also isn't directly related to being in-house. It's down to individuals, and most significantly how they communicate around requirements. It's a bit more tricky to do this remotely, but you guys also did this very well. I completely agree that you guys were among our top performers; you were absolutely essential to many stages of our growth, and I would hire you all again in a heartbeat. I love you guys, and I miss working with you.
* Our eng headcount was actually about 50% larger, the extra gap was more contractors. With so many contracting teams, I gained quite a bit of experience with a wide spread. You guys were great, Wyeworks were also absolutely fantastic. I won't mention the others, as they were not so strong, and one contractor in particular did a fair bit of damage as a result of isolated work that was largely overengineered (work that subsequently landed in a book, that's still popularized to this day, and is a total anti-pattern that I had to rip out of our code base myself in a mad hurry to fix the critical outages it's piss poor performance resulted in). The point is, overall, we had a couple of great contracting teams, you guys included, and a couple of not so good. I don't really see much direct correlation with "contractor or not" here, it's more about work ethics and processes. The contractors that did worse worked in isolation, the contractors that did better worked in collaboration. The best contractors always kept their cool as they retained the concept of "you're a customer". This advice extends to satellite teams too, where we had one that could have benefited from a more consulting approach to their integration. We all live and learn.
* Retention and ownership take a lot of work on all sides. We had a very different relationship with you guys to what we had with Wyeworks. Neither was bad, but Wyeworks was more like a company, and you guys were more like individuals. Of course this is a big product of history, you actually were individuals until after the close, and Wyeworks was obviously bigger than you guys by then too. Both great, both would be hired again in a second. You all demonstrated ownership and stuck with us through good and harder times. Thanks for being awesome! As far as the big G and contractors goes, well, we can't open this wound for all to see here, but Wyeworks got through the paperwork and continued with us for a while longer than you guys were able to. This isn't a comment about you guys, and as you say, we shouldn't bare all here right now, but it's just to say that large organizations have complex legal requirements that can be difficult to overcome - this is something that contractors need to understand, and companies relying on them that might be acquired should also take into account - it could affect your valuation in extreme cases. As far as "not a single employee", you're mostly right, maybe you are right, but did you forget our Kiwi friend, our first FTE? he's still here, rocking it. I agree with you that the typical churn rate in the valley is all manner of crazy. I have friends who've moved upwards of 4 times in a year. I'm glad to say that we had far better retention than that.
* Code quality. Well, I told a story about this above, so I won't repeat it all here, or risk damaging the guilty with more details, but it's really important to remember the core point: the gap was in work approach. We got crap code from people who worked in isolation. They were slower, their code was overengineered, underspecified, buggy, and unsustainable - but most critically - largely unnecessary - most of it could be elided with a quick conversation with the PO. It was replaced, and in the case I described above, it was replaced by me, which, given my position was an expensive call. This doesn't have anything direct to do with contractors though, it's just slightly easier to work in isolation over the wire than it is in person - though we had plenty who did that in person too, with similar but less extreme results. More importantly, it's easier to train this stuff out, to help individuals develop their skills and measure their effectiveness when they're local. That's a long winded way of saying that it is easier to manage your "average" employee in person than it is remotely. Strong employees, like you guys, this is less of an issue. You self manage, give and take feedback, and we all get better together.
* knowing what to build. Yep, as you say, this has nothing to do with location. It does have to do with communication, so a contractor needs to be extra effective at communication to make this excellent. Some can, some can't - same as any FTE's. Again the difference is, as a manager / leader, you can more easily draw people below this line up if they're within earshot. A contractor below this line you often end up needing to drop.
* H1B and "you're not good enough". I don't think we ever uttered such horrific words, but I'm sure they've been said somewhere. The degree requirements for the H1B can be a sticking point, and that impacted a few of our folks over the years. I think these rules are dangerous for the country, especially with the STEM numbers being what they are. Sure you can pile more people into universities here, but what are you going to do about post academic training (which is extremely important, see all the points above none of which are ever taught in a CS/IT degree). We also opened a satellite team as a tactical move to increase headcount without being stuck in the US/valley hiring market, and it was a good move. The team busted the ceiling on their hiring goals, and even though that rapid growth came with the usual growth pains, it was overall a very successful move and many great additions to our team(s). If we'd have been able to find other strong contractors we may have considered doing that too.
I completely agree with your conclusion that it's all about who you get. I hope that the above also speaks to this fairly clearly. I've had a wide range of strong and weaker FTE's and contractors. I don't divide them in that way. There are genuinely other business reasons to prefer one over the other, but a lot of the commonly stated crap isn't it - given the right people and the right attitude. As far as expense goes, it's all much of a muchness. If a company is that concerned about the cost difference of contractors vs. FTEs they're not hiring at the right level and may very well have some management and/or financial problems. From when I've done contract/consulting/WFH work, I'd avoid such companies.
I have recently recommended a bootstrapping company to use some contractors for some of their work, as they're situated in the valley and don't have the ability to effectively judge incoming talent. They can very effectively get up and running with some contractors, and take their time to find a really strong first local team. I could see them maintaining a mix long term, much like we did, and to great success.
I wish you guys all the best, and miss you.
disclaimer: I was the first Eng Director, and later CTO at said company. Nonetheless, comments are exclusively my own, and not representative of any organization.
A few things from my view, not to take away from anything you said, just to drop in some thoughts from my angle:
* If I was forced to pick favorites, the most productive SWEs we had were actually in-house. This is no reflection on anyone, and also isn't directly related to being in-house. It's down to individuals, and most significantly how they communicate around requirements. It's a bit more tricky to do this remotely, but you guys also did this very well. I completely agree that you guys were among our top performers; you were absolutely essential to many stages of our growth, and I would hire you all again in a heartbeat. I love you guys, and I miss working with you.
* Our eng headcount was actually about 50% larger, the extra gap was more contractors. With so many contracting teams, I gained quite a bit of experience with a wide spread. You guys were great, Wyeworks were also absolutely fantastic. I won't mention the others, as they were not so strong, and one contractor in particular did a fair bit of damage as a result of isolated work that was largely overengineered (work that subsequently landed in a book, that's still popularized to this day, and is a total anti-pattern that I had to rip out of our code base myself in a mad hurry to fix the critical outages it's piss poor performance resulted in). The point is, overall, we had a couple of great contracting teams, you guys included, and a couple of not so good. I don't really see much direct correlation with "contractor or not" here, it's more about work ethics and processes. The contractors that did worse worked in isolation, the contractors that did better worked in collaboration. The best contractors always kept their cool as they retained the concept of "you're a customer". This advice extends to satellite teams too, where we had one that could have benefited from a more consulting approach to their integration. We all live and learn.
* Retention and ownership take a lot of work on all sides. We had a very different relationship with you guys to what we had with Wyeworks. Neither was bad, but Wyeworks was more like a company, and you guys were more like individuals. Of course this is a big product of history, you actually were individuals until after the close, and Wyeworks was obviously bigger than you guys by then too. Both great, both would be hired again in a second. You all demonstrated ownership and stuck with us through good and harder times. Thanks for being awesome! As far as the big G and contractors goes, well, we can't open this wound for all to see here, but Wyeworks got through the paperwork and continued with us for a while longer than you guys were able to. This isn't a comment about you guys, and as you say, we shouldn't bare all here right now, but it's just to say that large organizations have complex legal requirements that can be difficult to overcome - this is something that contractors need to understand, and companies relying on them that might be acquired should also take into account - it could affect your valuation in extreme cases. As far as "not a single employee", you're mostly right, maybe you are right, but did you forget our Kiwi friend, our first FTE? he's still here, rocking it. I agree with you that the typical churn rate in the valley is all manner of crazy. I have friends who've moved upwards of 4 times in a year. I'm glad to say that we had far better retention than that.
* Code quality. Well, I told a story about this above, so I won't repeat it all here, or risk damaging the guilty with more details, but it's really important to remember the core point: the gap was in work approach. We got crap code from people who worked in isolation. They were slower, their code was overengineered, underspecified, buggy, and unsustainable - but most critically - largely unnecessary - most of it could be elided with a quick conversation with the PO. It was replaced, and in the case I described above, it was replaced by me, which, given my position was an expensive call. This doesn't have anything direct to do with contractors though, it's just slightly easier to work in isolation over the wire than it is in person - though we had plenty who did that in person too, with similar but less extreme results. More importantly, it's easier to train this stuff out, to help individuals develop their skills and measure their effectiveness when they're local. That's a long winded way of saying that it is easier to manage your "average" employee in person than it is remotely. Strong employees, like you guys, this is less of an issue. You self manage, give and take feedback, and we all get better together.
* knowing what to build. Yep, as you say, this has nothing to do with location. It does have to do with communication, so a contractor needs to be extra effective at communication to make this excellent. Some can, some can't - same as any FTE's. Again the difference is, as a manager / leader, you can more easily draw people below this line up if they're within earshot. A contractor below this line you often end up needing to drop.
* H1B and "you're not good enough". I don't think we ever uttered such horrific words, but I'm sure they've been said somewhere. The degree requirements for the H1B can be a sticking point, and that impacted a few of our folks over the years. I think these rules are dangerous for the country, especially with the STEM numbers being what they are. Sure you can pile more people into universities here, but what are you going to do about post academic training (which is extremely important, see all the points above none of which are ever taught in a CS/IT degree). We also opened a satellite team as a tactical move to increase headcount without being stuck in the US/valley hiring market, and it was a good move. The team busted the ceiling on their hiring goals, and even though that rapid growth came with the usual growth pains, it was overall a very successful move and many great additions to our team(s). If we'd have been able to find other strong contractors we may have considered doing that too.
I completely agree with your conclusion that it's all about who you get. I hope that the above also speaks to this fairly clearly. I've had a wide range of strong and weaker FTE's and contractors. I don't divide them in that way. There are genuinely other business reasons to prefer one over the other, but a lot of the commonly stated crap isn't it - given the right people and the right attitude. As far as expense goes, it's all much of a muchness. If a company is that concerned about the cost difference of contractors vs. FTEs they're not hiring at the right level and may very well have some management and/or financial problems. From when I've done contract/consulting/WFH work, I'd avoid such companies.
I have recently recommended a bootstrapping company to use some contractors for some of their work, as they're situated in the valley and don't have the ability to effectively judge incoming talent. They can very effectively get up and running with some contractors, and take their time to find a really strong first local team. I could see them maintaining a mix long term, much like we did, and to great success.
I wish you guys all the best, and miss you.
disclaimer: I was the first Eng Director, and later CTO at said company. Nonetheless, comments are exclusively my own, and not representative of any organization.
@raggi Thanks for chiming in with your POW. You certainly went into much more detail than I was comfortable going.
I completely agree with you (although wasn't of course even aware of all the details, the company grew so fast during the last years). It's all about ownership and communication, which are somewhat easier with someone next to you (with obvious caveats as well), but it's far from black and white. Actually, remote in some ways makes it more explicit: you have to write stuff down, and thus, when you hire new people (or people leave) it's more than tacit knowledge.
But yeah, it boils down to individual in the vast majority of cases, much more than whether the individual sits next to you or not.
“did you forget our Kiwi friend, our first FTE? he's still here, rocking it.” Of course not, but he was a remote contractor as well through the early years :-)
Maybe that was one of the things that helped us to begin with: since all of the developers were remote originally, you just had to have the communication in place. I would imagine it's trickier if there is an in-house team originally and then remote devs added to that.
Miss you too!
I completely agree with you (although wasn't of course even aware of all the details, the company grew so fast during the last years). It's all about ownership and communication, which are somewhat easier with someone next to you (with obvious caveats as well), but it's far from black and white. Actually, remote in some ways makes it more explicit: you have to write stuff down, and thus, when you hire new people (or people leave) it's more than tacit knowledge.
But yeah, it boils down to individual in the vast majority of cases, much more than whether the individual sits next to you or not.
“did you forget our Kiwi friend, our first FTE? he's still here, rocking it.” Of course not, but he was a remote contractor as well through the early years :-)
Maybe that was one of the things that helped us to begin with: since all of the developers were remote originally, you just had to have the communication in place. I would imagine it's trickier if there is an in-house team originally and then remote devs added to that.
Miss you too!
And the POW-instead-of-POV-acronym was completely unintentional, I swear :-)
[deleted]
In my experience the code delivered by outsourced developers is always of a low quality. It will usually do whatever you asked them to do, but that's it. No other considerations beyond exactly what you've outlined in the requirements will be given any consideration. No thought to future expandability, robustness, etc.
At my job currently we have been working with an outsourced developer as all of our internal developers are always busy but we have other things we want to do. So we thought, hey we haven't tried outsourcing in a while, let's give it a whirl. The results have been on par with every other time I've used outsourcing in the past 20 years.
The end result will probably work for what we wanted it for, but the code is bad. I am not looking forward to having to support it and work with it over the next 10 years. And it's been a ton of back and forth to just try to get the code to do what we said we wanted it to do in the first place.
At my job currently we have been working with an outsourced developer as all of our internal developers are always busy but we have other things we want to do. So we thought, hey we haven't tried outsourcing in a while, let's give it a whirl. The results have been on par with every other time I've used outsourcing in the past 20 years.
The end result will probably work for what we wanted it for, but the code is bad. I am not looking forward to having to support it and work with it over the next 10 years. And it's been a ton of back and forth to just try to get the code to do what we said we wanted it to do in the first place.
With all the SV talk about $100k+ salaries, the reality is that in the US you can pick up average developers at a pretty reasonable salary. Think closer to $30k-60k. Add on top of that the cultural issues that make it more difficult to have developers handle other issues throughout the day like client support, writing documentation etc, and you can see how it really isn't that huge of a gap. Remember there is no actual developer shortage in the US unless you are talking about the very highly skilled top tier developers.
TopTurtle1(2)
I am from Central Asia, here you can easily hire really good developers for 2K$, avg 1K$ and beginners are ready to work for <500$.
Most of the companies are already outsorcing their development here and selling in Europe, US.
Most of us may think developers aren't good enough. To some extent you maybe right, but in general thats not true. Avg. developers maybe haven'n worked with AWS so far, because mostly no demand for AWS in local IT companies, catching up is no problem. Instagram owners also haven't worked with highload before gaining success.
Update: Please consider offshoring also, not only outsourcing.
Update: Reasons so far(ordered by priority, opinionated):
0. Mindset, (founders love vs contractors need) to make product
1. Not comfortable with remote workers or difficult to manage
2. High gaps in skillset
3. Time/Cultural/Language barriers
4. Low quality implementation (docs, tests, code)
5. Retained value