8

Where the Rubber Hits the Node

Facing reality sounds simple—but it isn’t.

—JACK WELCH ¹

 

 

IN HIS MEMOIRS, JACK WELCH, the fabled CEO of General Electric and Fortune magazine’s “Manager of the Century,”² tells of his decision to stop manufacturing nuclear power plants in 1981 because the Three Mile Island meltdown two years earlier had scared America out of the nuclear power market. Welch was new on the job. The dedicated, expert managers of the company’s nuclear business objected, telling him, “Jack, you really don’t understand this business.” Welch writes: “That was probably true, but I had the benefit of a pair of fresh eyes.”³ GE exited the manufacturing side of the nuclear power business, while continuing to service its existing nuclear customers, very profitably.⁴ Welch says in his autobiography that he told this story “over and over again in the first few years as a CEO” because it makes a crucial point: To render a good decision “[a]ll you had to do was face reality and perform.”⁵

Of course, that makes facing reality sound simple, but, as Welch says in the next paragraph, “it isn’t.” If facing reality means knowing what’s what, in the Age of the Net, there’s more what—and more “what???”—than ever. Making a decision means finding your way through a dense thicket of claims, deciding what information to believe and which sources to trust.

So, when you have to flop one way or another—yes, there will be a domestic market for nuclear power plants or, no, there will not be—does the knife-edge of decisions make the tangled uncertainty of networked knowledge irrelevant? Worse, does the networking of knowledge make decision-making harder and riskier because it puts up so many contentious possibilities?

Since decisions are made by people with the authority to do so, we’ll explore these questions in this brief chapter by looking at the changing nature of leadership, starting with a non-networked example that may help clarify what it means to say that, just as knowledge is becoming a property of the network, leadership is becoming a property less of the leader than of the group that is being led.

If you want to understand leadership, one good place to start might be a school that has the training of leaders at the core of its mission. So I visited Lieutenant Colonel Anthony Burgess at the United States Military Academy at West Point where he directs the Army’s Center for the Advancement of Leader Development and Organizational Learning (CALDOL).

Burgess speaks three languages. The first is the clipped, acronym-filled patois of the military; the second, the disciplinary jargon of scholars of cognitive science and education that he learned while getting his doctorate of science in knowledge management. The third is the language of the Web.

As you listen to Burgess switch from one language to another, it becomes clear that the director of the Army’s leading-edge leadership innovation center actually does not talk much about leaders, at least in any traditional sense. If you ask him directly about leadership, he responds by talking enthusiastically and learnedly about how to create effective units that can accomplish their objectives even in the unpredictable circumstances combat troops typically face.

It’s not because Burgess is some New Age-y Internet guru. He’s hard-core Army: a West Point graduate who completed Ranger School and led a unit of the 82nd Airborne Division for three years. He is wholly devoted to developing leadership skills that will enable Army units to accomplish their objectives. But the leadership required is not that provided by a single individual, no matter how steely his or her gaze is, but rather the ability of the team to stay determined and motivated, to find new ways to accomplish their goal as the situation changes, to switch to new goals if that’s what’s called for, to be resilient as members of the team are injured or taken up with other tasks. For Burgess, these are desirable characteristics of a team, not of any one individual. Leadership for Burgess is distributed throughout the team, so that leadership becomes a property of a unit the way robustness is a property of an organism.

Burgess does not explicitly think of it that way, and was surprised when I pointed out to him that he consistently answered questions about leadership in terms of the effectiveness of groups. But it is in fact a sign of his commitment to the soldiers he’s training. Strong leaders are a means to an end. If that end—a team that accomplishes its objectives—is best achieved through distributed leadership, then that is what West Point will teach.

The change has occurred in part because the Net has made people more familiar with the benefits of connecting across hierarchical lines. For example, CALDOL grew out of an online discussion forum that Burgess and his colleagues created that does not display the rank of those posting to it. But much of the impetus behind seeing leadership as a property distributed across a team comes from the nature of the two wars the United States began in the first decade of the millennium. As Major Rob Stanton explained, “In today’s world, it’s not enough to be able to do the job of the person above you. You have to do 18,000 different jobs. You have to be able to manage water systems, run a town hall meeting, issue micro-grants, be politically savvy . . . and that’s if you’re a twenty-five-year old E5 [sergeant].”⁶ The successful unit—the one best able to accomplish its objective—consists of soldiers who not only have a broad range of skills but know how to learn quickly and respond creatively. Each soldier takes the initiative, every soldier collaborates. While the soldiers will of course obey orders that come down from the hierarchy, the group as a whole has to have the characteristics that enable it to succeed in an environment that changes faster than the hierarchy can respond.⁷

