Rob Cring­ley reports that IBM Global Ser­vices (includ­ing them unlucky souls from Price­wa­ter­house­C­oop­ers) will go in for mas­sive lay­offs, to the tune of 150,000. Rea­son? Cost effi­cien­cies from off­shoring to India. Which, of course, is bollocks.

Rob Cring­ley reports that IBM Global Ser­vices (includ­ing them unlucky souls from Price­wa­ter­house­C­oop­ers) will go in for mas­sive lay­offs, to the tune of 150,000. Rea­son? The usual. Cost effi­cien­cies from off­shoring to India.

I hate to prick the bal­loon but that can­not, and should not, be the rea­son for such a whop­ping round of lay­offs. I have worked with PwC on the tech­nol­ogy strat­egy side, the "man­age­ment con­sult­ing" bit. This unit of the audit­ing mono­lith was later famously acquired by IBM (after being called "Mon­day" for about a cou­ple of weeks – I bet Wolff Olins, the brand con­sul­tancy, must have made pants of money on that fun lit­tle vaca­tion of imag­i­na­tion). I have since worked in sev­eral dig­i­tal and inter­ac­tive out­fits, more from a marketing/media per­spec­tive, but only gained a bet­ter under­stand­ing of what makes technology-centric com­pa­nies tick. Which is why this announce­ment is a bit dif­fi­cult to comprehend.

What a Tech­nol­ogy Man­ager Should Think Before Outsourcing

Let's say you've got small project. This project has 5 or 6 guys work­ing on it. They've been at it for years, have writ­ten a good bit of the core under­ly­ing plat­form, and as such, know every­thing about it and can gen­er­ally tell you exactly where the prob­lem is if you call them with a problem.

Now you fire all those guys and hire a bunch of guys from some Bal­akam­bas­tan at 1/6 the orig­i­nal team's salary. Even if the orig­i­nal 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 han­dovers are sel­dom whole-hearted. Even if this new breed of cheap pro­gram­mers is excel­lent, it's going to take the team a good 6 months to a year to get com­fort­able with any decent sized code, regard­less of how stun­ning the doc­u­men­ta­tion is. Dur­ing that time the over­all appli­ca­tion design will get slightly worse as they try to imple­ment new fea­tures in ways that don't fit in with the orig­i­nal appli­ca­tion design.

In the mean time you've got 150 other tech com­pa­nies real­iz­ing that peo­ple in the rapidly grow­ing mar­ket of Bal­akam­bas­tan will work for peanuts and they'll all move in to the coun­try. Now your new team of pro­gram­mers are real­iz­ing that they can get more peanuts if they do the same sort of job hop­ping that was preva­lent in the 90s dot­com hey­days to get more peanuts. So over the course of the next year your new team is replaced by even newer peo­ple, whom you have to pay a lot more money, and who are com­pletely unfa­mil­iar with your code base again.

So now you're pay­ing your lat­est bunch of Bal­akam­bas­ta­nis as much as you were pay­ing your orig­i­nal pro­gram­ming team, but these new guys have lit­tle to no expe­ri­ence with your code base. Well done!

The truth is — you can only save money in this man­ner if you buy into the delu­sion that peo­ple are plug­gable resources, or that expe­ri­ence counts for noth­ing (yes, I have also seen peo­ple with 30 years of use­less expe­ri­ence, but I speak of actual, good qual­ity expe­ri­ence here). To peo­ple who believe that in the­ory you can get as much done with a sum­mer intern as you can with some­one with 20 years of tech­ni­cal expe­ri­ence, my sim­ple advice: give it a shot. One of my favorite quotes:

Out­sourc­ing is great and all, but done en masse, and with such stu­por, it only reflects the sense­less mis­man­age­ment of a giant cor­po­ra­tion. Stop by ibmem­ployee and you will see wherein lies the real malaise of a giant blun­der of this nature. A pic­ture is worth a thou­sand words: