This blog post is inspired by a fantastic paper by Fred Mear and Richard A. Werner. Mear and Werner argue that the adoption of the subsidiarity principle (SP) is the reason for the high performance of various organizations. The SP states that in any organization problems should be solved on the lowest possible level. According to Mear and Werner, this principle was adopted by the Prussian army in 1812 and they claim that it was a major factor in Prussia’s success on the battlefield in the 19th century. The SP was implemented in the army by giving a task which was in line with the general goal of the army to an officer but leaving it up to him how to reach it. This is beneficial, because the central strategists of the army cannot predict every situation and in contrast to them the officer on the front line is acutely aware of the current situation. The Prussian army accepted that chaos was inevitable due to the infinite variety of combat and hence used directive command which focussed on overarching goals while giving operational flexibility to the local units. Mear and Werner quote the Prussian chief of the General Staff, Helmut von Moltke the Elder, who explains the principle as follows:

The situations under which an officer has to act on the basis of his own view are diverse. It would be wrong if he had to wait for orders at times when no orders can be given. But his actions are productive, when he acts within the framework of his senior commander’s intent. It is absolutely necessary that subordinate headquarters recognise the object of what has been ordered. This enables them to strive for that object even if conditions make it necessary to act differently from what has been ordered.

Mear and Werner list the following advantages of implementing the SP in an organization:

  1. Shorter reaction time to changes as local decision makers (LDMs) don’t need to wait for instructions.
  2. Improved motivation as LDMs are empowered.
  3. Better total performance in achieving the overall goal.

According to Mear and Werner not only was the SP a key factor for the great performance of the Prussian army in the 19th century, it was also one of the reasons for China’s enormous economic boom after 1978 as Deng Xiao Ping decentralized decision making structures. Furthermore, they argue that the success of the many small and medium enterprises (SMEs) in Germany can be explained by the SP as well. They cite a paper by Rammer and Spielkamp who claim that the key advantages of these highly successful and innovative SMEs are the flexibility and speed with which new opportunities are seized – something only possible with decentralised decision making and small hierarchies. Mear and Werner also cite further papers which reinforce this point: SMEs are successful because they grant autonomy to their staff and have decentralized decision making. However, they also point out that this principle requires a higher level of training for every employee. Otherwise, the LDMs cannot make good decisions. In addition, promotions in an organization following the SP have to be based on merit rather than on seniority or connections. Otherwise, motivation will suffer.

Mear and Werner make a compelling case for the SP and they also have the empiric evidence to back up their claims. If you’re interested in these details, take a look at the full paper. It is a great read. But what does this mean for software development? Well, the paper clearly shows that localized decision making is preferrable to central decision making. That implies that we should empower development teams as much as possible to make their own decisions. Naturally, some coordination is required so that the overarching goals of the company can be achieved. Similar to how the Prussian army operated, managers should stick to directive command and let the people on the ground figure out how to exactly achieve these goals. Not only will this produce better results, it will also lead to greater employee satisfaction. Say, for example, that the currently most important company wide goal is to reduce the number of support requests raised by customers as they are taking up so much time. In a slightly bigger software product, the customer will raise support tickets in different areas of the product for different reasons. For example, one component might be buggy, while another one actually works fine, but is very difficult to use. Hence, it doesn’t make sense to explicitly tell the teams what they are supposed to do to reduce the number of tickets. Instead, they should have the freedom to figure out for themselves what will work best in their area. Also, making decisions locally helps the organization scale better. Anything which is done centrally is in danger of becoming overwhelmed when the company grows quickly. If the teams can handle everything locally, then this won’t be an issue.

Of course, making the decision on what is best for your area requires skills. The LDMs need the skills to assess their current situation and to come up with the correct response to meet the company goal. They need to be accustomed to thinking and deciding by themselves instead of relying on someone else further up the chain to break everything down for them. Hence, we need competent and well-trained employees and implementing the SP may require a lot of employee upskilling.

While local decision making has a lot of advantages, how can we ensure consistency? For example, how can we make sure that our software has a unified look and feel in such a setup? Customers neither know nor care which team has implemented a feature, they expect a seamless user experience. Rather than using a central team for this, my recommendation is to use knowledge sharing and communication to address this issue. If there is a knowledge base on how to correctly handle user interaction, then each team can use the documented best practices. In the end, the software should behave more or less the same even though there was no central coordination. Formal standards can also help here, but we need to be careful not to go overboard. Teams should always have the option to overrule a standard if they think that it makes no sense in their area. Also, central approval processes should be avoided. These tend to become bottlenecks and can cause a lot of frustration if expectations between the local teams and the central team aren’t aligned. A unified user experience can be reached even with a high degree of local decision making as long as it is clear to everybody involved what should be done and why it creates value.

It is also important to note that the SP requires the leaders of the company to trust their subordinates. It cannot work if managers feel the need to micro-manage and hence isn’t the right fit for a low trust company. If the company is organized in accordance to the SP, then leaders should limit themselves to strategy and people management instead of operational details. Both of these tasks are difficult, especially because the SP only works in a highly skilled and motivated workforce which isn’t easy to create in the first place. Also, the SP can only work if the employees are also willing to accept the extra responsibility. It can be very comfortable to offload all the hard decisions to the managers and this will no longer be an option once the SP is implemented.

It is noteworthy that the big hype around micro services during the last couple of years can also be seen as a drive to get the SP implemented via software architecture. After all, if every micro service is owned by an individual team, it is guaranteed that only this team will make the decisions. Obviously, there is more to micro services than that, but it is an interesting correlation nevertheless.

To sum up, the SP has proven itself for hundreds of years as a superior way to structure organizations. We should embrace it in software development as well. If you liked this blog post, please share it with somebody. You can also follow me on Twitter/X.