@brooks, @jacob and myself decided to spend some time writing copy. We aim to have a clear description of a future consulting product that would power an organization with collective intelligence. Such an org could use CI both to process information and make sense of it (SSNA) and make decisions and streamline its operations (Realities).
We decided to start by giving each other stuff to read (1-2 item, one hour of careful reading tops). Each of us recommends the others with material about our side of things.
The walkthrough with pictures, that shows how you use the data to answer some specific questions. This is superseded by @hugi’s presentation of Graphryder.
In my own words. This post has no purpose other than me chewing on the Realities idea so that I understand it better. If it helps others to understand as well, great, but I still recommend going to the sources.
It’s do-ocracy: who does the work calls the shot. Also, there is no veto power.
It’s consensual: when making a decision, you are expected to seek advice from (1) those who have knowledge of the matter and (2) those impacted by the decision. You are also expected to carefully consider that advice. Then, you still make the decision.
There are two versions of this. The simple version is informal. It is appropriate for decisions that do not have a systemic impact across Borderland. The formal version includes an obligation to transparency: you should make your proposal explicit; discuss how others will be impacted by it; invite questions, objections and suggestions; and address them.
Realities is a tool meant to minimize the bystander effect in communities. It is conceived much like an issue tracker, but creating issues implies stewardship on the issue on the part of the creator. This contrast with common issue tracking systems, where the stewardship of the issue (called a Need in Realities) goes by default to whoever assigns that issue to herself. This stewardship is a “last resort” one. Upon creating a Need, you become its Guide. Your job is not to fulfill it, but to find someone that can and will – its Realiser. If fulfilling that particular need requires many activities, then there will be many Responsibilities, one for each activity, and each Responsibility also has a Realiser. Responsibilities will often be nested: I need A to do B, and B to do C, which in turn fulfills need N. These are called Dependencies: C depends on B, which depends on A.
Realities has two advantages over traditional issue tracking:
No issue can ever be stewardless. This is an elegant move, that designs social incentives right into the system: you only create an issue if you care about it enough to want to steward it. Who calls the shots does the work!
As you use it, you discover the dependency map of what you are doing.
Realities also has advantages over hierarchy: Needs get matched to people that care about them, efficient in terms of use and fractionability of time, etc.