What is organization design?

“Organization design” involves the creation of roles, processes and structures to ensure that the organization’s goals can be realized.

Some people associate organization design with the mechanical arrangement of positions and reporting lines on the organization chart.

It is certainly true that organizational designers also need to define the vertical structure, including reporting lines.

However, organization design is much more than “boxology”.

Organization design problems are often some of the hardest problems that leaders face. Finding the right design often requires inventing a new solution to resolve a dilemma. And decisions made with regard to formal structure, roles and processes directly impact the jobs and careers of employees – and the ability of the firm to realize its strategic objectives.

In an organization re-design process one may consider elements at different levels:  

  • The overall organizational “architecture” (e.g., the corporate level, the role of the headquarters versus business areas in a large firm, etc.)
  • The design of business areas and business units within a larger firm
  • The design of departments and other sub-units within a business unit
  • The design of individual roles

The field of organization design sits at the intersection of strategy, operations, law and HR.

1. An important driver for organization design is the organization’s strategy – but the design of the organization may also to a great extent determine which strategies we may be able to form in the first place.

2.  We should, in general, attempt to align the organization with the work processes – so there is a close link between operations and organization design.

3. The design of the organization is also influenced by laws, regulations, and governance principles adopted by the industry sector.

4. Last but not least, organization design is fundamentally about people. People inhabit the roles that are defined in the organization design proces. People participate in design processes and also influence designs in many direct and indirect ways. 

reduce barrier

Fighting Complexity with Subtractive Change

Internal complexity seems to increase gradually over time in most organizations.

Earlier this year, a study was published in the prestiguous journal Nature that looks at the underlying causes of this tendency.

The authors conclude that there is a cognitive bias, which they call subtraction neglect.

As the name suggests, it leads people to add things and to ignore the possibility of subtracting things in order to solve a problem.

The authors mention some initial observations that led them to examine this issue.

For example, they analyzed improvement ideas that were submitted to a new university president. Of the 651 proposals, only 70 (11%) were subtractive, that is, involved removing something or stopping an activity.

To study this tendency more systematically, they set up a series of experiments.

In one of the experiments, they showed the participants drawings of a minigolf course and asked them for ideas about how to improve it. The experimenters coded whether the ideas were additive (e.g., “add a windmill”) or subtractive (e.g., “remove the sand trap”).

It turned out that only about 20% of the ideas were subtractive.

So with regards to organizational design, this may explain why we tend to add new roles, units, processes and reporting lines on top of the old ones, instead of removing and simplifying the organization.

Or, in our personal and professional lives, why we commit to too many goals and activities and end up with overburdened schedules (I am guilty of that myself.)

However, all hope is not lost.

In the minigolf experiment, they did another variation, where they offered cues, for example, reminding participants that they could “add or substract”. Offering a cue increased the likelihood that participants would submit a list with at least one subtractive idea.

This suggests that by raising awareness of the issue, we may be able to counteract subtraction neglect, at least to some extent.

In another recent article, Denise Rousseau suggests that this should be a key concern for everyone interested in organization development and change:

She adds that not all subtraction is good.

We need to distinguish between subtraction that adds value, by removing unecessary elements, and subtraction that removes elements that we actually need for the organization to function.

What are the appropriate organization design methods that we can use?

I think many of the methods and principles that I have discussed on my own blog in the past are relevant.

For example, the proposal by Prof. Nam Suh to periodically start from scratch and re-set the system. Or, in the words of organization development expert Paul Tolchinsky – do a yearly “Spring cleaning” of the organization instead of just assuming that everything should continue the way it is.

If we you have ideas for how “constructive subtraction” can be accomplished, I would like to hear from you – feel free to add a comment below.”

agile org

Using Reconfig to Create Agile at Scale

According to one study, 90% of all companies have adopted agile methods in some form. Typically, companies use agile methods for software development, but many also use agile principles more broadly.  At the same time, some companies experience challenges with agile implementation (e.g., see this article). This suggests that there is a need for systematic tools and methods to support both initial implementation and continuous development of agile organizations. 