Obviously the Army remains quite hierarchical above the level of the on-the-ground unit. But the separation of leadership from a leader, and the infusing of leadership into the group that is led, is likely to become even more widely adopted, for it has become a standard and effective way for networks to achieve seemingly unrealistic goals.

On April 16, 2007, at a little past seven in the morning, a senior at Virginia Polytechnic Institute and State University shot and killed Emily Hilscher, nineteen years old. When Ryan Clark, twenty-two years old, tried to help Hilscher, he was shot and killed, too. About two hours later, the murderer entered Professor G. V. Loganathan’s classroom, killed him, and then shot eleven of the thirteen students there, killing nine of them. Ultimately, thirty-two people died, some while barricading doors so that others could escape.⁸

The initial Wikipedia page about the killings went up within minutes of the first reports and consisted of a single line stating that a fatality had been reported. It was revised seven times in the next fifteen minutes, and rapidly became a useful and reliable source of information that evaluated and summarized reports from the media at the scene.

These horrifying murders stirred up a national controversy over gun control laws. But the shootings spawned a controversy at Wikipedia of a different sort: Did each victim deserve a separate Wikipedia entry?⁹ The question had nothing to do with judging the worth of the lives lost. Rather, the issue was whether those lives met the criteria for being included in an encyclopedia. Of course, the possibility of creating thirty-two separate entries would not have even entered the mind of a paper-based encyclopedia. But Wikipedia does not face constraints on its size. Instead the issue was whether Wikipedia best achieves its aim of being a great encyclopedia by being maximally inclusive or by enforcing rigorous standards for what merits inclusion.

The controversy over including the Virginia Tech victims occurred within a long-running debate about the biographies of living persons, or “BLPs” in Wikipedia jargon. These are some of its most ferociously disputed entries, since reputations and egos are at stake, and there have been awful cases of vandals strewing outrageously false information in some BLPs. Of course, the victims of the Virginia Tech murders were not living people, but many of the same questions were raised during a five-day debate on Wikipedia about whether the victims should even be listed and, if so, how much biographical information to include. Ultimately, the decision was made to list them with minimal detail: Ryan Clark is listed as “senior in Psych/Biology/English” and Emily Hilscher as “freshman in Animal Sciences.” Only six of those listed have links to their own Wikipedia articles: five professors, and the murderer.¹⁰

The debate among “inclusionists” and “deletionists” at Wikipedia continues to this day. But the choice in this instance was made easier by a prior decision made by Jimmy Wales, the co-founder of Wikipedia and its titular head. In September 2006, Wales added some language to one of the wiki pages that serves as a policy manual for Wikipedia: “What Wikipedia is not.”¹¹ To negative descriptions such as that Wikipedia is “not a publisher of original thought,” is “not a soapbox or means of promotion,” and is “not a crystal ball,” Wales added that Wikipedia is not a newspaper “and especially not a tabloid newspaper.”¹²

Wales spoke and the policy was created, just like Jack Welch deciding that GE will no longer make nuclear reactors. Except that it wasn’t like Welch’s decision all. Wales wrote in a public, editable place. His words were debated, and altered without his permission. And anyone could have introduced that policy, not just Wales. At the time I write this, Wales’s actual words have been entirely replaced by a more specific, and less memorable, expression of what constitutes sufficient notability for inclusion: “[I]f reliable sources cover the person only in the context of a single event, and if that person otherwise remains, or is likely to remain, a low-profile individual, we should generally avoid having a biographical article on that individual.¹³

There’s another way Wales’s decision was unlike Welch’s: He exercises his role as decision-maker reluctantly and as infrequently as possible. In fact, when I asked Wales for some examples of decisions he’s made, none sprang to mind. Finally, after a pause, he talked about a controversy the community was in the process of debating, having to do with allowing people to edit locked pages (articles temporarily closed to changes because of persistent vandalism or overheated back-and-forth revisions) by introducing a review process. A poll of the community had been held, but now the poll itself was being debated. So, what was the decision Wales put forward as an example of his decisiveness? To hold a second poll to resolve the controversy about the first poll. And what was the iron in the fist that Wales brought crashing down? “For the most part, people thought, well, that sounds reasonable. Sometimes people say it doesn’t sound reasonable, and they say, ‘Well, it’s Jimbo, so what are you going to do?’”¹⁴

