
[Ask HN] How do I counter an investor trying to outsourcing our dev? - Hates_
I am a big believer in having a small in-house team over an army of outsourced development. Sadly our investors thinks the opposite and wants to force us to use outsourced development to put us "5 steps ahead of everyone else". I'm am plagued by nightmares of having to manage these people remotely, being the CTO.<p>We just received this email explaining their stance. What are my arguments against this? Deep down I feel like I recognise that it will cause more problems that it's worth but I'm just having a difficult time verbalising my arguments.<p>---<p>Regarding outsourcing, in my almost 17 years of working with development I have never met a software developer that thought that outsourcing was a good idea, and across the board they have all reacted as you have, saying that we would like to have fewer people employed in close proximity rather than outsource.<p>I really do understand the reaction, but at the same time, everyone I know who has implemented a well-thought out dev outsourcing  strategy has pushed their business 5 steps ahead of everyone else by introducing scalability and cost efficiency into their business model. It is always something that has to be forced on the dev team by upper management at too late a stage in the company’s development, always causes a lot of resentment and conflict in the established dev team, increasing the chance of failure, and usually ends up getting the acceptance of the team as a good idea that makes them all richer and more successful. I’ve always sided with the developers on this, and every time it has ended up being the worst management decision I have ever taken and crippled our competitiveness.<p>We are building a potentially huge business here with multiple million dollar revenues in a few years, this has to be managed very cleverly and with a forward-thinking strategy to have a chance of success. We have an opportunity to build this into our strategy from the beginning and harvest those advantages at an early stage, increasing our chances of a successful outsourcing strategy many-fold.<p>The VC’s will place a high value on having such an outsourcing strategy in place and in several cases will reject the idea without one. Our current projections underestimate the number of developers that we are going to need to pull this off and also do not address the fact that we are going to need effectively around the clock development to keep up with the customers demands, which in itself requires multiple time-zone location.<p>An outsourcing strategy does not necessarily mean we cannot have a dev team here at home, or that we have to have 10 developers in India this month, but it does mean that we have to have a strategy for outsourcing and implement it in the next 6-12 months to get it into the DNA of the company. As soon as we have more developers, the CTO is going to have to spend time managing multiple teams and outsourcing, and we need to have a general strategy for that from the beginning that we can defend during VC due diligence.
======
aymeric
The VC's arguments are quite sound.

He is not saying he wants to outsource everything, he simply wants the culture
of outsourcing in early to make it smoother in the case outsourcing is needed.

I would outsource non-critical areas of your development, like analytic
trackers, admin dashboard, deployment scripts, reports, (bug fixing?) so that
the core team can focus on listening to the customer and react quickly.

Having to deal with a global team has its benefits and drawbacks. My
experience has always been great. Waking up the morning and seeing that
progress has been made during the night is an awesome feeling.

Maybe your experience with outsourcing has been a negative one, but even if
you disagree with your investor you could still agree to bring an outsourced
team to develop second importance stuff to experiment and prove to your
investor it is not a good idea to outsource. In the case outsourcing works for
your project, you also win.

~~~
AmberShah
If it's important enough to get done, then it's important enough to be done
right.

~~~
aymeric
Outsourcing doesn't equal to poor quality.

------
Unosolo
As far as "does it EVER work" concerned: it does. It doesn't work well though.
Most people can run, doesn't mean that most people can run as fast as Usain
Bolt.

