Realities
1. What is Realities?
The Realities platform is a tool for organizations to harness the information held by all of their members to model what the organizations does. “Model” here means two things: breaking down the organization’s work into activities and mapping out how they are interlocked; and associating activities to people who are responsible for carrying them out. This model is stored in digital form and displayed in an easily navigable node view. This allows a user to select any task and see what other tasks are dependent or depends on that task and who is responsible for them.
2. Use case
You are a stakeholder in a big, complex projects with many moving parts. For example: a community wishing to produce a festival.
- You can rely on a fairly large, diverse pool of people. Each person has their own availability, motivation, skill-set and experience.
The whole population of the community, ranging from musicians to electricians to chefs and engineers. Some people wish to put all their free time into this effort, while some want to keep their involvement to a minimum. - You do not know in advance who knows what, nor who cares about what, or even if anyone has a specific piece of knowledge.
Is there anyone who can put up an electrical network? Does anyone want to design posters? - You are not sure how best to break down and distribute your tasks.
Ok, let’s make a festival! But what are we supposed to do today?
3. Competing solutions
What you can do to deliver the project is to create a hierarchy, as many if not most traditional organizations do. Once created, a hierarchy is blind, because it is based on a model of the project that does not adapt and change as the people delivering the project think it through and discover new information. It is also inefficient, because people are matched to tasks through authority instead of on the basis of their skills and their motivations. Hierarchies are often not well suited to communities, who often rely on the passion of the volunteers and their desire to work with their peers.
You could also deliver the project through issue tracking. This is more efficient, since people assign themselves to tasks that they care and are knowledgeable about, without the need for matching tasks centrally. Also, it is not blind since as new subtasks are found to be necessary they are encoded into new issues. However, issue tracking is vulnerable to the bystander effect, so many issues remain unresolved. This creates frustration and dread in the team as the issues queue seems to grow forever despite the work team members put in.
4. Unique value proposition
Realities uses collective intelligence to:
-
Determine what needs to be done to complete your project
-
Determine the dependency structure of tasks, i.e. which tasks depend on which other tasks to be completed.
-
Keep organizational memory of dependency structures, making your organization less vulnerable to key people stepping down.
-
Match people with tasks, defeating the bystander effect.
-
Make the critical, but often thankless work of doing all of the above visible and the information transparent.
The main advantage of Realities is this: given a smart, responsive community you can get an organization to configure itself starting from a mission to complete, even if none of its individual members has much knowledge about how to complete it.
5. Key concepts: Reality Guides, Realisers, Responsibilities and Needs
A Reality Guide is someone who identify that a certain Need is necessary in order to complete a project. The Reality Guide identifies tasks - called Responsibilities, that need to be fulfilled in order to meet this need. The Reality Guide is then responsible for finding people willing to take on these tasks, called Realisers.
This system ensure that only tasks that are absolutely needed are added to the project, and that all issues have an owner - the Reality Guide. It is the task of the Reality Guide to find a new Realiser if one drops out from one of the Responsibilities that Reality Guide is responsible for.
This is in part similar to what happens with issue tracking software. There are, however, important differences.
|
Issue trackers |
Realities |
|
Issues are created by anyone in the community without central oversight. |
Responsibilities are created by anyone in the community without central oversight. |
|
The creator of an issue has no ownership over it and the cost of creating an issue is nearly zero. This leads to people creating issues they do not deeply care about. |
The creator of an Responsibility is by default its Reality Guide. The cost of creating an issue is large enough to make sure only high-priority issues are created. |
|
The creator of an issue is not necessarily the same person that will resolve it. |
The creator of a Responsibility is not necessarily the same person that will resolve it. The creator of a Responsibility is tasked with finding the person that will resolve it. |
|
Lots of “orphan” issues. |
No “orphan” Responsibilities. |
|
No incentive to take up coordination work and be acknowledged for it. |
The combined work of Reality Guides in identifying and prioritizing Responsibilities and matching them to Realizers is project coordination. Reality Guides are rightly celebrated for doing this work. |
6. How Realities works
For clarity, we illustrate Realities in an example context: that of organizing a festival.
|
In the festival organization |
In Realities |
|
Alice realizes that the festival is going to need water for drinking and sanitation. |
Alice creates a Need called Water. She is automatically assigned as the Reality Guide of that Need. |
|
Bob decides to take on the responsibility of arranging water. |
Bob assigns himself to be the Realizer of the Water Need. Alice is still guiding the Need and responsible for finding someone new if Bob drops out. |
|
Bob decides to have a water tank delivered to the festival by truck. |
Bob creates two Responsibility called Place the order for water and Receive the truck. Realities connects them to the Water Need. Bob is automatically assigned as Reality Guide of both. |
|
Bob decides to place the order of the water himself, but realize he won’t be able to receive the truck because of other commitments. |
Bob assigns himself as the Realizer of the Place the order Responsibility and starts looking for someone to be the Realizer of the Receive the truck Responsibility. |
|
Bob asks Carol to receive the truck and she accepts. |
Bob assigns Carol as the Realizer of the Receive the truck Responsibility. |
|
Bob realizes the water truck need to be payed after the water company has accepted the order, but he does not have access to the festival bank account. |
Bob creates a Responsibility Pay for water and is assigned the Reality Guide of the new Responsibility. In Realities he adds dependencies showing that the Responsibilities Place the order, and that Receive truck are dependent on the Responsibility Pay for water. |
|
Bob asks Danielle, the festival financial manager, promises to make the payment. |
Bob assigns Danielle as the Realizer of Pay for water. |
7. Data storage and what you can do with it
At this point, what Realities knows about the festival looks like this:
Realities uses a graph database, so its logic mirrors the human logic of “who is responsible for what” and “what depends on what”. This graph is easy to simplify and manipulate to obtain human-readable information. A nice feature of Realities is that, as a byproduct doing the project, your team’s collective intelligence builds and stores in memory a conceptual map of what your project is. For example, the Needs and Responsibilities nodes, plus the edges connecting them to each other can be interpreted as a dependency graph (figure 2).
You can also isolate the nodes representing people, and obtain a pattern of collaboration across the group of people delivering the project. This is similar to an org chart, except it focuses on the collaboration patterns. In this project, Bob is doing most of the collaborating (figure 3).
Finally, you can take the subnetwork centered on any node. When the node represents a person, the subnetwork shows that person’s role in the project. If we are worried that Bob might leave and make the whole project break down, we could start by looking at his subnetwork (figure 4). Is there some responsibilities that we could relieve him of?
