The second meeting of the European Organisation Design Forum (EODF) took place on May 10-12. It was hosted by Nestlé at their headquarters in Vevey, Switzerland.

The overall theme was “dealing with dilemmas in organization design”. We explored this topic in a group session the first day, where we talked about dilemmas that we had observed or were struggling with ourselves. Many of the dilemmas that were identified had to do with how we conduct re-design processes. Here are some from a group I facilitated:

• Balancing the need for speed with the need for participation and involvement in re-design processes
• “Habits versus desire” – design is about stepping outside and looking in new ways at how you work and are organized, but any new insights must also be integrated into everyday routines in order to have an effect
• The change needed to make a new design work may consist in introducing new ways of working – but could also mean stopping old ways of doing things!
• The way we draw a new design may look simple – but it should support the performance of complex activities.

I held a session myself (together with Mark Lascola)  where we addressed the dilemma “integration versus separation”. The idea was to say something about when you should integrate roles or sub-units into larger units, and when you need to separate roles or sub-units – a classic topic. The slides I used are included below and give three reasons for separation. Of course, this is only one part of the story – I was followed by Mark who explained why and how one should integrate. We then gave the participants some brief cases to work on to try out these principles.

What you see above is an incubator made from car parts. The concept was developed by Design the Matters, a non-profit organization in Cambridge, Massachusetts.

The key purpose is to help reduce the number of pre-term babies that die during the first month in the developing world. Ordinary incubators are too expensive for rural clinics in poor countries. Sometimes incubators are donated to these clinics, but research shows that up to 98% break down within five year. In many cases medical equipment is not being repaired, as the components are not available locally and the technical staff lack the required training to carry out these repairs.

So a group of engineers at Design that Matters came together and asked themselves how to address this problem. They started with field research in developing countries, interviewing medical staff, maintenance staff, as well as parents of newborn babies.

They saw many examples of discarded medical equipment, but also asked: What does get reliably repaired in rural communities? The answer was that cars do get fixed, and cars may contain up to 40,000 components that are delivered reliably to even the most remote community. So why not build an incubator of car parts?

You may be familiar with this story already, and you might ask: What does it have to do with organization design? Quite a lot, I would argue.

The story is basically about matching the complexity of your design with the capability of the organization. This is as important in organization design as it is in product design.

Particularly when organization re-designs are triggered by strategy processes, there is often a risk that new models are selected that presupposed capabilities that the organization simply do not possess.

When I did a series of interviews with leaders of large firms in 2010, I was told of three cases where an organization had restructured, only to find out later that the design simply did not work, and then had to reverse to the old structure again. In each case the key cause seemed to be a failure to understand the capabilities (both technical and human) required to make the new design work.

I am not saying that you shouldn’t be bold sometimes – we should always think about new and better organizational models for our organization. Nor can we can eliminate risk altogheter. But with a little bit of preparation we can minimize these kinds of risks.

If you are an executive, a consultant, or internal project manager working on a new design for the organization, do what the engineers in Boston did: Go out in the field.

Don’t sit in the board room with only a few select managers drawing boxes and reporting lines.  Ask people on the frontline about what works and what does not work. Ensure that you understand the effect of the organizational structure on operations and IT. Consider the required behavioral changes that are necesssary for a new model to work.

As I argue in my recent book, the goal should be to find the simplest design. Develop alternative models. Evaluate the alternatives against each other and – other things being equal – select the model that is the easiest to implement given your current organizational capabilities.

Related post:

How many pages to you need to explain your organizational model?

My son of 9 years took this photo during a family walk the other day, and I thought it might serve as a metaphor for the concept of Design Rules (or Design Propositions, as I call them in my book).

The organization design field – as most other management disciplines – is divided into two camps – the academic and the managerial, on each side of the fence.

Many of the books written for managers are of the “guru” type where a new and revolutionary solution is proposed, with little regard for evidence or data to support the claim.

Academics, on the other hand, mainly write articles for each other, often to resolve a theoretical problem instead of addressing a business challenge. How, then, are we to develop useful knowledge – knowledge that can help us improve organizations?

