Self-management with Organic Organization starts to get fun when we start thinking about more sophisticated and creative mechanisms to distribute authority. This often takes the form of circle restrictions, an element of organizational structure that we haven’t explored much in our content to date.

This is an advanced post, aimed at those who already practice O2. If you do not know how the method works in general, we recommend reading more about it or participate in our online training.

Definition

Located in the O2 Meta-Agreements is the concept of restrictions:

2.5 Restriction

“Restrictions” are limitations of authority that apply to all Roles in a Circle. Constraints consist of a name and a description.

Just like a role or an inner circle, a restriction is created within the circle in Adapt Mode. However, its function is quite different. Instead of setting performance expectations, as we do with responsibilities, restrictions limit the actions of the participants in a circle.

Context

To go deeper, I’d like to present the context of a fictional circle structure to use as an example. Imagine the following organization:

In it there are circles, such as the Operations Circle, with the roles clearly outlined. We also have the Development and Marketing circles. Any of these circles can have several defined restrictions.

Now imagine that within the Operations circle, you, in the role of Stock Savvy are responsible for organizing the inventory. You start to worry about the fact that Dr. Bacteria is constantly messing up the orders of the products on the shelf. Dr. Bacteria, when checking the expiration date of the products, often changes the layout of the canned goods. To make matters worse, Basket Maker also does this when he puts together the orders and assembles the baskets.

One way to deal with your tension as Stock Savvy is to define the Stock Layout artifact in your role, creating exclusivity. But this may generate other tensions for Dr. Bacteria and Basket Maker, as they also need to access the stock on occasion. You are not always available at the company office, which would make it difficult for them to ask you for permission all the time.

In this situation, a restriction could save you because you could limit access to inventory, without creating an artifact. So you decide to go to the circle meeting and propose the following change.

Add Restriction: Inventory Organization

After moving the products in stock, you must reorganize them back according to the layout defined by @Stock Savvy. If you come across inventory outside the layout, you should notify @Stock Savvy before making any changes.

With this restriction in the defined circle, both Dr. Bacteria and Basket Maker still have the authority to access and manipulate the stock, as long as they follow the conditions established in the restriction. Works just like magic, right? It’s a more sophisticated arrangement that allows you to maintain a certain type of organization but without centralizing an artifact in a role.

Restrictions can be useful in many situations because of their flexibility. But this same quality also brings some dangers, so they tend to be misused. Below we will see some counterexamples of restrictions.

Counterexample

Constraints are to restrict the roles of a circle, not to control people’s behavior. So, steer clear of restriction like this:

Delays: No one can be late for the circle meeting.

Restrictions are agreed upon by a circle through adapt mode, so it is generally not effective to try to push a rule that seeks to punish people or try to control them. If there is a trust issue, better use care mode for that. Restraints are only effective if circle members see meaning in them and seek to respect them. Also, saying that no one should be late usually doesn’t make people arrive on time. :P

Another common failure in understanding restrictions is seeking to use them to set an expectation. Consider the following restriction:

Scheduler: Everyone must follow the schedule defined by @Scheduler.

Note that the restriction does not have a condition, but seeks to define that someone does something on a regular basis. In this case a responsibility can be much more effective. You can create a role with the following responsibility to “Follow the schedule defined by @Scheduler” and invite everyone in a circle to energize this role.

Another real example

At Target Teal, the distribution of clients among consultants takes place according to a restriction defined in our structure. Making this the artifact of a specific role would not suit us, because if it were judged by one person, it would certainly be full of biases. As we are all consultants (and therefore interested in being “owners” of clients), we opt for a distributed process. This restriction has already undergone numerous changes and evolved as new tensions emerged. On the date of writing this restriction, it looked like this:

Restriction: Client Attribution

Any potential customer from:

– Target Teal’s public email;
– other online channels where the customer is looking for Target Teal as an organization (without looking for a specific consultant), or;
– contacting multiple partners at the same time

… will be considered a “customer without an owner”. Once a partner has identified an unowned customer, one must contact all partners through our special communication channel called: tt-unowned-clients, provide all the information one has about the customer and ask if anyone is interested in becoming the @Customer Owner. Once everyone responds or a 24-hour deadline is reached, one of three situations will be possible:

1) Only one partner is interested, so he or she becomes the Client Owner for that customer.
2) No partner is interested or available, the person who first posted on the channel informing about the customer must respond to the customer and tell him or her that, at this moment, no one is available to carry out new projects. It is advisable that he forward the customer to someone or some company on the extended network.
3) More than one partner is interested and they have not reached an agreement on ownership or shared ownership of the customer. The Client Owner is chosen by rolling dice.

If a partner is personally contacted by a potential customer and he is unsure whether he is looking for Target Teal (therefore, unowned customer) or just its services (owned customer), he should ask a version of the following question:

“Do you want to be seen by me specifically, or could it be another Target Teal partner?”

If the answer is something like: “Yes, my preference is to be served by you”, the client will be considered to belong to the partner. Otherwise, the client is unowned and will go through the process described above in this restriction.

If, for any reason, a Client Owner does not want or cannot continue to be a specific owner, he may pass the client on to any partner, using his own discretion and even negotiating financial returns.

Two important principles must be observed by partners who discuss customer ownership: “Serve customers in the best possible way and share work opportunities with all partners”.

Restrictions and artifacts

Restrictions go hand in hand with artifacts. This is because a circle cannot constrain something it does not control. Imagine, if in that structure that we presented before, the Development circle tried to create a restriction on top of the inventory. This would not be allowed by the Meta-Agreements, because the Development circle does not have the authority to do so. This restriction would be violating the “Inventory Layout” artifact, which is defined in the Operations circle. In order for this change to be allowed, Development would first have to gain control of the inventory via the corresponding artifact in its definition.

Let’s imagine another scenario where the Inventory Layout is not defined on any circle as an artifact. In this case, it is as if the artifact is from the general circle and the entire organization can access it. With this configuration, even if Operations defined a restriction internally in its adapt mode, this rule would only apply to roles within Operations. A restriction only holds for the circle in which it is defined and its inner circles. To make it valid for the entire organization, it could be defined in the general circle (the most ample in the structure).

This gives great power to wider circles to define processes, contours or how some organization’s resources can be used. Even so, at O2 we guarantee greater representation from the inner circles through the concept of double links (external link and elected internal link), thus avoiding abuses of authority.

In short, restrictions can be very powerful in distributing authority in Organic Organizations. Just be careful not to create them with the intention of solving problems of lack of trust. At O2 we always assume that people are trustworthy and well intentioned. Have you used restrictions before? Tell us about it.

Translated by Tanya Stergiou