Cookie Consent
By clicking “Accept”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.
Sweden’s new train and rail management system has recently been plagued by a series of issues, resulting in significant disruptions and delays of trains in southern Sweden and to Denmark. Unlike the previous system, the new software lacks the ability to reroute trains, leading to prolonged standstills across parts of the train network if a single train stands still. While I lack insights into the specific development process that leads to this situation, the problem at hand is a familiar one. It is not uncommon for these types of problems to appear with a root cause in the decision-making approach employed, wherein software functionality is determined from the top without a deep understanding of the actual work performed on the ground. I especially remember a development project being demonstrated for the end-users after two years of development and then put into the trash bin because it simply could not be used in the end-user’s context despite all business requirements being fulfilled. Nobody in the development team had any contact with the end-users during the two years and this turned out to be costly for the company. In this blog post, we delve into the consequences of top-down decision-making on functionality in complex systems where developers lack access to the end-users that are the ones handling problems with a high degree of complexity.
In many large organisations, top-level management tends to apply principles of Taylorism, a philosophy derived from Frederick Taylor’s scientific management principles. This approach seeks to streamline operations by prescribing standardised procedures and centralised decision-making. While Taylorism may work well in simpler, linear systems, it often falls short in complex environments, such as the intricate workings of a train system where multitudes of different problems can occur in different places on different trains for different reasons.
A simple example of where Taylorism works well is a pile of dirt piling up regularly in factory and needs to be moved to another location. You measure the average of time it takes for the dirt pile to become a certain size and then optimise the move by acquiring an appropriately sized wheelbarrow and create a schedule for the dirt pile to be moved. The process is optimised, and the dirt pile efficiently moved. But when you have a system where the number of possible issues is too large to determine the right cause of action beforehand, the Taylor approach falls short.
The decision-making process regarding software functionality must involve a thorough understanding of how the work is carried out at the operational level. In the case of the train management system, the lack of insights into the complexities of train operations and deviations has seemingly resulted in a software system ill-equipped to handle unforeseen challenges. By excluding, or lacking the ability to include, the expertise and experience of those working on the ground, crucial knowledge and problem-solving capabilities have been left out of the system from the outset. I have seen several examples of developed systems where the responsibility to decide how a problem should be practically solved is taken from the people solving the problems to the people writing requirements on the system and it never turned out great. If the people writing the requirements are not familiar with the complexity at the bottom, then the system risks lacking the support of handling complex problems in an efficient way. Alan Holub elegantly summarized one of the key points behind the success of Toyota making and underperforming factory to a top performer: “The decisions need to be made at the place where the work happens”. When a competitor took the same process and applied top-down in one of its own factories it simply did not work since small differences can make problem solving different in different contexts and people were not empowered to solve the problems.
In complex work environments the decision-making of how the system shall work must have a tight collaboration with the people performing the work. By involving front-line workers, who possess valuable domain knowledge and hands-on experience, in the decision-making process, organisations can tap into their expertise to develop solutions that address real-world complexities. It also empowers employees and allows for the incorporation of essential elements like the ability to reroute trains during issues, leading to a more robust and adaptable system.
Complex systems require resilience and adaptability to function effectively. By adopting a bottom-up approach to decision-making of how a system shall function, organisations can foster a culture of continuous improvement and problem-solving. This approach encourages the development of specialised knowledge, equipping the system with the ability to handle a variety of deviations and complex problems. When decisions are made closer to the ground, they are more likely to be informed by practical realities and possess the flexibility needed to navigate unexpected challenges.
Instead of relying solely on requirements handed to developers from the top, the developers should also spend time with the bottom. If a developer sits together with a person that is performing the work, you have a powerful combination of expertise. Software can be created with a good fit to requirements while maintaining the ability to solve the complex issues that might occur. You can think of it as a version of the “whisper game”: One person whispers an initial message into the ear of one person who whispers the perceived message into the ear of the following person. Typically, after five or six steps the message is typically scrambled and is no longer close to the initial message. The same things happen in organisations; imagine an initially expressed need is conveyed from a person working with routing trains all the way through management and procurement to development departments before ending up in front of a developer. The risk is high that the message is scrambled, or simplified to lose all intricates, but sitting together will close the loop the risk of developing the wrong thing is significantly lowered. Did the developers of the train management system get to sit down during development with the people who handles rerouting to better understand their needs? I don’t know. Judging by the results however makes me willing to bet that they did not.
Top-down decision-making of how software is supposed to work in complex work environments without understanding how the bottom handles problems a risk is introduced. Lacking a process to tap the knowledge and expertise of front-line workers, organisations risk developing systems that are ill-suited to handle real-world complexities and deviations. To build resilient and adaptable systems, decision-making processes must be decentralised, empowering employees, and tapping into their invaluable insights. By doing so, organisations can create software systems and operational procedures that are better equipped to handle the challenges of complex work environments, ensuring smoother and more efficient operations for the benefit of all stakeholders involved.
Martin Nilsson is a MS.C. EE with a master in Complex and Adaptive systems. He has been working with software quality for over one and a half decade. Today he consults companies with building better software quality trough better processes and better ways of working.