At GE, Jack Welch’s underlings might have said the same thing about one of his decisions: It’s Jack, so what are you going to do? But they probably would have meant it differently. You can’t do anything about Welch’s decisions because the organization is structured to foreclose that precise possibility; the person at the top is the person in charge.

Over the years, Wikipedia has developed a set of policies and processes that enable the community—the network—to make and amend decisions. When the network cannot come to agreement, other processes kick in, including an arbitration committee, and then, rarely, the ultimate arbitration committee-of-one, Jimmy Wales. But those escalations up the chain of command are considered to be failures of the preferred system of bold action by individuals, reviewed and elaborated by the community. “In the early days, I made a lot of policy decisions,” Wales told me, “but that’s not really sustainable.”¹⁵ These days, most of his decisions are either essentially coin-tosses when the community is evenly split or judge-like applications of principles that all in the community accept. Wales’s decisions come out of a community and after they’re made they are re-interpreted and re-expressed by the community.

The distribution of leadership across a network is not happening just at Wikipedia.

In 1991, a twenty-one-year-old Finnish student, Linus Torvalds, posted a message to a Usenet discussion board noting that he was beginning development of a free operating system. By 2006, Linux was the second most widely used operating system (after Microsoft Windows), and Torvalds estimated that there were about 5,000 developers working on it worldwide.¹⁶ The Linux community is far from flat, but its hierarchy aims at maximizing the autonomy of individual contributors while ensuring that high-quality, reliable software emerges. In a 1997 essay famous among developers, Eric Raymond compared the way corporations developed software to building cathedrals, while the Linux way was more like a “a great babbling bazaar of differing agendas and approaches.”¹⁷ But the Linux bazaar has a clear center; Torvalds, highly respected as an engineer, makes crucial decisions about the core (“kernel”) of Linux. A complex network of contributors takes care of the rest of what traditional leaders do.¹⁸ In one sense, this is nothing but traditional delegation of authority. Except that for participants it’s far more like pitching in than being delegated to.

Indeed, the official Constitution of the community that produces a bundled version of Linux called Debian says explicitly: “A person who does not want to do a task which has been delegated or assigned to them does not need to do it.”¹⁹ Authority can still be wielded against rogue members of the community—say, someone who does not follow the agreed-upon quality assurance practices—ranging from public shaming to taking away access privileges, and, as with all large-scale collaborative projects on the Internet, the Debian community has procedures for adjudicating disputes. Nevertheless, these projects are not hierarchies so much as networks in which some nodes are more equal than others. Leadership is distributed across the network itself as far as it can be.

How far is that? Debian does indeed have a leader, chosen in yearly elections. Any developer can enter the running by posting her or his platform on the Web site, and by participating in a series of online debates and question-answering sessions. Voting for the leader and on other issues proceeds in a complex fashion designed to protect minorities and to keep the group from splitting over contentious issues. The leader’s powers are limited, and she or he is supposed to make decisions about only those matters over which no one else has responsibility—very different from the hierarchical model. The circumscription of the leader’s powers is part of a conscious effort to maintain maximum autonomy for the rest of the community. In his book Cyberchiefs: Autonomy and Authority in Online Tribes, Mathieu O’Neil writes: “Debian must reconcile the central notion of each developer’s autonomy, and the respect for difference, with the constraints deriving from the production of a complex system with quality standards of the highest order.”²⁰ So, the software is divided into modules “to give developers full administrative control over their packages or teams, in a mini-cathedral model.” The developers have to follow strict guidelines for their modules so they can be easily integrated into the whole. Debian also requires members of the community to maintain identities, rather than contribute anonymously, because only those who have earned the trust of their fellows are allowed access to key resources that, in the wrong hands, could bring down the entire software project. Debian distributes leadership and decision-making as widely and smoothly as it can while still meeting its core mission of creating efficient, scalable, powerful, reliable, innovative software.

This distributing of decision-making can be taken further. Noel Dickover is senior new media adviser working with the State Department. ²¹ (He is also a world-renowned pumpkin carver.)²² Dickover is personally dedicated to applying technology to global social problems, particularly in the developing world. A traditional approach would be to build a worldwide nonprofit organization that funds software developers to work on the problems. The World Bank and USAID do that, but, as Dickover puts it, the people who win the grants are the people who are skilled at winning grants—not necessarily a skill that comes with being an incredibly inventive and productive “hacker” (in the good sense of a software ninja). Instead, Dickover creates “micro-ecosystems” that connect organizers in local communities with software developers anywhere on the planet. “Instead of determining top-down what the problems are and how to solve them, and then giving money to some developers, this is a much more grassroots approach, with just a few outside participants” who are brokering the connections, Dickover explains. “You’ve empowered the local people. You’ve made them the lead. And you’ve made the network their mentoring community.”

