This takes a certain style of leadership to really work well, doesn’t it?

Shirky: Absolutely. It does mean a big challenge to current practice.  It’s not an abstraction; it’s your own employees doing things in ways that don’t come from micromanaging. So the kind of leadership it takes is saying, we’ve hired smart enough people, and they know enough about the business from being on the front lines, that we’re actually going to turn to them as a site of value. That’s a big shift.

For instance, there have been a couple of imperatives pushed onto CIOs that are now shifting. One is the idea of having and managing a patentable portfolio of intellectual property, and the other is the perimeter defense of trade secrets. And those two things have gone hand-in-glove. IBM asked in its famous open source memo, where is the cost of managing the intellectual portfolio higher than the return on investment? And where is the cost to barriers to collaboration higher than the collaborative value we would get by sharing with people outside the four walls of the company? Decide which patents you want to lock down and which areas you want to put in the public domain to encourage cooperation.

Nick Carr writes that the heavy participation of companies like IBM, Novell, and Red Hat in open source projects like Linux “suggests that the Net doesn't necessarily weaken the hand of central management or repeal old truths about business organization.” That seems to run counter to the themes of your book.

Shirky: A lot of the advantages of hierarchy that existed still remain. This isn’t a complete reorganization of the business landscape. But what that kind of analysis is missing is that IBM is paying engineers to work on projects that IBM doesn’t own, or solely direct. You pay these engineers, but of all the relationships between senior management and line employees, the fact you are paying them is about the least important, institutionally. The idea that the minute you pay people to do something, you have the right to manage them and the right to completely take over that work for the benefit of the company–that’s not true.

IBM is not producing that code. IBM engineers are. IBM is paying those people because it’s getting value out of them. Linux creates value for the enterprise, it lowers our cost of managing software, it increases peoples’ budgets for hardware and services─but there’s this crazy middle step where Linux is not now and cannot be owned or controlled by IBM. Linux is a brutal technical meritocracy, and there is no senior manager at IBM who can say, “I don’t care what the kernel engineers think. I want this.” They can’t put it into the product without appealing to people who don’t work for them. If they announced a strategic change in the kernel, they would be laughed out of the room. They have given up the right to manage the projects they are paying for, and their competitors have immediate access to everything they do. It’s not IBM’s product.

There is a kind of perverse misreading of the change here to suggest that as long there are paid programmers working on the project, it’s not developing in any way different from what’s going on inside traditional organizations. It badly misunderstands how radical it is to have IBM and Novell effectively collaborating with no contractual agreement between them, and no right to expect that their programmers’ work is going to be contributed to the kernel if people external to those organizations don’t like it. And that’s a huge change.

When people read those statistics [about the professionalization of Linux development], they think, if there’s a salary, then all the other trappings of management must go along with it. Not only is that not true, it actually blinds you to the fact that paying someone a salary without being able to direct their work is probably the biggest challenge to managerial culture within a business that one can imagine.

Back to homepage