Buy vs. build, and why Scott McNealy thinks the CIO doesn’t need a staff

I’m going to unabashedly steal someone else’s anecdote for this post. I’ll justify doing so on the grounds that the anecdote has stuck with me since I heard it; I’ll talk about why, and why I tend to repeat it to my staff at opportune moments. Starting with this post, I plan to follow on with additional posts discussing more nuances of this very critical topic of buy vs. build.

About 5 or more years ago, I went to a CIO forum hosted at Sun Microsystems by their then-CIO, Bill Howard, who has since retired. At the time, Howard ran IT for Sun, with a staff that probably numbered in the thousands. His anecdote was about how he was frequently nagged by Sun chairman Scott McNealy about the size of his IT staff. Scott, according to Bill, was of the decided opinion that Bill could accomplish all he needed simply by having himself and an assistant, and outsourcing all the rest to external parties.

As I recall, Bill told this story with some mixed feelings. Some of it seemed to express a wry feeling of “this is the kind of thing I have to deal with from my management”; on the other hand, he went on to say that he actually thought that in a certain sense, Scott had a valid point. Bill also went on to note that despite Scott’s jibes, Bill still had thousands of people in his IT organization.

A joke often reveals a lot about the world view of the jokester. I don’t know, of course, but it may be that Scott McNealy operated in a world where, for all practical purposes, he focused on his own role and that of his assistant, and considered everything else as effectively “outsourced”, even to his senior lieutenants. It can get dangerously easy, as a senior executive, to reach that level of detachment. It’s something I advise against.

But that’s a different topic altogether. In any case, my main takeaway points from the anecdote itself reflect exactly those two twin, contradictory poles, representing simultaneous truths. The anecdote has stuck in my mind, and gotten repeated to my staffs, all these years precisely because both aspects of it are true:

  • Upper management can (sadly) often underestimate and/or undervalue the amount of work and complexity entailed in both “keeping the lights on” and delivering new features and functions to the business
  • IT systems and services are now actually quite often not much more than commodity items, which can achieve scales of economy and efficiency through appropriate outsourcing to firms that are expert in each particular area.

So yes, one can (and frequently does) farm out chunks of the existing IT work and rely on an external party to provide the associated service: systems development, systems operation (financial systems, e-mail, colocation facilities), tech support, help desk, even project management. For example, building a custom operations center for a web site today, when quality colocation facilities are readily available, is fairly foolhardy and almost always unnecessary.

But think about it. It’s also the case that managing a passel of external vendors is not a walk in the park. Strong horses need strong riders. And, in what shouldn’t be a surprise, companies that are created to exploit economies of scale will often push to achieve, well, economies of scale: this means that existing customers can often be neglected unless those customers manage the relationship closely and actively. All of that active management takes staff, and time, and knowledge. Equally, there are core competencies, integration requirements, and business-specific needs (less than people think, more more than management would typically like) that can effectively rule out the use of off-the-shelf, commodity approaches.

It’s all in the balance, of course. I’ll talk further in subsequent posts about possible approaches toward striking a balance.

Lagniappe:

Build-vs-buy background articles:

Speak Your Mind

*