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:
Dear Nicolay,
I whole-hearterdly agree with you on this, wanting to promote better communication (and understanding) between theoreticians and practitioners of management. However, without having read your book and the 72 design rules, I have to say that I think 72 rules are too man–unless you have integrated them somehow in a digestible number of groups. And I hope you have a very good index 🙂 !
Jaana,
thanks for your comment and encouragement. Yes, the Design Rules are grouped into sub-groups. Basically I follow the format suggested by Georges Romme, I start with an Objective, and for each objective, there are 1-3 proposed Design Rules (propositions). As an example, if your objective is to improve the interface between two sub-units, there are five main design rules (not 72!), which are intended to be falsifiable (ie testable), in the sense that if you reach the objective in some other way, something must be wrong or missing – an occasion to revise the design rules.