
Ask HN: Why don't startups outsource/offshore development if salaries are low? - tuyguntn
This is a follow up for &quot;What up with these startup salaries?&quot;(https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=9052727)
If salaries are much low in startups comparing to Big Co.s why don&#x27;t startup owners outsource  the development in cheaper labor countries and work on marketing, selling of their startups.<p>I am from Central Asia, here you can easily hire really good developers for 2K$, avg 1K$ and beginners are ready to work for &lt;500$.<p>Most of the companies are already outsorcing their development here and selling in Europe, US.<p>Most of us may think developers aren&#x27;t good enough. To some extent you maybe right, but in general thats not true. Avg. developers maybe haven&#x27;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&#x27;t worked with highload before gaining success.<p><i>Update: </i> Please consider offshoring also, not only outsourcing.<p><i>Update: Reasons so far(ordered by priority, opinionated):</i><p>0. Mindset, (founders love vs contractors need) to make product<p>1. Not comfortable with remote workers or difficult to manage<p>2. High gaps in skillset<p>3. Time&#x2F;Cultural&#x2F;Language barriers<p>4. Low quality implementation (docs, tests, code)<p>5. Retained value
======
patio11
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.

~~~
tuyguntn
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.

~~~
hawkice
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.

------
ChainsawSurgery
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.

~~~
tuyguntn
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.

~~~
ChainsawSurgery
> 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.

~~~
ouroborosidiots
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.

------
madaxe_again
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.

------
cpach
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.

------
turk-
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.

------
artemk
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.

------
matt_morgan
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.

------
davismwfl
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.

------
wes-exp
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.

~~~
hyperliner
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...](http://www.nytimes.com/2008/08/12/business/worldbusiness/12indiawall.html?pagewanted=all&_r=0)

~~~
wes-exp
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.

~~~
tuyguntn
> Be careful not to conflate offshoring with outsourcing

Ups, thats my fault, lets add offshoring to the title.

------
hoopism
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.

------
velox_io
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!

------
solve
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.

------
edwhitesell
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.

~~~
tuyguntn
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" ;)

------
akbar501
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.

------
twunde
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

------
kls
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.

~~~
busterarm
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.

~~~
kls
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.

------
ccallebs
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.

------
yummyfajitas
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.

~~~
falsestprophet
[http://www.urbandictionary.com/define.php?term=NRI](http://www.urbandictionary.com/define.php?term=NRI)
[http://www.urbandictionary.com/define.php?term=ABCD](http://www.urbandictionary.com/define.php?term=ABCD)

------
cheng1
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.

------
lordnacho
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.

------
caniscrator
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.

------
jbob2000
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.

------
GordonS
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!).

~~~
known
Argumentative & too emotional - are Indians tough to work with?

[http://economictimes.indiatimes.com/magazines/corporate-
doss...](http://economictimes.indiatimes.com/magazines/corporate-
dossier/argumentative-too-emotional-are-indians-tough-to-work-
with/articleshow/45638709.cms)

------
chromaton
How are their English speaking and communications skills compared to
developers in the US?

~~~
tuyguntn
Most developers have good knowledge of English, Lets use IELTS for this, I
guess scores are in range of 5-9 and arithmetic mean is somewhere at 6.0

------
bryanwb
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.

~~~
tuyguntn
> 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.

------
thewarrior
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.

~~~
jchrome
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".

~~~
thewarrior
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.

------
jarkko
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.

~~~
raggi
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.

~~~
jarkko
@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!

~~~
jarkko
And the POW-instead-of-POV-acronym was completely unintentional, I swear :-)

------
ebbv
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.

------
hiou
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.