He gives an example of the sort of project that inspired him and the group he helped found, CrisisCommons.org. Efforts to relieve the suffering caused by the 2010 Haitian earthquake were hindered by the fact that the streets of Port-au-Prince had never been fully mapped. So, OpenStreetMap.org posted satellite images of the city on its wiki. People from around the world, especially Haitians living elsewhere, started adding in street names. The map was, according to Dickover, “insanely detailed” within just a couple of weeks, and was routinely used by the World Bank, the United Nations, the US Southern Command, the US Marine Corps, the Coast Guard—“anyone who needed to get across town.” By the third week, the World Bank was funding people from OpenStreetMap to train local Haitians in the use of GPS equipment to add more and more local knowledge.

Dickover wants to make this sort of partnership of local people with a distributed network of developers more routine, so that we don’t have to wait for disasters to spur action. So, he has been organizing State Department–sponsored “TechCamps” around the world. For example, at the TechCamp in Santiago, Chile, at the end of 2010, people from Brazil and Argentina said they’d like to have a way to aggregate the data gathered by election monitors so they could get an overall picture of the situation on polling days. The requesters wrote up a “problem statement” and even produced a video explaining the issues. TechCamp passed these over to a loose coalition of developers called Random Hacks of Kindness, which sponsors weekend “hackathons” to write socially good software. Out of a hackathon held in Nairobi came an election monitoring system that was then deployed in Kenya, but that will also be used in South America and elsewhere. More TechCamps are planned for Indonesia, Moldova, Lithuania, and India.

The fact that Dickover’s work seems to have little to do with leadership or decision-making is exactly why it’s a useful example of both. Dickover and his colleagues are creating networks of local people with needs and social-minded hackers with the skills to address those needs. The decisions about who should take up which projects are made by the people with the most local knowledge—those on the ground who know the problems intimately and the developers who know the software possibilities intimately. It is a highly efficient and effective way to make decisions. It works because it is a network.

There are some elements of traditional leadership here, however. Dickover and his Crisis Commons co-founder, Heather Blanchard, spend much of their time organizing events and partnerships. Dickover is able to do this not primarily because of his position in the State Department. In fact, he was brought into the State Department because of the success of Crisis Commons. Dickover’s power as a leader comes from his ability to form networks around his idea. This worldwide ecology of talented hackers and local social organizers is succeeding at solving some urgent issues by distributing leadership as close to the ground as it can. Dickover, Blanchard, and others lead only by enabling that ground to be a network.

This has everything to do with the change in our knowledge strategies.

A Jack Welch stands atop a pyramid from whence the big decisions flow. He consults his lieutenants, who in turn have consulted their subordinates. At each step up the hierarchy, there is a reduction of information: More details are stripped out, the strokes get broader and broader. If decisions are going to be made at the top, then filtering, reducing, and concentrating information is the only reasonable strategy. Even then, Welch’s reliance on making decisions “from the gut” (the subtitle of his memoir) can be read as a recognition that GE is too big to know with the brain.

Meanwhile, with millions of articles in the English version of Wikipedia, nobody could expect Jimmy Wales, for all his vision and leadership qualities, to be an expert on everything. In fact, Wales is not even as much of an encyclopedia geek—that is, an expert on the nature and history of encyclopedias—as others in the community.

That’s why when a problem is escalated to Wales, his decisions are often more like the Supreme Court’s than a CEO’s: He cites some accepted principle that governs Wikipedia. The network of Wikipedians is bound together by shared enthusiasm, an ethos, and constitutional principles. Wales does not wield power so much as work to keep the network on the same page.

Of course, the success of large, collaborative projects on the Net such as Wikipedia, Linux, Debian, and Crisis Common’s networking of global software projects hardly means that corporations are going to switch over to networked decision-making. Governments require businesses to have a hierarchy of accountability, and there are times when you simply need someone to decide nukes or no nukes. And it’s easier to move leadership to the Net when the manufacturing process, as it were, occurs entirely on the Net. Nevertheless, traditional corporations have something to learn from these network-based enterprises.

