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?

I am not thinking about how many pages or slides you need to show the “boxology” – that is, who reports to whom – which usually requires only one page.

What I am thinking about is the number of pages you need to explain:

• 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.

It’s hard to communicate a model that has 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…”).

A better approach is to start by looking at the overall organizational model and consider whether it can be simplified.

So we should ask ourselves: 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 we 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 we have 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.