Reconfig is a software tool that is used to map and optimize the design of an organization. There are at least three factors that make it relevant for agile organizations.

The key feature of agile organizations is the small, cross-functional and self-managing teams. But how do you set up these teams – which roles should be combined to form a team? Reconfig has an algorithm that helps you identify teams with a combination of roles that benefit from being organized together.

One critique of the original Agile approach was that it was too focused on the individual team. Somehow, we need to scale up this concept to fit larger organizations. In a larger organization, you will have multiple teams or squads, organized within larger units, “tribes”, or programs in a project-based organization. You can use Reconfig to make sure that you set up a logical grouping of different teams within larger units. 

Finally, even in an Agile organization, not every part needs to be flexible, in most organizations, there needs to be a combination of stable and moving parts. Reconfig supports this by making sure that you can filter and optimize the organizational structure based on work processes or functions. And the algorithm is set up so that it will customize the design of the organization to each unit, rather than imposing one design principle to all units independent of how they work.  

If you’re interested in learning more about how to design an agile organization effectively, visit our web page at https://www.reconfig.no where you can download a white paper or request a demo that explains the key principles behind it.


Dealing with Structural Imbalance

I once worked with a medium-sized oil services firm (i.e., a supplier to oil companies) that seemed to have an “unbalanced” organization structure. The official organization chart looked something like this:

…but in reality, one business unit was far larger than the others and was viewed as a “state within the state”. So if we were to draw the units according to size, the organization chart would look more similar to this:

I was reminded of this case because I am interacting with two different organizations right now that have a similar issue.

But does it really matter whether an organization is “balanced” or “unbalanced”?

The members of the large unit can claim (and rightly so) that their unit is big because it’s successful! They have probably been able to grow in size because they have been doing the right things! So why should they be penalized by being forced to split into smaller units and accept positions with less responsibility?

Well, I hear that, but structural imbalance does represent a cause of concern and it is the responsibility of the leader of the organization to make sure that the system, and not only the parts, are optimized.

There are at least two potential challenges. The first is political: Size equals might. A large unit can come to dominate the internal agenda-setting and decision-making processes. In the management team, the executive vice president who is responsible for 70% of the revenues is likely to have more power and influence than the three colleagues who represent 10% each. The other units may be small today, but may also represent emerging businesses that one need to support.

There is also a tendency that the performance criteria of the large unit dominate the entire organization. So if the largest unit (or practice group) in a project management firm is measured on, say, hours sold, it is typical that all other units are also measured on this KPI, no matter what they do (the other units might perform more specialized services that should be measured on other indicators, such as the hourly rate charged and profitability).

The second challenge is duplication. In the oil services firm I mentioned above, the large business unit had its own staff functions (e.g., Finance, IT and HR), duplicating similar staff roles at the corporate level. This was not only costly in terms of the extra positions, but created an additional need for coordination to align policies at the corporate and business unit level.

In addition, letting a unit grow into a large and monolithic structure may not be the best solution when it comes to resource sharing across different units in the organization.

So how should we proceed? The solution will of course depend on the circumstances, but I would suggest a couple of things that we can do to better understand the current situation and evaluate the future options.

The first is to look more closely at what the teams or sub-units within the large unit actually do. To what extent are they dependent upon each other? In other words, we need to consider the work processes and the interdependencies. Similarly, to what extent do they work – or to what extent should they work – with teams in the other units? The results of such a mapping may look like the image below.

If the teams are relatively independent of each other internally, yet strongly related to teams in other units, you should “disaggregate” the large unit and find a new grouping that reflects the work processes. On the other hand, if you observe that the teams are strongly related internally (within the large unit), with few synergies toward other units, it might be an argument for spinning off the large unit into a separate organization.

In either case, you may use our tool Reconfig to do this kind of analysis 😊.