More at [http://stackoverflow.com/questions/502995/offshoring-does-
it...](http://stackoverflow.com/questions/502995/offshoring-does-it-ever-work)

Amongst other things, writing killer software depends on two pre-conditions:

\- Intimate knowledge of the domain, being at ease with the tools, identifying
yourself as part of the group people (field) working in the domain. This is
enabling factor.

\- External pressure or demand on the domain to change. This is a motivating
factor.

Outsourcing more often than not gets it exactly the other way round:

\- Outsourced organisations are not exposed to the natural external pressure
or demand exerted on the domain, they do not identify with the domain. Instead
the motivation is extrinsic: KPI’s, money and formal contracts.In other worlds
they don't feel the users' pain.

\- External teams lack intimate state-of-art knowledge of the domain due to
informational asymmetry; they don’t directly work in the domain but provide
services to the domain. That is to say they are less able to push state-of-art
forward, but would rather produce more of the same. Due to the lack of
information they work in a permanent haze, not being sure what the valid thing
is and this creates a lot of unease, reduces amount of positive risk taking,
and cripples creativity. Real advantages that software brings to the table in
any business is through gains in effectivness not efficacy.

------
ErrantX
It really depends on your business.

In my experience outsourced code is not as well supported, generally not as
well written _but_ pretty good value for money. The major risk I always saw is
remote devs disappearing (seen it happen plenty of times in the past) and you
end up with a sub standard product which will cost a lot to fix.

A lot relies on finding the right place to outsource to :)

But as I said; it really depends on your business and the code that is going
to be written. If you have a lot of wide ranging code outside your core "app"
then probably it makes sense to start outsourcing aspects of it. Keep core
development in house (it's too risky to leave that to anyone else).

You mention the issue of managing remote developers; this is a ball ache and a
real pain, especially if they are in a foreign country. If you get someone
awkward it becomes a pig to organise.

But it's not impossible; you just have to be firm and clear with your
instructions. And set pretty rigid time limits.

(also it's worth pointing out: HN is indexing very quickly by Google and the
email you posted is already searchable on there - so you might want to
consider removing it or putting it elsewhere if you don't want to risk this
being found :))

~~~
davidsmith
Surely no boss would have a big enough ego to Google his own emails? Oh, hang
on...

------
jwitchel
Your train has already left the station. You're not going to persuade him not
to outsource so don't try. Instead you should persuade him that maintaining
control over your outsourcing is the critical requirement for success. And
focus on how you want that to play out.

Regardless of whether you outsource to India, China, or a a guy down the block
many of the same issues apply.

1) Can you fire the company if you need to? "All relationships end badly or
they wouldn't end." When you have to fire the outsourced team, do you have the
skills internally to take control before you find a new group?

2) Can you ensure the outsourced team doesn't do anything sketchy. Do you have
a team internally that can protect against back doors, lockout triggers for
non-payment, inappropiate code insertions, undesired use (or non-use) of GPL'd
code.

3) Due-Diligence. How (specifically) do you plan to get through due-diligence
-- not just with VC but with an acquirer who _will_ look at your code and how
it was developed? Code review, architectural review, etc. Without a local team
firming at the helm that process will go poorly and cost the company far more
in a valuation hit then any cost/time savings.

4) Customer Data. Although it's just about impossible to avoid giving a remote
team access to your customer data, you can't give them total control. You need
a strong DBA locally to ensure your DB meets your security and privacy
standards.

5) Around-the-clock development. The reason outsourcing is effective is not
because it's cheaper (it's only marginally), not because they're better
(they're the same as us), it's because you can do around-the-clock
development. They check in code at 6 AM your time, you check in code at 6 AM
their time. That's how you get ahead. If you simply transfer a single
development team to a different time-zone, all you bought yourself is a 20-30%
cost savings and a bunch of frequent flier miles.

So the net-net on your pitch is: control, intellectual property ownership,
customer data, and speed.

I suggest you pitch: a) Acceptance testing stays domestic b) Design stays c)
Software Architecture and Spec Writing stays d) Small team of the very best
developers stay e) "everything else goes"

