Leverage points for technical debt management

Last updated on July 10th, 2021 at 07:17 am

McMurdo Station, Antarctica, as seen from nearby Observation Hill
McMurdo Station, Antarctica, as seen from nearby Observation Hill. The United States Antarctic Program, a unit of the National Science Foundation, operates the station. It can house as many as 1258 people in Summer. Photo (cc) Gaelen Marsden courtesy McMurdo Station in Antarctica.

Adopting a technical debt management programs entails significant organizational change. The problem can seem so daunting that we don’t know where to begin. The places to begin are the places where the change agents have greatest leverage—what systems analysts call leverage points. Consider this scenario:

You’re sitting in the kickoff meeting of the new Technical Debt Management Task Force. The CEO is talking about how she realized that the company had a technical debt problem. It was when the Marigold project went through delay after delay, and was finally declared done, with multiple objectives waived. She’s saying something about, “we were trying to do backflips with millstones around our necks. So I want this task force to show us how to get rid of the millstones, and then get rid of them.”

OK, you think. But how? We’re a global enterprise with thousands of engineers and operations on every continent. Except maybe Antarctica. No wait, we’re there, too. McMurdo I think. We have software we don’t even know much about, acquired long ago along with the companies that built it. And we’re building new systems or modifying old ones all the time, trying to move everything to the cloud while enhancing data security. Where do we begin to look for the millstones of technical debt?

Have you been in that meeting? If not, can you imagine being in that meeting? Meetings like that are happening around the globe. We’re all in the same soup.

Leverage points: how to get rid of the millstones

It turns out that the answers to the millstone questions are available, but the pioneers and deep thinkers who have shown the way aren’t working on technical debt. Their field is called systems analysis. They work on problems like the collapse of the North Atlantic fishery, urban deterioration, unemployment, poverty, climate change, and the causes of the Great Recession of 2008—really difficult problems. Although the technical debt problem isn’t quite that challenging, it’s challenging enough to justify taking a look at the methods of systems analysis.

And when we do that, we immediately encounter a concept many call leverage points.

What are leverage points?

Leverage points are places in complex systems where a small change in one thing can produce big changes in system behavior. In a brilliant 1997 article, Donella Meadows describes what she calls “places to intervene in a system.” [Meadows 1997] She followed this article, making improvements each time, in 1999 [Meadows 1999] and 2008 [Meadows 2008]. Let me summarize Meadows’ work here.

To alter the behavior of a complex system, intervene at one or more of 12 categories of leverage points. For example, one category is called “Rules.” It consists of the incentives, punishments, and constraints that govern the behavior of the people and institutions that comprise the system. By adjusting the system’s rules, we can alter overall system behavior.

One more thing: the leverage points form an ordered hierarchy, ordered by effectiveness. Acting at a higher-level leverage point is more effective than acting at a lower-level leverage point. And more difficult, too. The ordering of the categories is a bit fuzzy, because every situation has its own quirks, but generally, the order is as given in the list below.

The twelve leverage points

In a moment I’ll give an example of using leverage point #9, Delays, to bring about change in the way the enterprise deals with technical debt. But first, here’s a brief summary of the leverage points in increasing order of leverage; not enough to truly understand what they are, but probably enough to pique your interest. As I write posts that illustrate interventions at these leverage points, I’ll link to them from here.

  1. Numbers: Constants and parameters such as subsidies, taxes, and standards
  2. Buffers: The sizes of stabilizing stocks relative to their flows
  3. Stock-and-Flow Structures: Physical systems and their nodes of intersection
  4. Delays in feedback loops
  5. Balancing Feedback Loops: The strength of the feedbacks relative to the impacts they are trying to correct
  6. Reinforcing Feedback Loops: The strength of the gain of driving loops
  7. Information Flows:  The structure of who does and does not have access to information
  8. Rules: Incentives, punishments, and constraints
  9. Self-Organization: The power to add, change, or evolve system structure
  10. Goals: The purpose or function of the system
  11. Paradigms: The mind-set out of which the system—its goals, structure, rules, delays, parameters—arises
  12. Transcending Paradigms

Delays in feedback loops

When we use feedback to control systems, and there are delays in the feedback, we can potentially create destructive system behavior. And that can happen when we try to control technical debt.

Whenever we try to control a quantity in an enterprise process, we must (a) set a target value for that quantity; then (b) measure its current value; and then (c) take action as appropriate to move the current value toward the target value. Systems analysts (and control theorists) call that arrangement a feedback loop. The action taken to move the current value to the target value is sometimes called the control signal. Under certain conditions, the feedback works as expected.

For example, to control the profitability of the enterprise, we can examine its net income, say, quarterly. And at the end of each quarter we can make adjustments if net income isn’t in the target range.

Feedback loops generally work pretty well, but under some conditions, oscillations can develop. One of those troublesome situations occurs when there’s a delay in the loop that’s of the same order as (or longer than) the time the system takes to respond to adjustments. Meadows uses the example of adjusting the water temperature of a shower when there’s a long delay between making the adjustment and feeling its effects. Overcorrection is almost inevitable, and that’s what causes system oscillation.

