
My experience with off-shoring teams and what went wrong - rlv-dan
https://return.co.de/blog/articles/india-scaling-people/
======
t1o5
The author forgot to mention how much he paid for the offshore team. There was
no mention of money in the things that went wrong. I think the cost is a very
important factor if you expect a high quality project.

I have seen many people who bash India and Indian engineers for low quality
work, but lets get to the crux of the problem. Its not that Indian engineers
are all bad. They come in all shapes and sizes. You will get the best ones if
you pay enough. You pay cheap, you get cheap.

Where can you get cheap ones ? From those big IT companies who treats
employees as resources. The employees in turn will also treat their jobs along
those lines.

So if you need high quality work, please don't go to these giant corporations.
If you look hard enough, you will find small high quality places, but they are
not cheap and not 'scalable' like your manager wants them to be.

~~~
elboru
> From those big IT companies who treats employees as resources.

I've worked in those companies, they do treat employees as resources. I was
amazed how executives, RH and even Project Managers refered to developers
literally as "resources", example: "We are happy to announce we have five new
resources in project X".

No one seemed to care, that mentality was just sad.

~~~
swagtricker
The best response to people calling individual contributors "resources" is to
politely correct them. If the abusive terminology continues, then the
"resources" have the right to "return the favor" by setting the standard in
the culture of referring to managers as "overhead" (e.g. "I should ask my
'overhead' if I really need to attend that stupid meeting. I might be able to
dodge it so we can get this new feature checked in.")

~~~
markbnj
Problem is large orgs are political by nature. If you acted that way chances
are you'd be sidelined into some dead end thing, given all the crap work, or
even laid off as "not a good fit" or something. If you were the kind of person
who didn't care about those possibilities then you might as well be working
for a small company where you'd have a lot more fun... which is a backward way
of saying that the people who work at large corps often do value security and
stability and do care about keeping their jobs.

------
luckydude
BitKeeper guy here (predecessor to Git and Hg). If you think about the
capabilities of a distributed source management system you can quickly see
it's an enabler for out-sourcing.

As a commercial DSCM provider, we got to watch a lot of out-sourcing attempts.

In 18 years of doing that, I've only seen one really successful one. Which was
a Portland based dev team and a Singapore based test team. Every day, the dev
team would check in their stuff (or make it available in a test tree) and the
Singapore team would wake up, pull it, test it, document the failures, the
Portland team would wake up fix and dev some more, lather, rinse, repeat.

As I recall, the Singapore team was out-sourced, different company, but they
had a stable group of people dedicated to working with the Portland guys. It
was more like two teams working on the same project.

I've seen countless efforts based on "I can get 3 guys in India for what I
have to pay one junior guy here" fail. The time difference makes communication
hard, you have to send someone to manage the India guys and communicate what
you want, there is zero loyalty, if a better gig comes along all the time you
put into onboarding those guys is lost, the quality of the code is pretty
crappy, etc.

Pretty quickly it becomes not worth it.

~~~
compiler-guy
“There is zero loyalty.”

In business, even in the US, there is almost never loyalty. Or, perhaps more
precisely: In business, you have to buy loyalty.

I guarantee that there is a price at which you could buy a very stable, very
competent team in India. But then it wouldn’t be super cheap outsourcing any
more, and the benefits aren’t so great.

If you want stability in your workforce, you gotta pay for it. Whether in
cash, working conditions, or some other way.

Pay for cheap labor, get cheap labor. And don’t be surprised or disappointed
that you got it.

~~~
megy
> In business, even in the US, there is almost never loyalty.

There is loyalty here. You don't hire someone and they come in to work and
work on OTHER PEOPLE'S PROJECTS. You don't get people lying to your face daily
about their skills, it comes up pretty quickly that they can or can't do the
work.

Loyalty isn't just leaving because you have got a better offer.

~~~
praneshp
> There is loyalty here

Correct, but your OP is saying you need to buy that loyalty.

------
codingdave
> we needed to reject some candidates because we simply could not understand
> their English pronunciation.

That could be a mistake - If you find someone who has good skills, and would
otherwise make the team, there are language bootcamps you can send them to,
which will help with their English. I have sent people to them, and they ended
up being wonderful members of my team, once we got past the communication
barriers. If you are willing to coach on other topics, refusing to coach on
communications is an odd choice.

For my part, when building an offshore team, I did a few things:

1) Brought them here for a couple weeks. Seeing how we work, and getting to
know each other in person made a huge difference, including being able to get
used to accents and mannerisms. Like any other team, it built trust, which
goes a long way towards working well together.