~~~
gte910h
>5) Around-the-clock development. The reason outsourcing is effective is not
because it's cheaper (it's only marginally), not because they're better
(they're the same as us), it's because you can do around-the-clock
development. They check in code at 6 AM your time, you check in code at 6 AM
their time. That's how you get ahead. If you simply transfer a single
development team to a different time-zone, all you bought yourself is a 20-30%
cost savings and a bunch of frequent flier miles.

I'm highly curious on how this executes well in a high control environment.
I've only seen this work at all well in very very loosely coupled codebases
with huge amounts of responsibility division, and even that said, the
technical and project leads seemed fully utilized handling the two teams.

Care to share the howto on this?

------
bdickason
I was in your camp a few years ago. Vehemently against outsourcing,
nightmarish experiences with a number of firms. Overall, just a lack of
results and confidence in the process.

Then we got lucky.

We hired a developer who had just moved here from Slovakia. He had lots of
friends back home who were looking for work.

He now leads our 'outsourced' division which costs less than the cheapo
corporations that spam me with 'OUTSORCED LABOR' e-mails. They work hard, they
love what they're doing, and they are GREAT coders. We have a personal
relationship with each of them.

The best part is, because they're each freelance coders, they can recommend
2-3 friends and vouch for them personally. They benefit from hooking their
friend up with work and we benefit from their solid recommendation.

Would this work if we didn't have a developer from the country? Probably not.
But it works for us :)

------
arethuza
I'd ask him to put you in touch with one of their portfolio companies who has
outsourced successfully. If they can do that then you might learn something
useful from the other folks - if they can't then they _might_ drop the idea
(although probably not much chance of that).

------
jister
I am from the Philippines and like India or China we are also part of those
outsourcing countries but not that popular though.

Companies in first world countries often think that quality goes down when
they are going to outsource their projects. Maybe. But having worked in
outsourcing firms (for a decade now) here in the Philippines, we always came
across projects that were poorly written too. These projects came from first
world countries that were developed by supposed-to-be the cream of the crop of
software development. And these are not small companies by the way.

The current project that I inherited in my day job was developed by a company
in Europe and it's a nightmare! The other project that I am working as
freelancer is from US and I think I need not say more.

Anyway, I am not offended and I totally understand your situation. I hear
these comments all time for years now and it's a shame that we all suffer from
low quality projects wherever we are.

In the end, it depends.

------
ido
If you cannot articulate your reasons your 'gut feeling' might not be correct
this time.

I've personally had some absolutely atrocious experience with outsourcing but
also a very good one with a small Romanian outsourcing company[1].

[1] <http://www.softgress.com/>

------
mark_l_watson
For quality technical work it is much better to have the team all in one place
- arguing otherwise is silly. Countering this is (sometimes) large cost
savings.

I am in the position of being just about the only remote worker with the rest
of the team in Silicon Valley. I really have to make a strong extra effort to
stay in touch and in sync with the home team. In my case, this is totally
worth the effort, but my general advice to people is to get a small number of
very good people in one place.

On the other side of this issue: I have worked with a lot of teams in India,
Vietnam, Brazil, and Eastern Europe. Having many inexpensive and well
educated/trained coworkers really opens a lot of doors to doing development
that can't be justified with more expensive developers.

------
dman
What industry are you in ? What problem are you solving ? Often the ability of
outsourcing vendors ability to help you hinges upon the answers to those two
questions. If youre solving either - an algorithmically hard problem or a
problem that requires iterative refinement, then you might have some valid
reasons not to outsource. Otherwise having additional manpower available when
needed might actually be a good thing.

------
gte910h
Outsourcing has pluses and minuses. Additionally, there is the question of
domestic outsourcing vs foreign outsourcing.

Now all that said, what can you do to appease the investor, but give over to
him? I don't recommend it, but hiring on the "worse end" of the below list has
surely poisoned past companies I've worked with against consultants.
Additionally, you can say "sorry, not going to do it". You didn't make him
CEO. At the same time, you will likely risk further investment from the
fellow, but if he didn't specify before investing he was going to force this
issue, well, then you can point that out you're feeling betrayed here
suggesting this huge of a cultural change.

