A New York Times discussion piece on outsourcing (this link will rot) has again stirred up a brouhaha in the blogosphere, particularly one panelist's comment to the effect that coding is a 'low-skill' activity. Umair Haque also has useful comments, in which he sees outsourcing and its productivity gains as one of the consequences of the Net itself.

The same article provoked an e-mail conversation with my cousin-in-law Will Fitzgerald, which I thought might have wider interest. For background, Will currrently lives in southwest Michigan, is an AI expert and past Internet entrepreneur. Here we go:

WF: I thought you'd be interested in this column, by a friend of mine, Joyce Park.

TO: Hmmm, well she's knocking over a strawman. The guy at which she's taking offense is an academic, not a practitioner, and doesn't likely understand the nuances of roles in a product organization.

As anyone who's done it knows, there's code and then there's code. Doing a well-defined set of functionality in between two pre-existing APIs (as an instance) is 'low-skill' compared to open ended architecture, algorithms research or product design teaming (for further instances). The former you can - and perhaps should, economically - push offshore. No need to pay big overhead to do the nth tweak on a HP printer driver for Windows and on a WiFi AP embedded code. The requisite skill level is now attainable in many places worldwide, and it's pretty hard to say that you ought to move someone to the Bay Area from either Iowa or Bangalore to get it done. For better or worse, I think this conversation is pretty much over in the marketplace.

Heavy design, OTOH requires more group interaction with other designers and with marketing people - assuming a commercial goal. Harder to do at a remove, requires both more experience and skill, and there are fewer engineers who have the capability to do it at all. The old observation of the orders of magnitude range in effective output from software engineers is pertinent here - some fraction of engineers have the ability to function at this level, more not. We're now skimming this cream from a much larger pool of candidates globally. For those who rise to the top, but are not already based in the US, are they better deployed here - at higher costs but possibly greater efficiency - or back in Bangalore, Taipei, what-have-you? What are the implications if you try to make that move in mid-career, rather than have the chance to have the formative work experiences in situ?

That's an important conversation to have. With one outcome, the Bay Area for IT turns into Manhattan - a financing center primarily. With another, it continues as a sort of Detroit (I'm reaching a bit here) - retaining primary design, but shopping out much of the assembly work, so to speak. Where I agree with her post is that the discussion is more about 'religion' than about trying to analyze what is working, and what not.

WF: She may be knocking down a strawman -- but she does cite him just as a "for instance." On the other hand, I recently met with a senior Accenture executive who assumed that push to off-shore is going to happen in a major way -- and this wasn't just print drivers, but fairly serious enterprise software development (i.e., the sort of thing Accenture often does).

TO: One of the problems of Accenture and the other big shops is that they have to compete with hordes of individuals and small teams that can take on many of the tasks they use to roll up into an enterprise-wide relationship. And the little guys don't have the overhead and 'utilization issues' that the big consultants have. So they may be forced to lower their cost base so that it + overhead remain competitive.

WF: I like your 'Detroit' analogy; one of the questions is how the long term gain of having a seasoned IT workforce will be factored against the short term gain of out-sourcing what seems like scut-work. Database table design, e.g., can be be done in CA or MI or India -- but if you shop this out, will you eventually have high-level designers who understand the whole design cycle close enough to hand?

TO: Leaving the question of just who makes such decisions. Maybe it makes some sense in large organizations that have some hope of capturing the value of the entire career cycle - IBM, Intel, Accenture. But the reality is that most IT workers cycle through many employers, so that makes the career development into a private good (look out for yourself), and the company contribution into an externality. And more and more of the IT innovation comes from small organizations that can't afford the luxury of spending on externalities. I conclude that here is no locus for decision making on this. Gov't intervention will just chase the higher skilled tasks away along with the lesser. Hence my interest in a descriptive, analytic take on the problem, rather than 'religion'.

WF: Yes, when I wrote it, I didn't like that 'you.' But rather than just say there is no locus of decision, perhaps noting there are several loci. And I think government and private non-profits can play an effective role my mitigating some of the risks/costs of 'local' skill development. The local Southwest Michigan First organization is trying to keep/develop life sciences jobs in SW Michigan and is being surprisingly successful through a variety of initiatives, including brokering relationships and information among various stake-holders. They're not perfect, but they're not just stemming the tide, either. There may be models for IT job out-sourcing here, too. In small ways, I've tried to make a case for SW Michigan being a good place to outsource information technology jobs from California-- there are a lot of good IT people here and, while you can't pay them Indian wages, you don't have to pay them California wages. I didn't succeed at this when I was the CTO of I/NET, but that was at the depth of the IT bust.

(After this exchange, I happened across David Hornik's post on a law firm's reunion. Now there's an outfit that's figured out how to capture a bit of the benefit of the professional growth and network formation that happen within its pressure cooker walls. In my observation, very few Silicon Valley companies ever make an attempt in this direction.)
10:46:26 AM