2) I took lessons in Hindi. Never spoke it to them, never got fluent, and many
Indians don't speak it anyway... but just trying to learn it helped meet in
the middle on accents, and helped communications to the point that I often
ended up translating between 2 English speaking people who just couldn't
understand each other. And they appreciated having an American who would just
laugh with them when we couldn't understand each other vs. getting frustrated
and making them fear for their job.

~~~
mixmastamyk
Nice points. Unfortunately the type that is looking to offshore has a lot in
common with those who are not interested in training or coaching at all. No,
must "hit the ground running."

------
iooi
> Most of them came pretty late (around 9 or 10am), mostly due to heavy
> traffic in the city.

How is that late? It's not rare for some developers to get in between
11am-12pm in the large tech companies I know about/have worked at.

~~~
reaperducer
The last two places I worked, the devs were expected in at 7:00am, and 8:00am.
The second place gave you a five-minute grace period.

These weren't "tech" companies. They were companies in other industries.
You're not going to find a lot of 11am devs in finance, healthcare, or
manufacturing.

~~~
user5994461
> These weren't "tech" companies. They were companies in other industries.
> You're not going to find a lot of 11am devs in finance, healthcare, or
> manufacturing.

You'd be surprised. 10am is very common.

------
thisisit
This was a real insightful look at how "clients" feel when coming down to
India. There are some great points made on how things don't gel well together.

I have been on both side of the fence - both as a "resource" for an offshore
client and contracting a team for work. If I reading this correctly the issue
might have started from candidate selection itself.

You have to be strict when it comes to hiring. Startup scene has ensured a
good developers are paid well. But most offshoring firms tend to keep the
salaries low even for in-demand stuff like mobile app development.

So, offshoring pools can be dry. In which case, companies tend to fudge
resumes or provide some low quality devs.

So, look out for people being unable to answer basic stuff, that is red flag
1. And if they are unable to explain their past projects, that is red flag 2.

Apart from that, there is another thing you have to answer - What is more
important? Good candidate or quickly selecting one?

We had to spend 8-9 months looking for a candidate. We found one who fit
nearly 80% of our criteria, even with the best pay possible.

But when we tried building a team quickly - the overall pay rose
exponentially.

IMO, a better idea is to open an offshore center and fester a culture that you
want. It is difficult to ask people to follow one company's culture while they
are working in another.

~~~
mateo411
>IMO, a better idea is to open an offshore center and fester a culture that
you want.

You want to replace the word fester with foster. Fester has a negative
connotation.

------
dedsm
I owned a company that provided off-shore services to companies in the US, it
worked perfectly.

If you are doing off-shoring, you really need to insist on the independence
and the ability to speak up of the team, it doesn't work if you get yes-men,
sadly that's the general case for India-based offshore companies

~~~
megy
"Are you a yes-man?"

"No"

Perfect!

------
0x445442
It's an old, old story; middle management's never ending quest to commoditize
and automate software development. They'll never accept software development
has almost no commonality with assembly line work. But they keep trying.

Fast, good, cheap; pick any two.

~~~
andrei_says_
Isn’t this what their business education defined as success?

------
Joeri
_Although I never got an explanation, their managers were probably selling
their employees to multiple projects. I 've heard that this happens from
people working there._

