Leverage Points for solving complex problems

Adopting Donella Meadows' thesis to Product Management

It’s funny. As humans, and far worse as managers, we like to think that if we can fully understand the immutable laws of how and why things happen, then we can exactly solve, plan, execute and manage them. Yet a majority of new projects and products continuously keep running into delayed timelines, unforeseen dependencies and lack of resources. Why?

Did something go wrong with the planning? Or did we think about the problem statement itself in the wrong way?

Internalising complexity

Moving away from Systems Thinking to Complexity Thinking

Tell me if you’ve ever been in this situation.

In a meeting, all stakeholders decide to work on a problem. The problem itself looks simple enough. We just need to go from point A to point B by building X. But! But, when you step out of the meeting room into the real world and start diving into the problem you begin to discover a complex web of interconnected, often related, sub-problems and dependencies - complex relationships that need to be solved first before you can even attempt to go from A to B.

What happened inside that room was our human brains trying to establish a linear cause and effect relationship (not your fault, our brains are wired to take the path of least resistance). But that’s not how the real world works. In reality, the world is complex. It’s hard to establish simple cause and effect relationships in a linear fashion. “Let’s solve global warming by moving 100% away from coal.” - Sure, but then what about the millions of people you would leave behind in poverty in the developing world which can’t yet afford renewables?

It’s something start ups on their 0-1 journey face on a daily basis. A few months ago, at indiagold, our product team was given a clear objective - automate the assignment of field agents (our Loan Managers) to the customer’s home (think how Uber’s algorithm matches the right taxi with you). Hitherto, this exercise was done on excel by a few operations team members. Now the problem statement looks simple enough, right? We just need to go from A(the excel) to B(the automated scheduling). “Just remove the damn excel!” our co-founder would say.

I wish it was that easy!

Once we started diving into it - we discovered the sheer magnitude of complexities that can happen on ground. Now, a trained human can understand and respond to such complexities in real time (as inefficient as that is) but for a machine to do that - the use cases need to be programmed into it.

What if the agent suddenly marks itself absent or has to leave after 4pm for personal reasons? What if the customer cancels at the last minute when the agent is just about to reach? How to minimise overall company costs and maximise profits through efficient routing? What to do if the bank closes by the time the agent reaches the nearest branch? How to handle scenarios when the loan booking and disbursals are done on different days? What to do on weekends when banks are closed? I could go on and on, but you get the point.

Taking a reductionist linear path was clearly not going to work here given the complexities involved in field operations and the randomness of human behaviour. But neither would a purist systems thinking approach. We needed a different perspective - one that took into account all the chaos that exists on ground (and the internalisation that we can’t solve for everything together). That’s where unknowingly, which I now recognise in hindsight, we adopted Complexity Theory over Systems Thinking.

The difference between the two is subtle. As the author Jonathan Sapir in his book ‘Thriving at the Edge of Chaos: Managing Projects as Complex Adaptive Systems’ notes:

While Systems Thinking seeks to define an ideal future and then define strategies to “close the gap”, Complexity Science works with the evolutionary potential of the present, i.e. it seeks to understand the “now”, find out what can be changed (in a measurable way), and then take small evolutionary steps in a more positive direction without any assumption of the end destination. Systems Theory deals with “complicated” systems: there are input and output flows and straightforward cause and effect (as in machines) where the pieces can be understood in isolation and the whole can be reassembled from the parts.

Through the constant evolution of the scheduling system (the algorithm being one small component of it) we saw the efficiency of the operations (the full system) going up. Today our field agents on an average book 18X the number of loans per month than what they did a year ago. But if we were to look at that data point just 1 month after the first version of the algorithm was launched - that number was just 1.5X. It’s hard to directly attribute if there was 1 component or feature or sub system that drove this efficiency. Instead as we tackled all the complex relationships, and steadied our understanding of this complex apparatus in its entirety - the system as a whole began to become better.

There’s another difference between Systems thinking and Complexity thinking. Allow me to use an example - consider an organisation with various departments/ pods. It is a systems comprising of sub-systems. Each pod is given targets. The outcome here measured is at a component level. Now to chase those objectives, say one pod makes a change that has unintended consequences for another. That’s why at indiagold, we give pods overlapping OKRs. Unlike the radical holism of systems theory, complexity theory recognises that changing one part of the system can have unintended consequences overall.

