Allen Gunn is a facilitator, convener and open source advocate. As Executive Director of Aspiration, he helps NGOs, activists and software developers maker smarter use of tech for social change. Later this month, Aspiration is partnering with Greenpeace’s Mobilisation Lab to host the first-ever Open Campaigns Camp in Berlin. We recently got together to chat about working open and the leadership required to make it work; here’s an edited transcript.
Matt: What does “working open” mean for you?
Gunner: I think working in the open is a set of values, processes and commitments. The values piece centers around transparency, sharing works in progress, enabling interested people to participate, and collaboration versus control.
In the open paradigm, control takes a back seat to collaboration.
In terms of process, its not so much an inventory of tactics as a set of systems and ways of working that invite participation and promote transparency.
The commitments are about flexibly staying the course. And by that I mean: when you invite participation and you don’t get it right away — or when the participation you get isn’t the participation you want — you’re committed to following through, instead of jumping to: “this isn’t working.”
That all sounds hard. Why do it?
First and foremost because: when it’s done well, collectively-produced assets and outcomes tend to simply be better than those produced by small groups.
“Many hearts and souls” mean better outcomes.
I believe in the “many eyes” principle — but also in the “many hearts and souls” principle. Having many personalities, values and experience-sets involved in creating something intrinsically makes the finished product more robust and broadly relevant — versus, say, three privileged white guys in Silicon Valley kicking something out.
In that sense, working open is a necessary component of scale — and, arguably, for success in general. So much of what fails to scale, in technology and innovation, fails because projects or ideas launch without adequate ownership.
Working in the open changes those geometries of ownership. It means a much broader and more diverse set of stakeholders feel they have a hand in creating, envisioning and bringing the outcome to bear — whether it’s a piece of code, a body of work, or any other advance.
So how does that shared ownership work in practice?
I think of it as concentric circles, originating outwards from the project initiators. You have to start with that core team, the people who show up first; you need to start with them in mind, get them to agree on what’s important, and get them into a shared vocabulary. Without that, there’s no minimal essential product to collaborate around in the first place.
You don’t necessarily need to go “all open” all at once. It’s important to leave the early tender moment alone.
The open process you follow next organically invites participation — because you’re blogging, you’re posting to etherpads, you’re putting all your thinking on a wiki. When you’re publishing and thinking out loud, you are intrinsically inviting others into your thinking, into your process, and by extension into your project. It’s less about an “internal vs. external” thing, and more about an integrative broadening of the circle.
So what’s the right way to lead through that process? How is “open leadership” different?
Leadership in hierarchy tends to be primarily about giving instructions. Bosses and senior managers tell people what to think and do, and everyone else dances to that tune. As a result, the need to be proactively responsible is actually constrained; it tends to focus more on “the need to get your shit done,” based on what someone else has told you to get done.
With the working open paradigm, there’s a much more egalitarian approach to knowledge, ideas and innovations.
Leadership in open communities is facilitative rather than directive.
It’s about process design, facilitating participation and successful contribution. And about creating a space in which people feel safe to join, participate and engage.
Working open by no means mitigates the pathology of bad management or bad power dynamics. But it creates a richer opportunity for the best to emerge, and for the collective to thrive as a collective — rather than as a hierarchy.
But doesn’t someone *have* to take charge? How do you prevent it from becoming a big squishy mess?
First, I think it’s very important to make a distinction between agency versus anarchy. Working open gives all stakeholders agency; it does not invite them, most of the time, to participate in anarchy.
Granting agency is not the same as inviting anarchy.
That’s why well-defined processes are so important: it’s essential to have well-defined pathways for agency and participation. People always forget: Wikipedia failed several times before it succeeded, before it landed on just the right participation design to make it work. In the beginning they had all these really rigorous peer review things — they tried to control too much. Even though they had a really good mandate and value proposition (to collectively generate and aggregate human knowledge), it wasn’t until they got their processes just right that their value proposition could be delivered to a broader base.
For code, those processes are things like pull requests, code reviews, design reviews, that kind of stuff. For Wikipedia, it’s editorial review, and the process by which you gain editorial reputation. These processes are not anarchistic. They immediately grant agency to all stakeholders. But that’s different than making an implicit promise of “anything goes” anarchy.
So rather than open leading to chaotic or anarchic energy, it encourages the broadest number of people to take an issue and make a difference, at the point their motivation inspires them to do so.
It sounds like you’re suggesting open models actually require more leadership, not less.
I personally believe open requires more intentionality and discipline to be successful, yes — more so than traditional hierarchies.
For “open” to work well, there has to be an intrinsic commitment by all the stakeholders — to follow the process, follow through on commitments, and give feedback and interact with others in the community, in a lateral peer-based fashion.
To me, good leadership in open communities sees things that are going to impinge on or constrain openness and addresses them. That includes members of the community that are too aggressive, too critical, or don’t yield the talking stick enough. Or on a mundane level, identifying the collaborative platforms the community is using as it scales.
I think you lead with a very earnest form of humility.
The best forms of open are lovingly subversive, in that they draw others to form their own conclusions about the benefit of open rather than beating them over the head with it.
Many well-intentioned open projects fail. Is there a key ingredient for the more successful ones, you think?
It’s important not to paint “open” as a panacea, or a “just add water” kind of paradigm. Open is a struggle. It’s a struggle with the self as well as a struggle with the group. Part of the problem with giving everyone agency and autonomy is they claim their agency and autonomy to varying degrees — which means you are often herding cats on meth. It takes commitment to the process and stick with-it-ness to really realize the full potential.
So much of what makes open work is about volunteering or proactively going “above and beyond.” Even if you are paid to be working in an open context, there’s still more than one way to participate — it’s that relevance that inspires people to do more.
Your organization puts a big emphasis on the human and cultural side of tech. How does that differ from the typical Silicon Valley paradigm?
At Aspiration, we see ourselves as the roadies or the janitors in an organization. We aspire to the essence of good roadie-ness versus the essence rockstar-ness. Our job is to keep things functioning at a clean, high-optimal level.
It’s a subversive roadie, or subversive janitorial posture — because we know we can have influence and shape how things go. But by having those self-identities, we’re trying to help other people really rock out to their own audiences.
For the typical bullshit keynote at the typical bullshit conference, the emphasis is on being the “rock star” — not the servant leader.
The whole idea that somebody sits up there for five minutes and blows you away with their brilliance, and where the audience’s only real response is to applaud — I hate that paradigm. It’s absolutely brain damaged and counterproductive. The naivety of thinking that some group of people can anoint some other group of people as the “geniuses” and future leaders. Screw that.
For us, there’s plenty of people who want to be the boss; there’s not nearly enough people who want to be the roadie. Servant leadership is about leading by example through others’ success, not your own.
Culturally, at least in North America, we tend to equate speed with success. Yet, open projects can often have a long tail leading up to their transformative impact. Are there any reasonable proxies that can help gauge the health of an open project in the often-expansive space between launch and “results”?
Many points discussed here tugged this piece written by Marco Rogers at Yammer out of my reading history. Among other points, it highlights the importance of distributing agency and accountability amongst a production team:
https://modelviewculture.com/pieces/engineering-management-and-diversity