Offshore developers from a body-shopping company who are _shopped_ to multiple
customers is common. I've seen it happen multiple times in different
countries.

I have over a decade of experience trying to make off-shore development work
with several off-shoring companies, one of which was a wholly owned subsidiary
(to avoid the various overbilling strategies). I've never been convinced it is
worth it overall. The semi-irrational insistence on off-shoring was actually
one of the primary reasons I quit my last job.

------
iAMAGuest
> But that was very exhaustive and couldn't obviously go on like that forever.
> Then we switched to weekly meetings, reviews were mostly done by their team
> lead.

That's where you went wrong first. You let go of the responsibility and handed
it over to people who did not necessary have your best interests in mind.
Quality, schedule, outcomes etc need to be managed, and managed so problems
can be picked up early.

Secondly "It turned out that from those 8-9 developers we hired, at the end of
the project only 3 of them were actually committing code. Although I never got
an explanation ...", point to another management issue.

I am sitting in a country with a reputation for being an outsourcing hub, I am
from the western world and I can tell you that there are many talented
developers. The problems are the same as I have had with managing western
teams, personal issues, skill levels etc though some of higher or lower
impact. But the basic fact remains, the further you distance yourself from
responsibility the greater the risk of failure.

------
gabept
For me, the secret was to stop looking at teams, and start looking at
individuals.

We found extremelly talented people that were underpaid, dislocated and
suffocated by a toxic and outdated culture.

~~~
r00fus
I always thought this. However, it seems like this would require a lot of
direct management. Who was the PM for you - was it you? if not, was she/he
local to the devs? What was your timezone?

My struggle with offshoring to India (from PST) is that the nearly opposite
timezone affords minimal overlaps, and thus either the offshore personnel or
the local person managing would have crappy hours.

------
carlsborg
There’s a right way to do this and a wrong way to do this.

More than a decade ago I started out as a developer on an offshore team for a
US based product startup. We grew from 2 people to 19 people and the US based
company did well in its market and got acquired in a successful exit a few
years later.

There are numerous success stories like this for every engagement gone wrong.

Now days I run an India based offshore team from Europe. The cost model has
changed dramatically over time, but the premise that you can ship quality code
with an India team is very much viable. Every large tech company does it. I’m
happy to chat offline if you want.

~~~
maxk42
I've hired a lot of remote developers over the years and it has pretty much
been a flop 2 / 3rds of the time. I had some reasonably good success with
Columbian developers a few years back, but the two most outstanding devs I
hired on a remote basis were based out of Utah and Connecticut.

I hired one a few months ago from Ukraine who absolutely blew the competition
away when it came to the coding test, but then failed to actually put in the
work hours when he started the job.

Any advice for interviewing / hiring remote devs that don't suck?

~~~
carlsborg
I think the engagement model is equally if not more important than the
recruiting. Tie their growth into yours. The startup I mentioned above gave
the India team stock options.

------
lowken10
About 15 years ago my company made a long term investment in hiring software
developers from India.

Early on were some of them terrible developers? Yes, but so are many United
States based Developers.

Now 15 years later I can tell you that my India based coworkers are some of
the best developers that I've ever worked with.

------
beagle3
I’ve heard and read so many “here is how my offshoring went wrong” (or even
just outsourcing locally), that I am really looking for successful examples
and what one can learn from them.

~~~
wordpressdev
I work as offshore / remote consultant with entrepreneurs and small-medium
sized companies in the US. Some of these clients are working with me since 5-6
years.

~~~
x0x0
You're not a good example though. You can definitely build a successful
relationship with a single dev in India. An easy route is to start on upwork,
pay well, churn a bunch of people until you meet someone good, then hire them.
The complexity comes when you need a team of people to build more than one
person can do.

~~~
wordpressdev
Building remote teams is tough, agreed. But it can be achieved. Off-shore does
not / should not mean cheap labor in some obscure part of the world. There are
plenty of examples of companies thriving with remote teams, such as:

