The Leverage Points in Engineering Ecosystems

Donella Meadows’ 12 leverage points applied to software engineering ecosystems

I’ve been interested in ideas from systems thinking and complexity for some time which tends to align with my personal characteristics of not getting too caught up in detail and wanting to make sense of the larger whole. I’m more of a generalist than a specialist, drawn to the novelty of new ideas and nuance rather than clinging to a black-and-white worldview.

I wouldn’t describe myself as a systems thinker, but someone who tries to have an appreciation of systemic complexities, realising the non-linearity of many aspects of our world, and realising that cause and effect are often more complex than we realise.

Systems and Complexity

It’s not easy to see how the parts of a complex system interact from a holistic perspective. We can never understand or model a complex system accurately, we can only really hope to appreciate its nature.

Societies, forests, human beings, and companies are all examples of complex adaptive systems. We may also think of coral reefs, ant colonies, the global economy, and social networks such as the internet as complex adaptive systems. Systems are everywhere.

Systems are composed of many interacting elements that self-organise to produce emergent behaviours, adapting and evolving in response to environmental changes. Teams of software engineers are complex adaptive systems too. We often see the role of a manager to take certain actions, like pulling levers, pushing buttons, or turning taps in their system of teams in order to produce desired results. But complex adaptive systems are non-linear, they’re not straightforward, and often the interventions of a well-intentioned manager (or a president/prime minister in the system of a nation-state) will produce unintended consequences.

We all exist in a world of complex adaptive systems and as the world gets ever more interconnected, interdependent, and ever more complex, it’s worth exploring systems thinking as a framework to help understand the nuances of our co-existence a little better.

Donella Meadows

Donella Meadows (1941-2001) has been hugely influential in bringing systems thinking to the masses through her book ‘Thinking in Systems’, published posthumously in 2009. This has been a popular choice as a systems thinking primer for those in software engineering who are looking for a more nuanced perspective on the many interdependent components within a software engineering ecosystem.

The 12 leverage points, outlined in her essay "Leverage Points: Places to Intervene in a System", offer a framework for understanding the levers we can use to influence complex systems, such as organisations, teams, or other social structures. Meadows’ framework suggests that not all interventions within a system are equally effective; some points offer greater leverage for creating lasting change than others.

She arranged the leverage points in ascending order of effectiveness, from the least influential to the most powerful. These points range from superficial tweaks, such as adjusting numerical parameters to altering the rules and regulations in a system, to deeper, more transformative actions, like altering the goals of the system or working with people’s attitudes and beliefs.

While the inspiration for her original essay was triggered by her observations at a North American Free Trade Agreement (NAFTA) meeting in the early 1990s, her essay was structured as a general framework for understanding and intervening in systems and so can be used for insights into the intervention points within a software engineering ecosystem that would provide the greatest leverage.

The 12 leverage points mapped onto a software engineering ecosystem will look something like the following.

Low Leverage Points: Addressing Symptoms

12. Constants, Parameters, Numbers

Parameters are fixed values within a system, like speed limits or temperature settings. Adjusting them often produces limited impact since they don’t address the system's underlying structure.

In software engineering, this could involve tweaking superficial metrics like lines of code produced, number of PRs, sprint velocity targets, number of unit tests, bug fix rates or error budgets in an SRE context. It would also apply to engineer wages. While these adjustments might offer some temporary improvement, they often fail to address underlying systemic issues.

Donella Meadows suggests that constants, parameters and numbers occupy up to 99% of our attention but there is not a great deal of leverage in them. “People care deeply about parameters and fight fierce battles over them. But they rarely change behaviour.”‘

11. Size/Stability of Buffers

Buffers are reserves that help systems handle variability or shocks, such as water in a reservoir or inventory in a warehouse. The size of a buffer determines how resilient the system is to disruptions, but making them too large can lead to inefficiency.