How controlling technical debt can create feedback loops

So let’s suppose that we’re trying to control the rate of accumulation of technical debt. One approach is to set a target for TDnew, the new technical debt generated in a project. To be fair to all projects, we decide to normalize this quantity according to the project budget B. So we set targets for each project’s N = TDnew/B, and we require that projects estimate N, on an ongoing basis, with a goal of having N in some target range when the project is complete.

Identifying technical debt isn’t straightforward

One problem with this approach is that we rarely identify accurately all the technical debt we’ve incurred until some time has passed after project delivery. With time, as the newly produced assets go into production and learning accumulates, we acquire the wisdom needed to identify more of the technical debt we created. This is one source of delay in this feedback loop.

So let’s assume that this happens for several projects, and management decides that delayed recognition of incurred technical debt is a common occurrence. To account for this, management lowers the target ranges for N for future projects. This causes project managers and project sponsors to include in their project plans additional effort directed at retiring more of their incremental technical debt before their projects complete, to enable them to project lower values of N. They must therefore identify as much of the incremental technical debt as they can, and retire it, to meet the lower targets for N.

How oscillations set in

But recall that technical debt identification sometimes requires time and experience using the newly produced asset. And the reverse process also occurs. Technical artifacts that we thought were technical debt prove to be useful in unexpected ways, and actually turn out not to be debt items after all. As a result, some of the incremental technical debt that got retired before the project was completed actually should not have been retired. Eventually, people realize that this happens with uncomfortable frequency, and so the targets for N are raised once more.

Oscillations thus set in. Long delays inevitably cause them. To prevent oscillations, shorten the delays.

How to shorten delays in feedback controlling technical debt

When we use feedback to control a system, delays in that feedback can lead to instability. Trying to control technical debt is no exception. With technical debt we can shorten delays in several ways.

  • If the asset is meant for human use, involve representatives of the user population in the development and design process as soon as practical. Have them exercise the asset, or prototypes, early. Listen to their suggestions. Observe how they use the asset.
  • If the asset must interact with non-human assets, exercise it early and often. Don’t think of this as testing, though it might look very much like testing. What you’re actually doing is searching for shortcomings in how the asset interacts with non-human assets, in design and implementation in an asset that already works.
  • Subject the asset to multiple reviews all along the development trajectory. Don’t wait for final release to review it.

These practices expose technical debt items early—potentially, during initial design—thereby reducing delays in identifying what is and what isn’t technical debt. They help to advance the date at which we uncover missing capabilities or capabilities designed or implemented in awkward ways. No surprise, I’m sure, but these practices are consistent with Agile approaches to technological development.

Indirect effects can add to delayed recognition of technical debt

Most of the argument above assumed that the incremental technical debt associated with the project was incurred within the asset undergoing development or maintenance. But technical debt can occur in other assets as well. When the development team is unaware of such “remote” or “indirect” incremental technical debt, recognition of that new incremental technical debt can be significantly delayed. The project’s N (the ratio of incremental technical debt to project budget) will appear to be smaller that it actually is, until that remote incremental technical debt is recognized.

This form of delay is likely to occur when the debt incurred is asset-exogenous. Recall the example of line extension of mobile phones. In that example, the enterprise incurs technical debt in one set of products as a result of the introduction of a different product. In some cases, the newly incurred technical debt is immediately evident. When it is not, delays can be substantial.

This effect is by no means rare. Any organizational change can potentially add to the technical debt portfolio—reorganizations, acquisitions, expansions, wholly new products, and much more.

Last words

Interventions at the leverage points of an organization can produce the changes we want with a minimum of effort. Some subtlety is involved, because Meadows’ leverage points are expressed at a high level of abstraction.  But applying them to the problem of technical debt management is a promising approach.

Bookmark this post. I’ll be linking to more examples of using leverage points to manage technical debt. So far:


[Meadows 1997] Donella H. Meadows. “Places to Intervene in a System,” Whole Earth, Winter 1997.

Available: here; Retrieved: June 28, 2018

Cited in:

[Meadows 1999] Donella H. Meadows. “Leverage Points: Places to Intervene in a System,” Hartland VT: The Sustainability Institute, 1999.

Available: here; Retrieved: June 2, 2018.

Cited in:

[Meadows 2008] Donella H. Meadows and Diana Wright. Thinking in Systems: A Primer. White River Junction, VT: Chelsea Green Publishing, 2008.

Order from Amazon

Cited in:

Other posts in this thread

Technical debt: monochronic and polychronic cultures

Last updated on July 7th, 2021 at 03:23 pm

A Simmental cow and calf
A Simmental cow and calf

In the context of today’s prevalence of global teams, the word culture evokes consideration of the differences between different national cultures. We think of the difference between Singapore and Latvia. Or we might also consider regional differences between Massachusetts and Texas. Or between San Francisco and Los Angeles. These differences are real. They do affect the way the inhabitants of these places deal with technical debt. But these cultural differences are topics for another time.

For now, let’s consider how a particular cultural attribute of teams or groups in organizations affects how they manage technical debt. Specifically, how we regard time correlates closely with our preferences, biases, and even the way we think about approaching technical debt.