Buffer: [https://buffer.com/about](https://buffer.com/about) Automattic
(parent of WordPress):
[https://automattic.com/about/](https://automattic.com/about/)

By the way, I am in Pakistan, not India :)

~~~
x0x0
My apologies for assuming.

I would say there aren't so many examples of companies with heavily remote
workforces thriving. As a founder, this was the subject of a lot of internal
debate. I largely came to the same conclusion as a lot of companies: remote
slows down execution, and execution is probably the single most important
thing for a small company.

Also, this article discussed something different than building a remote team,
and more in line with what most customers want: hire a mostly pre-made remote
team all at once. The desired advantage is less cost savings and more speed.
Building a remote team yourself is much more likely to work, but also probably
slow enough that it's not worth it. You have to find a remote teach lead +
hiring manager, work with him or her enough to trust him or her, and then
empower that person to run hiring cycles.

------
sebringj
I don't think it matters where people are as long as there isn't some
hindrance to their work ethic or shady work schemes going on. You simply have
to be due diligent AND be a tech lead at the same time. You cannot offshore
that part. No way. Instead, you directly know each person working on the
project and directly work with them, while providing guidance to the entire
team. (Directly meaning on Slack since its offshore) For example, a coder puts
out something sub optimal. You then correct that code, then go through this
with your coder in a constructive way why this way is better and more
efficient, while also noting to the group here is an example of X where you do
Y. I make repos specifically for projects to refer to as example code
scenarios that commonly crop up. For example, here's how you do a background
image on a flexbox that auto sizes itself or here's how you destructure a
promise.all easily, or here's a baseline project to start from with basic
bones and structure to work from. You have to really guide and lead and there
is no easy button where more time spent is the trade off of the cost savings.

------
farhanhubble
In India hiring decisions, on any level, are mostly based on which college one
comes from, how many random buzzwords one can speak, and not based on the
actual skills one has learned during college or picked up at work. People
'learn' things by reading nuggets from interview prep sites, they memorize
things and repeat like a tape-recorder during interviews. No wonder their
'understanding' is non existent.

At one end of the spectrum are people who come from 'premier' colleges (term
invented by HR folks, I guess), like the IITs and NITs. Although these
institutes produce some brilliant minds, the majority of graduates have no
skills whatsoever. Most of the skilled ones go abroad while the'unskilled'
ones get hired in India. So it's not uncommon to come across people, who have
fancy titles, get paid insane salaries (by Indian standards) and who have been
selected through 'rigorous' technical interviews to fumble when writing a
simple application program.

At the other end of the spectrum is a huge number of people graduating from
private colleges. The quality of teaching and learning at these colleges is
abysmal. Most of them end up at one or other 'IT giants' doing menial
maintenance work and earning a pittance.

The salary varies a lot across the spectrum but the quality of work is equally
bad. Their approach to programming, and problem solving in general, is trial-
and-error combined with some Googling. As the author points out the code that
is produced by these 'engineers' and 'programmers' is compiler-ready not
production-ready.

Of course there are exceptions too. A small minority of people who stay back
in India working for startups or as freelancers are amazing at what they do
irrespective of which college they went to or how they learned to program.

When you're sampling from this pool, your hiring process has to be ingenious
or you end up with insurmountable technical and financial debt.

------
seltzered_
Another approach would be to start with one developer living in europe/US
already but wants to live in India. Example: I have an Indian friend who was
working in Seattle but ultimately wanted to go back to India. He found a job
where he started at the headquarters on the east coast for a few months then
moved to India to build a team there.

The key thing is patience on these projects and paying people well. FWIW I'm
impatient and when I had a similar discussion with management as in the
blogpost I openly said it was a bad idea and found myself laid off months
later. The company eventually had changes in upper management and closed it's
India design center.

------
mindhash
Agree with most points.

A plug and play never works when it comes to scaling engineering function
through not just india but anywhere.

One must invest from a long term standpoint. Offshoring isn't a shortcut to
scaling, its better from cost perspective.

Its best to first get someone on the team who knows local ecosystem(offshore)
and is good fit from your culture standpoint. Its a harder process but once
you get this right you are most likely to succeed.

~~~
hinkley
I kinda blame the dotcom boom for this. Everyone lamented the bad habits
developers learned but from my perspective it was the managers who picked up
the worst tricks. As a manager you can make any lie work for about 18 months.
After that the devs know if you’re full of shit and by the two year mark you
have to find a new group of developers to feed your lines to.

You aren’t building a product. You’re building a team that knows how to build
that product. If you don’t then version 3 won’t ever happen. If you do it
poorly enough version 2 will not happen.

And once you’ve taken that risk of making a new product, why wouldn’t you want
a version 2 or 3? Isn’t that where all the money is?

------
latchkey
I'm from SF. Living in Saigon now for almost 2 years. Lots of people reach out
to me to 'offshore' here because they hear that VN devs are pretty good and
salaries are a fraction of the Bay Area.

What I've learned is that Vietnamese developers are generally smart and hard
working. There is a lot of young hipster attitude. They don't suffer from some
of the same cultural issues I've seen in other countries. They have their
whole own baggage here. ;-) They really love the latest technologies and
strive to keep up to date on things. At the end of the day, it is quite hit or
miss, but that could really be said anywhere.