In a software engineering context, this could include things like the size of a development team or the amount of testing resources allocated to a project. It could also include server resources or storage capacity. Increasing these buffers might provide temporary relief, but they may not address the root causes of problems like inefficient processes or poor communication.

10. Structural Design and Intersections

System structures dictate how components interact and where bottlenecks occur. Redesigning these connections can influence the system’s flow and efficiency, but the impact is limited if the underlying culture or goals aren’t aligned.

In software engineering, this could relate to the architecture of a system or the organisation of development teams. We might choose a microservices architecture as a response to scaling challenges, without addressing team collaboration issues or an over-reliance on rigid matrix structures that hinder cross-functional collaboration. Meadows argues that while modifying these structures can have some impact, they are still relatively limited in scope.

While changing team sizes and structures may make some difference, it is better to do organisational design in the ways advocated by Team Topologies which also advocate for mindset changes and specific behaviour modes at the intersections of teams which activate the greater leverage points in the system.

Mid-Range Leverage Points: Influencing Behaviour

9. Feedback Loop Delays

Delays in feedback loops affect a system’s ability to respond to changes. Shortening delays improves adaptability and reduces the risk of overcorrection or instability.

In software engineering, this could involve adjusting the length of a development sprint, cycle times or the frequency of releases. We could also introduce continuous deployment pipelines that minimise delays between code commits and user feedback. Understanding how delays impact the pace of change within a software engineering ecosystem is crucial for optimising efficiency and responsiveness. An example of an overcorrection might be an overbearing manager chastising a team for poor performance at the end of a sprint, leading to further delays in the next sprint due to team resentment.

The yearly performance review is a very long feedback loop, it’s much better to ensure feedback happens in frequent 1:1s in order to avoid overshooting or undershooting performance targets. A lack of customer proximity will create inefficient customer feedback mechanisms resulting in the wrong product being delivered. Long-lived branches come with long feedback cycles, whereas small batch sizes delivered in a trunk-based dev environment result in quicker code reviews and tighter feedback loops. Likewise, long planning cycles may result in an overcapacity or undercapacity in skills and people resources.

8. Balancing Feedback Loops

Balancing loops are self-regulating processes that keep a system stable, like a thermostat maintaining room temperature. Strengthening these loops ensures the system remains healthy and avoids extremes.

In software, this could involve tightening feedback mechanisms like code reviews or user acceptance testing. Ensuring that these feedback loops are effective and aligned with desired outcomes is essential for improving software quality.

Balancing feedback loops are self-correcting forces in a system. A culture of promoting rest and relaxation after bouts of pressurised work is a self-correction mechanism to help avoid burnout. Regular pulse surveys, engineering culture surveys, and team retrospectives help to find opportunities for balance, just as our human bodies will sweat or shiver to bring about homeostasis in extreme temperatures.

7. Reinforcing Feedback Loops

Reinforcing loops amplify behaviours or effects, like compounding interest in finance. These loops can drive growth or decline depending on what’s being reinforced.

In software engineering, this could involve amplifying positive feedback loops like knowledge sharing, mentoring or collaboration within teams. Encouraging these behaviours can lead to a more supportive and productive environment.

Reinforcing feedback loops are contagious, like a virus. As acts of kindness are reciprocated through the system, so too can toxicity. Gossip spreads, but so does good-will. Both are powerful. Lack of care and attention to code quality can breed ever-mounting technical debt and a chaotic codebase, just as conscientiously ensuring the next person succeeds can ripple out across an organisation.

6. Access to Information Flows

Information flows guide decision-making and influence behaviour. Making critical information visible can transform how systems function by empowering informed actions.

In software engineering, especially when striving for autonomous teams, ensuring open access to information flows is crucial due to its impact on sensemaking, decision-making, and action-taking within a system. Transparency regarding team purpose, communication channels, progress, and challenges can significantly contribute to a team's effectiveness. This fosters a sense of ownership and accountability among team members, leading to a more collaborative and engaged work environment. We might also consider transparent salary bands to address equity.