The concept of Design Rules was proposed by Dutch professor Georges Romme (building on the work of another professor in the Netherlands, Joan Ernst van Aken). Romme sees Design Rules as a device that can help bridge the division between theory and practice.

The key idea is to express research-based knowledge as practical action principles for addressing a given problem or challenge in an organization. Example: Imagine that academic research concludes that global firms that are decentralized are more profitable than those that are centralized. This can be turned into a design rule by stating that

“if you lead a global firm and is considering its structure, to maximize profitability, select a decentralized structure”.

A key element is that design rules should be both actionable and testable. “Actionable” means that a manager or employee in an organization should be able to implement it, and “Testable” means that it should be possible to find out whether the principle leads to the intended effects or not.

To be actionable, it has to be fairly specific. My example above is probably too vague – do we mean that all functions should be decentralized, or only some (e.g., marketing, sales)? Do we mean that this principles applies to all firms, or only firms in some industries (e.g., consumer goods)? Do we by “decentralization” mean to move people into regions, to transfer decision rights, or both?

Ideally a design principle should also be accompanied by a tool that a manager can use for assessment, in this case, for example, it could be a tool or framework to assess how centralized or decentralized a unit in the organization actually is, data comparing different firms in a given industry, or guidelines for implementing more decentralized structures.

To be testable, we have to have some system for following up the implementation. Design rules are a starting point for learning – if we manage to feed back information about the effects and then revise the design rule based on our experience.

In this manner, design rules are like the ladder in the picture above because they allow us to go from theory to action, and back to theory again.

In my book there are 72 design rules alltogether. I am considering how to make them available to more people. One possibility may be to create a wiki where the design rules could be described and where practitioners could suggest (or make themselves) edits and changes. Let me know if you have any thoughts about this.

Related post: 

Developing a new applied science for organization design

But I hope you agree that the long maturation time has led to a decent end result. My goal has been to write a book people that both business people and students (and their professors) will approve of – readers will surely let me know whether I have succeeded or not.

In this video I explain why I wrote the book and some key key features of it. You can view the detailed chapter structure here.

The video lasts for about 6 minutes.

The slidecast lasts for 14 minutes.

This presentation deals with the key topic of my new book that will be released next week. The book provides an analytical and data-based approach for analysing complexity and developing simpler organizations designs.

If you are a manager, consultant or academic interested in this topic, I hope you’ll consider joining us. See below for more information. Click here to register.  (If you are based in North America, take a look at ODF or Global organization design society in Canada)

I am writing this on my way back from Brussels, where I attended a workshop convened by Richard Burton (pictured above) and Børge Obel, two leading academics.

They are the initiators of a global community of scholars, consultants and executives who are interested in developing better approaches for designing more effective organizations.

One important driver is a growing dissatisfaction with current organizational theory, which has become an increasingly irrelevant discipline.

Few managers are active users of academic research, which is not surprising, since academics have few incentives to produce research that is viewed as relevant.

To give just one indicator of the gap between research and practice, take a look at the chart below. In one survey, only 1% of HR managers reported that they were frequent users of academic research.

This result can be compared with similar studies of research utilization in other professions. One study in Canada among physicians (both general practitioners and specialists) found that 82% had downloaded one or more scientific articles from an internet database during an 8-month study.

What Richard and Børge are talking about is the need to create a new field, a field that has an impact. Here’s how they formulated the purpose of the workshop that I attended:

Today’s complex, dynamic, and highly interconnected global economy has made the ability to design and redesign organizations critically important (…) the field of organization theory and behavior has failed to deliver insights that can inform practice and guide change for desired outcomes and performance.

Organizational theory is important for the design knowledge base, but it is incomplete in content and largely silent on the process of design and change.

Organizational architecture, on the other hand (…) can be thought of as an applied science – a "scientific art"  – similar to engineering in the physical sciences or medicine in the biological sciences.

To achieve this status, we need to develop a theory for application, going beyond the current research focus in organization theory and incorporating many other disciplines.