How people experience space and time

Anthropologist Edward Twitchell Hall, Jr. (1914-2009) developed fundamental concepts for thinking about how we experience space and time. In The Silent Language [Hall 1973], he introduced the concepts of polychronic time and monochronic time. They represent two different ways human cultures relate to time.

People and cultures with a monochronic orientation (M-People) regard time as linear. M-People are most comfortable when they undertake only one task at a time. They tend to sequence tasks one after the other. Their motto is “Work on one and get it done.” When M-People must tackle more than one task in an hour, they divide the hour into blocks. They dedicate each block to one task. But time division isn’t always possible. When M-People work in groups, and when they must do more than one thing simultaneously, they divide their groups. Then each subgroup can focus on one task at a time. This is more or less how conventional (pre-Agile) project teams work.

People and cultures with a polychronic orientation (P-People) regard time differently. They define time more in terms of completed tasks than in terms specified by the hands of a clock. For example, a farmer might define time by what’s happening: it’s time for planting, for harvest, for haying, for canning, or for calving. Finer increments are also defined by what’s happening: it’s time for milking, time for breakfast, or it’s sundown or sunset. More than one thing can be happening at any given time.

Monochronic and polychronic orientations in organizations

In organizational cultures, the differences between monochronic and polychronic orientations are evident at every level of activity. For example, in a meeting of M-People, only one person has the floor at any one time. M-People schedule their agenda items, and after they move to the next agenda item, they don’t return. (Well, they do sometimes return, but they aren’t comfortable when they do) A meeting of P-People might have several people talking at once. They bounce from topic to topic as the discussion calls for it. M-People are very uncomfortable in P-style meetings; P-People are likewise uncomfortable in M-style meetings [Brenner 2018].

M-approaches can work just fine when we know in advance what the tasks entail. We can carve up our total work into pieces and address them one at a time, because they either don’t interact much, or because we can control their interactions. And we can partition the work across the available people and groups, each working on one piece of the effort.

And that has worked well for much of the work involved in producing and maintaining today’s complex technological assets.

But M-approaches can get into trouble when we work on something that’s complex or unfamiliar. When we don’t have (and can’t devise) a detailed plan of the work, dividing the work either by time or by task can be difficult to get right. To do this kind of work, we must depend more on interpersonal relationships and close teamwork than on scheduling and task partitioning. M-style approaches can flounder. And that’s where P-style approaches have big advantages.

In polychronic work styles, we’re more focused on accomplishments than schedule, because we don’t really know enough about the work to make a detailed schedule. In some instances, estimating how much work something might take is essentially impossible because we don’t understand the task in enough detail. We must then let events guide us, in the way the seasons guide the farmer. The people doing the work must adapt as they go, which requires strong relationships, tight collaboration, and trust.

Polychronic approaches might work better for technical debt management

And that brings us to technical debt management. We can address some kinds of technical debt with M-style approaches. We understand those debts and we know how working on their retirement will affect other work. But many forms of technical debt are so entangled with the rest of the organization’s efforts that P-style approaches are more likely to be successful.

For example, consider a project that’s aimed at retiring some kinds of technical debt. That might require access to assets that are critical to certain revenue streams. And suppose that ongoing work unrelated to retiring that technical debt might also affect these same assets. Coordinating all these efforts is complicated, even when we’re planning for only the next few weeks. But coordinating these efforts six months or twelve months in advance is probably impossible, because we can’t create schedules reliable enough to support such planning. The schedules of the various interlocking activities aren’t well enough controlled for that, any more than a dairy farmer controls the calving schedule. The cows control the calving schedule.

For many technical debt management activities, M-style approaches are simply unworkable. We cannot answer with useful precision questions like these:
  • What is the total cost this year to retire the technical debt of that kind?
  • How long will it take?
  • What would it cost if we retire that debt next year?
  • Will that debt retirement interfere with our plans for the rollout of the Marigold products next September?

Last words

Conventional project management might not work well for technical debt retirement efforts. Regarding technical debt retirement efforts as “projects,” with defined schedules, defined budgets, and defined staff assignments might be a serious error. Agile approaches, which are inherently more P-style, might work better.


[Brenner 2018] Richard Brenner. “Polychronic Meetings,” Point Lookout 18:1, January 3, 2018.

Available here; . Forthcoming.

Cited in:

[Hall 1973] Edward T. Hall. The Silent Language. New York: Anchor Books, 1973.

Originally published in 1959. Order from Amazon

Cited in:

[Meadows 1997] Donella H. Meadows. “Places to Intervene in a System,” Whole Earth, Winter 1997.

Available: here; Retrieved: June 28, 2018

Cited in:

[Meadows 1999] Donella H. Meadows. “Leverage Points: Places to Intervene in a System,” Hartland VT: The Sustainability Institute, 1999.

Available: here; Retrieved: June 2, 2018.

Cited in:

[Meadows 2008] Donella H. Meadows and Diana Wright. Thinking in Systems: A Primer. White River Junction, VT: Chelsea Green Publishing, 2008.

Order from Amazon

Cited in:

Other posts in this thread

Show Buttons
Hide Buttons