Photo Credit: Birds on a Wire by user Kiwi Flickr

Letting Go of Control

Copenhagen, a city of networks. Photo by Andrea Minoia, used under Creative Commons licensing. Copenhagen, a city of networks. Photo by Andrea Minoia, used under Creative Commons licensing.

Cross-posted from the Connecting to Change the World blog with permission. Copenhagen—John and I came to this lovely city in June to help start a global network of 17 cities focused on deep carbon reduction. As happens with many social-impact networks, the initiators of this network organizing were not the potential members, the cities, themselves. Instead, three intermediary entities had come up with the idea of building the network and planned the first organizing meeting and a funder had invested the resources to get going. It was a classic case of network “engineers,” as we call them, doing the early heavy lifting in building a network. But, as we detail in “Bonus Track—Advice for Funders and Other Network Engineers,” right after Chapter 2 about starting up networks, there are perils. And most of them were present at the Copenhagen meeting. The fundamental issue is control—whose network is it? And the most important task for engineers is to recognize the need to relinquish much or all of the control they have at the beginning, and then actually to do it. As we explain in “Bonus Track”—There is nothing wrong with engineers exerting strong influence over a network’s design, but if they are too heavy-handed or persist in controlling things for too long, their networks may never become highly engaged or generative; the members will just wait to find out what the engineer wants. With this in mind, the Copenhagen meeting organizers had heeded the first of “10 Lessons for Network Engineers.” Specifically, we had talked with each potential network member about the network’s purpose, the first design issue that a network must resolve. We had designed the meeting to allow the potential members to develop a consensus about what they wanted the network to do, rather than just ask for agreement on what we thought it should do. To help this along, we had identified a handful of potential purposes and organized time for the potential members to explore them. In other words, we tried to implement Lesson 1: Don’t dictate the network’s purpose; co-create it with potential start-up partners. After the meeting, we took what had been said by the potential members, who had agreed they wanted to work together, and developed a set of concrete potential activities for the network. And we sent that out for feedback through a Survey Monkey that allowed each potential member to indicate which, if any of the activities, they felt strongly about and which they didn’t care about. With that feedback in hand, it was possible to draft a proposed statement of purpose, first year objectives and priority activities—and then send that out to the members for further feedback. At the same time, about a third of the members volunteered to serve on a steering committee to start to take over decision making. It’s a deliberate, iterative, and somewhat slow process. But it starts with the engineer recognizing that as members buy in, you can shift control into their hands and start trusting the network.