In the past, I've never really been a huge fan of offshoring, but with the
right company, I've seen it work here on several occasions now. If you're
willing to pay a bit more (but still way less than the bay area) for the
better dev houses here, you can really get some quality work done.

------
pm90
Off-shoring is hard. But it can be done right. It requires honest intentions
and a commitment of enough financial resources. If a firm is off-shoring
simply to get the cheapest devs, its not going to work.

One of the first companies I worked at had an India office even though the
company was pretty small (~50 engineers in total). The Director of the India
office was good at recruiting good engineers and they were paid much above
market rates for the city they were based in (still less than what US based
developers were making). This situation worked out best for everyone. The only
problem was when scheduling long face to face meetings, which had to be done
either super early or later in the night. But I felt it was a small price to
pay to get to recruit a lot of good talent.

------
jrochkind1
Do the Indian developers get "cross-cultural training" in how to deal with
Americans, Germans, or other people from 'hiring' countries, or is it assumed
that only the Europeans and Americans have the aptitude to accommodate
unfamiliar cultural expectations?

~~~
rpiguy
I am sure they do, it is very common to have cross-cultural training. Go back
30-40 years and the Japanese and Korean professionals were getting cross-
cultural training to work with US teams.

Most MBA programs also include this kind of thing regardless of what country
you get your MBA in.

Of course you get a lot of generalities like:

\- Americans like fast decisions

\- Americans would rather fix a wrong fast decision after the fact than wait
to make the decision

\- Europeans generally prefer analysis and deliberate decisions

\- Japanese are consensus based and hierarchal

Etc.

~~~
jrochkind1
"Americans like fast decisions" I'd love to work in an organization with some
American managers/admins like that!

------
teachrdan
The punchline: "It cost us nearly a million Euros to get both applications to
a state that was acceptable to our customer. That did not include the actual
personnel, coaching and travel costs."

"It seems that costs scale better than people."

------
blub
The company management doesn't know what they're doing and are looking to grow
while magically cutting costs by outsourcing.

It takes years and/or a very solid network to build competent teams.

What went wrong? Your company is managed by amateurs.

------
rootsudo
I've had success using Filipinos for outsourced labors.

Also fun to live in the Philippines.

Realistically, if you need to coordinate people to only talk to person A
because he's in department X then you're going to have a rough time...

------
GFischer
Well... _" It turned out that from those 8-9 developers we hired, at the end
of the project only 3 of them were actually committing code."_

I guess that's what went wrong :( . I wonder why they do this, because they
can?

