Role system

From Value Network
(Redirected from Role System)
Jump to: navigation, search

This page explains the Role System for an OVN. A role is a cluster of activities an individual takes within an OVN.


  • The role of facilitator can be seen as a cluster of the following activities: communication, planning, documentation, social media outreach, ...
  • The role of administrator can be composed of activities like: office work, documenting (reading, writing, etc...), accounting, etc.

Roles can be fixed or emergent. The experience accumulated by affiliates in SENSORICA shows that open communities require a set of essential roles in order to function properly. This set might vary according to context. Essential roles must be visible to the entire community, they must be explicit and affiliates must be continuously encouraged to take them.

  • animator (give soul to the community, motivate, energize),
  • guide (help new affiliates integrate the community),
  • technical support (assist new affiliates with their problems using the tools and equipment needed for value creation),
  • administrator (perform tasks that support the community and its infrastructure)
  • ambassador (perform outreach activities in order to maintain an adequate influx or resources)
  • add others...

As opposed to classical organizations, roles are not appointed to individuals in open communities. In other words, one individual cannot monopolize a role for any period of time. Experience shows that in absence of power relations there is no guarantee that the appointee will maintain his/her role as promised or agreed upon. Some open communities can experiment with appointing essential roles to a given individual, if these role explicitly bring with them some sort of rewards (money, reputation/influence, etc.), if there is a mechanism to record individual commitment to the role and make it public, and if there is a mechanism to punish failure to keep the commitment by affecting reputation or the ability to extract value from the system (through the value equation for example), or by other mechanisms.

Open communities become statistically stable and can prosper only if all the essential roles are filled with high probability. This require some redundancy, i.e. at every given moment there are enough individuals in the system that can occupy an essential role, so that the probability that someone (anyone who can fill the role) performs an essential task as needed becomes close to 100%. Open communities become unstable and are in danger of collapsing if there is not enough redundancy into the system to allow essential roles to be filled whenever needed. In other words, open communities require a critical mass to function properly. Usually this critical mass is around 150 affiliates or members.

The value accounting system, reputation system and role systems must interact with each other.

The Role system must interface with the individual profiles and has write access to them.

The role system starts with a set of predefined categories and lives space for emergence of new roles. An OVN is an adaptive structure, therefore the role topology MUST be flexible and emergent.

The role system and value accounting

Roles can be modulators in the value equation. In other words, a group of affiliates collaborating on a project can decide to weigh time contributions according to the type of activities performed. Thus, {one hour of engineering work} can be evaluated at 2 x {one hour of manual labor}. It is up to the group how to use roles in the value equation and the [[value accounting system] allows for any kind of arrangement, from egalitarian to very meritocratic.

The role system and organizational structure

The organizational structure is essentially the topology of roles within the OVN, plus the relationships that emerge between these roles. En emergent role system will result in an emergent organization.

An OVN requires a sound value system, a fair reputation system and an accurate role system.

The value accounting system records and evaluates every affiliate's input, or contribution. Revenues are calculated in terms of member's contributions. This system outputs a map of value sources and of the value flow distribution. The reputation system incentivizes good behavior within our community and helps to focus attention. It plays an important role in the creation and the flow of value within the network by filtering participants for adequate tasks. It also informs the service system. The role system incites voluntary subordination; it plays an important role in self-organization. It also informs the service system.

All these systems are necessary to induce tight self-organization within an OVN, and to render the network creative and productive. These systems are also designed for network-to-network interface.


We believe that the proper implementation of the role system needs an ontology of activities and a method to extract patterns from logged activity, which are turned into roles and surfaced. For example, some individuals will only contribute with cash, financing infrastructure development and maintenance and/or specific projects. That would be a strong pattern of engagement that would be linked to a role that could be named "financier", or "investor".


See a simple implementation of the role system implemented on SENSORICA’s website.


Ampie I think that, whilst the role topology must be flexible, there is a limit to how emergent a role can be. Yes, there is an emergent aspect to it. The assumption of a role by an agent/participant should be absolutely voluntary and based on a consensus reached in the collaboration. This is in line with the requirement that a collaboration should be self-organizing. Participants should be allowed to relinquish and change roles from one project to a next. Roles should be fine-grained, and highly contextual. The work/activities associated with a role should be able to change and adapt over time, as long as there is consensus. However, once an agent/participant performs a certain activity/work in a given collaboration such as a project, it would be fair of other participants to expect that agent/participant to also take responsibility for other activities. Example: In a collaboration, a certain type of project, one activity involves the request for a service. This activity is associated with a “Customer” role. Another activity associated with this role details the requirements that need to be fulfilled for the specific request before payment is done. Is it fair for the Customer to now refuse to take responsibility for that activity, because we want to keep the Customer role emergent? Is it wise to let someone else specify the requirements if the Customer is the one to provide sign-off before payment? I find it hard to see that it could be. Performing one activity should automatically imply a responsibility to perform other activities, and this responsibility is encapsulated by the role associated these activities. The roles that a participant has fulfilled over time will also guide us as to what kind of reputation metrics could emerge for that participant. A customer could have a reputation for providing solid, well thought through requirements. Providing requirements is not really expected from the “Programmer” role. It is very possible for a participant to fulfill the “Customer” role on one project, and the “Programmer” role on the next, in which case that participant would indeed have a reputation score for his/her ability to provide solid, well thought through requirements. But it would not make sense to evaluate a participant that has never fulfilled the “Customer” role for his/her ability/tendency to provide solid, well thought through requirements. In fact, it would be blatantly unfair to rate such a participant on his/her ability to provide solid, well thought through requirements, and such ratings are irrelevant, destructive and should be disallowed.


In March 2013, during Lynn and Bob’s visit to Montreal, we had some discussions about the role system. In my opinion, the role is an emergent property of an agent, that relies on all the activities recorded by the agent. Examples of activities are: writing, reading, demo, tutoring, traveling, R&D, meeting... See more examples in the Back office catalog spreadsheet. A role is defined by a cluster of activities recorded by a member, as you can find in the old time log spreadsheet. Examples of roles are: animator, evangelist, engineer, … Thus, an animator would be someone that logs activities related to communication, organizing events, meetings, perhaps some traveling... The activity base of a role forms the reference of the role, it in fact its semantic basis.

Joshua from Enspiral [captured by Tibi during a conversation] There is a value to have pre-established roles, rather than totally emergent, because as soon as someone puts a role hat on information starts flowing towards this individual in a preferential way. Joshua also distinguished between Roles (accountability, responsibility and metrics, like facilitator, coordinator...) and Crafts (skills, like engineer, designer…, somewhat independent of context).


A role is a collection of competencies, accountabilities, authorities, typical activities and relationships. A typical org chart calcifies these into a position which is then assigned to one person using a process that includes merit and politics, accidents and circumstances. The positional assignment is then scarcely revisited as stability is a goal in a fixed structure like an org chart.

I would encourage you to consider fluidity in all role assignments. To use roles as attributes and descriptively, not as investitures of power or exclusivity of ability to act.

In particular, decision authorities should be algorithmic, based on an evaluation of skills and competencies required to make a decision (as well as other relevant factors, such as experience, tenure and others as decided in designing governance), not on the formal assignment of a role.

In other words role "assignment" should be fluidly attributed (filled in real time based on an algorithm) redundant, and assigned to the maximum possible actors. Quorum for a decision can be one or perhaps more of those who are qualified.

See SENSORICA's original role document.