Judicious use of outside development resources can improve a software
company's morale. Pretty much all other uses tank it.

I'm not poo pooing external consulting in all cases, however I am saying _be
realistic_ about what you're going to be dealing with when you hire someone at
"1/5 the cost".

I contend, if your business plan _can be excuted by a bunch of external
consultants_ , can't you instead build your company into a platform, and get
third party developers to build on it instead, and make your money off
licenses?

Sorry about the unorganized nature of the following points: They're not
connected enough to really summarize further.

\---------------------

With foreign outsourcing, you run into issues with cultural mismatch, as well
as time zone issues. These are often huge issues for a company, and your
relationship can get adversarial rather than team oriented relatively easy in
that situation.

Additionally, around the clock development is rarely the boon your investor is
making it out to be.

It is exceedingly hard to manage without sapping all the time of the people
who are not on the same time zone as the majority of players . Large
development teams basically in the same time zone are usually much more useful
than the same size or smaller team spread around the time zones, as
coordination get's more expensive off timezone.

Additionally, foreign outsourced firms suffer from legal risks and IP risks
(where they steal/take/copy) your code. Trade secrets, etc, are much harder to
enforce cross borders.

Lastly, with foreign outsourced employees, you lose key technologists every
few years with no way to directly offer them better terms.

Domestic outsourced employees are STILL problematic (Disclosure, I currently
run a product development company, so some people consider us domestic
outsourced employees). With Domestic outsourced employees, you face several
challenges still.

Firstly, if you gain enough control over their schedule or in-office work to
make them like a real employee, you risk tax consequences.

Secondly, you can still lose technologists, however you can often mitigate
this with buyout provisions with the providers (See contract to perm offers).

Thirdly, _any_ external employees is a trade secret risk. If the secret is
such is can be done in secret, no way to tell if the domestic external
employee is developing something offsite with someone else using your secret.

Domestic employees, whether external or internal, are vastly more reachable by
phone (usually), and are definitely easier to reign in via law. Contracts are
much more meaningful to someone you can easily sue the pants off of.

But even though domestic employees have some slight advantages, they have some
disadvantages too

Most people who work domestically for per project hire, would make more in
industry than they would working in a freelancing capacity. So the very
qualified will _still_ get job offers you will find hard to counter due to the
structure of your hiring arrangement.

Well, your "Individual chance of success" appears to vary widely depending on
where you hire from. In the experience of teams I've worked with, and others
I've talked to, here appears to be the lay of the land with foreign dev
shops.(Please speak up with your own experiences; I'm going for full and
complete rather than 100% nice; more experiences lead to more results):

Indian: Often one of the cheaper options, but also the one most likely to
staff your team with people who completely lie about their competency (or just
don't know they're bad) with the given technologies. It is nice that everyone
speaks English, but that's often not as important as the huge cultural
mismatch in which frankness and the ability to say "I don't like this, change
it" without lots of pain to the people at the company you're working with
aren't really there. Lots of "work to the contract" type stuff here which
means specification but avoids deep design goals.

Many of the Indian development shops are "low prestige, low ability"
workplaces for India, and once their employees gain real competency in a
technology, they move to a more typical product company in India, leaving
foreign consulting behind. There are some good experiences too, but they're
highly depended on WHO you hire, and are often prefaced by "but these first
guys we hired...."

