Voting, Collective Leadership, and Identity Commons

Thanks to next week’s Creating Space, Collective Leadership has been on my mind a lot recently. It’s also been a key element of the new Identity Commons. One of the issues we’ve been grappling with is decision-making. To understand why this is a challenge, you have to understand the underlying structure and philosophy of the organization.    (M5R)

Ultimately, Identity Commons is a Community Mark that represents a set of values concerning Digital Identity. It’s a name bestowed on the community of folks who care about User-Centric Identity. If you care about this stuff, then you are part of Identity Commons. There is nothing to join, and you are free to use the name and logo as a way of demonstrating your support of these values.    (M5S)

Why this is such a powerful and important construct is a topic for another day. What’s interesting about this particular community is that there’s also a corresponding legal structure, a nonprofit organization that is in the process of being incorporated. This organization consists of community “Stewards” — people appointed by the community to represent the interests of particular sub-communities (“Working Groups”) and who are responsible for managing the tangible assets of the commons. There are rules for becoming Working Groups and Stewards, but they are extremely lightweight.    (M5T)

All of the Stewards comprise a Stewards Council. Each Steward has an equal vote on all matters. There is a Chair, but that position is mostly facilitative. There is also a Chief Catalyst, someone (not necessarily a Steward) who is responsible for handling the operational duties of the organization and catalyzing action in the community.    (M5U)

It’s a fascinating, but delicate structure. The Stewards Council has an important leadership responsibility, but that role is distributed equally among all of the Stewards. How do Stewards exercise leadership effectively given this structure? Decision-making via voting is clumsy in many contexts, and yet that’s the only process that we’ve actually defined.    (M5V)

We’ve had a number of interesting conversations on the topic, and the latest discussion recently surfaced a lurker, Martien Van Steenbergen, who cited an interesting reference on holacracy. Martien quotes the following excerpt (emphasis his):    (M5W)

Another common question is about the “possible votes” in integrative decision making. At first it can sound like there are two possible votes on a proposed decision — “consent” or “object” — though that’s missing a key point. Consent isn’t about “votes” at all; the idea of a vote doesn’t make sense in the context of consent. There are no votes, and people do not vote.    (M5X)

People do say whether they know of a reason why the proposed decision is outside the limits of tolerance of any aspect of the system, and then decision making continues to integrate that new information. This isn’t the same as most consensus-based processes — either in theory or in practice — although it does sound similar at first, especially before an actual meeting that seeks consent is witnessed.    (M5Y)

This quote is keying on the difference between Collective Leadership and consensus leadership. They are not the same thing. With Collective Leadership, you are acknowledging the multi-faceted requirements of leadership, and you are empowering those best suited to meet those requirements to fulfill that leadership role. You are not voting on every decision, which would be a sure path to disaster.    (M5Z)

One of the ways this manifests itself is by making decisions “without objection.” This is a technique from Roberts Rules Of Order that Joaquin Miller brought to our attention. Essentially, you empower people to act, unless someone in the group objects, at which point an alternative process kicks in. Everyone still has a voice in the decisions, but it is a proactive rather than a reactive style, and it encourages action rather than stagnation.    (M60)

I believe that when you have great collaborative process, voting is a rubber stamping process, even when the topic is controversial. In other words, the actual decision-making process starts well before any vote happens. Healthy deliberation results in Shared Understanding, which in turn helps to surface clear courses of action that navigate through the obstacles of contradictory ideologies. When there is pressure for movement (another pattern of high-performance collaboration), then people will rally around those courses of action.    (M61)

Implications of the Kintera Data Sharing Announcement

Andy Dale reported earlier this month that La Leche League will be using Kintera‘s software for member and donor management. More importantly, the two organizations will use open “standards” to share data between their respective systems. Andy’s company, ooTao, is implementing the data sharing using technology known as XDI.    (LK3)

The data sharing problem is well-known in every large organization, and it boils down to this: You have common data across multiple systems and databases, and none of it is linked. Because it’s not linked, it’s difficult to update information, it’s difficult to maintain a high-level accuracy, and it’s difficult to do any serious reporting. Every time you add a new system, it gets exponentially harder to do all of the above.    (LK4)

Does Kintera’s announcement mean that the data sharing problem has been solved? No. But it’s still an important announcement. To understand why, it’s important to delve a bit deeper into what makes the data sharing problem hard in the first place.    (LK5)

First, standards are inherently hard.    (LK6)

Second, getting an established market of vendors to agree on a set of standards is even harder. The problem is that every vendor thinks that lock-in is good for their business. The bigger problem is that they’re absolutely right, as long as lock-in is the status quo. Open data sharing is not viable until a critical mass of tools support it, and there’s no short-term return on being first to market (other than marketing value, which I would argue is underappreciated).    (LK7)

Third, those who have been trying to address the problem have been going about it the wrong way. In particular, they’ve made the social problem bigger when it should be smaller, and they’ve made the technical problem smaller when it should be bigger.    (LK8)

The most common mistake that people make when trying to agree on a standard is to try to get everyone on board up-front. That is the path to certain failure. The best approach is to get two people on board up-front, build something that works and is open, and then approach others about joining the effort. Getting small groups of people to collaborate is hard enough. Don’t make it harder than it needs to be.    (LK9)

On the technical front, people seem to have oversimplified the problem. It’s not just about coming up with the right set of APIs and XML schemas. You have to also think about identity — on many levels, as it turns out. The data needs to be addressable, which means you have to think deeply about identifiers. Also, the most common type of common data is people information — in other words, digital identities. The requirements around Digital Identity — especially User-Centric Identity — are more complex. The good news is that engineers are well-equipped to handle this kind of complexity; you just need to make sure it’s part of the problem statement.    (LKA)

Back to the Kintera announcement. They’re doing the right thing by building something that works between two organizations, rather than declaring a standard up-front and trying to convince everyone to jump on board willy nilly.    (LKB)

They’re also doing the right thing by hiring ooTao to implement this piece, because ooTao understands the identity problem, and it has credibility in the grassroots identity community. While calling XDI a “standard” is a stretch — there’s not even a published spec yet — it will most certainly be open, and a number of organizations and individuals have already contributed to it. More importantly, all of this stuff will work with OpenID and i-names, two technologies that can be accurately called open standards.    (LKC)

Will XDI “win”? It doesn’t matter. The architectural and practical lessons learned in implementing and deploying something real will move us one significant step closer to solving the data sharing problem, regardless of the role that XDI plays in the the long-term solution.    (LKD)

Should you avoid XDI because of the uncertainty over whether it will “win”? Absolutely not. The architectural changes you will need to make to support XDI will be largely spec-independent. Should you need to migrate to a different spec at a later point, the work required will be relatively minor.    (LKE)