The availability of information can foster desirable behaviours as Donella Meadows illustrates with a simple example:

“There was this subdivision of identical houses, the story goes, except that for some reason the electric meter in some of the houses was installed in the basement and in others it was installed in the front hall, where the residents could see it constantly, going round faster or slower as they used more or less electricity. With no other change, with identical prices, electricity consumption was 30 percent lower in the houses where the meter was in the front hall.”

In engineering terms we might want to expose information as described in the book by Dominica DeGrandis “Make Work Visible” which focuses heavily on exposing Work in Progress, hidden dependencies, unplanned work, and waste. Likewise, the observability of deployed technical systems leads to wider accountability in engineering teams.

5. Rules (incentives, punishments, constraints)

Rules shape the boundaries of a system and influence how its components interact. Adjusting rules can shift behaviours but must be aligned with desired outcomes.

In software engineering, this could involve establishing clear coding standards, development processes, ‘definition of done’, or policies regarding code ownership/stewardship. Behaviours will be highly influenced by an organisation’s use (or misuse) of OKRs, bonus and career advancement policies, and their approach to public rewards and recognition. The way that failures and missed performance targets are handled will also be highly significant. We might also consider restricting approvals to prevent bottlenecks (e.g., limiting required sign-offs or Change Approval Boards for releases).

The rules of operation for many organisations are laid out through legislation, which varies according to local jurisdictions. Legislative rules may restrict the use of some levers.

“If you want to understand the deepest malfunctions of systems, pay attention to the rules and who has power over them”

High Leverage Points: Transforming the System

4. Power to Change or Self-Organise Structure

Giving a system the ability to adapt its structure increases resilience and innovation. Self-organising systems can evolve to meet new challenges.

Empowering software engineering teams to set their own ways of working, define their processes, choose their tools and tech stacks, and experiment with new approaches cultivates a sense of ownership, agency and innovation. The autonomy, discipline, and reflexivity of self-organising teams allow them to adapt and respond more effectively to changing demands and challenges in uncertain business environments.

“The ability to self-organize is the strongest form of resilience. A system that can evolve can survive almost any change, by changing itself.”

Donella Meadows asserts the leverage power of systems that can experiment and evolve through their own self-organisation while cautioning against viewing one kind of culture as superior to another

“Insistence on a single culture shuts down learning. Cuts back resilience. Any system, biological, economic, or social, that gets so encrusted that it cannot self-evolve, a system that systematically scorns experimentation and wipes out the raw material of innovation, is doomed over the long term on this highly variable planet.”

She refers to the phrase ‘Let a thousand flowers bloom’ which implies a ‘letting go’ that few are comfortable with, which leaves this leverage point underutilised.

This leverage point aligns with the principles discussed in L. David Marquet’s ‘Turn the Ship Around’, and decentralised decision-making frameworks, such as those seen in DevOps or the Holacracy concept.

3. Goals of the System

A system’s goal drives its behaviour - the purpose or function of the system. Aligning goals with desired outcomes ensures that all components work toward the same purpose.

In software engineering, this relates to clearly defining the primary purpose of software teams and the goals of the projects they undertake, and ensuring that those goals are aligned with the overall aims of the organisation, is critical for high-performing engineering teams. Such goals could include shifting left on quality or security or a focus on outcomes over output. This shared connection to a meaningful purpose guides decision-making and prioritisation throughout engineering processes.

Perhaps the goal of an engineering ecosystem is to ‘Create the conditions in which engineers can make their deepest contributions’? If the system serves the engineers in this way, they will be better at serving the goals associated with organisational prosperity.

2. Mindsets & Paradigms Underpinning the System

Paradigms are the deeply held beliefs that shape how systems are understood and operated. Changing a paradigm can transform the entire system. This relates to people’s beliefs and attitudes about the way things should be, the hearts and minds that are so influential in a system.

Shifting mindsets and paradigms in software engineering can profoundly impact how systems are developed and delivered.

