Contents

What Policies Are For (And Aren't For)

Policies are only a way to grant access or limit access in a specific way to something that is already controlled by the Circle or Role. It's a much more limited definition of "policy" than what we're used to see in conventional companies.

Policies can:

Give access to a Domain or something otherwise exclusively controlled by the Circle. This includes specifying conditions that need to be followed to access the Domain. (e.g., "Everybody can post to the Facebook company account as long as they sign with their name")

Limit access to something owned by the Circle or Role. It can go

from simply specifying a certain way of using an asset (e.g., "every role creating a company account with a third-party service must use a strong password with at least 8 characters"),

defining a specific process for doing something within the circle (e.g., "all projects must be tracked in GlassFrog or Trello"),

to down right forbidding an activity (e.g. "no other role than the Spokesperson is authorized to speak in public in the name of the company")

Policies cannot:

Govern something that the Circle or Role has no authority over in the first place

Mandate an action or activity from a role (e.g., "Marketing must send newsletters every 2 weeks"). Instead, creating new expectations on Roles can be done with adding Accountabilities to those role. However, it's fine to require an action as a condition to impact a Domain (e.g., "Everybody can post to the Facebook company account as long as they sign with their name").

Govern people outside of their roles (e.g., "Everybody must say hello in the morning")

Examples of policies

Example of policy on a circle that has a Domain of "Company's Website". In this example, this circle is granting access to the Finance circle to modify some pages:

Policy: Authorization for Finance to edit some webpages
The Finance circle may edit the pages of the website that support Finance-related processes (i.e., the "Make payment" page, the "Payment plan setup" page, and the bank account details provided upon product purchase).

Example of policy on a circle limiting a specific activity within the circle. In this example, the circle is constraining all roles within the circle to store passwords a specific way.

Policy: Password Requirements
Anyone using passwords to secure company-related accounts with access to company assets or sensitive data must ensure those passwords are strong, not duplicated on any other system, not stored anywhere except a highly protected repository, and may not share the actual password text with anyone else.

Creating Policies

Policies can be created

on Circles: on a specific domain they control, or more generally on all functions and activities within the circle. Only a circle member of the circle can propose creating a policy for the circle, and they can only do so via the governance process.

on Roles, if they control a domain defined in governance. When a role controls a domain, the role can publish policies regulating that domain at will—no need to go through the governance process.

A useful way to think about Policies is to start by thinking about what your role/circle controls. A Policy can only govern what you control. For instance, if you want a Policy around what roles are authorized to add pages to the website, you first question should be "Does my role control the website?". The diagram below shows the decision tree for that example.

Policies in the Constitution

2.1.2 Policy Definition

Policies granting or limiting authority within a Domain duly controlled by a Circle may only be defined or amended through the due governance process defined in Article III of this Constitution, except to the extent otherwise allowed under the terms of Section 2.2.1. Further, solely for the purpose of defining Policies that limit authority of its contained Roles, a Circle shall be deemed to hold a Domain controlling all of the functions and activities performed by such Roles, whether or not explicitly defined as a Domain of such Circle. (source)

1.3 Authority Over Domains

A Partner duly filling a Role shall have the authority to control and regulate each Domain assigned to such Role, by (a) assessing specific requests for permission to take actions that impact such a Domain, and approving or denying such requests, and (b) defining or amending ongoing grants of authority allowing others to exert control or cause a material impact within such a Domain, as well as limits or constraints on how others may do so when otherwise authorized (each such grant or constraint of authority a “Policy”), which shall be valid and binding once published in a forum freely and conveniently accessible to all Partners who may be impacted by such a Policy; provided, however, that the authorities granted under this Section 1.3 shall be further limited by and subject to any constraints duly operating upon such Role itself or such Domain per the terms of Section 2.1.4. (source)