Centrifugal and centripetal leadership

I’m reading The Innovator’s Prescription, Clayton M. Christensen’s excellent analysis of the health care problem facing the United States. It’s a long book (almost 500 pages), and I’m only 30 or so pages into it, but it’s already turned out to be quite thought-provoking.

One concept in particular caught my attention so far: the idea of decentralizing versus centralizing product development. Christensen introduces it to sketch out where he thinks disruptive innovations in the medical device industry will come from.

At the beginning stages of most modern industries, the initial products are so complicated and expensive that things become centralized: we take the problems to the solution.

By way of illustration, in the formative years of the telecommunications [industry], we took our messages to the Western Union telegraph office…[but] while the vendors of [these] expensive, centralized products work to make them even better, disruptive innovators, by making the products simpler and more affordable, drive a decentralization of the industry—bringing the solution ever closer to the problem or need.

For example…the telephone made it possible for people to communicate over long distances from their homes rather than the telegraph office. With mobile phones, we don’t have to be home; we can communicate from our pockets and purses.

Christensen pp. xxxix – xl

What I find interesting in this is not so much the implications it has for medical device manufacturers (although the decentralization of this industry will have profound effects on health care); rather, it seems like the kind of leadership required to develop and market centralizing versus decentralizing products needs to be very different. Here’s what I mean…

All the corporate functions, from front office to back, across all value chains, would need to be structured and operated in ways tailored to each of these distinctive go-to-market approaches. As a leader of any stripe in the organization, how you run your division and contribute to the larger operation of the organization as a whole would seem to be shaped in large part by whether your products were centralizing or decentralizing. But as a technology leader (CIO or CTO), your job would seem to be especially shaped by this distinction.

Now, in terms of keeping the lights on for the organization, I imagine the CIO/CTO job to be materially the same in either case: providing reliable email, phone, and desktop computing, a capable and responsive service desk, effective application development, stable network and infrastructure—all this would be required no matter the organization’s product development orientation. So much for the demand side of IT.

But in terms of the supply side, technology leaders will need to approach their jobs very differently to support a centralizing versus decentralizing product development strategy.

Most importantly, the end-users in each case will be completely different (internal employees versus consumers), and your organization will have much more control over the former than the latter. Among your employees, you can mandate training, audit usage, and cultivate a high-degree of expertise, effectively creating a stable, predictable set of power users for your products.

When your end-users are external consumers, on the other hand, you can expect no such control. They will not spend much time (or any) reading instructions let alone participating in training; depending on your industry, it’s likely that the majority of consumers will be occasional users at best, and so you won’t have a large, stable body of power users; and monitoring how your products are used will be difficult, time consuming, expensive, and fraught with observational challenges (from getting folks to even answer your questions to getting them to answer truthfully/thoughtfully).

Many other important differences flow from this foundational difference between internal and external end users.

  • Requirements gathering—although applications used by internal end-users ultimately touch the customer at the window, the stakeholders for requirements gathering will be a much more controlled set of folks than if we had to reach out to the customers at the window themselves. This is especially magnified if we’re going to market with a decentralizing product that has never been decentralized before…how do we know who the right stakeholders are if the product doesn’t exist yet?
  • Quality of UI/UX—think of the difference between the website or kiosk UI/UX for an airline versus the DOS screen most employees use at the gate
  • Production release risk—although any production release carries risk, having production issues with millions of end-users has far worse consequences than those same issues with a much smaller set of internal users
  • Quality assurance—the nature of QA (from planning through test execution) will be very different for centralizing versus decentralizing products given the differences in number of end-users, likely end-user expertise, and so on

As a CIO/CTO working to deliver supply-side IT value to my organization, I’ll need to do my job differently in each case, both in terms of how I run my shop and how I sit at the table with my peers to lead the organization as a whole. It seems to me that how you can enable technology to provide value during all corporate activities, from strategic planning to tactics and execution, will be shaped in large part by whether your organization approaches product development as a centralizing or decentralizing activity.

But I think we can go further and push this line of thought past Christensen’s initial contrast between centralizing and decentralizing product development strategies to include distinctions within each of these strategies.

Consider Microsoft and Google: with their office software (Google docs and the Microsoft Office suite) both of them have brought the solution to the problem. Rather than having to submit documents to a centralized processing group (the secretarial pool or an administrative assistant), knowledge workers can produce documents themselves. So far, both are delivering decentralizing products.

But within this, they are doing so in two very different ways. Microsoft brings the product to the desktop (thick client delivery), while Google brings the desktop to the product (web based delivery). As a technology leader in one or the other of these organizations, you would need to structure your services and the value they provide to the organization very differently to be successful.

In the end, I don’t think there’s a simple way to approach this distinction as a leader. So much of what’s required will be dependent on your industry vertical, the product or service being offered, and the specifics of each organization that it’s difficult to get too specific about what a given leader in a given organization will need to do.

But despite that, I think Christensen’s distinction is a useful one for folks leading an organization (or working towards that goal one day). I’d love to hear from you all about this: do you find this distinction helpful? Not so helpful? Have you encountered it before? Had an experience with it in your work life you’d like to share? Let’s get the conversation going and see what comes up!


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: