The Organizational Design work carried out by Target Teal generally involves giving more clarity to agreements within an organization. We believe that one of the first steps towards the evolution of the organizational structure and perhaps the adoption of self-management practices is to explain how things work. But this is not an easy task. In general, I find it very difficult to describe minimally clear organizational policies. In this text I intend to cover how to write good policies (or restrictions if you are using O2) for a clearer, more explicit and adaptable design.

What are organizational policies?

Policy is a very broad term within the administrative world, generally used to designate a set of rules that are followed by the members of an organization. Some authors make a distinction between process, procedure and policy, but I consider this distinction irrelevant. In this text I will consider a policy as any kind of restriction on the authority (capacity to act) of people within an organization, implicit or explicit. For example, if before publishing a new marketing campaign you must ask 3 different people for approval, that is a policy. If the entire purchasing process must go through a financial analysis, with defined authority, specific criteria for each authority, this is also a policy.

Organizational policies often function as a means of regulating access to shared resources. That’s why they are so used by the financial, legal, controllership, HR areas etc.. However, the traditional use of policies often goes in the direction of establishing control over people’s work through shareholders rather than allowing it to be carried out effectively. As a reader of Target Teal’s blog, I imagine you know that we don’t condone this type of use. We believe that organizational policies should be defined in a shared way rather than imposed by the layers above.

The essential

To enable the evolution of organizational design in any context, I believe these 3 things are fundamental:

Evolve policies quickly. First of all, we need to stop treating an organization’s governance like an untouchable sacred cow. Instead of spending months creating the perfect budget policy, write something good enough for now and get it up and running. I’ve seen groups spend 3 months discussing what a policy could be like. If you spend months working on the text, it is possible that you will become extremely attached to it. Another problem is that we fail to experience the benefit that politics could bring by looking for the perfect solution. For organizational arrangements, the done is better than the perfect.

Define how the policy will evolve. For agreements to adapt quickly, it is essential to define how they can be changed. Who approves the policies today? How is this decision made? Maybe this is the best place to start. If it’s not clear how this deliberation takes place, it’s likely that you’ll spend months “aligning expectations” around getting nowhere. We don’t want perfect policies, but rather, ones that are just safe enough, which leads us to…

Treat each policy as an experiment. We are so attached to the traditional management structure that we don’t realize that each role, each policy, each agreement can be treated as a little experiment. Our search for the perfect solution brings us to complete paralysis. This is not always easy when the organization demands it. Maybe if you call the policy “Agile” or adaptive it sticks more easily.

These 3 things are not only essential for policy evolution, but for organizational design in general. With them in mind, you can begin to worry about how to write good policies.

Characteristics of good organizational policies

Let’s explore the following characteristics of good policies, one by one:

  1. Restrict and only that
  2. Atomic and user-oriented
  3. Objective and succinct
  4. Clarify authority
  5. Offer structures without prohibiting

Restricts and only that

Within the Organic Organization we like to make a distinction between accountability and restriction. Accountability is an expected activity that someone does, such as “writing content for the Target Teal blog”. An accountability is part of the definition of a role and gives one clarity about what others might expect. The accountability is unconditional, that is, it does not depend on a specific situation. The restriction is something along the lines of “If you are going to publish new texts on the blog, notify the channel #Contents in Slack”. That is, the restriction can establish an expectation of something, when there is a very specific condition. Our focus in this text is the second – which we treat as a synonym for policies.

Because there is no clear place to define the accountabilities of each one (the job description does not meet this demand), many organizational policies are filled with unconditional responsibilities. My invitation here is that in writing a policy you focus only on 1) what you want to restrict, or 2)the specific condition that one should wait for, leaving accountabilities elsewhere. The reason for this is that these are different questions that we ask ourselves when researching agreements. Note:

  1. What are my accountabilities? What is expected of me? I will look at my roles and accountabilities.
  2. Do I have the authority to do this? Can I really do this? I will consult the policies (restrictions and artifacts at O2).

In my experience these 2 questions are asked at very different times and therefore I think it is more appropriate that their answers are found in different repositories (roles and responsibilities for the first, policies/restrictions for the second).

For example, within a purchasing policy of a certain company I found a specific section on “Accountabilities”, which said:

CEO: Approve or disapprove purchase orders within its purview, observing budget compliance.

To solve this, I would move this expectation to the “role” of the CEO and leave the purchasing policy with only restrictive things, such as:

Every purchase must have its purchase order duly registered in the organization’s financial system.

In this way the policy only restricts and does nothing else.

Atomic and user oriented

I believe organizational arrangements should follow “good practices” similar to “Evergreen notes“. I think of organizational structure as a kind of shared knowledge, as if there were several notes about what is expected of people and what is restricted. That’s why it seems interesting to follow practices in this field. One of these characteristics is to make each policy “atomic”, that is, dealing with only a small specific thing. Within computational systems we also call this cohesion. Let’s go to an example to make everything clearer. 

At the time of writing this text, Target Teal’s structure has a policy called “Distinction between Partners”:

