I would say it never really has worked; there is no "anymore".
One problem in outsourcing is the thinking that programmers are somehow easily replaced; the "just find 'a' developer" idea, with little to no thought put into whether it may matter if the chosen team has any idea what they're doing. Two anecdotes. Years ago I was given such a team, to maintain a system primarily written in two different languages; the manager in charge gave me two guys from the other side of the world who were to be "taking over" the project despite not knowing how to program in either language, and there was no arguing this point. On another project, a resource from far away was graciously donated to me to help with a C++ project; I later realized he had chosen to recreate several container classes in C++ as if he'd never heard of the STL.
Another problem is the fundamental misunderstanding of culture. Managers in the U.S. seem surprised when they encounter wildly different behaviors overseas (gee, it's almost as if they had hired someone from a completely different part of the world!). For instance, I have encountered remote groups that are astoundingly good at self-preservation, who will basically change their minds and do whatever they want at the last minute to prop up their team at the expense of your project. Individuals, too, may have side projects that they care about much more than anything you have asked them to do.
Agreed. 20 years, and I've never seen a return on an outsourced project. The overseas company whittles the specs down so far, your own guys could do it in a weekend. The cost of managing is larger than the value received: barriers include language, timezone, network access, culture, currency, import/export rules. The culture one is huge. Many cultures, a worker won't contradict a boss for any reason. So you're trying to get an expert opinion out of them about how to proceed, they're just saying "Uh huh, yes boss".
Or they will require such detailed functional specs that by the end you're almost literally just paying for ten fingers to do the typing. An example that I wish weren't true: one specification had detail to the level of specifying that a particular form required a button to submit the form. The returned product had a button titled "Submit the Form." It did nothing, because the specification did not explicitly say to submit the form when the button was clicked.
A web app I inherited, for which I do not have the original spec, and initially developed by an outsourced offshore team, had one route that was literally "/obscure/reset_password?user_id=x". A light dawned when I realized they must have been asked to provide an unguessable or "obscure" endpoint for account actions.
You should try other outsourcing destinations. Large timezone differences are indeed a hurdle, and culture differences is always underestimated. Add to that the general ineptitude of managing projects in large companies, and you have a recipe for disaster.
In Western Europe, the most compatible culture and therefore easiest place to start, is Eastern Europe and Russia. If you are in the US, I'd personally just outsource to US companies in the midwest. Some of my western European clients are actually doing this now, as for example NC hourly rates are lower than Moscow rates.
Managing projects where you have big cultural differences require many years of experience in that particular area. Even then, it requires a much higher project management effort.
If management of a project with a local team take on average 10% of total project time, a project with developers in a markedly different work culture will easily take 20-30% of time spend.
We had a wonderful Ukrainian engineer working for us. It was a very productive relationship. He worked 1 on 1 with a project leader here, and they got more done than the Russian team ever did. But that ended; one day in the standup he said "I have to go; we're having a revolution outside my window".
I remember having to work with a Croatian outsourcing company once, it was pretty much the same as the worst-case people talk about for India. You had to nail down the specs exactly, most of what you nailed down wouldn't get implemented anyway (despite being paid for it) and a lot of what we thought was nailed down was implemented incorrectly due to poor understanding of English. Conversely I've heard a lot of good things about the better Indian and Chinese outsourcing companies. It feels like one of the biggest problems with outsourcing is that when a company decides to outsource, they're already price-sensitive, so many of them go for the lowest bidder instead of paying the extra for a good outsourced team -- which would still usually come out cheaper than a good local team.
Fully agree. Nationality alone isn't a sure fire indicator of quality. I find that on average there is a higher success rate with eastern europe / russia vendors, especially when the onshore personnel are inexperienced with outsourcing. But of course there is hits and misses no matter what country you choose. Finding a good vendor in any location is a discipline in itself.
And yes, if a company decides to outsource with low price being the overshadowing priority, they are likely to end up with the amazingly low price and amazingly low quality vendors.
Also agreed. Shopping on the basis of nationality misses the point. The problem with India is that small cheap outsourcing shops have zero chance of attracting top talent. In smaller markets, where big prestigious technology companies don't have offices, you are more likely to luck-in to exceptionally good overseas engineers at a good price.
But you sure can't count on this happening, and, by the very nature of this effect, it doesn't scale, and it isn't repeatable.
Funny. In my experience telling something as it is is a very easy way to piss of the client, who in general have huge ego that they are from a superior culture.
One of the primary benefits of an external contractor is that they are mostly unaffected by whatever politics are occurring within the company. This means that they're more likely to give direct, honest feedback, and they won't worry very much about whose feelings it hurts. This is supremely valuable in most organizations, and impossible for most employees to provide if they want to stick around for more than a few months.
There are unreasonable people everywhere, of course, so it's not that weird to find a client who doesn't understand the value of this service.
Even if that is true (which it may well be), it's yet another landmine for companies who seek solutions via outsourcing.
I'd agree with OP on this. I've never seen a distributed, outsourced approach work. The product has always been poor or even worthless.
Having said that, I have seen distributed, in-house projects work, sometimes very well, even when the teams were internationally distributed, and even with moderate language barriers.
And now the bigger software companies are opening "research centers" in the offshore countries and just plain moving the jobs there. Specifically China, which was the big deal when the president of China recently met with Facebook, Twitter, Google, and Apple at Microsoft's main campus.
Oh boy... That leads on to another thing that most non-technical (and even some technical!) managers don't understand: IT people are not drop-in modular components that will instantly work!
Here's an example: I did some BI work in Qlikview. The existing reports for a particular division were badly written, and were each loaded manually for each client. Due to a number of reasons, we weren't able to change this situation immediately, but we kept what we had running even though it was incredibly inefficient.
Eventually it got to the stage where we needed to get the reports working in an automated fashion. I had a solution I was willing to work on, but was unable to find the time to do it as my primary responsibility was to another BI project.
The manager kept putting off getting new resources, and tried to "fix" the reports himself, only ending up breaking them completely.
The solution that management came up with was to employ a new resource. However, by the time they employed the new person they had 3 days to get the reports working. The problem was that even though the new person understood Qlikview exceptionally well, he didn't understand (and had no way of knowing immediately!):
1. What the dashboards needed to show (not documented)
2. The data sources used in the Qlikview dashboard
3. The way the Qlikview load script had been coded
As the guy was really, really good it ended up taking just under two weeks to get to grips with the underlying data structures and business requirements. The implementation to fix the numerous dashboards took another week. Then fixing any issues took another week and a half. So that was about a month and a half of work to get the guy up to speed, then implement a solution.
Management expects someone to be like a field replicable unit, that you can drop-in and replace on a project. But that is not the way these things work - the nature of people and projects (which are each different) is that there is ALWAYS a lead time - sometimes up to months depending in the complexity of the project - where the new person you employ (no matter how good they are) needs to familiarise and understand the systems and requirements of the business before they can actually do productive work.
Orthogonal nit, you tripped over one of my soapboxes: "employ a new resource".
People are not resources, like a vein of coal. They are individual. Which was your point. But using the word "resource" instead of "person" perpetuates bad ideas.
When you deal primarily with people whose primary roles and careers have been driven entirely by Taylorist managerial principles (fundamentally, the belief that managers are the ones that know best and most efficient instruments to allocate workers and efforts instead of relying upon workers themselves) then you're somewhat forced to deal with the language of contracts where people are interchangeable with the term and it's a reality you have to just deal with if you do business with them. It's treating all your workers like you're playing Starcraft rather than trying to manage an elite Navy Seals team where each person is fully capable of independent actions and thoughts. Rather, most large companies are used to rather low quality labor and I might dare to say that some companies prefer their "go do something" labor as fairly narrow while their managers are showered with praise and glory constantly for the work of those they're managing.
It's hard for a lot of people on here to imagine dealing with 100k+ other coworkers but at a point you oftentimes have to abstract away what makes people human to work in most large corporations. I'm not advocating that this is correct, but much like slavery and flat world theory, I hope this becomes outdated and struck out as both completely ineffective from a business standpoint as well as unconscionable.
Unfortunately I think we're still stuck in thinking of software development as being like assembling a product on a manufacturing line. Assembly lines reproduce a product model in volume. People forget that developing the model takes loads of time from designers and engineers. Software developers are the designer, engineer, and assembler all at once.
No, you prototype out the assembly line when you are working on it (actually not that different from how assembly lines are designed), though I guess in some cases you sell the assembly line itself, rather than the services it provides or the products it produces.
> It's hard for a lot of people on here to imagine dealing with 100k+ other coworkers but at a point you oftentimes have to abstract away what makes people human to work in most large corporations.
Working myself for a company of 150K+ employees, I can confirm this is totally true.
I hate a lot of high-level business speak like "resources", but what I've come to realize is that one cannot think of 150K people as individuals. It's too much for the human mind. If you see this as an indictment of large corporations, I wouldn't blame you. Just realize it's a reality of operating inside them.
In this context, the narrative was around hiring a single individual, not moving a thousand-person division of engineers onto the project. In a large-scale system, you also have to deal with the entailments of all those thousand people: the managerial overhead, the administrative overhead, the offices, etc. "Resources" becomes more appropriate, because it is more than individuals.
People rail against this, but I think it profoundly misunderstands the semantics. Gas is a resource. Money is a resource. Gold is a resource. A person is a resource. Nonetheless, only one of them is going to help my car go farther if I stick it in my fuel tank.
A resource isn't intrinsically a fungible commodity (when they are, we call them "commodities" ;-); often they are unique. The common trait of resources from a businesses perspective is that they are valuable to the business. Sure, I'd like to think I have more significance to this world as a person, but the day my employer doesn't see me as valuable is the day I start sending my resume around...
The other way to look at it is that while employees are individuals, they all take a paycheck. So, on the cost side, employees are all just different sized paychecks. When you are looking to assign employees to a task, you absolutely think about which individuals could/should be dong what, but before that, there is a decision about how much in the way of paychecks, if any, you ought to burning on that work. That first decision has little to do with the individuals involved.
> Gas is a resource. Money is a resource. Gold is a resource. A person is a resource.
A person is not a resource outside of contexts in which chattel slavery exists. Labor is a resource, of which persons -- laborers (whether independent contractors or employees) -- are contracted suppliers, not units.
This dehumanizing confusion of supplier with the resource they supply seems to only happen with labor.
> A person is not a resource outside of contexts in which chattel slavery exists.
Your reference to chattel inspired me. Consider the cow. Cows are resources. There are a ton of rules about what one can and cannot do with cows, but businesses still think of the "cow" as their resource, and "beef" and "milk" as some of the value they get from the resource.
Now, to your point on slavery, the rules for what you can and cannot do to people are very different from cattle. Of course, slavery is pretty irrelevant to whether someone is considered fungible (owning people is horrible, but it doesn't change whether they are interchangeable or not).
In practice resources are often suppliers and often the value the business extracts from them are provided under contract or at least a generalized regulatory framework. You are again confusing properties of certain kinds of resources with properties of resources in general.
Labour is very much how you marshall your "people" resources. It's a far more impersonal window through which to view people's relationships with businesses.
> Labor is a resource, of which persons -- laborers (whether independent contractors or employees) -- are contracted suppliers, not units.
Check out the definition of a "resource". It's the asset you draw upon to accomplish something.
Strictly speaking, the real "resource" is the employment or contract with the person, not the labour. However, thinking in those terms is terribly impersonal and not terribly useful for reasoning about a business (outside of legal disputes); in reality the person(s) under a contract correlate with suitability, outcomes, etc. a heck of a lot more than the contracts themselves. So what you really think in terms of are the people, not the contracts.
Agreed. My bad, in fact I acknowledge the irony, given my point (as you have picked up!) is you cannot treat contractors like a physical commodity! I appreciate you highlighting that discrepancy in my comment :-)
That's less a foible and more a character strength :-) the foible is referring to someone as a mere "resource" (and yes, I am acknowledging my own foible here!).
Good point. I hate that word "resource" as applied to people, but I say it all the time, because everyone else does -- not a conscious choice, just a bad habit.
> Management expects someone to be like a field replicable unit, that you can drop-in and replace on a project.
Someone needs to explain to me why would this be a bad thing?
They bleed lots of money and that allows the Darwinistic decimation process to kick in and ultimately wipe them out.
A fool and his money are easily parted, and that is how it should be.
You see, someone who is not capable of programming, should not be allowed to manage programmers, because that simply amounts to an insult. He cannot do what you can do. Therefore, he is an idiot. Nobody wants to take orders from an idiot. Every single business on the planet is now, one way or another, turning into a technology platform. This means that in the end, it is programmers who will own and control everything, and not that bunch of idiots.
This is not how life works. It is how you wish life would work.
Humans are social animals. The power to cause (or prevent) change in organizations is political in nature. The power to affect operations through technology is at best instrumental to the power to decide what effect is to be implemented. By ignoring these facts, programmers forego the opportunity to be seen as valuable allies and turn themselves into exploitable resources. No amount of progress, or "platformization" is going to change that.
Sure, getting high paying jobs with little accountability can be kind of cool, in the short term. But you need to think what happens next. If social Darwinism is true, idiot managers will die out and be replaced with more competent managers. It will take years, but at the end of day, they will wise up. And if so many of them see programmers as a threat they will cut our jobs.
To a degree, this is what we are seeing now. The older generation of managers learned that programmers are unreliable, so they outsource not to save money, but to mitigate the risk of having to deal with programmers directly. The next generation is learning that the 3rd parties that isolate them from programmers are unreliable too. I expect the next generation will be very reluctanct to have in house development at all, and that they will limit themselves to existing products from reputable companies, if at all.
Hard to tell what happens when that option is also shown to be not reliable.
> You see, someone who is not capable of programming, should not be allowed to manage programmers, because that simply amounts to an insult.
I hate this trope. There are thousands of professions out there, and most of them involve some kind of specialized knowledge/ability/skill. Do you really expect the head of your organization, the person least likely to have time to do independent work, to be the one with mastery of all the activities in the organization?
> He cannot do what you can do. Therefore, he is an idiot.
This one is even worse. It's not like programmers know how to do everyone else's jobs, and they aren't idiots.
> Nobody wants to take orders from an idiot.
Some cynical folks have argued that the advantage is that idiots are easily manipulated...
> Every single business on the planet is now, one way or another, turning into a technology platform.
Technology != software, and even if it did, very few businesses are viable as a software platform. Software is becoming an increasingly intrinsic part of most businesses, but so is accounting, legal, hr, management...
> This means that in the end, it is programmers who will own and control everything, and not that bunch of idiots.
I can imagine an accountant thinking much the same thing a century ago...
I hate this trope. There are thousands of professions out there, and most of them involve some kind of specialized knowledge/ability/skill. Do you really expect the head of your organization, the person least likely to have time to do independent work, to be the one with mastery of all the activities in the organization?
It's considered unethical for doctors or lawyers to have their work supervised by anyone who isn't a doctor or lawyer. They enforce the rule through professional conduct rules and boards. the result is very high prestige, pay, and working conditions for people with similar skills and education to programmers.
But the atomistic libertarianism and lack of solidarity among programmers makes us targets of mass low wage immigration, outsourcing, and every kind of unpleasant work situation.
> It's considered unethical for doctors or lawyers to have their work supervised by anyone who isn't a doctor or lawyer.
With lawyers (more familiar there than with doctors) I don't think that's usually the case; the ABA model rules don't prohibit lawyers from being supervised by non-lawyers (though they do prohibit lawyers from co-owning law firms with non-lawyers, or sharing legal fees with non-lawyers, and they do prohibit lawyers from allowing their employer to "to direct or regulate the lawyer's professional judgment" in providing legal services -- whether or not the employer is a lawyer; this doesn't prevent supervision of the lawyer as an employee, it just essentially means that the lawyer doesn't have a Nuremberg defense of "just following orders" for professional nonfeasance or misconduct.)
> It's considered unethical for doctors or lawyers to have their work supervised by anyone who isn't a doctor or lawyer. They enforce the rule through professional conduct rules and boards. the result is very high prestige, pay, and working conditions for people with similar skills and education to programmers.
I've supervised lawyers, though I'm not a lawyer. I know the same applies to other people with regards to doctors. The trade establishes rules they can't violate, but there are a ton of caveats on that. Regardless, those restrictions are actually needed by the organizations for specific roles. If a programmer was needed in a similar way for a specific role, it'd largely work out the same way. The main difference is there'd be no independent review board that has no idea what is going on in the day-to-day unless otherwise alerted.
The prestige/pay/working conditions thing is more a result of a trade group, and the consequent standards for people even being part of the trade, than due to supervision by those who lack skill expertise.
If you restrict yourself to the subset of programmers who have similar education, training, and professional validation processes as doctors & lawyers, I think you'll find a lot of prestige, pay, and quality work conditions (lawyers and doctors will tell you that it isn't quite as good as you imagine anyway).
> I hate this trope. There are thousands of professions out there, and most of them involve some kind of specialized knowledge/ability/skill. Do you really expect the head of your organization, the person least likely to have time to do independent work, to be the one with mastery of all the activities in the organization?
Agreed. How would you even run a small town according to this "logic"? You would need to be a professional in many different fields. That's why you have advisers for, and that's why a good manager will listen to the people he is managing.
They bleed lots of money and that allows the Darwinistic decimation process to kick in and ultimately wipe them out.
Better yet -- they bleed lots of money but don't die out, due to being hugely profitable, so they continue bleeding lots of money and we finally get the trickle-down economy Reagan promised us.
It's a bad thing because it doesn't work that way. Software engineers are skilled workers, not assembly line workers. And business Darwinism doesn't really work. Otherwise Comcast would have gone under years ago.
> I would say it never really has worked; there is no "anymore".
Completely agree. I saw this trend when I managed pieces of my team in the Philippines. Nothing wrong with the people there, but you still get what you pay for. When outsourcing is supposed to be 'cheap' people who were any good would be gone in a month or less because I wasn't allowed to pay them more. The second part is that very little software is 'here is a complete spec, now type in the code'. It is usually I have an idea and maybe a rough spec and I need a MVP written to start exploring. During this exploration having my software people learn and explore with me is critical.
Add in the timezone costs, communication costs, costs of actual good people, turnover, and pretty soon the costs are what it would take to have someone local.
This is interesting, because you're ignoring the fact that the author worked in this exact business for some time and claims that it did once work and doesn't anymore.
Either he was deluded at the time and overcame his delusion without ever realizing he was deluded (which is possible) or there's more to it than you make it seem. Because I think someone who says "this used to work and now it doesn't" may have something profound to say that the person saying "this has never worked" needs to hear.
Perhaps you're right and software outsourcing has never worked, in the sense that from a total cost standpoint it has never been better to contract development of a software project to a third party than to create it in house. I don't agree with this, but we'll accept it for the point of argument. You're still ignoring his point that the change in economics has caused a cultural change in the attitudes of those who lead outsourcing entities.
The article claims that previously, the economics allowed them the luxury of trying to deliver a result to their customers. Now, they are not able to do so because the economics require them to milk their customers for every cent in order to break even.
This may not directly affect you if you have always believed that outsourcing doesn't work and you disagree with his opening statements attempting to rebut that mindset. But it's still an interesting view from the inside.
> This is interesting, because you're ignoring the fact that the author worked in this exact business for some time and claims that it did once work and doesn't anymore.
Reading between the lines, it "worked" because it was an incredibly high margin business and so when a project wasn't on track they could simply throw many more developers into the mix to get it over the line.
> Either he was deluded at the time and overcame his delusion without ever realizing he was deluded
Or I suspect they simply have a different idea of "worked".
I suspect the OP means was better (I.e. Cheaper, quicker, or of a higher quality) than an internal team could do. Whereas I suspect the writer meant he could keep clients reasonably happy and deliver ok software.
At the end of the article, his explanation of how this used to “work” is based on what developers were once paid. Cost is a tricky thing to sum up because if you state just one thing (monthly rate, as he did), it's easy for other costs to be left out.
It is entirely possible to pay less for the same talent. My thinking is that he got lucky though.
If you start out underpaying, you can still overpay thereafter. Here is a quick top-of-my-head list of major software costs that can come up (not too far) down the line, after paying initial development wages:
- Documentation turns out to be nonexistent or written in a way that is hard to decipher, or wrong. (This seems more likely with outsourcing because heck, you didn't specify that you wanted the code documented, and it'll take hours to add all that, plus you might pay more later if it's not there...)
- Serious bugs are lurking that require a little time to discover.
- Although the system demo'd well with initial tests, it collapsed when asked to scale slightly; e.g. it exposed a bad choice of algorithm that blew up with large N. Sometimes bad algorithms from inexperienced developers can create a catastrophically large amount of refactoring work.
- The developers took short-cuts and exposed the company to a legal minefield (e.g. copying something or injecting patented or GPL'd code without asking), rendering their working and brilliantly-implemented solution unusable. Now what...even if you can argue that it's their fault, you're probably going to be paying lawyers for something (defense or lawsuits).
- The system does seem to do what it's supposed to do but it turns out you didn't specify it quite right and it integrates poorly into your environment in some way. So, great: it's done, it's here, it runs but you still aren't getting anything out of it because you have to spend more time and money to bring it to a usable state internally. Typically this doesn't happen with internally-developed systems because the people are familiar all along with the idiosyncrasies of the environment.
Even at a cheaper hourly rate, how many more times are you going to go back to the provider (just a few more hours at a cheap rate to fix the next problem...) before you've gained nothing? Much less the fact that you have zero actual employees who understand what you bought so if the provider ever goes out of business or triples its prices, you incur another "new" cost: hiring or redirecting your own people to figure out this thing that you bought and now have to maintain yourself.
The simple truth is that people who outsource development to firms in developing nations are trying to get more than they're willing to pay for, which has never worked - ever.
It is an inherent issue with the industry, demonstrated by the strategy of adding more people to a project and expecting productivity to increase on a linear scale. Although, intuitively, people surely understand that writing software is a complex task it's surprising how many people seem to just assume it's just banging away at keys on a keyboard.
I have seen the same problems on in-sourced projects. You still need capable engineers. May be managers who outsource their projects tend to be more clueless. I give you that.
Software is very hard to do well, and you're right that many in-sourced projects fail or suffer extensive problems. But when you outsource, you keep all the normal, natural problems of software development and add many more enormous burdens and difficulties on top of that. In my experience, the failure rate of outsourced projects is much higher than that of in-sourced projects. We can't gloss over the differences by just saying that they both experience failures.
I agree that capable engineers are very important, but I have seen more than one project with high-quality engineers fail. Of course, you very rarely get high-quality engineers with outsourcing.
I completely agree with you. I was just trying to stress the importance of having capable engineers. It seems that people forget about it when they outsource. Furthermore, you actually need better engineers if you outsource.
> I would say it never really has worked; there is no "anymore".
That's the point of the article. To quote the final sentence: The point of all this is that outsourcing simply can't work, because your business interests can't be aligned with the interests of your outsourcing "partner."
The author is on the right track, but he fails to form a serviceable thesis. You should never exchange cash for services if you follow his thesis strictly. My ten year relationship with my own awesome dentist falsifies this thesis.
To find a better thesis, we might ask, what's the difference between my dentist and WeCodeLikeNoOneElse, Inc?
I think the main difference is reputation, the role it plays the given marketplace. I'm not sure why, but the market for offshore development has never counted on reputation. I can't name a single firm. I can't even remember the name of the firm I recently interacted with as a contractor coming in to to clean up their mess. If I were to suss out any one of the unsolicited Linked In offers for cheap development I get each week, where would I even start?
My dentist has built up a loyal clientele by word of mouth in the community over a lifetime. The community is small enough that a shady dentist would be run out town in no time.
Conversely, I do know the names of some local dev shops, and I know their reputations. The ones with good reputations do not treat their clients purely as cash cows. Although they face the same, or worse pressures on utilization, they do quality work, at a premium. They have built brands and will grow or sink mostly on reputation. They still constantly face incentives to pump out shit, but there's a counter balance that's missing in the offshore outsourcing market.
> What's the difference between my dentist and WeCodeLikeNoOneElse, Inc?
Lack of reputation might be a factor in why software outsourcing sucks, but the dentist analogy doesn't work.
How does the average person find a dentist? They ask their neighbor or co-worker, who says, "Well, I go to Joe on Maple Street, and he's OK." Seriously, how many dentists does your neighbor actually know? It's probably exactly 1. How many dentists has your neighbor gone to in his entire lifetime? Probably 2 or 3. He has no basis for making comparisons.
I trust neighbors and co-workers to give me movie and restaurant recommendations because the average person has experienced hundreds or thousands of those.
PS: Here's how I find a dentist or doctor when I move to a new city: I do a Google search for ones nearby, look up their credentials, then choose one who went to a recognized university and whose degree is not too recent (inexperienced) and not a terribly long time ago (outdated knowledge, retirement age). This can't be any worse than selecting the 1 guy that your neighbor knows.
As for dentist, I found mine the best way possible - a coworker's sister studied with this dentist told my friend she wouldn't trust anyone else. Been going to his office ever since.
for dentists as for outsourcing, it is often an unnecessary effort to try to find the best available one. "he's okay" is a perfectly fine metric - i.e. "will do the job i need done, at a price and quality that are acceptable to me". small-scale yes/no-based reputation is fine for that.
more specifically, you don't need your neighbour to have seen lots of dentists so much as you need lots of your neighbours to have seen joe on maple street and deemed him okay.
There are "boutique" outsourcing places, some in countries you would not expect, who do specialized sorts of work with the best quality at low rates. A lot of people I know the Los Angeles area run startups with outsourced development shops in India that have excellent, excellent teams.
Personally, though, I don't like working for somebody else's consulting shop because of the agency problems mentioned. For instance you get a call from a customer who wants to know why his project is not moving forward, well the real answer is "My boss told me to work on somebody else's project because it is more important to the company." If you say that you will have an unhappy customer and some kind of "correction" from your boss, but if you refuse to give a true answer for the schedule slip, the customer will wonder if you are brain dead or all getting stoned at work or about to go out of business or...
Software development "inside" a company has its own problems too that show up in various forms.
A "non-technical founder" can often spend $25-50k or so to outside developers to make an e-commerce system that is a "minimal viable product" and then you are in a good place to market it, show to investors, bring in more people, etc.
Sometimes it works but sometimes it does not, you might pay the money and get nothing or get a product which is minimal but not viable.
If you've been told to work on something else, and you get a call from the customer asking about project status, the correct answer should be to refer your customer up to their allocated project/account manager.
If your boss is re-assigning you then not keeping the customer informed on progress, that sounds like bad management, not a flaw in the agency model.
In that particular case my manager would not have done anything different than I would do or get any different results, it would just be somebody else doing it.
Effectively I was doing the project management and the only thing he was doing was cashing and cutting checks.
> For instance you get a call from a customer who wants to know why his project is not moving forward, well the real answer is "My boss told me to work on somebody else's project because it is more important to the company."
If you in source though, the right answer might be, "My boss told me to work on somebody else's project because it was more important to the company.". ;-)
> To find a better thesis, we might ask, what's the difference between my dentist and WeCodeLikeNoOneElse, Inc?
The difference is that your dentist job is way easier to define, .e.g "Take care of that cavity"
When you outsource the development of a software, you easily end up with pages and pages of specs, and it's almost certain there will be holes in them.
Even if the remote dev shop is of good faith, it takes a lot of effort and talent to actually understand what your client need and want.
Exactly. "Don't outsource" comes loaded with false positives and false negatives. I absolutely would trust Galois to write software for me in pretty much any circumstance imaginable. And on the other hand, I've seen far too many insourced dev teams deliver pizzas when theyve been asked to deliver hamburgers, and then subsequently try to modify the pizza into a hamburger because they didn't want to rewrite.
When you have someone you trust, you use them. When you don't, you go by reputation (aka trust by proxy).
Absolutely agree on the reputation and word of mouth.
There are great freelancers and consultants who can work with you to build your app. If you work in the industry long enough you will eventually come across them and they really know their stuff. Otherwise, it's a total crapshoot.
They will able to show you a portfolio of work, they will NOT just build anything you ask for (instead they'll work with you to refine your idea into something viable), and they will be expensive.
However, all of these people are local and I have never heard a success story first-hand about looking overseas to cut costs.
I don't know about the word "outsourcing", but there are many cases where getting an experienced external team to build software is a great way to go. It works much better than trying to hire an in-house team for a small non-tech company, not least because it's impossible to get anyone good to join.
> The author is on the right track, but he fails to form a serviceable thesis.
Totally. His whole argument is essentially that the margin isn't high enough. It fails to acknowledge the truth that is highlighted all over this thread: most businesses are terrible it managing software development. It follows then that there is value in a trusted business specializing in managing software development to assist those businesses for whom it isn't a core competency.
Could also be training. Your dentist has years of highly specialized training, and if he faked his accreditation he'd expect to end up in prison. Your random programmer can set themselves up with no training or accredited knowledge whatsoever.
I think one of the biggest problems with outsourcing comes from 2 groups of people.
Generally these are the most vocal proponents at first, only to become some of the most vocal opponents later. The way I would classify them, generally speaking, are: (a) business people looking to keep costs down but don't know the first thing about running a technology project, (b) those who think "outsourcing" means "I tell you the idea, and you do all the work".
Technology projects (especially custom ones) are hard, and they require a lot of due diligence and hard work from all parties involved.
I would never recommend a non-technical person / company to try outsourcing. It's a recipe for disaster. That is unless you fully trust the person / group of people who you're putting in charge of the project.
EDIT: Thought I'd add a clarification here. Never recommend outsourcing of CUSTOM projects that is. Cookie cutter solutions it's obviously a different story...
And I guess another edit would be to differentiate "scale" of a project. Large scale projects which will be "centerpieces" to a company, are the kinds of projects that I read about being outsourced which alot of times seem to turn bad.
> "outsourcing" means "I tell you the idea, and you do all the work".
It is okay for anyone to think this, but in any project it is not okay for the workers to leave it uncorrected.
I do contract software projects in the US (near NYC). I get this on every project. A loose scope and a general idea, and then the go-ahead.
It is my responsibility to refine the scope. Sometimes that takes an email, sometimes a longer discussion, and sometimes it takes a small prototype for the client to play with to find out if it is right for them.
It would be incredibly dishonest to just make a project based on what I saw from the beginning. It'd be dishonest of anyone in any industry.
I think I agree to a point. What I discuss ahead of time with potential clients is the fact that in order for the project to be successful they need to be engaged and willing to work with me toward what eventually will be the end product. I've never received what I would consider a "sufficient spec" ahead of time, but I'm always (as long as the client is engaged with me and with the project) able to do the extra legwork to come to a concrete understanding of what we're trying to accomplish.
I have, early in my consulting career, worked with companies where there was literally no feedback, insufficient specifications, and we had no access to the people who would eventually be using the software. It was at this time, early in my consulting career, when I decided this was a critical intangible I must have in a potential client before I start negotiating an actual contract.
And this is exactly the kind of thing that's a lot easier with someone in the same country, the same culture, and the same language. The big problem with outsourcing to another country is that you've got a big communication gap in the middle of your project, and you need to compensate for that.
(Though you can also easily run into this problem without outsourcing, but I every step between the programmer and the user/customer makes this problem more likely.)
You're certainly right. But, the same goes for if they were developing the software in-house: you need to have the customer use the software.
It is probably a bit more pronounced in consulting, I agree.
This is extreme programming, at least part of it. It is called a lot of things (client tests, cards, whatever) but the goal is the same: to get frequent and critical client feedback.
I've had the same experience as you. Asked to implement something, but you KNOW they are not using the software.
> those who think "outsourcing" means "I tell you the idea, and you do all the work"
What mystifies me is people will laugh in your face if you try this outside programming, but are taken seriously almost exclusively by the programming field, even decades after its acknowledged most projects fail. Clearly other forms of enlightenment have failed so far; maybe extreme sarcasm would work? We've tried everything else and it hasn't sunk in yet...
So I've got an idea. Psychedelic accordion music. Awesome huh? Now unfortunately I can't play the accordion, but I'm sure I can just take advantage of some poor person on the other side of the planet who can play an accordion and currently can't afford to eat. On one hand I have to move fast and break things so I'll need to hire the first accordion player I ever meet, on the other hand I need to appear to be pinching pennies so I'll need to hire the cheapest accordion player on the entire internet (and what could possibly go wrong with that?), and on the third hand I could only hire ivy league grad accordion players who live in only one town but then I'd have to complain constantly about the small supply and high salary demands and extreme groupthink ... Eh I'll get the cheap guy, what could possibly go wrong.
I've got another idea, I'm going to disintermediate the legacy plumbing industry by positioning my new unicorn as an intermediary (err pretend not to notice that) in the lucrative and exciting excrement removal field. Unfortunately I don't know anything about plumbing or sanitation or building codes, but move fast and break things, and I can just hire some people who know what they're doing, I'm an ideas guy you know, so I deserve all the rewards. True, the guys who told me they know plumbing, also do not know plumbing, and we're a little unclear on what flows downhill or uphill or whatever hill. But that's OK because our unicorn's iOuthouse shipping rate is going exponential. I even greenwashed my product by making it out of organically grown free range hemp cardboard, which is a good selling point for the tens, maybe hundreds of potential customers. Oh wait, did I say that? I meant tens to hundreds of millions of potential customers. I also integrated "social" and "chat" by implementing "long line to the bathroom" although the lawyers claim professional sporting events have prior art. Oh well off to collect the billions I'm entitled to, got an IPO to arrange!
But somehow you can build a house without knowing much about static loads, roofing, plumbing, insulation, heating etc. Of course the less you know the more you risk that someone sells you crap, but that is nothing special to outsourcing.
I would of course expect to be able to tell a producer/composer to come up with some accordion music, and that he will know what questions he has to ask and when to send me a demo for feedback to make this a success.
Construction projects, if not managed by someone who knows what they are doing, absolutely do go over budget and overtime. The difference is that on construction projects, construction project managers who work for the company commissioning the building work are experienced project managers who have normally been working in the construction industry and are knowledgable and skilled in many areas of construction and do know what can be delivered, what should be delivered, and what they need to go when they encounter problems and project slippage.
In fact, in construction there is actually MORE outsourcing than in software projects, because in actual fact you'll contact out specialise work (e.g. Electrical work) who then often five work to subcontractors.
Where I live it is very ususal to just hire an architect and then a general contractor. So the party that commissions the project (has the "idea") really has little knowledge at the start of the project. But of course they depend on their partners to handle all the project management.
Which all is just to say: I think it is very reasonable and common to only bring the idea and then hire someone to do the work. The problem with what is mostly called "outsourcing" in the software industry is not the fact that you want to hire someone, but more in how careful you select your partners.
If the secret sauce of unicorns were mere commodity shovelware, I would agree. There's nothing wrong with outsourcing non-core competency side jobs or commodity shovel work, happens all the time.
Or rephrased, is a tech unicorn not made out of tech?
I believe it is not. There is a user behavior and a data flow that go together to get traction. Marketing is probably the most important part. Luck being the 2nd. Tech may be way down there, alongside carbon paper.
I have been doing project work for big chemical companies in the past 8 years. The full project description is usually less than 20 lines and I work hand in hand with my customers to get the project done the way they want. I am talking about complex thermodynamic modelling and HPC code here. The kind of thing where you basically need a PhD in the scientific area + a full stack understanding of programming to do it right.
They outsource the work to me and they are really happy at the end.
Apparently this is how certain companies make money from government contracts. They deliver exactly what is asked for, at an unreasonably low bid, but then make the real money when the client suddently realises, far too late, that what they asked for wasn't what they needed.
Which is the fault of the government department who should have spent time and money on a competent business analyst to work out what was required.
If you outsource your work with specific requirements and don't involve the outsourcing company in the development of your requirements, which they then deliver in full, then you have nothing to complain about.
Well no, it's mainly the fault of Congress and procurement rules which require going with the lowest bidder. And it also is the fault of the companies that do this.
> (b) those who think "outsourcing" means "I tell you the idea, and you do all the work".
This is especially bad because those people are in my experience bad at communicating their ideas. Experienced external developers will know when and what to ask to minimize extra workload. Even more experienced developers will know when to shut up and just bill the extra time due to changing specifications.
I find I can generally guide a conversation in the right direction, but I also find that I can never approach a project as though I'll be the person to tell the client when a project is done.
The client has to understand their product well enough to be able to tell me not only if / when it's done, but if it's not done they need to be able to explain precisely why it's not done. Not in a confrontational way, but in an exploratory way. As long as we continue to discover reasons to continue to work on the project, the expectation has to be that I'll continue to bill for the hours I put in.
In my limited experience you are spot on. Non technical people cannot manage these projects. They don't really understand the project themselves and by outsourcing they think they get to pass their problems on down the line.
These people only look at cost and cannot determine skill level or product quality. It ends up costing 2-3 times as much if they went with a real developer from the start.
Cookie cutter solutions it's obviously a different story...
Are they even considered outsourcing? Like, Samsung licenses ARM. They are said to have licensed IP, rather than said to have outsourced CPU development.
I'm not sure what the precise definition would be. But I was mostly thinking of web-based solutions. Like the difference between a custom solution that could potentially require an entire team of developers vs a shop that, for example, specializes in customizing WordPress templates. Even though there is some customization involved, it's an example of what I would define as "cookie cutter" solution in web development.
And I think that same concept probably translates over to the difference between consulting firms building fully custom solutions vs. consulting firms coming in to customize licensed software (like Microsoft or Oracle, etc).
I've been part of a project that by the time was called "The most expensive IT project on the planet" and it was planned, run, build and supported by outsourced resources.
I can't stress this enough, this is a mistake, having your management/architecture teams from outsourced companies is just stupid. Nobody is responsible for anything they have no risk at all, it's the best job on earth.
You see those guys come, change everything to their management/architecture style, manage it like they own the company making reckless decisions and before the boat hits the rock they jump ship preferably to join the competitor in a similar project (because they copy each other), because now they have experience and know-how... This cycle is still going on and I know people making a living from this, some are completely clueless but can successfully switch jobs because "They were part of XXXX team in YYYY company" that nobody knows was a complete failure yet.
They still have not finished it ( 2 years after ) all personal from the initial setup are gone, all fault of course is on them now, so new guys can continue to make reckless calls that will probably cost billions of dollars and they will receive nothing in the end.
This is a terrible waste of resources and it's the Cancer to business nowadays.
The problem is, internal people often are afraid to take risks to implement something brand new because they know they will be going through performance reviews. When the internal staff is empowered by management then it can be done but managers are often not inclined to trust their people enough to empower them at the required level to take on high risk projects.
There's also a liability aspect in publicly traded companies. It's easier to lay blame on the outsourcing company when the project fails and conversely take the credit when it succeeds. Either way, the outsourcing company wins because they get the latitude to design and program their way and get paid as well as experience.
For public companies, outsourcing is a win/win and the cycle continues.
You payed a billion dollars for a solution and instead of a product that can be used you get to throw the blame of the failure in someone else? I can see your point regarding internal people making hard decisions, but this is simply a "hide my ass" win/win.
If your managers/team can't manage your innovation projects you should get someone that can, otherwise the market will eat you after a couple of those "wins", in the long term you are losing.
I wasn't advocating, just mentioning what I've seen. your message is right, management needs to trust their people more is what it comes down to. Incidentally, it's paid.
I will add one more reason: with appearance of online outsourcing platforms, best developers flocked there as individuals (and that is the only way to really reliably make $4000 as a developer in Ukraine as far as i know). They don't have middlemen, which normally only get in the way by obscuring the communication, and easily beat any outsourcing shops (which don't do much valuable management anyway, just lease out workers). Because individual freelancers and offshore outsourcing companies' employees are doing the same work, only people who left with the agencies are those who are inept and know it - otherwise they'd go to Upwork themselves and get an instant 3x raise. So don't expect an agency to have good people...
A Ukrainian developer told me that working for a large outsourcing shop looked better in the eyes of her friends and family than being a freelancer. She said being a freelancer, was, in her opinion, seen as a sign you couldn't get work with a big consulting firm.
She had just become a freelancer, despite her perceived drop in status.
Being from Moldova, and working on Upwork, I understand what he means... There is a bit of distaste for freelancers because there are a lot of very cheap freelancers working on the local market (because they would not be able to find a good project on upwork) with very low quality of work. All questions go away though when you tell your family how much more money you make.
EDIT: As per sibling comment, there are two types of freelancers: very high qualified or very low qualified. The general public usually hears more about the low qualified ones though.
Hard to tell. I hired many people on Upwork, and i can say that there are quite some mid-tier ones. Charging about $15 an hour and in general, worth their money - for example, overally good but with English so poor they can't get high paying customers themselves.
It may be because she is a novice developer and not immersed much into the IT world, and not highly qualified yet. With the non-IT people 'freelancer' might look like a nice word for 'unemployed'. Much higher status of an experienced freelancer is undeniable (a $4000 freelancer is solid upper class - able to afford multiple full time home staff - in most of Ukraine)
Mostly true, with caveat: it's hard to find big projects as single freelancer. Simply put, you won't be able to score a client that needs (let's say) both server side, front end, android/ios app finished in the same time. When working in (good) outsourcing shop, you work as a team.
I worked for two good outsourcing shops and both experiences were great.
> it's hard to find big projects as single freelancer.
> server side, front end, android/ios app finished in the same time
This is not true.
The freelancer simply needs to position himself as someone who can build and manage a team that can do that. I've served as a technical lead on projects managing other freelancers. Large projects.
> Simply put, you won't be able to score a client that needs (let's say) both server side, front end, android/ios app finished in the same time.
While that might be the case for some clients or projects mostly the problem is a sales and legal one.
Single freelancers can't afford to deal with ridiculously complex enterprise sales processes.
Large clients on the other hand for the most part don't want to be directly involved with contractors due to administrative (managing accounts payable for a huge number of small suppliers instead of just a handful of large suppliers) and legal reasons (managing and assessing individual supplier contracts; depending on the country and how you market your services as a freelancer there can also be issues around fake self-employment, which this way large clients can conveniently outsource to a third party).
Although his comments are accurate there's nothing terrible profound about them.
For quite a while everybody has realized that out sourcing was never anything more than labour cost arbitrage, dressed up with fairly empty "sales" rhetoric.
However he misses a more fundamental way in which clients and outsourcers interest are misaligned.
Because outsourcers are essentially selling bodies they have no incentive to become more efficient through labour cost reduction.
I suspect this failure is the real reason for the current "in sourcing" vogue. As software development and delivery becomes increasingly automated the labour cost component will drop, along with the pressure to outsource.
The outsourcers business model is fundamentally broken and it's only a matter of time before this shows up in the bottom line.
We did simplify software development _a lot_ since the dawn of computers. Compilers, IDEs, standard libraries... it's not really automation yet, but a programmer today is much more productive than a programmer forty years ago.
Outsourcing doesn't have to be based on pure time&material model. Software houses have huge incentives to become more efficient - using scale to their advantage, becoming experts in technology, etc. - all that to compete with other software houses.
I know from first-hand experience that this isn't the case.
Obviously T&M is the preferred contract structure for the service provider, but many projects get done on different metrics (fix-price, result-based, T&M with upper/lower bound etc.). It's quite a competitive industry, so a big client can negotiate for a different contract structure if the project allows it (obv. not for bodylease stuff).
Also, your assumption about labour-cost arbitrage isn't completely true. Many external consultants (incl. developers) make better salaries than internal staff.
The argument doesn't make sense. He brings up a lot of the challenges of outsourcing, and makes offhand remarks about good ways to address them. But if his argument were true, no contractor would "work".
The entire contracting industry fits into his description of "outsourcers". Lots of contractors work effectively for their clients. As a person in ANY business, if you believe that your only incentives are to get your clients to pay more, more often, then you will fail. Fucking your customers will wreck your business in any market. The customer has to feel like they got some value out of the deal.
The real incentive for a contractor is to provide the best (perceived) quality of product, for the highest competitive price possible. Even the bottom-price bargain barrel shops know this. They're just bad at it.
I think the author has a point, as software development is lot different than most other contracting gigs.
In most successful contracting jobs one would have a very clearly defined scope (processes and materials to be used, what is a clear outcome, etc.).
Software development has lot of ambiguity - processes to be followed, materials (technology stacks) to be used, what is a clear outcome (nobody knows unless it is validated in the field - apart from internal testing scenarios).
It is in the interest of the customer to define and specify what it wants as much as possible.
In more formal environments it is normal to have a requirements specification as a point of entry for developing the SW, and the first output by the contractor should be not code, but technical documents describing how this requirements are going to be met, how they are going to be tested, the technology used...
Of course this is a process that require additional effort and time, not only on part of the contractors but from the customer as well (in terms of requirement definition and review).
What I'm saying is that there are well known processes and methodologies to deliver SW products, and it's up to the customer to define what it wants, and to what detail, and up to the contractor making sure that he has a clear idea of what he is going to get.
You're right: I think the biggest difference in product quality comes from the differences in reputational effects.
A local developer or consultant will often rely almost exclusively on referrals and their reputation to get new (high-priced) gigs. So they have a strong incentive to keep quality high and to have satisfied customers.
On the other hand, outsourcing providers tend to be fly-by-night operations whose sole competitive advantage is low cost. They have essentially no reputational incentive, as there will always be another fool looking for Facebook at bargain bin prices.
Individual contractors can and do work well in client organisations. Separate scaled up consulting and outsourcing businesses are the problem IMHO, and this is what the article argues too.
I run a software outsourcing company and I recognise many of the issues raised.
I did spot a few problems with the article though. Firstly, you should never outsource in order to save money. The author kind of assumes that is why you're outsourcing. That doesn't work.
The main reason to outsource should be to buy in expertise. Many companies do not really know how to document software requirements, or what a non-functional requirement is, or how to design user interfaces, or what makes good UX, or what a good test plan looks like, or how to run user acceptance testing.
Some companies don't even realise that those things are important. They just think that if they just hire a few Ukrainian Java Devs, they will get good software out the other end.
Some dev shops don't even realise that those things are important either. They just act as a middle man. Connecting you to the Ukrainian Java Devs.
Even if the customer does understand what's involved in running a software project successfully, sometimes it just has no desire to employ developers. Maybe they are not the kind of company that can attract and retain good technical talent, maybe they just prefer to stick to what they do best. Either way, using a dev shop offers an attractive alternative to contractors because the team doesn't disappear the moment you stop using them. The team sticks around and retains a certain amount of knowledge ready for next time you need some changes.
What's the best way, as a developer who realizes these things are important, to end up on a team that also does?
I've tried working at agencies who were middle men as you described and faced economic problem of the OP article -- if the client couldn't provide real specs and communicate effectively, who cares -- we just have to bill and make payroll.
I've tried working inside organizations to build things, but they're in a sadder economic situation generally -- they get forced to have built a team because outsourcing failed due to working with agencies like the above, but they aren't a software company and don't have the budget or skills required to build and manage a complete software team.
I sympathise. I think the best way is to ask lots of questions in your interview. Developers are in demand, so asking some probing questions about the process is not going to hurt your chances at all. If anything it'll improve your standing.
Ask about the development process, what documentation gets produced, and what tools they use. Then listen carefully to the answer.
Ignore the buzz words, and focus on actual tangible artifacts. Saying "we're agile" or drawing a flow chart on the white board doesn't mean anything. Can they show you the scope of the current sprint? A Kanban board? A burndown chart? Some wireframe drawings?
If they can't show you anything tangible, that's a warning sign.
This is a good point. I will definitely be asking for tangibles. My last position actually lied (or somehow thought there was ambiguity in how they could answer "Do you do QA? Do you have a QA team?").
> OK, what's the solution, then? Just pay more? I don't think that's going to solve the problem; I'll just burn more money.
Sounds like the author hasn't actually tried to solicit a company with higher rates and therefore assumes way too much here.
I think a lot of devs/shops who are more expensive are so because they're demonstrably better. According to free-market logic, they can charge more because the market is willing to pay them more. Why would the market be willing to pay them more? Because their services are worth paying more for, due to them being better.
Higher rates align incentives because they make the provider more vulnerable to reputational effects. If you're targeting $150+/hr projects, you can't use online platforms to find clients. That end of the market simply depends almost exclusively on reputational marketing (referrals, industry contributions, mindshare).
Hence, as their continued ability to get contracts depends on having satisfied customers, higher-priced shops have an inherent incentive to deliver quality. As opposed to low-end shops who are just scooping up clients with their low rates and therefor have no quality incentive.
> If you're targeting $150+/hr projects, you can't use online platforms to find clients.
Not true. I make $150/hr. The client found me online and we work entirely online. Furthermore, it is a deeply-discounted rate because I have 15% of the startup's shares.
This is questionable though. My first company was an onshoring consulting firm, and I know I was rented out for 197/hr, yet this was still 100% their business model.
>Why would the market be willing to pay them more? Because their services are worth paying more for, due to them being better.
That's a stretch. It might be be the reason they're more expensive, but it might not be. Maybe they choose to work in San Francisco, rather than Idaho, so their overhead is higher. If price were the only signal of quality, then the low-quality workers would take advantage of the signal and charge the same.
This isn't hard to see in reality: can you name any industry or product where higher price assures better quality?
> This isn't hard to see in reality: can you name any industry or product where higher price assures better quality?
Nothing is assured, but almost every industry has a correlative relationship between price and quality. It might not be a linear correlation and it's not 100% consistent, but on average a more expensive product is almost always better than the cheaper one. This applies for everything from cars to employees.
This is only true for people who thoroughly understand what they are buying. This is very rarely the case for people hiring programmers. The only people who are capable of hiring programmers are other programmers (and often not even then). Everybody else is totally incapable of hiring programmers or distinguishing between incompetent, lousy, mediocre, or possibly good candidates. That is why the boss of a technology company (Google, Facebook, Microsoft, Oracle) has to be a programmer, or else sooner or later, the technology firm will crash and burn.
Even when developers are included in the decision, any decision other than 'use outsourcing' is met with "But, $10/hr!" by management and game over. Been there; had that done to me.
Either the management are programmers themselves (Bill Gates, Sergey Brin, Mark Zuckerberg, ...) or else the company is a lost cause. They will simply get expelled out of the market by companies -- who take no prisoners -- of which the management are programmers. Only a programmer can create half a trillion dollars of value (Google Search). Nobody else can do that. Their output is too inferior for that.
Granted, not exactly the work of one person, but neither is Google search. https://en.wikipedia.org/wiki/Edward_Jenner is probably the highest gains from any one person. Though there was a lot of prior work in the field.
If I've only had self-taught exposure to programming and can do like PHP/WordPress and a bit of rails, but am more of a marketing business person, if 5-10 years down the road I want to start a software company and don't want to be taken advantage of would you absolutely recommend becoming proficient in a language to have cursory knowledge, or for your examples above would the management/CEO have to be a full-time extremely proficient programmer?
It's not a stretch. A more expensive laptop is generally better than a cheaper one. A good engineer is generally more expensive than a cheaper one. A good doctor... a good lawyer... etc.
> can you name any industry or product where higher price assures better quality?
Life doesn't give you any assurances. I'm talking about free-market logic and its application in general.
Generally speaking, you get what you pay for. If the dev in San Francisco is not good enough that the market is willing to bear his rate, then he won't have enough work to make ends meet and will move back to Idaho.
You have to be willing to pay more for quality, but simply paying more won't magically increase the quality. The only solution is to learn enough about that you can distinguish good from mediocre. If you just go looking for someone who costs as much as a good dev, you end up running into the arms of con men.
Free market logic requires perfect information, though. How many of us have seen Highly Paid Consultants come on that were absolutely terrible, yet were paid more than we were in salary?
Outsourcing has worked for me and my clients for 10 years or so. The main aspects of making it work is vendor selection, local manager with outsourcing experience and proper choice of engagement model.
The author, Yegor, is arguing outsourcing categorically does not work due to lower vendor margins from 2001 and today.
What he fails to mention is that while Eastern Europe has risen in cost, there's still plenty of locations with much lower cost and therefore much wider margins. In such locations, his main argument would no longer be valid.
Even in Ukraine, there's huge difference in cost of living and therefore average salary across the country. Kiev is very expensive. Dnepropetrovsk, Kharkiv and Donetsk, not so much. But nowhere are you going to find 300 USD a month developers. 2000-2500 maybe, but not 300.
Further, the vendors he describe are not good vendors. Good vendors will raise the price to provide a sufficient margin in order to provide a good quality service. Bad vendors will sell with low price being their only parameter, and yes, such companies will typically have the mindset of "milking the cow". Until they fold from one day to the other, that is.
Finally, the mismatch Yegor describes between client and vendor expectations could be entirely removed if he just chose a different engagement model. For product development, you shouldn't do a fixed-price project model. Rather, do a monthly retainer based model for the same employee(s), where you pay the vendor x amount of dollars for the full allocation of person x. This way there's no prioritizing from the vendor company that can influence your project (unless the vendor is straight up fraudulent). And with a cancellation notice of 3 months, the margin can be lower as there's no risk for the vendor.
· Slack: Now valued at nearly $3 billion, this company used outsourcing to develop its solution in its earliest days.
· Fab: This large startup partnered with developers in India to maximize funding while scaling up when their business showed signs of growth.
· Skype: They used a team of developers in Estonia to help them build out their business.
· Klout: To get its technology in the right place before launch, Klout relied on many outsourced developers
A lot of start-ups coming up with good ideas and quality products doing good in so called developing countries
Calculate Software revenue generated in developing countries, You have only showing negative side why you dont you write article about outsourcing guidelines?
what should they do use “Made in own country” Product strategy?
But i agree with just one thing: don't outsource management. If you hire some developers from an outsourcing shop in outstaffing mode, or just hire them individually on Upwork, that's fine. But don't let the agency do the management. If you can't do the management yourself you can't succeed.
Ironically, he is bashing about outsourcing, but he himself is doing just the same.
Of course, he does it the clever way (I read the description at teamed.io, how he makes software-development cheaper by paying "more"):
By breaking down the tasks into 30 minutes microtasks, he will only buy the "fat" from the programmers cow. The muscles, filaments and veins, he does not buy.
Of course, you can buy only the raw implementation part (at best, only the typing) of a software -- but somebody will have to do the reading of the specs, to do some guesswork ... and so on.
By buying micro-tasks, this company does use the fact, that many people will only count the "real" net programming time but not the time in-between those micro-tasks -- reading the specs, preparing the next job, doing the thinking, maybe communicating, waiting for the next assignment ...
And the final clever way is: The time estimations come from the company and that is the base for the payment. When a contractor took over a job for 30 minutes and worked on it for 59 minutes (without all the reading and other stuff as said before) ... will he go and reject the money because he nearly worked 100% more on it than expected? Will he really tell the company, that he is not that big talent, he was hired for in the first place?
There's a huge number of outsourcing companies on my country, but the ones that are able to attract more clients are the ones who don't care for their products, since their business model is like that.
Normally those ones focus on showing you their teams not their works.
As someone who spent several years as a solo freelancer/consultant, sometimes offshore, sometimes onshore.
The main reason this type of work is drying up, in my experience, is that there is too much free money flowing around. Why deal with a temporary worker when you can afford to hire them full-time and have them sit in your office?
Furthermore, full-time engineers add a lot more to your valuation than freelancers and consultants do. A client once told me that adding a consultant to their "full-time" force increases the company's valuation by $100,000, but a proper full-time engineer adds $1,000,000 to the valuation.
I'm not sure why, but if I had to guess I'd say it's a combination of a company showing clear signs of growth (more employees == growth), and the lower churn because of 4 year vesting plans.
It's because there's at least one person on-board the company who understands the technical underpinnings, and has incentives that (usually) align with shareholders -- versus consultants whose bottom-line is never entirely dependent on the success of your company.
> Why deal with a temporary worker when you can afford to hire them full-time and have them sit in your office?
Because after paying his taxes and his cost of living, this full-time person makes way less than the guy doing the same job from the Ukraine. Therefore, everybody with just even half a brain will do the math and will not be available for sitting in his office. They'll put up their own office on some sunny beach in Guatemala and log in from there. Don't tell me it is not true, because that is what I have been doing for the last 10 years.
Oh I know it's true. I did it for years. But then I hit a glass ceiling when I wanted to charge SF rates, but do the independent thing. Nobody wanted to pay for that.
So now I'm sitting in a SF company, charging SF rates, and building my positive signals so that I can eventually go back to the independent thing and keep charging SF rates.
I used to work for an Indian MNC first, I was their eyes and hands in United States so I had to work with a lot of remote teams every single day.
Like everything, working with remote teams is also a skill. May be you worked with some team in poland and they were brilliant, good for you; you don't have to manage. But all remote teams aren't like that. The mantra for working with any remote teams is to micro manage. Have everyday calls with them, specifically tell them what you are expecting.
Before that, I myself was a remote developer, before traveling to US. As many of you already pointed, this depends on the vendor you go with. There are lot of multinational companies who outsource work and some of them are really good. A lot of discussion is going on that the teams have reduced the specifications given to them again I would tell you that it all depends on the team you choose. I never did that myself, hell the person who outsourced the worked to me, was not very knowledgeable. So does that mean I can judge everybody who outsourced work to us?
makecheck said, the software outsourcing never really worked, when I was working in that MNCs we had projects ranging from huge telecom companies to Aviation companies. And those projects ran close to 5 years - 10 years. How did the CXO reap the benefits for 10 years if he doesn't see value in it?
Honestly, having worked in corporate IT, a project big enough to last for 5-10 years has an enormous amount of inertia behind it from the tens or hundreds of people in the company who got behind it, all the "ra ra" project newsletters, the political capital expended to get the project budget approved, etc..
Even if it was going absolutely terribly and wasting millions of dollars, the project sponsor has every incentive in the world to keep moving forward and try to get something out of it to justify all of that. The failure of a big project like that might kill somebody's career at that company; a lackluster deployment a few years behind schedule is survived more easily.
Here's the big question, though: I have to put in a lot of work to manage an overseas team. In many cases, more than I would have to put in to manage a local team. And the costs aren't really that much cheaper. So if I have to put up with all that, why would I want to outsource?
"And those projects ran close to 5 years - 10 years. How did the CXO reap the benefits for 10 years if he doesn't see value in it?"
Did anyone ever actually do the analysis? I doubt it. They saw a cost reduction in one quarter and called it good. They haven't taken into account the extra work needed, the costs of reimplementing stuff after they get it because it's so bad, or anything like that. And because the CXO spearheaded the initiative, anyone who questions it is going to be questioning the CXO's competence.
I can't say much about the subject since I never used outsourcing, however 4000$ a month for a Ukrainian dev looks really over evaluated, it's much more than most positions in France.
Outsourcing companies tend to exaggerate skill level of their employees and one could be called a "senior developer" only after 3-4 years of experience. These "seniors" can be paid much lower salaries (say, $1500-2500 monthly) while the company can charge its client $50-100 an hour. That's where their margins are.
Your first job might led you about only $500, though, and on the opposite side of the spectrum there are people of exceptional skill that bring home $5000-7000 per month.
These sums seems higher than in Europe simply because of different tax structure. If you bring home in, say, Berlin, $3000 after tax, your employer and you still have to spend another 3-4k on pensions, insurance and taxes - about 100% premium vs 5% in Ukraine. Here we don't have any of that. Our pension will be about $200-300 and we don't have a decent quality health care or education for our families provided by the state.
Also, mortgage rates here are insane - 20%/y with 25% down payment! So most developers end up saving big parts of their salaries to afford buying property without taking loans.
Many developers here would prefer $3000 in Berlin over $5000 in Kiev because of all the value that you get from the state and the economy.
*My numbers around taxation may be off to some extend but you get the idea.
One thing that always struck me about some countries that seem to have a really low housing (rent) costs: the home prices seem to be equal that in the US!
It doesn't make any sense. I'll see homes for 100K USD, but rent only $200-300/mo? How does that work?
I live in such a country. My parents have a $250k home, that would cost only $500-$600 to rent.
But here is the catch, they only pay $200-$300 in municipal taxes. I guess in the U.S it'll be a few thousands dollars. This cost will eventually drill down to the person renting the property.
Also that's the price tax-free because nobody is paying taxes on rental (which is 30%).
The general property tax rate in my area of the US is about 1.25-1.5% the value of the home. My home is ~$500k and my property tax is about $7250 a year. Previous home was ~$300k and my property tax was about $4200 a year.
Schools are funded primarily through this mechanism.
Property taxes are a lot in many places in the US. Not all states are bad. Some states you only have a few hundred dollars a year. In NJ (my home state), especially near NY, it is normal to pay ~2-3% of the home's value a year in taxes.
Yep, that's interest rate - I checked with several bank sites before posting. This is due to volatile economy (war, corruption, all that) and higher risks for banks. You end up paying several times the price of the property. Like I said, almost everyone I know just puts aside 30-50% of their salary instead and buys at once when they save enough. 50% of 4k - and you effectively have only $2k to spend each month. Doesn't look that rosy compared to France, does it?
Rent is cheap - I pay about $500/mo for a 1 bedroom apt in the city center. 10 minutes of walk to the office. The price of that place? - about $200k. That's one of the reasons we don't have a proper rental business: it just doesn't make sense.
That's because the Hryvnia, Ukraine's currency, is a volatile currency which is hardly worth the paper it's printed on. It has declined about 20% YTD against the Euro, and about 45% YTD against the dollar. Inflation is also extremely high.
> It doesn't make any sense. I'll see homes for 100K USD, but rent only $200-300/mo? How does that work?
It's +- how it works in Poland in dozen or so biggest cities. There's no ad valorem tax on buildings, just a very small muncipial tax basing on land area and some multipliers depending on category. Also there's still shortage of buildings in these cities.
50m^2 flat in Lublin is worth around $80 000, I could rent it at $250/month maybe. The price of renting is on the high side for the city size, it helps that that particular city has 5 universities and 100 000 students with 350 000 regular population.
It is very common in India. Rent costs are typically half or less compare to US properties. Most people who buy are using black money or hoping for high appreciation in price of property. With rental income no one can service mortgage.
A small disclaimer: I'm talking from remote programmer point of view.
I really don't get why the place I'm working from determines how much do I earn.
Am I bringing less value working from Malaysia than from London? I think the value you bring in should be the only factor what your salary depends on.
Can somebody shed some light on it? I know there are some arguments like costs of living, but why it should be even considered? It's totally up to you where do you live.
Easy: in a market economy, your salary depends solely on how much a developer like you can be had for, not on anything else.
So if you're a unique, highly sought-after expert, the country doesn't make much of a difference directly, because people like you a generally hard to find.
But for a pre-senior level, there's a lot of people available, so the amount the client is willing to pay is determined by how much other people like you (from a place like yours) are willing to work for, which obviously depends on the country.
And then there's the selection bias. If the reason you got found is because the client has been looking for developers in your country, chances are that the client is looking to save money and isn't willing to pay much. Those clients who are willing to pay more generally look in different places.
And finally, a US-based client working with a US-based contractor is protected by US laws, unlike when working with a contractor from a developing country with a less reliable judicial system.
I agree what you say, but there is also a different case.
I heard a lot of stories about companies paying different just basing on where the programmer lives. Eg. if he switches location, he automatically gets less/more money. This is a biggest nonsense for me I want to clarify.
If they can get away with it, they'll try, because it's more money in their pocket. They don't care if it's fair or not. Plus, often times the people actually making salary decisions like that are "HR professionals" or something, who have no real understanding of the value of one individual vs. another. They just compute the minimum salary needed to keep the turnover of generic FTEs low in some market.
> I know there are some arguments like costs of living, but why it should be even considered? It's totally up to you where do you live.
I think that matters because it lowers the wage you can put up with. Thinking from an employer perspective, assuming non-specialist skills, it's more costly to work with someone remote in a different timezone (b/c communication difficulties, etc), so they'd only do that if they can push your wage low enough so they come out ahead with the extra costs vs. a local developer. They also like money, so if they can push your wage down further than that, they'll try.
That's just not true. For one you're not factoring in the cost to hire, monthly tax on that salary etc. I doubt a good developer earns less than 4k gross in say Paris.
My other problem with this line of thinking is this idea that you are getting less for that 4k than if you were to hire someone from the US. There are extremely capable people around the world with excellent communication skills and if you're looking at it with this attitude you will just miss out on this talent.
From the article : "Today, a good Java developer in the Ukraine earns $4,000 a month."
As I understand it, it's not what the dev costs to its employer but what he takes home.
And where did you read that I had the idea that they were not good enough to justify this kind of money. My surprise at the 4k number comes from 2 thoughts :
- how come a dev from a poor country earns more than one in a rich country ? (I don't say they shouldn't, just that it's surprising)
- and as I wrote in another comment, I read since the war the average Ukrainian pension is 70$ a month. I would have thought devs salaries would be more in line. 4k a month must be "stratospherically" rich there.
You are taking the article too seriously. The guy googled a bit, came up with some half-digested ideas and burped them with a clickbait title. Here’s a recent overview of Ukrainian IT market on the largest Ukrainian IT community hub. Look at the last two pictures.
http://dou.ua/lenta/columns/jobs-and-trends-2015/
In Poland (where salaries in general are higher than in Ukraine, my guess would be about twice as high) 4 grand for a dev isn't unheard of, but far from typical, especially outside of Warsaw.
Let's not pretend software developers are paid exceptionally well in the Netherlands. Somehow it's a skill that's way undervalued here, compared to e.g. middle-management. That said, a senior dev with an academic background (ie: if you can do more than just programming but also have the background to acquire and use complex domain-specific knowledge) you can easily make over $6000 gross a month. The cost of hiring you will be almost double that for the employer.
You're not going to make that kind of money by working projects for a consultancy firm though, the margins they are making on your skills are ridiculous.
You can easily make over 100k a year as a dev in NL if you're self employed, assuming you charge 60 an hour (about half the rate a consultancy firm charges customers) and work 1800 hours a year. That way, you have no benefits, no insurance, and no income when you're between projects, but an income that your English speaking peers at least don't laugh as hard at.
I don't think the wages are all that bad considering the generous benefits. What's really killing is the cost of living here.
What you charge your customer as self-employed dev can't be compared to what an employee makes. The rule of thumb I heard is that you should consider about a third to be "net income". The rest is taxes, investments and various costs (including insurance and retirement).
So a self-employed dev making 100k would be comparable to an employee making 30-40k. It's a very rough estimate; it's probably a bit better than that.
I'm self-employed and have about €120k revenue per year (working 4 days a week), and I think my taxable income ended up below €60k last year.
You're probably referring to health insurance, but that isn't a major problem. Health insurance is commercial, but regulated.
Employees are insured for unemployment, disability etc. Your employer is insured to cover your wages if you're sick. If you're self employed, you either don't get paid for hours not spent working, or you have to buy similar insurances commercially. You will also need insurance for liability and probably for legal costs. If you're good at your job and good at selling yourself, you probably make more than an employee would, but the 60 an hour are not pure profit.
Doing some comparisons between various European countries it looks like the wages for junior and middle experienced devs are wildly different, matching what you might expect. But the wages for senior devs start to converge.
160hours/month @ $25 = $4000. Go and have a look at Upwork. Relatively few developers there charge less than $25/hour. It is considered a low-ball rate. Even the Indians or Filipinos will hesitate to bid on that kind of projects, and they otherwise have a reputation of "being cheap" ("the cheap guys"). The only place in Europe where you can get really cheap labour, is the Ukraine. Don't try to fish for this even in Romania or so.
Aren't European salaries generally quoted post-tax though? For an apples-to-apples comparison you'd have to think of the American salaries in terms of "after tax and typical payroll deductions (incl health care)".
I assume they will be more capable than the average developer in any country.
Everywhere I've worked and lived companies doing anything remotely complicated need to hire devs that are significantly better than average or it's just a waste of money. Sometimes they just aren't around at any reasonable cost for whatever reason.
That really depends. Productivity differs between programmers with orders of magnitude. Assuming a career of 35 years, this programmer only grosses 1680000$. That is 6 zeroes. So, that would be a level-6 programmer. By programming Google Search, Sergey Brin and Larry Page produced half a trillion in value. That is 11 zeroes, corresponding to level 11. For example, if you can get a level 8 programmer to work at level 6 for you, you are into making truckloads of money. You could easily beef him up to level 7 and still be laughing all the way to the bank. But then again, most employers are not particularly working on level-8 subjects. I suspect that the problem is rather at that level than anywhere else; especially in France. What software worth mentioning have they ever built over there? Of course, they can't pay anybody anything. From what money would they be doing that anyway?
Assassain's Creed and Far Cry might have had some work done by the French Ubisoft HQ, but most of the work was "offshored" to the friendly same-language-speaking Montreal offices.
UbiSoft == French Company (France) having offices among others situated in Montreal, Québec (Canada).In Montreal mostly French is spoken (English being a close second).
The Montreal Studio of Ubi is responsible for the games you mention ...
Sergey Brin and Larry Page didn't make their money by programming, though.
Taking your methodology at face value, the guy employing a level 8 programmer for less than $10 million / year is by definition a level 8 programmer himself, even if he can't program at all.
"Why doesn't traditional outsourcing work? Well, because I came up with a competitor for it!":
> Present us with your requirements, be it a web system, mobile app, or Big Data who-knows-what. We will give you our best team of freelancers, all working remotely, and we will orchestrate their work, keeping you an active participant in the project.
Yeah, his message is confusing. It sounds like what he wants to say is "don't outsource to indian development shops, outsource to us instead"
What his company does is outsourcing. He works / runs and outsourcing shop. He might be good at it (or not), but that doesn't change what he is. It's like saying "don't eat hamburgers they're gross, instead enjoy our patented meat-between-two-buns product!"
Semantic quibbling. He's saying, don't go the usual route to a foreign nation/language/currency/export/timezone cluster. Instead hire a local agency that will work with you closely. Its a legitimate issue. My own contracting company calls is 'Domestic Outsourcing' because the word outsourcing comes with so much baggage.
Oh, and we do the work ourselves. No six-pack of random developers hacking away.
My impression is that early outsourcing did work but it worked because the first outsourcing in India companies were founded and staffed by an elite fraction of Indian developers who, for the money, were in many cases sufficiently better that the in house counterparts to overcome the very significant problems of remote development. Capitalism works and that huge salary differential has eroded to the point where this is no longer the case. You can no longer get a Phd to work on your in house CRM system for $20 an hour. Outsourcing companies tried to scale past this talent imperative through heavy process focus but this of course only works for very well understood problems of which there are few in the software world.
This is also the case with US based contract development shops. It's easy to "run your own contract business" when it's just you doing the work and you can decide to pay yourself whenever the client can get you the money.
The second you have a single "employee" your sole focus shifts to making payroll on time every month. Completely changes the formula.
I think the real tldr is: Outsourcing companies and their clients have incompatible incentives; because the outsourcing company only keeps getting paid as long as the project isn't finished/delivering value to the client.
Except that would've been always true. So the "anymore" part is purely clickbait.
The truth is Outsourcing never worked. But it was cheap enough that it could have been considered a worthwhile attempt at cutting cost, even if it ended up costing more with re-writes it was justifiable.
Now, you can't justify even attempting it given the high risk of failure.
Yeah. I always found it weird that outsourcing actually is a thing, because misalignment of values is pretty obvious. I will guess that the company doing the outsourcing is usually also burning someone else's money to fund the project.
If that's the reason why outsourcing doesn't work, why employment does work? I think this is the flaw in the article.
Perhaps outsourcing and employment do work, but it's always better to hand the job to somebody from local culture or to your friend/family. At a higher price, though.
I think you can generalize it like that, although maybe it more depends on type of relationship you want to have; physical proximity is only a proxy for that.
Perhaps building a more robust reputation systems is a true way to get a more efficient economy.
That's a pretty broad generalization. The maintenance contracts I have in place with my clients incentivizes us to build software that doesn't break and requires minimal maintenance.
Here in Brazil the US Dollar is 1:4 to the local currency (and the value is raising), so right now the exchange rate is really favorable to a customer in the northern hemisphere.
Not only the labor, real estate assets and companies are beginning to look very cheap for foreigners.
Good article, and most anyone who has used Upwork will relate.
It's not just about off-shore devs. Any time you hire someone part-time / short-term and pay them hourly... what's their motivation (keep in mind they were the lowest bidder)? To give you the best quality code, or to extend / prolong their contract?
If you want to make sure your priorities and goals are aligned with your developer, make sure they are on-staff and have a percentage of the company. Or better yet, learn to code yourself.
He seems to be talking about the low-end of outsourcing, though. I've worked at large enterprises that have outsourced to your Tatas, Wipros etc and although you do get some issues, on the whole it mostly works.
Obviously, I wouldn't outsource the system that is my main revenue earner, but getting someone in India/Poland/Wherever to fix bugs in your room booking or hr system makes sense.
I've had the opposite experience. TCS and Wipro are better than nothing but there's either a talent/skill issue or they just don't care (misalignment of incentives). Even "on-shore" resources that sit in your office range from bad to mediocre on the skill level or if they know their stuff they aren't invested. It could be that the companies I've worked for weren't willing to put out the bucks to get premium developers from these companies though, I can't say I was involved in negotiating. And that's just developers. Outsourcing operations to these companies is incredibly bad. They don't care about anything but their SLA's and will do anything besides actually solving a problem to meet them.
Well, you should not outsource project - you should outsource people. Have a mix of inhouse developers who will cooperate with contractors. Force them to attend scrums, make them a remote part of the team. The difference is - you can use them for a period of time when you need them and then release the resources when they are no longer needed (fire them).
I'm glad that Ukrainian Java devs are earning $4000 a month. The quicker wages rise in low wage countries the sooner the 'first world' countries will return to overall wage growth.
True. But manufacturing is already being onshored back to the US partly as a result of rising wages in China (and largely due to falling energy costs in the US).
Interesting take on consulting. I agree, the traditional consulting model is fundamentally flawed, but after reading some of his other blog posts, I'm not as sold on his approach to hiring and "orchestrating." For example:
"In our projects we discourage any horizontal communications between programmers, and you won't be able to get any help from anyone. You will be on your own and you will fail, because you are used to patronizing someone senior, in your office."
This is so ludicrous that it almost sounds sarcastic. While I agree there is value in searching out your own solution, talking through problems and asking advice from team members is very valuable. It doesn't have to be a junior asking a senior. There's clear value in talking problems out with an equal and even a senior talking through a problem with a junior.
It addresses the question of why companies exist, rather than adhoc gatherings of independent economic actors held together by contractual relationships. Coase suggests that this is due to "transaction costs" involved in negotiating everything into a written contract structure upfront rather than adhoc managerial coordination as needed.
TLDR; the author thinks outsourcing that attempts to increase ROI by leveraging international income disparities to minimize labor costs doesn't work because providers of such work want to earn as much as money as possible for their own businesses.
My thought/question for the author would be: how then can companies that work together do so without operating as charities, or are all businesses in relationships deluding themselves? Should everything be brought in-house, for example, house building? Is there a line, or a particular type of outsourcing that works or that doesn't? (Executive management, sewing employees' clothing, trimming their neckbeards?)
I think it's fairer to say the author thinks outsourcing fails because interests are not aligned. The client benefits from a successful, well-designed and efficient code base. The outsourcing company benefits from billing more time to clients that pay a lot on time.
I don't think this is an overseas thing. This is an in-house vs hired gun question.
For the "Anymore" part of the authors title to be logical, the points in his article about decreases in income disparity over time must be considered an integral part of his argument, i.e., before the disparities were reduced, outsourcing (according to him) worked.
Regardless, the question about how other businesses can be successful in their relationships if his argument were to hold water still stands—every business relationship involves imperfectly aligned interests.
By the way, a client benefits from positive return on investment. A client who loses money and receives a well-designed and efficient code base does not, i.e., the codebase is merely one component with variable traits that must be adjusted properly for each scenario.
I really hate outsourcing of any kind. I am a person that likes software development and I hate seeing it treated as something you want to spend as little money as possible for.
One of my last companies that I worked for got bought out. We only had around 8 software devs and the parent company had a 300 man team in India! Needless to say, any new problem that popped up had a strong push from the new management to send it off to the offshore team. And there was also a dumbing down of our solution stack since all the offshore team knew was Windows, Java, and Oracle (none of which we used). After two years, I left and so did half the team.
I used to feel the same way, but I've come around a little bit over the years. I've worked on projects where a portion of the work was augmented by an offshore participant. It works when the specifications can be produced easily and written without onerous oversight. It also helps when it's work nobody on the team wants to do.
Your sentiments about it are important, though, which plays into that last sentence. When a dev team is presented with "we're offshoring this and you're going to help" they tend to have a bad attitude about it and subtly (possibly unconsciously) work against the project's success.
When used properly, the team enjoys the lighter workload and doesn't have to work on "non-sexy" things. In our case, we had a very complex, old protocol that we needed a C# library written for. No commercial implementation was suitable, and it wouldn't have been technically difficult to write, but it would have taken a long time to do, so we pointed the small offshore team at an RFC and our expected interface and wrote the rest against that interface. A few weeks before the first prototype, we wired it up with their code. It worked brilliantly and I don't think anyone on the dev team even talked to one of the offshore developers. It's important to mention that in this case, the offshore team cost about 1/3 as much as it would have cost to bring someone on to do this work (deadlines couldn't be extended) and there wasn't any more work that we could have put that person on afterward, so it would have been a short-term hire. There are parts of many software projects that fit here -- it falls apart when companies think all of software development fits. There's a difference between tightening 900 screws to the right torque with a precise manual vs. designing and building the entire car.
I had success with one outsourcing project where we had a dedicated project manager and a prototype. We asked the outsourcer to make an exact copy of the prototype for a different platform and had success.
I think if you are a good outsourcing shop, you want money to pay salaries, but you also want referrals and repeat business. So you want to do a good enough job. It's the same with every company struggling to meet payroll, except a little more distant. But with globally accessible reviews, the world is a smaller place nowadays.
This is a very good application, as many times just writing a spec is not adequate to describe a project and I am sure you did some iterations to arrive with a prototype. I am currently outsourcing something similar with similar results. Thanks for sharing.
I've witnessed two occasions in succession where "outsourcing" failed right in India where an Indian start up "outsourced" to a firm just in the next street. The usual suspects listed in the article like "Cultural mismatch", "Lack of face to face communication", etc., were not the factors in this case.
Lack of clear requirements specifications, payments agreed to on-paper milestones vs. payments against actual working code, insistence / payment of advance money to the tune of 50% even before any actual deliverables (Some firms don;t even start work with that. Their logic is that - start ups go bust more than they succeed and they do not want to wait till you succeed to get their money.), lack of technology awareness from the founders (founders were non-technical in the web domain), etc.,
The factor of cost arbitrage did not play any role here.
These were the learning points:
- They should have picked up a good firm based on known references rather than go with the cheap one based on a google search.
- Tie payments to working deliverables rather than abstract things like design sign off etc.,
- Track, monitor regularly
- Be aware of the technology you are outsourcing. If you are an enterprise IT consultant and you are going to outsource the web work. Be sure to read up on Php or whatever technology they use and ask/think through relevant questions/ improvements
Funny, I just came back from visiting two companies that do excellent outsourcing work for us, one in India, eternussolutions.com and one in Poland, www.soldevelo.com.
The secret? We've built a long term relationships with them, have reasonable expectations and communicate continuously.
I've worked with offshore teams since 2005 and there are major benefits: prices that are roughly 1/3 of what it costs to hire the equivalent person locally, availability of talent (everyone's scrambling these days in the Bay Area), and the ability to quickly scale up or down your team.
There's also a price. You need to deal with the time difference; I have calls at 11 PM. There are cultural differences that you need to be aware of. The Holidays are different and usually more frequent, they won't be familiar with certain segments of the US business environment such as health care, HR, etc. And they won't work the same long hours. They have better work/life balance. On the other hand, you're not giving them options, so that's totally understandable.
In summary, have reasonable expectations, expect that there'll be a ramp up period, and be willing to learn from the other side.
But this isn't so bad: outsourcing used to be merely arbitrage (you made a profit just because you was here and your customer was there, buying on one market and selling on the other - 'free money' in the sense that it didn't require much talent or ability to withstand competition to make).
Now it's just a business just like any other: there is about as much chance to turn a profit operating a U.S. local software development shop or an offshore one. Prices you can charge and your costs will be still somewhat lower, because of all aforementioned factors like time zones, cultural and language barrier, and many offshore locations being legal grey zones where you can't really procesute anyone for say, stealing your secrets or violating your NDA.
Every source of free money ends one day because too many people will try to get it, and this moment has arrived for offshore outsourcing, but it doesn't spell its death.
It sound like many other businesses, with costs and customers that change over time and many people to keep happy.
Also sounds like the arbitrage is no longer as profitable as it used to be. And that's a good thing. When information is flowing, you get less people profiting simply for having information others don't.
I'm curious, what protects a customer from the author's personal outsourcing company against the author's criticisms of outsourcing?
Their company home page talks about constant value and quality approval / adherence, but it sounds like the same sort of marketing schtick that ever outsourcing company promises.
The price differences over time aren't what's made outsourcing fail over time.
And it's not outsourcing...
It IS the misalignment of goals.
Clients fail when...
They feel like they're paying someone to do something, so they become their agent. That agent is now assumed to do the most amazing job possible with unclear specs.
-- Root: bad specs, bad product management.
Providers fail when...
They take on work that's unclear, or understandings may not be totally aligned. Good providers aren't just inflating hours -- they're hitting on their understanding of deliverables. If that understanding is misaligned, success is impossible.
-- Root: bad specs, bad product management.
Bad specs, bad PM don't cover everything (you could have bad ideas, bad design, bad devs, bad architecture, bad QA, bad adoption/inner-circle feedback processing), but it's the most common root.
This is true of outsourcing generally, not just outsourcing to lower cost offshore regions. Back in 2000 I left my secure dev job with a large US bank to join a startup and chase the dotcom boom with a startup. The crash happened, I got laid off, no one was hiring, so I ended up joining a boutique 'consultancy' doing dev for banks. Over the course of the next three years I learnt a brutal lesson in the consultancy development business model. As this post points out, there's a fundamental misalignment of interests. The client wants the project done, and the consultant resources gone. The consulting firm wants maximum headcount on the project for maximum duration, and therefore maximum billing. This misalignment means the consulting firm can't speak the truth to the client. The consulting firm can't speak the truth to their employees either, and will usually give them some flim flam about how consultancy is the best of all possible worlds as it combines the security of permanent employment with the variety of contracting. In fact it combines the worst of both - the insecurity of contracting with the lower pay of permie work. Consultancy firms run on one key benchmark - utilisation level. Most, like ThoughtWorks or IBM Global Services, will aim for 65 to 70%. That means 65-70% of employee hours must be billable to a client. If you drop below that rate you have to fire people. At the 'boutique' consultancy I worked for they ran at 95%. Folk would roll off a client assignment at 5pm on a Friday, and get a phone call firing them at 5.10pm! So far, so simple. As the original post made clear, it's all about margin. And, as the original post also made clear, the result of this business model is one disastrous project after another. So why does it keep happening? The fault there lies on the client side. The clients hiring the outsourcing and consultancy firms are usually large corporates looking to manage costs down. The project sponsors are senior managers with long term careers in these highly political organisations. When their projects fail they can't make a fuss about it as that would draw attention to their own management failures. Instead they have to pretend the project is a qualified success, and jump to another team or silo in the corporate environment so some other sucker is left clearing up the fallout. So the consequences of failure are repeatedly eluded, as Mr Pointy Headed Manager slips off to another team, and the consulting firm moves on to the next billing opportunity. I was a little shocked when all this became apparent to me, back in 2002/3, when I saw a $25,000,000 project get canned by a large US bank without ever getting into production. Now of course I understand that it's just how orgs like EDS and IBM Global Services make their money. And the upside is, as the article points out, that it enables wealth transfer from developed economies in North America and Western Europe, to developing regions like Eastern Europe and India, by means of rising developer salaries. The conclusion I draw is don't ever work for a 'consulting' firm like ThoughtWorks. Be a permie or a contractor...
I couldn't read to the end because of the bad formatting. Let me fix some of it:
This is true of outsourcing generally, not just outsourcing to lower cost offshore regions. Back in 2000 I left my secure dev job with a large US bank to join a startup and chase the dotcom boom with a startup.
The crash happened, I got laid off, no one was hiring, so I ended up joining a boutique 'consultancy' doing dev for banks. Over the course of the next three years I learnt a brutal lesson in the consultancy development business model.
As this post points out, there's a fundamental misalignment of interests. The client wants the project done, and the consultant resources gone. The consulting firm wants maximum headcount on the project for maximum duration, and therefore maximum billing.
This misalignment means the consulting firm can't speak the truth to the client. The consulting firm can't speak the truth to their employees either, and will usually give them some flim flam about how consultancy is the best of all possible worlds as it combines the security of permanent employment with the variety of contracting.
In fact it combines the worst of both - the insecurity of contracting with the lower pay of permie work. Consultancy firms run on one key benchmark - utilisation level.
Most, like ThoughtWorks or IBM Global Services, will aim for 65 to 70%. That means 65-70% of employee hours must be billable to a client. If you drop below that rate you have to fire people.
At the 'boutique' consultancy I worked for they ran at 95%. Folk would roll off a client assignment at 5pm on a Friday, and get a phone call firing them at 5.10pm!
So far, so simple. As the original post made clear, it's all about margin. And, as the original post also made clear, the result of this business model is one disastrous project after another.
So why does it keep happening? The fault there lies on the client side. The clients hiring the outsourcing and consultancy firms are usually large corporates looking to manage costs down. The project sponsors are senior managers with long term careers in these highly political organisations.
When their projects fail they can't make a fuss about it as that would draw attention to their own management failures.
Instead they have to pretend the project is a qualified success, and jump to another team or silo in the corporate environment so some other sucker is left clearing up the fallout.
So the consequences of failure are repeatedly eluded, as Mr Pointy Headed Manager slips off to another team, and the consulting firm moves on to the next billing opportunity. I was a little shocked when all this became apparent to me, back in 2002/3, when I saw a $25,000,000 project get canned by a large US bank without ever getting into production.
Now of course I understand that it's just how orgs like EDS and IBM Global Services make their money. And the upside is, as the article points out, that it enables wealth transfer from developed economies in North America and Western Europe, to developing regions like Eastern Europe and India, by means of rising developer salaries.
The conclusion I draw is don't ever work for a 'consulting' firm like ThoughtWorks. Be a permie or a contractor...
I would argue that software outsourcing works as well as it needs to. I used to be vehemently opposed to it, for all the normal reasons, but for the people (especially the CIOs) who pursue it, they get exactly what they deserve and I think a lot of them are perfectly ok with that. My experience [reporting to a semi-sociopathic CIO] has taught me that it's a lot easier to be flexible with contract labor (by using OpEx and other methods of shifting funds to increase/reduce monies for the work), and sometimes they care more about that than accurate delivery dates or supportable deliverables of high quality that do what they're supposed to.
Isn't it possible that if you do staged deliverable and fixed payments that this will mitigate the risk?
If you are able to specify the deliverables needed in enough detail, then you can make payment contingent of milestones. That way the outsourcing company gets a steady stream of guaranteed income, but it's continent in them completing the work. It also allows you to cross check the work frequently.
This, of course, means that you have specified what you need clearly and in sufficient detail that you can actually go this. That means though that you need a very technical lead who has the ability to do project management. I can't see how else it could work!
I have launched at least 10 products with remote developers and I can assure you that it works perfectly fine. The key here is to find a good local manager that is from a country that you try to hire developers from.
I agree with Danilka. I provide the same service to French clients. I live in Paris, and I work very closely with client project management teams, in the same offices. This eliminates 99% of communication problems. Email's in the profile.
I think an interesting question that I am currently trying to think through is whether it's possible to structure your outsourcer relationship in such a way that their incentives are more aligned. I will be renegotiation a contract with a company, were we represent over 80% of their business. They have great technical people, and have generally delivered good work, but with more management overhead than we'd like - so we want them to be more accountable. Any ideas would be appreciated.
He is comparing the best developers in Ukraine at $4000/month with $40/hr in the US, which is what juniors make. Even with that weird comparison the margin is pretty healthy.
The problem with outsourcing is that anyone good who can do basic marketing of themselves on odesk, or wherever, will quickly get very busy and raise their rates to market level.
So, really this just comes back to that Benjamin. It can be summarized in one sentence - the lucrative nature of doing outsourcing before is no longer true today.
I think the best strategy is to find a good developer, then stick with him/her. There are tons of good developer out there who are willing to do hard work for almost nothing. You just need to find one.
Simply hiring the lowest bidder is a waste of time unless your project budget is $50000 or more. At that range, you can find hungry developers that are willing to do ten times more work then you would get from established players.
Outsourcing works great for prototyping and unit testing. You can also use it for mentoring quite nicely if you get the right folks. I've done all of these successfully. I've also had good luck with website design, where you already have the UX clearly mapped out and now you just need someone to fiddle with the css
Ie, it doesn't work anymore .. except when it does.
It is irrational to expect outstanding performance from an entity that does not have significant skin in your business. That's the rationale behind startups giving up shares to early employees. For contractors: more time= more profit. For Employees: better performance = more profit.
What about some of the more hybrid models that are growing - where you have a company trying to build a brand on quality work - like TopTal or Codeable - where they have seemingly good management overseeing the work?
outsourcing works when you and your devs are aligned, you have a tech owner on the client side and regular checkins from all parties. What doesn't work, and never worked, is throwing loose specs over the wall and expecting the next Instagram.
Moreover, people who manage remote, outsourced, teams for a living (I used to be one of them) have known this for years. The ones who don't know this are the non-technical founders who think the idea is the hardest part. Alas, that has been an issue for years before outsourcing became popular.
As a consultant who has in the past worked with outsourcing companies, the mantra I've used to explain "why it doesn't work" is far simpler: Cheap labor =/= Cheap Projects.
There's a number of ways it happens, and reasons that are, in general, hard to explain. Some people might try, as this article does, and rationalize based on whatever their experience is. Some of it I agree, some of it I disagree... it doesn't matter much.
But in my experience, 100% of the time, it always comes down to this adage: you get what you pay for.
It is important to remember that when you outsource something to a cheap labor, the keyword is 'labor' and not 'cheap'. Developers in SV don't understand this, probably because they aren't directly doing the cost calculations.
And here is the problem - articles like his one, saying how outsourcing doesn't work, are actually why outsourcing doesn't work. For example, consider someone who reads one article daily which says outsourcing doesn't work or that the resources are not very good. In last 10 years I have yet to meet a single client that gave the kind of independence you get as a developer in US. Yet every time all I read in a client's bad experience is that he/she had given too much independence.
I am in Bangalore and I work for a British Client. I WILL take the name, it is 3ds (French one). And here the only thing that matters is that client remains happy. Here is what happens here in Bangalore:
1. Client doesn't give any work which requires cognitive skills, since he is sure the return will be bad and he doesn't have time to take chances.
2. This in turn discourages good developers and forces them to:
a) Suck it up, forget about any career achievements and keep doing the maintenance job as mortgage payments are a bigger threat. Slowly the quality of output decreases.
b) Switch clients/jobs, which means sudden requirement of a resource and investing even more time in training him/her.
3. A lot of companies hear only bad stories about China stealing tech and making knock-offs, never mind that most of these knock-offs don't have any effect outside China and China is a closed market in the first place, that they have trouble handing over critical software/hardware for development. Half of my friends I know work via VPN even in office. In my office it is not possible to work on a laptop. I need to come to office and then work remotely. This is shit. Even with internet speeds in India being faster and cheaper than UK/US, when 2k people suddenly connect to VPN from a single point cursor stops responding immediately. This means slower work.
4. All meeting times are decided by client according to his/her convenience. Almost all of clients from UK that I have worked so far had literally 0 idea what its like to attend a scrum after lunch. Too early to start asking questions, too late to completely absorb the answers. US is even worse - most American clients set up a meeting at around 10:00pm (9:30am PST). Then they complain that people from India don't talk a lot.
5. Worst is pacifying a client's ego. It is not possible to tell him that he has done something wrong. It is not possible to squarely go over his authority and fix it. So Indian managers let the failures lurk for longer than necessary, and at the last moment find some scapegoat and hope the client doesn't fire him.
Mediocre developers are who make it big at the end. They stick around until H1B and then earn hefty amounts abroad.
All the concerns you bring to the table here have been caused by either previous failures of outsourcing leading to low expectations on deliverables (in which case, why outsource?) or a lack of communication by the management of the outsourcing company.
Now there might not be much you can do about the first issue, but it seriously behoves the company to do something about point two. I also think, however, that if your company is relying on work from companies in a different timezone, then you probably need to get over working at odd hours fairly quickly otherwise you are going to start to lose clients.
I'm not sure software outsourcing ever worked (but after reading the article, I'm fairly sure that title was picked for aesthetics rather than serving as a thesis statement).
I had this discussion with a friend who was charged with controlling costs as the new head of IT for a company he'd worked for since graduating. He had no prior experience in IT and was discussing his plans to "fire IT and offshore" in 2002.
The issue of "motivation" between an internal and external team was touched upon but it was the biggest factor in the failure that wasn't already obvious[1]. He points out a good customer for [the outsourcing company] is a paying customer. Not a customer with a successful project. That's a little more cynical than I'd be, but the point of competing priorities is important. Prior to offshoring, the internal staff's motivation was to create software for internal staff that made the business more successful. Their bonuses were paid when the company beat their profit targets, but that wasn't the entire motivation. They were a sciences company and much of the IT staff came from the company -- they were folks who were augmenting their work with code, often writing something so useful that the rest of the team used it and their job became maintaining/extending that software. They knew what to write because they either had previously done the work or were still somehow involved as a user of that software. The IT guys and the main staff were all science geeks and friends with one another so "Jan knows what Bill is expecting to do with this and he won't like it if it's designed that way." That tribal can't exist with an offshore team.
The plan was a complete failure; the offshore shop never got up to speed on the existing code-base, outages became a way of life (IT support was also offshored) and the decision was reversed after about two years. When they brought IT in house, they couldn't find anyone who wanted to work for them. In retrospect, they should have predicted this problem since they started having hiring problems almost immediately after the move -- they couldn't get the needed STEM graduates for their main work due to the poor reputation caused by the move. Interviews were outright refused -- most said they weren't interested due to fears of being replaced later[2]. They made a series of bad hires with onerous requirements in their work contracts--bonuses paid out regardless of being employed at the time they were paid--basically "protection" measures built in to calm the candidate's concerns. This was made worse by the economy improving and them no longer having access to more desperate candidates.
The failure of this project was bad enough to eliminate most companies of their size. They were lucky that they were a business who's customers had a regulatory reason to use and they lacked any competition (mainly because they're very good at what they do). This would have been a time when someone could have stepped in to compete with them. The delays caused by this were passed on to customers who had the potential to fail regulatory compliance as a result.
I've been intentionally vague about the business to ensure I can keep the friendship. I realize this post makes him sound like "an idiot" (I called him one at the time)--but bear in mind this was 2001-2002. 9/11, bad economy, and an IT budget ("new" at the time) growing like crazy were huge problems for them. IT then was seen as a necessary, unwanted, expense in most businesses their size. Coupled with prominent stories of offshoring success with little actual data about the details, it looked like an obvious choice. To the credit of his character, he set his ego aside and reversed his decison in just short of 2 years. They still occasionally augment with offshore for technically easy but time consuming work, and do so very effectively, but nobody is interested in replacing tribal knowledge with outsourced talent at his company (in 2007-2008, it never came up once as an option to improve the balance sheet). I've e-mailed him about this post in case he wants to provide detail that I wasn't comfortable sharing; but I'm leaving that to him.
[1] The obvious was having no transition in place between letting everyone go and spinning up the off-shore plan. The team literally inherited tens of services and a large code base to both support and expand on with nobody from staff able to tell them how any of it worked. Being that he failed to account for that problem you can use your imagination about every other thing that wasn't accounted for.
[2] A google/twitter search of the company yielded blog posts and other related items about the offshore move. IT folks communicate publicly when they're treated badly by an employer and they were treated terribly when they were let go. The worst thing was that despite being 2 years prior, most were convinced the company had done this only a few months prior. Objects on the internet are closer than they appear, I guess.
I have hired Russian speaking devs (not firms) hourly and, after the initial hiring filter, about 60% were very productive and didnt want to bill for months for nothing. I worked with them personally, though.
One problem in outsourcing is the thinking that programmers are somehow easily replaced; the "just find 'a' developer" idea, with little to no thought put into whether it may matter if the chosen team has any idea what they're doing. Two anecdotes. Years ago I was given such a team, to maintain a system primarily written in two different languages; the manager in charge gave me two guys from the other side of the world who were to be "taking over" the project despite not knowing how to program in either language, and there was no arguing this point. On another project, a resource from far away was graciously donated to me to help with a C++ project; I later realized he had chosen to recreate several container classes in C++ as if he'd never heard of the STL.
Another problem is the fundamental misunderstanding of culture. Managers in the U.S. seem surprised when they encounter wildly different behaviors overseas (gee, it's almost as if they had hired someone from a completely different part of the world!). For instance, I have encountered remote groups that are astoundingly good at self-preservation, who will basically change their minds and do whatever they want at the last minute to prop up their team at the expense of your project. Individuals, too, may have side projects that they care about much more than anything you have asked them to do.