12 Leverage Points to Intervene in IT Organizational Systems

As a self-proclaimed “systems thinker”, Donella Meadows has given me quite a lot to think about.

The twelve leverage points to intervene in a system were proposed by Donella Meadows, a scientist and system analyst focused on environmental limits to economic growth. The leverage points, first published in 1997, were inspired by her attendance at a North American Free Trade Agreement (NAFTA) meeting in the early 1990s where she realized that a very large new system was being proposed but the mechanisms to manage it were ineffective.

Below, I have taken Donella’s 12 leverage points and tried to relate them to my context (an IT organization). I have tried to create IT-based examples and only slightly altered the original leverage point itself. The list is in increasing
order of effectiveness.

12. Constants, parameters, numbers (such as standards, SLA’s, etc)
Parameters are points of lowest leverage effects. Though they are the most clearly perceived among all leverages, they rarely change behaviors and therefore have little long-term effect.

The basis for thinking around this dates back to Taylorism – scientific management, and management by visual numbers alone. In most cases its “diddling with the details”. Many of the important issues a company faces cannot be measured (Deming) like the impact of an unhappy customer, or the multiplying effect of a happy one.

That said, it’s not that parameters aren’t import. They can be, especially in the short term and to those standing directly in the flow. People care deeply about parameters and fight fierce battles over them. If a system is chronically stagnant, parameter changes rarely kick-start it. If it’s wildly variable, they don’t usually stabilize it. If it’s growing out of control, they don’t break it.

11. The size of buffers and other stabilizing stocks, relative to their flows
A buffer’s ability to stabilize a system is important when the stock amount is much higher than the potential amount of inflows or outflows. In a lake, the water is the buffer: if there’s a lot more water than the inflow/outflow, the system stays stable. Buffers can improve a system, but they are often physical entities whose size is critical and can’t be changed easily.

Luckily, in software development or a service organization, stabilizing stock might not be physical and therefore the ability to alter it is not a constraint. Tools like Kanban and visualized workflow can quickly show us constraints. Our ability to “batch” just enough stabilizing stock (buffer) can happen quickly and with relative ease.

10. Structure of material stocks and flows
A system’s structure may have enormous effect on operations, but may be difficult or prohibitively expensive to change. Fluctuations, limitations, and bottlenecks may be easier to address.

For example, the flow of finished product into a production environment might be constrained by a teams ability to deliver it without an automated means. Stabilization and flow would require the use of an automated deployment solution which could be costly, and inconvenient to build and maintain.

9. Length of delays, relative to the rate of system changes
Information received too quickly or too late can cause over- or under reaction, even oscillations.

For example, the team is considering building a data warehouse. The project will take 2 years to complete, and the solution will be viable for 7-10 years. The first delay will prevent data from being useful for the first 2 years, while the second delay will make it impossible to build a warehouse with exactly the right capacity.

8. Strength of negative feedback loops, relative to the effect they are trying to correct against
A negative feedback loop slows down a process, tending to promote stability. The loop will keep the stock near the goal, thanks to parameters, accuracy and speed of information feedback, and size of correcting flows.

For example, one way for an IT project portfolio to avoid becoming less and less useful as mass quantities of work bombard the system (and subsequent projects stop being completed) is to implement a simple governance process. As business owners regularly work with one another to force priority decisions and reduce the burden, the participant receive a direct benefit. This doesn’t happen simply by “slowing their requests to IT”, but actually reducing their requests to a level appropriate for IT teams to absorb effectively. The participants cannot benefit from “doing damage more slowly” – only from actually helping.

7. Gain around driving positive feedback loops
A positive feedback loop speeds up a process. Meadows indicates that in most cases, it is preferable to slow down a positive loop, rather than speeding up a negative one.

The “calcification” of an IT ecosystem is a typical feedback loop that goes wild. Through mass contract hiring, lots of processes and projects can be supported. An increase in capacity will lead to an increase in projects and an increase in productivity of the system. More project productivity leads to more technology implementations, more technology (physical and virtual), more processes and activity, more IT support, etc. The more systems are built and managed, the more work is generated, and productivity increases. However, this technology sprawl begins to calcify as it is delivered onto production hardware. The more that’s delivered, especially that which is built with a primary objective of “quick and dirty”, the more complexity built into the system. The more complex, the harder it is to manage ongoing enhancements, and understand the nature of what needs to be enhanced. Over time, complex patches, dead code, contractors exiting firms and taking their knowledge, un-owned systems, and failed refactorings adds to the system calcification until many of those systems are near unsupportable. At some point, the IT delivery mechanism grinds to a hault, and IT staff work feverishly just to “keep the lights on”.

6. Structure of information flow (who does and does not have access to what kinds of information)
Information flow is neither a parameter, nor a reinforcing or slowing loop, but a loop that delivers new information. It is cheaper and easier to change information flows than it is to change structure.

