IBM and the Tricky Edges of Outsourcing
Rob Cringley reports that IBM Global Services (including them unlucky souls from PricewaterhouseCoopers) will go in for massive layoffs, to the tune of 150,000. Reason? Cost efficiencies from offshoring to India. Which, of course, is bollocks.
Rob Cringley reports that IBM Global Services (including them unlucky souls from PricewaterhouseCoopers) will go in for massive layoffs, to the tune of 150,000. Reason? The usual. Cost efficiencies from offshoring to India.
I hate to prick the balloon but that cannot, and should not, be the reason for such a whopping round of layoffs. I have worked with PwC on the technology strategy side, the "management consulting" bit. This unit of the auditing monolith was later famously acquired by IBM (after being called "Monday" for about a couple of weeks – I bet Wolff Olins, the brand consultancy, must have made pants of money on that fun little vacation of imagination). I have since worked in several digital and interactive outfits, more from a marketing/media perspective, but only gained a better understanding of what makes technology-centric companies tick. Which is why this announcement is a bit difficult to comprehend.
What a Technology Manager Should Think Before Outsourcing
Let's say you've got small project. This project has 5 or 6 guys working on it. They've been at it for years, have written a good bit of the core underlying platform, and as such, know everything about it and can generally tell you exactly where the problem is if you call them with a problem.
Now you fire all those guys and hire a bunch of guys from some Balakambastan at 1/6 the original team's salary. Even if the original team hangs around to train the new guys, the new guys have to ramp up from scratch. And you can rest assured, these kinds of handovers are seldom whole-hearted. Even if this new breed of cheap programmers is excellent, it's going to take the team a good 6 months to a year to get comfortable with any decent sized code, regardless of how stunning the documentation is. During that time the overall application design will get slightly worse as they try to implement new features in ways that don't fit in with the original application design.
In the mean time you've got 150 other tech companies realizing that people in the rapidly growing market of Balakambastan will work for peanuts and they'll all move in to the country. Now your new team of programmers are realizing that they can get more peanuts if they do the same sort of job hopping that was prevalent in the 90s dotcom heydays to get more peanuts. So over the course of the next year your new team is replaced by even newer people, whom you have to pay a lot more money, and who are completely unfamiliar with your code base again.
So now you're paying your latest bunch of Balakambastanis as much as you were paying your original programming team, but these new guys have little to no experience with your code base. Well done!
The truth is — you can only save money in this manner if you buy into the delusion that people are pluggable resources, or that experience counts for nothing (yes, I have also seen people with 30 years of useless experience, but I speak of actual, good quality experience here). To people who believe that in theory you can get as much done with a summer intern as you can with someone with 20 years of technical experience, my simple advice: give it a shot. One of my favorite quotes:
Outsourcing is great and all, but done en masse, and with such stupor, it only reflects the senseless mismanagement of a giant corporation. Stop by ibmemployee and you will see wherein lies the real malaise of a giant blunder of this nature. A picture is worth a thousand words: