We don’t like to be controlled. And we don’t like control systems.

Few of us want to have a controlling boss who looks over our shoulder, follows our every move, and criticize what we do.

Similarly, few of us want detailed rules and procedures that constrain how we perform our work.

We want our manager – and the system that we are part of – to have some faith in our competence and willlingness to do the work to the best of our abilities.

Similarly, we may prefer an informal relationship with our business partners, and we may react negatively if they insist on developing a detailed contract before the work can start.

We want to be trusted. Of course.

But are we thinking about this in the right way?

It turns out that the “trust versus control” dichotomy is too simplistic.

One example is the level of trust that you have in an organization.

Imagine a company representantive telling you:

We’re really informal. We trust people here. So we don’t monitor whether the objectives are met. We don’t take compliance very seriously. We don’t do internal audits, we don’t check travel bills or invoices, and we perform no safety checks in our operations. We have no written rules, and don’t define people’s roles or responsibilities.

Would you want to do business with such an organization – or work for it?

Probably not. This is why studies show that having internal control systems is positively related to levels of organizational trust among employees (see this article).

Similarly, if we don’t want to skrew up in our work, we probably don’t object to having somebody checking on what we do before we press the button and set in motion a complicated process that may entail technical or financial risk.

In other words, in some cases we actually welcome the control.

And when working with an internal external client or supplier, we might find that collaborating to specify the terms of a contract actually builds rather than destroys trust. 

Recent research suggests that it is not the use of contracts per se that is important for trust, but how you develop the contract, what is actually in the contract, and how you use it (e.g., see this paper).

So why do we think about trust versus control as a dichotomy?

I asked a former colleague of mine, Per Forsberg, about this. He is currently an associate professor at the Örebro University in Sweden.

In his research, he shows how one type of control system – accounting – can maintain and strengthen social relations.

He explains that if you implement institutional rules, or a formal system of control, such as an accounting process, people will tend to think that it will diminish the social capital (i.e., trust) that exist because them.

But he argues that the opposite is often the case. He cites Nobel prize winner Elinor Ostrom, who argued that institutional arrangements are the foundation of social capital (including trust).

If you consider the different countries around the world, this seems to be true: It is in the countries with the most sophisticated legal systems and the most advanced governmental institutions that people have the highest level of trust toward each other (see this web page).

We also have this idea that control systems is a recent invention. We imagine that people lived in idyllic farm societies until the industrial revolution. Then Fredrick Taylor came along with “scientific management” and started measuring, monitoring and controlling employees.

This is not the case, however.

In one of his articles, Prof. Forsberg describes the use of tally sticks – wodden sticks on which notches were made with a knife to keep a count or score.

They were used for centuries before paper was invented (and even after) to keep track of obligations and for recording pieces of work done by individuals (This is the origin of the expression “to keep tally of” – tally means stick in Latin.)

For example, in villages in Sweden, there could be tally sticks for being the fire guard, taking care of the poor, or ringing the church bells. The tally sticks created transparency: They were used to divide up the duties among the people in the villages and make sure that nobody did too much or too little. 

When individuals agreed to use such a tool, it indicated that they were willing to be open and show others what they contributed. This in turn signaled to others that they had nothing to hide, and were willing to cooperate.

These systems are not necessarily implemented in a top down manner – as Prof. Forsberg argues, people can themselves participate in developing institutional rules. 

Tools for measurement, monitoring and control are actually the basis for democratic engagement.

So if we bring this back to organization design, what are the implications?

I think we should stop viewing trust and control as opposites.

It’s not the absence of control that creates trust. On the contrary, you need control systems to build trust and facilitate effective collaboration among people in your organization.

The question is whether you have a well designed control system – and how you use it.

Related posts:

If you mean it, formalize it

Is your organization overspecified or underspecified?

Why we need to learn to contract – podcast interview

Image attribution: https://www.freepik.com/free-vector/business-background-design_999966.htm

Let’s assume that you are planning a re-organization.

How do you proceed?

• Do you make the decision based on the information you already have, or do you analyze the current organization first?
• Do you consider only one alternative, or do you develop multiple options before you decide?
• Do you make the decision yourself, or do you involve other stakeholders?

We know from extensive research that the quality of the decision that one makes is highly correlated with the process that one follows.

And the more complex the issue is, the more important the process becomes.

But it may be difficult for a single individual to change the way decisions are made. It seems like the decision making style is embedded in the culture of the organization.

Hence the level of sophistication varies from one organization to the next.

So there might exist “maturity levels” with regards to decision making. 

I have not done systematic research on this, but I have participated in a lot of organization design projects over the years, and interviewed hundreds of managers about these issues.

Based on my own observations, there seems to be four maturity levels, as illustrated above.

Let me explain each one of them.

Maturity level 1: Autocratic

In organizations that are at this maturity level, the boss decides, with no involvement of others.

I once interviewed a senior executive of a large, international company. I asked him how decisions about re-organizations were made in his company.

He told me this anectode:

A few years ago, before Christmas, we thought that the CEO was working too much and was looking tired. So we suggested to him that he take the Christmas off.

To our surprise, he agreed and spent the entire week between Christmas and New Year’s eve in his mountain cabin.

But then, when he showed up the first day in January, we realized that he had not been idle during the break…he was carrying a large print-out of the org chart, with multiple changes indicates with a red pen.

At the first management meeting in January, he announced how the new organization would look, and allocated the people around the table to their new roles. That’s how the new organization was introduced.

After that, we joked that we would never again ask the CEO to take a Christmas break…

People in the same company told me that they often spent two or three years implementing a new organizational model.

This is probably not a coincidence: Organization design is simply too complex an issue to be handled by one person working in a mountain cabin, no matter how bright that person is.

When you make a decision without understanding the underlying complexity of the issues, you will get a prolonged implementation period.

One reason is that it will take time to “sell” the new model and explain how it is supposed to work.

Another reason is that it will require a lot of local changes and adaptations to the (usually poorly conceived) model to make it work (e.g., see this study).

Maturity level 2: Involvement

In some organizations, one realizes that involvement is key. These organizations are at level 2 of the model.

Involvement increases the degree of acceptance. When people feel that they are heard, they are more likely to support an initiative to introduce a change.

On the other hand, involving people does not guarantee an effective decision process. It may produce a consensus, which is good, but the technical quality of the decision may not always be optimal.

I have observed many companies that arrange a lot of meetings with discussions about these topics. But they don’t seem to follow a structured process. People exchange viewpoints about possible solutions, rather than confronting data about the problem.

They usually don’t have any decision criteria, and usually fail to consider alternative options.

When you go back later and ask why a new organizational model was chosen, they usually can’t explain exactly when they made a decision, or even why. 

Maturity level 3: Sequenced

Some organizations reach a higher level of sophistication, which I call “Sequenced”.

Managers in these organizations divide the decision making process into phases.

In particular, they make a clear distinction between “As-is” and “To-be”.

In the “As-is” phase, they seek to understand and document the current organization. If successful, this creates a common understanding among stakeholders of how the current organization works, and about its strenghts and limitations.

By spending time and money on documenting the current organization, one increases the chance that one identifies the most important underlying issues, and that one selects a solution that actually increases performance.

Documentation is also crucial for transparency and future learning: It makes it possible to explain to people why a decision has been made, and to go back at a future point and check whether the assumptions were correct.

In the “To-be” phase, they consider how they might address the issues identified in the “as is” phase.

But organizations at the “managed” level don’t just develop one alternative. They develop multiple alternatives, and have some criteria that can be used to evalute the alternatives against each other.

Developing multiple alternatives has consistently been shown to increase the chances of making a successful decision (e.g., see this study of actual decisions in a German firm).

Maturity level 4: Analytical

When firms introduce a new product, they rarely rely on intuition alone – they do (among many other things) market research and conduct systematic product testing before the product is launched. To do this, they collect data and analyse the data using statistical techniques.

But strangely, when managers in some of the same firms make organization design decisions – with consequences for hundreds or even thousands of employees – they may rely on little more than an organization chart scribbled down on paper napkin (I actually once observed a scenario like this.)

But thankfully, this is changing.

Leaders are becoming aware that organization re-design may be a necessary, but complex, undertaking.

They realize that they should be armed with the best tools available to increase the chances of success.

So the most sophisticated firms – those at maturity level 4 – use analytical tools (of course, in addition to involvement and sequencing of the process).

Analytical tools may, among other things, be used to…:

• Increase the clarity of unit mandates and to minimize goal conflicts in the organization (see my book and this article that I published recently).
• Reduce coordination cost by grouping roles using a clustering algorithm (see my previous blog post about the Reconfig software tool that I have developed with two colleagues).
• Ensure that managers at different levels have the right span of control (I use a simple Excel tool for this, I might post it later to this blog)
• Estimate the required size of units based on capacity considerations (I use a time usage survey for this purpose).

Moving to a new level

So how do you increase the quality of organization design processes in your organization?

Based on what we know from other areas, it is hard to jump across maturity levels.

So you probably need to institutionalize processes at level 2, before you can move to level 3, and you need to be at level 3 before you can move to level 4.

But the important thing is to start. Hopefully, this framework can be a guide on the way.

Image source: Flickr

In the TV series Kitchen Nightmares, UK chef Ramsay Gordon visits struggling restaurants and tries to help the staff to improve quality and attract more customers.

When he first visits the restaurants, what Ramsay often finds is that they have a menu the size of a book (in one episode, the resturant offered more than 100 options.)

Despite the wide selection, the food is not necessarily what people in the area would enjoy. And the large menu means that the logistics becomes complicated. Sometimes the staff don’t even know how to make some of the dishes.

The result is poor quality food and unhappy customers.

The solution, of course, is to offer a simpler menu.

To do this, the restaurant first needs to understand the needs of the customers. Then the kitchen staff can create a profile – focus on one type of food, and aim to deliver a smaller set of dishes in a consistently excellent manner.

A restaurant is just one example of a social system.

It’s a general principle: You get higher quality, as well as higher productivity, if you limit the number of things you do or the number of products you offer.

This effect can be observed in every industry sector. As another example, consider health care.

A team of researchers* conducted a longitudinal study of a medical group in Minnesota with 32 different clinics, some serving a narrow mix of patients and some serving a broader mix of patients (i.e., providing more diverse services or serving more diverse patient groups).

Here’s one conclusion from their study:

Clinic site visits by the researchers revealed that (…) patients served by less-complex, focused clinics are more satisfied with their care, perceive clinic staff as more courteous, and staff perceive they provide a higher quality of health care than broad clinics.

There are at least two different reasons that can explain this effect.

The first is well known – it was in described in 1776 by Adam Smith in theWealth of Nations: Specialization.

Smith wrote about individual workers, but the principle is the same.

A more focused sub-unit will increase its capability faster, because it can repeat the same (or at least similar) activities many times, instead of shifting between different activities.

This is well known.

But there’s another important factor, which, until recently, has received little attention:

With a broad mandate; when you combine many different activities, chances are that some of them will be in conflict with each other. You can call it “negative synergy”.

Sometimes this is the case when two activities have different time horizons, or compete for the same resources.

Consider, for example, a hospital with a surgery department that is responsible for both emergency and elective care (scheduled operations). The more acute medical cases are likely to be prioritized, and resources will then be allocated to emergency care, which will have a negative impact on the ability to provide elective care. 

This is why experts recommend a separation between the two tasks, with one department within the hospital performing emergency care, and another performing elective care.

This makes sense intuitively, so we have to ask ourselves why unfocused units (or units with combinations of incompatible activities) even exist within large organizations. 

There may be a universal tendency to increase the scope of what we are doing. 

Over time, we take on additional responsibilities. We add things to the menu – literally or figuratively. Initially, it may make sense, but at some point, the complexity starts impacting our effectiveness.

So, how do we avoid it?

As always with these issues, awareness is step 1.

If we are aware of the tendency, we may periodically review our mission and mandate, and consider whether we have the appropriate scope.

If you are planning a re-design process, there are a couple of analytical techniques you may use.

The first is “top down” analysis. You start with the customer needs and define a set of goals/functions that the organization must perform to succeed.

You then review the key goals/functions against each other. Cross-tabulating them in a table is useful (For a more sophisticated methodology, see the appendix in this article that I published last year.)

You want to avoid (or minimize) situations where the achievement of one goal or function will be detrimental to achieveing other goals and functions (if this is a risk, you should allocate the goals or functions to different to internal units).

The second approach is “bottom up” analysis, starting with the roles and work processes. We need to understand how processes are related to each other, in order to design sub-units that have a set of highly related roles (the software tool I am developing is intended to support this kind of analysis.)

Are there any downsides to focus?

Yes, there may be.

The most important downside may be reduced task variety for employees – that is the whole point of a narrow mandate. For some employees, this may decrease their motivation.

But this challenge can be handled in other ways, such as by offering job rotation or possibilities for transfers to other internal units.

Overall, though, increased focus should be positive for employees – it will give them a clear direction for their work and allow them to excel at what they are doing.

*The quote above is taken from this article:

Van de Ven, A. H., Leung, R., Bechara, J. P., & Sun, K. (2011). Changing Organizational Designs and Performance Frontiers. Organization Science, 23(4), 1055-1076.

Can an algorithm improve the design of your organization?

I believe the answer is yes.

In fact, together with two colleagues (Kim Soldal and Tore Christiansen), I am developing a software tool for this purpose. It is called Re:config.

The goal is not to automate the entire organization design process – that is not realistic (nor desirable).

What we are developing is a decision support tool: A tool that can help practitioners (leaders, internal advisors, and external consultants) create more effective organizational models.

We have created a video that explains the basic concept (it lasts for about 3 minutes):

As the video explains, what Re:config does is to help group elements (roles, teams, or sub-units) in the best possible manner.

A grouping task is like this: Should role A be organized in the same team as role B? To answer this question, one needs to know what tasks A and B have, and their interdependencies (how they are related). 

This becomes a hard task when the number of elements increases. 

As an example, if you have 6 roles and need to allocate them to two sub-units, there are actually 41 different ways of doing this (!).

Which of the 41 options is the most effective one? An algorithm will find the answer faster than the human brain.

By making better decisions about grouping, you will reduce coordination costs: Less time will be used in meetings and on email to coordinate with others, and more time will be spent on the core tasks. 

It will also enable you to create a more flexible and modular organization, one where each sub-unit has a clear and focused mandate, with responsibility for a complete deliverable (or a set of closely related tasks). 

* * *

What we have now is a prototype. It works, but like all prototypes, it will need to be further developed and testet.

For this reason we are seeking 3-4 partners (industrial companies or consulting firms) that are interested in testing the tool in their organization.

So let me know if your firm might be interested in collaborating with us on this.

P.S. The main assumptions behind the tool are described in chapter 5 in the second edition of my book.