An example is “visualization” of current work in the context of a system. Kanban methods are a good example, and so are scrum artifacts that tend to radiate information. This speeds the information flow to a much broader audience and can have a big impact on the actors in the ecosystem. In many cases, unimpeded flow of information lead to major change in the operation of the system. We humans have a systematic tendency to avoid the impact of our own decisions. That’s why so many feedback loops are missing – and why this type of feedback loop is popular with the masses, unpopular with the current powers that be, and effective when done.

5. Rules of the system (such as incentives, punishment, constraints)
If you want to understand the deepest malfunctions of a system, pay attention to rules, and to who makes them.

In an IT context, rule-making comes from many places (executives, HR, managers, regulatory authorities etc). In general though, the rules tend to come from the management structure that exists in IT. And, “rules” are a very powerful lever indeed (and they’ll always exist). There is a caution though, as rules tend to drive unexpected behavior. I like to believe excessive rule making as “lazy-leadership”. If there are behaviors I want, I offer incentives. If I want a behavior gone, I regulate. In almost every way, both of these tools miss the point, and tend to de-moralize behavior in the system. We drive people to do things for the reward, NOT because it’s the right thing to do. Or, we create a game to find the loop-holes.

4. Power to add, change, evolve, or self-organize system structure
Self-organization describes a system’s ability to change itself by creating new structures, adding new negative and positive feedback loops, promoting new information flows, or making new rules.

Lean and Agile philosophies derive much of their true power from this incredibly influential lever. The ability to evolve a system or subsystem with autonomy and self-organization cannot be understated. The IT community is still grappling with their new found autonomy (in the last 10-15 years), but those that have been given this power have made incredible progress over time. This capacity of part of the system to participate in its own evolution is a major leverage for change.

3. Goal of the system
Changing goals changes every item listed above: parameters, feedback loops, information and self-organization.

An organization might make a decision to change the goal of an IT staff, moving the operations and support functions out of the organization to a third party provider. That goal change will effect several of the above leverage points: information on SLA’s might go from loosely administered to contractual obligations (rules). Or, a IT organization might decide to go from an “order taking” function to a “technology steward” function, altering many of the above levers almost overnight. To be sure, a change in the goal of the system is a powerful lever in the intervention of an IT system.

2. Mindset or paradigm that the system — its goals, structure, rules, delays, parameters — arises from
A societal paradigm is an idea, a shared unstated assumption, or a system of thought that is the foundation of complex social structures. Paradigms are very hard to change, but there are no limits to paradigm change. Meadows indicates paradigms might be changed by repeatedly and consistently pointing out anomalies and failures in the current paradigm to those with open minds.

There exists a concept called double-loop learning, developed and popularized by Chris Argyris. By in large, the point of double loop learning is that, when faced with consistent failures of a system to reach it’s goal, we begin to challenge the goal itself, not the strategy to reach the goal. In single loop learning, if we fail, we “try-try again”. What if the current mode of thinking that draws us to this goal is fundamentally flawed?

A concrete example might go like this: IT is a service provider. We continue to be the best service provider and pay close attention to our customers needs. Whenever they ask us to deliver, we do it. We don’t ask questions and we don’t say no. And in doing so, we are fulfilling our primary purpose.

In this scenario, we have a belief system that says “we do what the customer wants”. What happens if we continue to try and make this model work, but it never does? Instead of coming up with another strategy to “deliver what they asked for”, maybe we should question the fundamental paradigm. Why does our IT organization exist?

1. Power to transcend paradigms
Transcending paradigms may go beyond challenging fundamental assumptions, into the realm of changing the values and priorities that lead to the assumptions, and being able to choose among value sets at will.

Many today see IT as a stock of resources to be converted to organizational services. Some firms believe that looking at IT as people that have needs, dreams, expectations, and a yearning to be challenged . These views are incompatible, but perhaps another viewpoint could incorporate them both, along with others. In essence, to keep yourself unattached, flexible, and to realize that no paradigm is “true”. Even the one that shapes your own world view is incredibly limited, almost laughable understanding of the true complexity.

I enjoyed Donella’s position, and I loved going through this exercise. It’s helped me organize my thoughts, and in a way, is something to come back to when I need to challenge myself. I will leave you with one final thought from her paper:

“Magical leverage points are not easily accessible, even if we know where they are and what direction to push on them. There are no cheap tickets to mastery. You have to work at it, whether that means rigorously analayzing a system, or rigorously casting off your own paradigms and throwing yourself into the humility of “not knowing”. In the end, it seems that power has less to do with leverage points than it does with strategically, profoundly, madly letting go.”

2 thoughts on “12 Leverage Points to Intervene in IT Organizational Systems

  1. Pingback: Jason Montague
  2. Pingback: Jason Montague

Leave a Reply

Your email address will not be published.