First, network decision-making scales up better than hierarchical decision-making does, at least in some circumstances. For example, in a 2006 paper, Peter Denning and Rick Hayes-Roth argue that responding to events the size of Hurricane Katrina requires “hyper-networks”: multi-component organizations that are truly huge, spread out, and differentiated.²³ These hyper-networks do not have a hierarchical top, relying instead on distributed decision-making. Denning and Hayes-Roth could just as well be describing large Internet projects: If Wikipedia and Linux had to rely on centralized leadership, they would never have been built as rapidly or as well.

Second, network decision-making also excels when decisions require a great deal of local knowledge, which is particularly the case when situations are fluid and diverse, or the path forward is not yet fully known. It does not work nearly as well when the goals are set externally, there are many workflow dependencies, the processes are well understood, and contributors feel compelled to follow directives.

Third, network decision-making can motivate people where hierarchical, top-down decision-making would have the opposite effect. Hierarchies often scale by suppressing difference and disagreement. But as Denning and Hayes-Roth—senior academics at the Naval Postgraduate School with considerable practical experience—write: “The component organizations in hyper-networks . . . have adopted decentralized decision making, because it enables them to work for the common purpose without giving up their separate identities.” The networked collaborative organizations we’ve looked at would be depopulated in an instant if the members had to give up their local identities and loyalties.

Fourth, when decisions are distributed throughout the network, more of the local knowledge can be applied. There is, of course, a balance here, for you do not want local leaders to make decisions that work against the good of the whole. This is one reason that collaborative networks often structure themselves into fairly autonomous modules (as with Linux and Debian): Local expertise can have more effect, with less risk to the whole.

Fifth, when decisions are made locally throughout the network, they are likely to express the interests of the local members who, typically, are volunteers. This is one way to make “corporate social responsibility” more than a bullet item on a corporate PowerPoint slide. Of course, all of the networked collaborative efforts we’ve looked at also have structures in place to ensure that local units or individuals don’t stray too far off the agreed-upon course.

Sixth, hierarchical organizations that rest the pointy end of the pyramid on the back of a single human being are not as resilient as organizations that distribute leadership throughout a connected network. That is one main reason that Tony Burgess wants leadership to be distributed across an on-the-ground unit.

Seventh, hierarchical decision-making is completely of a piece with our traditional reductive strategies for dealing with a world that is too big to know. That’s to be expected, since decisions are almost always really about the relative merit of competing streams of knowledge: Should you believe the local branch that’s telling you it’s too risky or the market analysis that says it’s a goldmine? As the business environment becomes more complex, thanks to globalization and, yes, to the burgeoning Net, reductive strategies run an increasing risk of going wrong by missing the detailed contours of the local landscape. Network decision-making keeps decisions as local as possible—quite literally the case with the global organization Crisis Commons.

For these reasons, and also because the new generation is having its expectations set by its Net experiences, decisions within hierarchies will increasingly take on characteristics of decisions made by networks.

I began this chapter by asking if the network properties of knowledge—its containing differences and disagreements, its never being entirely done and settled—become irrelevant in the moment when a leader has to make a yes-no decision. And it is certainly the case that in most business environments, leaders at the top still have to make the critical decisions that take the company one way and not another.²⁴ Does traditional top-down decision-making remain unaffected by the changes that networked knowledge introduces?

A little bit yes, but mainly no.

Jimmy Wales certainly does have to make yes-or-no decisions at times. But those decisions cannot be understood if they are taken as a mere moment outside of their networked context. In a networked collaborative organization, a decision is part of a wave rippling throughout the structure. Each decision has a history, expresses multiple local interests, and is absorbed by the organization that makes the decision its own.

As old-style hierarchical decisions increasingly occur within enterprises enmeshed in the Net, those decisions are taking on some of the network’s properties, even if the decision-makers don’t explicitly recognize it. The CEO of General Electric could be entirely off the grid, but still GE’s engineers, product managers, and marketing folks are out on the Net, exploring and trying out the ideas that affect their branch of the larger decision tree. After the decision, they will engage with the network to get feedback that may affect the execution of the decision. The organization’s appropriation of the decision—the way it makes the decision its own—will be accomplished over its network, and will be visible on the network, including inevitably and to some degree on the vast public network.

The networking of knowledge therefore does not end at the lonely, non-networked desk of the Decider who has to flop yes or no. The moment of decision is now explicitly a node in a network from which it arises and through which it pulses. And that’s for a clear reason: The network contains far more knowledge than any single leader could contain, tap, or manage. As organizations get bigger and become more essentially entwined in the Net, it will take a network to make the wisest decision.