I remember once our sales team made a small change in the parameters of the incentive policy (lever #12 as we will discuss later) - indirectly it impacted the way the Sales Managers used their app and consequently the entire lead management and loan booking system.

Unintended Consequences

It reminds me of the story of 12 blind men touching an elephant - each being right from their point of view but obstructed from seeing the full picture. Complex systems are much more challenging and different than just the sum of its parts.

Inability to view the system as a whole, a problem compounded by the view points of individuals

Once we internalise these real world complexities, we can then truly appreciate these levers that systems thinker Donella Meadows outlined in her famous essay, “Leverage Points: Places to Intervene in a System” (link here)

Leverage points to intervene in a system

“Leverage Points” are places within a complex system where a small shift can produce big changes overall. It sounds much cooler in Norwegian if you can pronounce it: "Inflytelsespunkter".

As practical and useful as I’ve found them to be, I’m sure you will find these act as a handy reference whenever you are tasked with complex problem solving. Following her original essay, they are listed here in increasing order of effectiveness. However, for ease of remembering I’ve clubbed the 12 leverage points into 8.

Parameters/ variables

Think of them as control knobs in your systems - the constants and variables. They are the easiest to change, but have little long term effects. The RBI can keep changing interest rates, but it would not impact the productivity growth of the economy or stop economic cycles from happening. In the short term though, they would be able to increase/ decrease the quantity of capital in the system.

Stocks

These are buffers that stabilise a system. Keeping higher stocks as buffers maintain stability but come at the cost of efficiency. Take inventory for example - keeping extra inventory would ensure that if an order comes suddenly you can service it, but would come at the cost of cash flow.

I remember how once we got sudden traffic surge when a referral campaign went viral - a 40K RPM spike when we could have have handled 4K RPM at best. They were the early days and we were following a monolith architecture. Even though we had elastic load balancers and auto-scaling groups configured, they’d only work upto a limit with the server instances. Keeping extra buffer would have added to our stability, but would have come at a cost. We ended up solving for that problem in a different way. There’s a separate blog out there for it if you want to read, but I hope I make my point about stocks and their impact on a system.

Structure

Meadows gives this example in her original essay,

When the Hungarian road system was laid out so all traffic from one side of the nation to the other has to pass through central Budapest, that determined a lot about air pollution and commuting delays that are not easily fixed by pollution control devices, traffic lights, or speed limits.

The only way to fix a system that is laid out wrong is to rebuild it, if you can... But often physical rebuilding is the slowest and most expensive kind of change to make in a system. Some stock-and-flow structures are just plain unchangeable.

Think of Meesho moving away from social commerce to traditional e-commerce and the structural change that would require. It’s a big change, but it’s better to do it now than later. The advantage of being an early stage company is the freedom to evolve or change fast. It gets harder over time.

Feedback loops

Imagine you step into the shower on a cold morning. The water is cold! You turn the knob to get more hot water and put your hand under the water to measure. It’s still not warm enough, so you turn it further to get more hot water. But wait! Suddenly the water becomes too hot. It’s burning! You turn it in the other direction to make it colder and keep doing this till you get the perfect temperature.

Consider the shower and yourself as 2 interacting sub-parts of a system. You placing your hand beneath the shower is a feedback mechanism. The knob is what you’re using to set the parameters. If you’re making decisions based on delayed information, by then the situation might have changed. This can cause the overall system to gear away from its steady state and cause frequent oscillations (rapid under-corrections and over-corrections) which are never good for the business.

Identifying the right feedback loops and measuring them in a timely manner is extremely important. A negative feedback loop is self-correcting; a positive feedback loop is self-reinforcing. Both need to be balanced and measured against the rate of change in the system.

Information flows

There is a funny story about Volvo from the '90s. The Swedish car manufacturer found itself with excessive stocks of green cars. In order to do away with the excess inventory of green cars, the sales and marketing team began offering attractive special deals. But nobody had told the manufacturing department about the promotions! The manufacturers read the increase in sales of green cars as a sign of consumer demand and further ramped up production of green cars.

Who does and does not have access to information greatly determines the success of the system as a whole. The leverage point is then to provide the right information in the right form at the right time to the relevant stakeholders. Especially in systems that involve operations, these information flows are critical for timely decision making and overall efficiency, though it holds equally true for other systems as well.

Incentives and rules

Incentives, punishments and constraints not only define the boundaries of any system but also drive the behaviour of the people interacting in the system. And since people are at the core of any system, their behaviour greatly determines if the system as whole meets its goals.

Changing such rules can dramatically change how various stakeholders interact with the system. The example of unintended consequences due to a change in incentive policy was reflective of perverse incentives that can be created - altering the behaviour of individuals and how they behave in a system.

The ability to self-organise

We begin to go a bit meta here - but any executive who has had to set up a team will recognise this. It also gets harder from here.

Self-organization is the ability of a system to change itself in response to changing circumstances.

RBI suddenly changed the rules to your business model? Okay - but how do you respond to it? Can your team self organise and chart out an action plan with some direction?

It’s extremely powerful because a self organising system can improve its own rules, information flows, and feedback loops by itself. However such a state requires constantly inducing a high degree of agency amongst key actors coupled with decentralised decision making (whatever can be decentralised).

System goals and paradigms

Is your startup’s goal to raise the next round at a higher valuation? Or is your goal to become profitable? Whatever the goal - it determines what every single molecule in your organisation would prioritise and build for. It is what ties the complex system as a whole rather than just being the sum of its parts.

A point of caution here - remember that constantly changing goal posts can be death by torture and wasted bandwidths/ resources. It can create a feeling of anger and dissonance amongst stakeholders who put all their efforts towards achieving one goal when they are suddenly asked to move towards a different goal. While flexibility and self-organisation is key, they work best when goals are clearly defined.

Meanwhile, at the expense of becoming more meta, a system’s paradigms are the most impactful leverage points that can be changed to create long term impact. They are the implicit beliefs that exist in a system. “This is the responsibility of the sales team”, “I can’t start on this problem till it is put in Jira” - these are often so deeply ingrained in our minds that we don’t consciously articulate them. They percolate and multiply throughout the organisation and collectively determine the culture of the organisation. That is the hardest to change, but as Meadows notes -in the long term what can have the greatest impact.

---

Changing our approach

When I was first asked to set up a team, I made this mistake while taking interviews.

I would incorrectly judge candidates based on their approach to breaking down large problem statements into smaller parts and correspondingly solving them with a structured approach (I was testing for systems thinking). Here’s what I wish someone had told me - most case studies are designed to test complicated but linear problems. Not complex problems.

As this HBR article notes:

Practically speaking, the main difference between complicated and complex systems is that with the former, one can usually predict outcomes by knowing the starting conditions. In a complex system, the same starting conditions can produce different outcomes, depending on the interactions of the elements in the system.

Instead of rewarding the rapid pace of thoughts rushing through their brains, trying to map all the dependencies, relationships, scenarios and intricacies - most case interviewers actively look for “structure”. I’ve changed my approach since - I actively look for people identifying these complex system interactions in the first 20 mins and if they are able to do so, then guide them to build a structure around such interactions in the next twenty. 

Why? This is much closer to the real world, where builders start with chaos and gradually put all the pieces of the puzzle together. Problem discovery and then mapping all these interdependent pieces together, is the biggest value add any PM can have. It’s also the hardest. Get it wrong and no amount of hard work will save you. 

Each day I’m still discovering things for myself and refining my perspective. So far though, I’ve come to identify that problem statements in a complex interconnected system usually fall in 3 categories. If you know of any other, do ping!

1. Coupled: 2 or more problems interconnected with each other 

2. Causal: Solving problem A requires solving problem B first

3. Standalone: Rare, but exists - usually easiest to solve

As Ian Malcolm, in Michael Crichton’s book Jurassic Park notes:

[We] have soothed ourselves into imagining sudden change as something that happens outside the normal order of things. An accident, like a car crash. Or beyond our control, like a fatal illness. We do not conceive of sudden, radical, irrational change as built into the very fabric of existence. Yet it is.

It would be useful to internalise the complexity that exists around us - if anything, I am sure it would lead us to the creation better products.