A key initial goal is to ensure that there is a critical mass of people – the community currently has around 80 members but Richard and Børge are intent on increasing this number. They plan an annual meeting where members will be invited to present and discuss contributions. Another important element is the establishment of a new journal. The editor is Charles Snow, a well known US academic.

If you are interested in following the development of the community there is a Linkedin group where news and announcements are posted.

Related post:

Why are there no laboratories in business schools?

In this podcast interview we discuss how the Requisite Organization approach can be applied to address complex role/reporting issues. Paul Tremlett is a consultant with CORE International in Canada.

Before listening to the podcast, it may be helpful to take a look at the brief cases that I wrote last week and that we use as a starting point for the discussion.

Some of the things that we touch on are:

• Requisite Organization (RO) as a broader management system
• The combination of fundamental principles and situational judgment
• The importance of diagnostics in the organization design process
• Why it is necessary to do a full costing of a proposed structural model
• Why there are no “dotted lines” in an organization designed according to RO principles
• Why asking “who should report to whom” may not be the right question if you want to resolve role/reporting issues!

If you want more information about the Requisite Organization approach, take a look at the website of the Global Organization Design Society.

The first person out is Paul Tremlett, a Canadian consultant and member of a community of practitioners called the Global Organization Design Society. This community is devoted to the application and further development of the so-called Requisite Organization (RO) theory proposed by Elliott Jaques.

Jaques was quite insistent that he had found the right way to design the ideal organization. So I decided to challenge Tremlett to participate in a blog interview – and clarify: How can RO help us solve tricky role/reporting issues that we are confronted with in complex organizations?

Instead of discussing generalities I wrote two mini-cases and will ask him during the interview how he would approach the situations described. The cases are based on issues that we have discussed during my previous client engagements (to fit each example into one page I have simplified as much possible while trying to keep the essence).

You can read the cases below.

The interview will be posted here in about one week’s time.

• Who delivers what to whom
• Who collaborates with whom
• Who lends resources to whom
• Who decides what

A real example – drawn from an internal document – is shown below. This is an attempt to clarify the roles in a major UK bank. My first impression was that it seemed like a rather good example of how one could clarify the roles of an organization. When there is confusion with regards to roles and responsibilities, managers and employees usually welcome efforts that can help clarify who is responsible for various decisions and tasks. A matrix like this may be a good pedagogical tool.

But when examining the document a bit more closely, I noted that the matrix contains no less than 245 cells (5x7x7) as the responsibilities (“Approach”, “Inform”, “Advice”, etc. along the top) depend not only on the particular phase in the sales process but also on the channel and product. The accompanying Word document explaining the logic of the chart shown above runs to more than 60 pages. And we are still only talking about one of the issues mentioned above – who decides what. I assume that it would require several hundred pages to fully describe the organizational model of this bank.

One may wonder whether employees are able to internalize and enact a model that is this complex. If nothing else, it is hard to communicate a model that have a lot of contingencies and exceptions to a general rule (“Unit X is normally responsible for customer contact, but if it is a segment B client requesting service 1 for Region 2, then Y is responsible, and if it is a segment C client requesting service 2 in Region 3, then Z is responsible, except when the client already has a relationship with X…”).

In my experience, a better approach is to start by looking at the overall organizational model and consider whether it can be simplified. Are goals in conflict? Are there overlapping unit mandates? Does the formal structure match the work processes? Do we know who’s the internal client, and who’s the internal supplier? If the overall model is clear, logical, and simple, there’s usually less of a need for detailed specification at lower levels.

I am not suggesting that one should practice “simplification by ignorance”. Complexity will not go away by refusing to describe it (for example, by only presenting a new organization design by means of an organization chart showing reporting lines, leaving out other important aspects, and asking employees to find their way through the maze one has created.) If it really takes 60 pages to describe roles and responsibilities in your organization, that is the number of pages you should use. But if you have a choice between two models, one that can be explained in 10 pages and one that requires 60, select the former.