China: Many _large_ companies have Chinese based consulting arms. They use
them often especially in the embedded sphere. You do not often deal as
directly with the development team in this country, but through an English
speaking liaison. It's hard to get a cultural feel through that type of
relationship, but in general, it feels more able to handle real criticism than
the Indian experiences. Comments, names, etc are often understandable, but can
be not, depending on the codebase. Things can get quite tied up in agreements
here, then the agreements completely ignored (which I do not really understand
why they spend so much time working on the agreements if they then know
they're going to ignore them). Some companies even keep liasons up for daytime
meetings with the US (others involve a late evening schedule to effectively
meet). Costs are on average higher than India

Success in this sphere appears to be about fiercely contained components that
have detailed specifications. More likely to have high ability folks, but
still much in the way of passing off low skill as high.

Western Europe: Specfication stages seem to go much faster, however people in
Western Europe don't feel like they work that many hours (probably true, but I
don't know that much about European labor law). On top of the coordination, it
makes for an interesting development. Similar skill variance as you see in
North America, (with the good AND the bad). More realistic about schedules in
my experience than their much lower cost peers in the developing world.

Eastern Europe: This is the place you hear the most good about. There are
plenty of low skill people trying to pass themselves off as high skill people,
but if you find good companies, they often hire several good people and fire
the lower skilled ones. Things like oDesk work out okay to hire individual
devs, but the company based solutions are often far superior (in both time,
individual additional management of employees, and even cost sometimes). The
time zone being far out of sync is the biggest issue in this zone. Prices are
_all over the map_ though as far as work goes. I personally view that as a
good thing, as you'd rather pay an amount in excess of the local norms if that
gives you more team stability (for some projects).

North American: This place is one of the most at hand. It feels like you're
working with someone you could "make permenant any day", and like you really
have recourse of law to deal with them in case of trouble. In reality, it's
pretty hard to hire people who work for consulting/product dev companies away;
they often enjoy the life they have more than the additional cash you can toss
at them. Additionally, you get the entire spectrum of americans here,
including the used cars salesmen types who slide along on charm rather than
ability, or secretly farm out your stuff to yet a third dev house. You can
most easily hire these folks on from a legal standpoint, but these folks are
often in the higher cost spectrum (and if they're not, you need to ask _why
not_ ).

[I'm sure I've offended a few hacker news people, for that I apologize, but
this is what I've learned working with people abroad and at home. Please join
the discussion and add your experiences]

------
ohashi
Perhaps you shouldn't be countering but making an argument about timing. 'I
think that is a good idea when we reach milestone X and this is how and why we
would do it then'

You seem to acknowledge the need for it, yet don't want to start right now. So
make that argument.

------
markbernard
Here is someone with experience outsourcing. And it is not good.

[http://www.lessonsoffailure.com/companies/outsourcing-
cost-l...](http://www.lessonsoffailure.com/companies/outsourcing-cost-lie/)

------
specialist
Hi Hates.

TL;DR: I'm sorry for your situation. Offshoring will fail. Find another job.

Here's my experience, some bullet points, followed by my advice:

Our bean counters have tried to offload our work overseas. Maybe 5 or 6 times
now. It never works. Here are my disjointed observations:

#1 The motivation to offshore is to reduce costs. Company grows by cutting
costs? Companies grow thru investment. My product is in an emerging market.
What moron tries to cut costs during a turf war in a green field?

#2 Most projects fail. Offshoring just reduces the cost of failure.

#3 Most companies wouldn't send their work down the block (e.g. outsource to
another company). Too many problems. Losing a core competency. Accountabilty,
transparency, responsiveness, etc. Then how does sending it across an ocean
make it all better?

#4 Offshoring will roughly triple your work (as a dev). Teach your
replacements, manage your replacements, QA/test the crap they create, give up
when you've run out of time, and end up doing a last minute rewrite.

#5 Want to know what working with offshore people is like?

First, take your experiences herding project managers, business analysts, QA,
testers, etc. All those "value add" corporate drones.

Next, add language barriers, culture mismatch, timezone skew, complete lack of
accountability and transparency, zero domain expertise, and very green
developers.

That's what working with offshore "teams" is like.

#6 It's about the people. I'd outsource again if I was working with the best.
I once sent a lot of our work to Europe (Belgium, Germany, Spain, France)
because we found the best people to do some very specific work. The people we
found were rockstars. Offloading specific tasks, plus all of the
infrastructure and processes we had in place, was like a force multiplier for
my team; it freed us up to work on other stuff. It was awesome.

#7 Time to market is more important than cost. I simply cannot imagine a
scenario where contracting / outsourcing / offshoring will shorten a project's
schedule. (With the exception of #6.)

#8 All the methodology stuff is mumbo jumbo. Agile, Scrum, SEI Level 5, ISO
9001, blah, blah, blah. Everyone we've worked with is well versed in all this
crap. Doesn't count for squat.

There's a difference between saying and doing.

I'm sure you've interviewed lots of people. The candidates with resumes
sporting all the vogue certifications are always a disappointment. They
allegedly passed a test. But we give programming tests and they usually
chowder.

Tell me what you've done. Not what you know. Methodology is moot if you don't
ship a useful, usable product.

#9 During the last 5 years, our bean counters have tried to use Indians and
Vietnamese. No expense was spared on training, sending people back and forth,
etc. The people we got to meet were absolutely wonderful.

I can't say enough how proud I am that our overseas peers are working in the
field and trying to get ahead in life.

Okay, done with the accolades.

Pretend for a moment that offshoring to India is workable. In our experience,
the turnover is incredible. At one time, the programmers we trained would last
maybe 9 months, and then zing, they'd be off to higher paid job. So then you
start over again with fresh meat, which is a reset (e.g. the forming,
storming, norming, performing cycle).

The Vietnamese people were super duper nice, and tried really really hard. But
the language barrier proved insurmountable. I think there's probably some
cultural stuff at play too, but we never really got past the most basic
programming tasks, so I honestly couldn't say.

#10 Our product (was once) in a new market. Emerging. And still changing
rapidly. All these offshore "bodyshops" want requirements and specifications.

Um, yea. Not possible.

We're making it up as we go along. The customer doesn't know what they want
until they see something. (Typical of an emerging market.)

If you've ever written documentation (reqs, use cases, UML, specs, test plans,
etc.) you know that it's just as hard and takes just as long as programming.
In fact, it harder. Because you're explaining stuff to a green programmer who
has no domain expertise.

Frankly, at that level of details, it's just quicker and easier to write the
code.

#11 When (not if) the offshoring fails, you'll be blamed. You didn't try hard
enough. Or you sabotaged the project.

As though Tinkerbell really will fly, if you'd all just clap loud enough.

###

Okay, I think that's my list.

Like I said at the top, we've tried this offshoring thing multiple times. I'm
absolutely certain it'll continue.

Those of us actually doing the work have tried to argue, deflect, stop, etc.
We always lose the debate. Now we're just numb and don't say anything.

The bean counters are not like you and me. They go nuts when they see 1/5th
the labor costs. That's the only number they care about.

To them, we're all just interchangeable. They have exactly no idea what we do
or how we work. Programming! Geesh! How hard could it be? And for these costs,
I can get 5 times the number of programmers! We'll have 5 times more product!

I've been around a lot of professions. Programming is a weird thing. We're
dismissed and second guessed all the time. What other profession is this
poorly regarded? People don't second guess their architects, plumber, doctor,
contract manager, mechanic, geologist, etc. (Or maybe they do...)

Okay. Rant over. Here's my advice.

Find another job. Something that'll make you happy.

I'm at a point in my life that I like having a steady job, health insurance,
and accrued vacation time. And I'm not busting my ass working 80 hours a week
making someone else rich again for a while. So I just smile, keep my head
down, and quietly pick up the pieces after each failure.

Such a life.

~~~
hga
" _Most projects fail. Offshoring just reduces the cost of failure._ "

BINGO!

When I saw that bit of wisdom some months ago I realized why the off-shoring
craze had gotten so far. In many big non-IT themselves companies most IT
project do indeed fail, so offshoring is a fantastic way to continue to
pretend to do IT while spending much less money.

------
JoachimSchipper
There are always lots of people on here who would be very happy to work
remotely; why not go with that instead? (The difference isn't very large, when
it boils down to it...)

