Most experts on organisation design or operating model design or enterprise architecture will tell you that you need to define your “design principles” or “design criteria” before you start developing solutions. The design principles tell you what “good” looks like. They help you narrow the range of solutions you should consider. They help you choose between alternatives. They help you keep aligned as you get further and further into the detail.

But how to get good design principles. Phrases like “lean and efficient”, “with the minimum number of layers in the hierarchy” or “more customer oriented” are common. But, in this form these phrases are not very useful.

There are two things you can do to help improve your design principles. First, try the negative. If the negative is not realistic, you have some work to do. So “not lean or efficient” is clearly nonsense, implying that this design principle needs some work. “Not customer oriented” is more possible. The opposite might be “product oriented” or “technology driven”. So, identify a negative or an opposite that makes some sense – showing that there is a real choice. Then consider all the points in between the opposite and the idea you started with. For example, the points could be “product oriented”, “product led, but with customer sensitivity”, “customer led, but with product experts”, “customer oriented”. This then raises the question where on this scale do you want your company to be. Often the answer is “Ah .. we want to move from ‘product oriented’ to ‘product led, with customer sensitivity’. We don’t want to lose our product leadership.” This then becomes the design principle. Much more useful than the simple sentence “customer oriented”.

For the phrase “lean and efficient”, the scale might be “committed to superior technology” at one end and “lean and efficient” at the other. It might also be “committed to customer needs” at one end and “lean and efficient” at the other.

With each scale you are trying to articulate a real strategic choice. This helps you avoid producing platitudes.

Once you have chosen a scale for each design principle and a point on the scale, you then need to ask the question why. In fact you may need to ask this question a few times: the five whys. You want to become as clear as possible about why you are choosing this point on the scale rather than the other points on the scale. These reasons why will be really helpful to you when you are facing tricky design compromises.

Finally, you need to ask your self what the implications of the design principle are. If the design principle is “product led but with customer sensitivity”, then the implications might be things like:

– Some people taking a customer perspective who have influence on product development and customer experience

– Some research into customer needs and customer experience

– Some segmentation of customers

Following this way of refining design principles, it is also useful to summarize each design principle in a table that has three columns

Design principles and design criteria, let me add design requirements to increase confusion.
If you look at structure in general, one can wonder what are well designed structures? Would you need principles, criteria or requirements to answer that question?
I say: principles, so these must be generic, and not specific for a specific organisation. E.g. Lean would say a good structure has independent flows, QRM would say a good structure is made out of autonomous cells.
The requirements are dealing with ‘what should the result of design help accomplish’ for THIS organisation. Organisations should create kinds of value for the stakeholders they have. This implies that current structure doesn’t help meeting the goal of effectively and efficiently delivering value. So, one can compare current structure with some designed alternatives, and for each requirement explain why the new design is helpful.
The criteria remind me of Multi-criteria decision-making. When you make such a matrix the requirements should be part of the criteria, but there may be additional aspects that influence the choice, e.g. cost of implementation, ease/leadtime of implementation. etc.

I think it is clearer to distinguish between principles as OrgDesign-general, and criteria & requirements as organisation-specific …. (which is not the case in the blog above)