Examples include:

• Transitioning from Waterfall to Agile for flexibility

• Adopting DevOps to enhance collaboration and automation

• Implementing Domain Driven Design to align software architecture with business domains, fostering shared understanding and creating systems that accurately reflect real-world complexities

• Transitioning from project-oriented to product-oriented thinking

• Adopting remote and hybrid working environments

• The idea of the DAO which has emerged from Web3 thinking - The Distributed Autonomous Organisation

Donella Meadows asks:

“So how do you change paradigms?”

For her answer, she refers to Thomas Kuhn, who wrote the seminal book about the great paradigm shifts of science:

“In a nutshell, you keep pointing at the anomalies and failures in the old paradigm, you keep coming yourself, and loudly and with assurance from the new one, you insert people with the new paradigm in places of public visibility and power. You don’t waste time with reactionaries; rather you work with active change agents and with the vast middle ground of people who are open-minded.”

1. Transcending Paradigms

This lever is reminiscent of the idea of Teal organisations, as described by Frederic Laloux, representing an advanced stage of organisational evolution that is informed by thinking from a wide spectrum of influences, from the development theories of Clare Graves and Ken Wilber to various spiritual and philosophical influences, as well as influences from systems thinking and complexity theory.

In software engineering, this means recognising that no single methodology is universally the ‘best’. It involves cultivating a flexible mindset that remains open to innovative solutions, continuously learning, and encouraging emerging thinking, and combining and integrating methodologies to suit situational demands. Transcending rigid paradigms is the most difficult of all leverage points to utilise and can only occur in environments which actively support open thinking, dissent, and actively challenging the status quo. Such organisations are few and far between.

Donella Meadows’ words on the power to transcend paradigms liken the idea to a Buddhist enlightenment:

“There is yet one leverage point that is even higher than changing a paradigm. That is to keep oneself unattached in the arena of paradigms, to stay flexible, to realize that NO paradigm is “true,” that every one, including the one that sweetly shapes your own worldview, is a tremendously limited understanding of an immense and amazing universe that is far beyond human comprehension. It is to “get” at a gut level the paradigm that there are paradigms, and to see that that itself is a paradigm, and to regard that whole realization as devastatingly funny. It is to let go into Not Knowing, into what the Buddhists call enlightenment.

People who cling to paradigms (which means just about all of us) take one look at the spacious possibility that everything they think is guaranteed to be nonsense and pedal rapidly in the opposite direction. Surely there is no power, no control, no understanding, not even a reason for being, much less acting, in the notion or experience that there is no certainty in any worldview. But, in fact, everyone who has managed to entertain that idea, for a moment or for a lifetime, has found it to be the basis for radical empowerment. If no paradigm is right, you can choose whatever one will help to achieve your purpose. If you have no idea where to get a purpose, you can listen to the universe (or put in the name of your favorite deity here) and do his, her, its will, which is probably a lot better informed than your will.

It is in this space of mastery over paradigms that people throw off addictions, live in constant joy, bring down empires, get locked up or burned at the stake or crucified or shot, and have impacts that last for millennia.”

So Which Lever Should I Pull On?

Systems Thinking is more of a guide rather than offering a prescription. Donella Meadows’ leverage points offer a useful lens for appreciating and engaging with complex systems like software engineering ecosystems. However, systems thinking isn’t a rigid blueprint for change. It is a way to deepen our understanding of how interconnected elements may influence one another and evolve. The goal is not to dictate exact actions but to inform decision-making with a nuanced appreciation of complexity.

Donella Meadows’ perspectives can help us think about things when we are faced with a complex system. In doing so, we will be better placed to judge the potential effectiveness of an intervention. It’s worth remembering that high leverage points are the ones which are most resisted by the system so the difficulty of change increases as the potential impact increases.

Systems thinking invites us to remain humble, curious, and flexible as we strive to create environments where engineers can make their deepest contributions.