I’ve been doing some thinking about offshoring recently. For those of you not in the IT industry, ‘offshoring’ is jargon for outsourcing of white collar jobs to developing countries like India and China. There’s been a lot of talk about this phenomenon: Salon (1 and 2), The Economist [sorry, it’s a pay article], InfoWorld, and CNET News.com have all commented recently. In addition to reading these articles and others like them, I’ve also talked to folks in the software industry, as well as friends who work in aerospace and packaged good manufacturing industries. And I’ve come to the conclusion that a certain amount of offshoring is inevitable, since the labor cost differential is so great.

However, like any other business fad (or any fad, for that matter), there are external costs that haven’t simply are not fully understood. Among these are

1. Loss of customers
The constant mantra of folks who are trying to tell IT workers how to adjust to losing their jobs is ‘retrain, retrain’. But retrain for what? What job isn’t offshorable? Nursing is the only one that comes to mind. If allvirtualizable (i.e. can be done without face time) service jobs where there is a price differential get pushed overseas, that’s millions of jobs lost. The American economy has been the engine for most of the world’s growth over the last 10 years, sucking up exports from other countries to the tune of billions of dollars. What happens when the consumers of the USA don’t spend money, either because they are out of a job, or afraid of losing their job soon? It takes a visionary like Henry Ford to realize that if you grow the amount of folks who can buy your products, you grow your business.

2. Loss of future business leaders
If you export big chunks of your IT department, perhaps keeping only senior folks who can help manage external projects, then you win in the short run. However, eventually those folks will retire (ask NASA). And if you haven’t brought any entry level talent in, where will you go to replace these needed folks?

3. Difficulty of managing far flung teams from different cultures
This is difficult in two ways. One is the logistical aspect. If you want a teleconference, you have to adjust either your schedule or theirs. And if the country is on the opposite side of the globe, possibly both folks need to be in the office at an awkward time. The second difficulty is related to quality. Just as the Japanese products in the 50s and 60s were thought cheap and low quality, some of the work done overseas today is a lower standard than expected. This is true of all software of course, but it’s harder to control the quality when you write a spec and throw it over the wall.

In short, offshoring is in its infancy. More of it is coming down the line, but, as the hidden costs are discovered, the benefits of local teams will come back into focus. I can do much of my consulting work from my house, yet I still find that most companies want me to come into their office. Why? To some extent it’s control (should be careful not to blog my way out of a job here), but it also is because communication, in each direction, is easier with someone who’s on site. There’s extra effort expended in any kind of virtual communication. And by meeting me, the customer and I build a relationship, which is perhaps more important for trust in business than anything else.

I also want to address Michael Yuan’s comments:

“3. Coding is a dying profession in the long run. If the jobs have not been outsourced to developing countries, the new generation of model-focused automatic code generation tools will eliminate the need for basic coders anyway. The jobs that have a future are system designing and architecting (the real engineering jobs). I think the ability to design end-to-end systems using whatever tools available is an important skill for the future.”

I’ve commented enough, I hope on, the idea that all coding work will or should be outsourced to developing countries. But I think that the idea that ‘the need for basic coders’ will be eliminated due to improvements in ‘automatic code generation tools’ is foolish for a number of reasons.

1. If you don’t understand basic coding on a system, when the automatic tool doesn’t do what you need it to, the means you’re screwed. Basic coding is not something you can pick up at school–you need to be out in the real world, working on crufty systems that are too expensive to change and older than dirt, to really appreciate what automatic tools can and cannot do, and what systems can and cannot do. In addition, easier code generation means more code out there, not less. And, easier code generation means more code out there. And, the easier the code is to generate, a la Visual Basic, the more likely the person doing the generation won’t get it right, or won’t document it, or won’t understand why there’s certain behavior exhibited. In this case, someone who has a deep, visceral understanding of the system and language will be called in.

2. Yuan talks about architecture and system design being the ‘real engineering jobs.’ I’ll agree that those are more stimulating and challenging than coding, and also have a higher value add. But again, how many folks are system architects right out of school? I certainly wouldn’t want to work on a project that had been designed by someone with exactly 0 years of real world experience. If you abolish entry level positions, you eat your seed corn, as I mention in my comments about offshoring above.

3. There is no silver bullet. The hard part isn’t writing the software, it’s determining what software needs to be written.

4. Someone’s got to write the tools. I remember an old science fiction story, by Isaac Asimov I think, about a world of taped learning. You took a test at 18 that determined what your skills were, and then you listened to a set of tapes that taught you all you needed to know. The protagonist was distraught because the test just didn’t seem to fit him–he was outcast and ridiculed for not knowing his profession. Of course it turned out that the folks that couldn’t be tape educated were exactly the folks who were able to write the tapes. Someone’s got to write the tools. (I don’t pretend, however, that anywhere near the same number of folks are needed to write tools as to use them.)

Michael and others are certainly correct that things are going to change in the software world. It’s not going to be possible to just know a language–you have to be involved in the business and maintain relationships. But change is nothing new for IT workers, right?

In short, it appears that Neal Stephenson was correct. I leave you with an excerpt from Snow Crash:

“When it gets down to it–talking trade balances here–once we’ve brain-drained all our technology into other countries, once things have evened out, they’re making cars in Bolivia and microwave ovens in Tadzhikistan and selling them here–once our edge in natural resources has been made irrelevant by giant Hong Kong ships and dirigibles that can ship North Dakota all the way to New Zealand for a nickel–once the Invisible Hand has take all those historical inequities and smeared them out into a broad global layer of what a Pakistani brickmaker would consider to be prosperity–y’know what? There’s only four things we [America] do better than anyone else

music
movies
microcode (software)
high-speed pizza delivery”

And none of the four above are guaranteed (except perhaps the high-speed pizza delivery).

Happy New Year.

One thought on “Is the American tech worker obsolete?

  1. ihath says:

    With regards to the book review you provided on amazon.com about the alchemist, the boy’s name is Santiago. Read the first page.

Comments are closed.


© Moore Consulting, 2003-2019