If a Partner in Transition wishes to take on the role of @Cliete Owner for a specific client or @Organiser they should seek advice from one or more of the Full Partners before taking on the role/client.

If a Full Partner wishes to propose the entry of a new Partner in Transition, he must make it clear that if the person enters into the partnership, in the first 3 months there is a great chance that Target Teal will not meet the income needs of the Partner in Transition. In addition, it must offer opportunities to work on consulting and training contracts (open or closed) as soon as the person becomes a Partner in Transition.

In open communications, such as websites and newsletters, partners should avoid mentioning the labels Partners in Transition and Full, so as not to hinder the work of Partners in Transition due to the "golem effect".

Comment: Partner in Transition is a title that new consultants who are in the process of joining Target Teal receive. After going through a probationary period they become Full Partners.

I’m going to be more precise here to address the concept of atomicity. While this policy addresses a common theme which is what it says in the title, there are clearly 3 very different things it tries to do. To illustrate this we can separate it into 3 different policies:

  1. Assignment of clients to Partners in Transition: This policy would be in the best interest of the transitioning partner, as it is he who should seek advice, and thus justifies the separation.
  2. Criteria for invitations to Partners in Transition: This one directly impacts any incumbent partner who wants to invite new transition partners.
  3. Communications for Partners in Transition: This affects a few roles that talk to the external audience, such as the role responsible for the website, or the way in which the transitioning partner itself is presented outside the organization.

It seems to me that having 3 policies with these titles would make it much easier to find what I need when I quickly scan Target Teal’s organizational policies. Separating the policies is also justified because they impact different people/roles. But as I said, I’m being precise, as the text is only a few lines long. If you have a 15-page policy, you might make significant gains from breaking it up into smaller chunks with specific titles.

Objective and succinct

Even though it was already covered above, it is good to emphasize that you should try to eliminate unnecessary redundancies in the text. Repeating the same restriction in different ways does not increase the chance that people will understand the text or follow it, on the contrary. The bigger it is, the less chance it will be read, understood and followed. For example, in the same policy I found two different excerpts:

Excerpt 1: Every purchase must have the budget, deadline, payment conditions and input, observed by the immediate manager.

Excerpt 2:Ensure that every purchase made is previously aligned and agreed upon with the approver of the authority corresponding to the purchase amount.

They’re not exactly the same, but they both say there’s some kind of approval necessary in the process. I would write something like:

Before making a purchase, you must seek approval from your immediate manager, informing of the budget, deadline and payment terms.

This policy that I rewrote would be for the requester of any purchase. We could have another that would limit the manager’s action, bringing clarity that he can only approve something within his scope of authority.

Clarifies Authority

For a clear and effective organizational design, I believe it is essential to define within organizational policies how decisions are made. The opposite of this implies creating a great inertia, as can happen in this case here:

Payments sent outside the deadline stipulated in this policy must be renegotiated by the applicant or immediate manager.

Renegotiated with whom? Like? The manager who decides? Is it a consensus between manager and applicant? Of course, in case of doubt, the authority will stay with whoever already has it (manager). If the organization is in a quest to distribute authority, it becomes especially relevant to fill in these gaps and define what exactly “negotiate” means. For example:

Payments sent after the deadline can only be made if the manager explicitly approves and defines it as a “valid exception”.

Offers structures without prohibiting

I’ve seen several proposed policies with the objective of prohibiting any action within the organization in any situation. For example, an organization was going through a period of crisis and decided to forego any hiring. The solution (not so suitable in my view) was to establish a policy such as:

No hiring is to be undergone.

It seemed to me that in this case the real intention was not to definitively stop hiring people, but to be much more judicious in the hiring process. Especially since, situations could arise where hiring someone could be essential. Imagine if a person with a rare and important competence leaves the organization – I am sure that hiring would be desirable in this case, despite the crisis period. Therefore, it is more useful to define a policy that offers structures without prohibiting, for example:

Before opening a vacancy for a candidate, the person making the request must fill in a justification form. Then you should seek advice from at least 3 members of the Culture team. Only then will the requester be able to decide to continue with the opening of the vacancy or not.

This type of policy increases the security around decisions about opening vacancies, since it requires a reflection by the requester (when filling out the form) and also the contemplation of other perspectives. Thus, making it possible to open the vacancy.

When we design policies that provide frameworks without forbidding, we make the organization more adaptable. Rather than blocking important organizational functions, we create clear paths and contours for them to happen without creating major tensions.

Writing some sort of policy is better than none at all

These criteria presented are intended to improve organizational design. By no means do I recommend that you inhibit people from proposing a policy (or any kind of agreement) for not being “adequate” to what I’ve described here. On this journey of evolutionary design, some policy is certainly better than none. A text, however crude it may be, should be appreciated as an act of courage to make things clearer. It’s the first step! So take it easy on criticism until people are well used to making policy proposals. Only then propose evolutions based on these criteria.

Translated by Tanya Stergiou