~~~
stevenwoo
Was asked to give an estimate on a project that was offshored and I was amazed
at a.) how few commits the developers did over several months b.) how little
the person who hired the offshore developers was monitoring them. It's just so
trivial to just check progress once a day, I like to commit to a development
branch at least every day because I am paranoid about losing progress or
experiments that I can reference even if I decide on something better later.

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

------
Yhippa
> In Germany, you would not call yourself a senior but apply for a position as
> senior.

Interesting. Anybody know why that is? Seems to happen in the US.

~~~
fitpolar
Because there are no junior developer jobs advertised.

That’s almost not sarcastic. Realistically though there is a lot ambiguity
over what defines a senior dev. If postings said 10-15 years experience or
experience in building stable and complex architecture across the whole
lifecycle...or something similar...that would clarify things.

~~~
crowbahr
It's very confusing honestly. If I wanted to apply for a job right now I've
got 1 year professional iOS development experience and 2 years Android... So I
don't really feel like a senior Android developer at all but junior positions
are incredibly scarce.

Most places I've seen are asking for a lot more experience or just saying
senior with "deep knowledge of Android framework"... Whatever that is supposed
to mean.

Like are you asking me to know the exact implementation of the stock
ArrayAdapter for ListView so that I can tell you why we'd need a custom one or
are you looking for someone to debug Dalvik/kernal issues?

Like I can architecture good clean code (and have done so for personal
projects as well as professional) but I still _feel_ junior because it _feels_
like junior should until be 4+ years of experience.

~~~
lainga
>Like are you asking me to know the exact implementation of the stock
ArrayAdapter for ListView so that I can tell you why we'd need a custom one or
are you looking for someone to debug Dalvik/kernal issues?

In my experience, both. They will hire for someone who knows every detail of
one field, and once you're hired, put you to work on a 5-year-old bug queue
for a technology you know nothing about.

~~~
crowbahr
Joy. Doesn't really entice me to leave the startup I work at.

------
pkaye
I find it important to have a off shore managerial team fully responsible for
the project in the same manner as the home office. You can't just hire the off
shore team and tell the home office engineers to make use of them. Also the
project should be divided so that there is minimal need for daily
communications between the teams.

------
megy
Yes, you need someone onshore to inspect every bit of work. Offshoring can be
done if you expect it. You don't just give them a project to work on an check
in when it is done, or once a week.

We would have standups every day, and tech leads in our country. They would
explain the work needed, make sure they were on task, and check there work.

------
JoeAltmaier
Sometimes its about ... everything. Time difference * culture difference *
tool availability * hierarchy * quality expectations. If they are all 90%, you
still end up at under 50% of the expected result.

------
jccalhoun
Interesting read. I would like to read something written from the perspective
of the team in India that maybe explains some of their impression of the
companies they are working for.

~~~
BareNakedCoder
Read "Speaking of India" by Craig Storti.

------
hemantv
Well good developers can get $100k in India. So money is very bad reason to
hire in India.

But equity you get is peanuts.

------
lijurajpillai
You pay peanuts you get monkeys !!! If you want to outsource for cost then
good luck with that, but if you want to do it for skill then you have options.
There are really good shops who provide amazing service.These companies hire
from the right schools and provide great training . Too much generalisation
and lack of information in the article.

------
znpy
«if you pay peanuts, you get monkeys»

------
mvpu
Indian engineers in India are like animals in a zoo. Indian engineers outside
India are like animals in a forest. They thrive and shine because they are
free. It's all in the environment. The only way to add "offshore" teams safely
is to find people who refuse to accept a code review comment because that's
not the right thing to do, no matter which part of the world they are in.

~~~
ILikeConemowk
>Indian engineers in India are like animals in a zoo. Indian engineers outside
India are like animals in a forest. They thrive and shine because they are
free. It's all in the environment.

These kind of generalizations are useless. There are "zoo animals" and "forest
animals" all over the world regardless of location.

