Feedback Loops Defeat Static Plans: Governing Dynamic Complexity in Programs

A program can be structurally understandable and still behave in ways that make yesterday's sensible intervention tomorrow's problem.

When delivery slips, the obvious response is often to increase work intensity. Add people. Authorise overtime. Run more meetings. Escalate more issues. Compress approvals. Each intervention appears rational when viewed as a direct response to a visible variance.

The difficulty is that programs are not collections of isolated cause-and-effect events. Actions alter behaviour, behaviour changes relationships, and delayed consequences return through the system. More overtime can initially increase output, then reduce productivity through fatigue and rework. More people can increase capacity, then absorb the best people in onboarding and coordination. More governance can improve visibility, then slow decisions until teams work around it.

These are not random failures. They are feedback.

The Strategic Context

Oehmen and colleagues distinguish dynamic complexity from structural complexity. Structural complexity describes how a system is composed. Dynamic complexity concerns how the state of the system and its relationships change over time.

That difference matters because conventional management information is often static. A dashboard shows schedule variance, resource use, risks and milestone status at a point in time. It may not show why the system is moving in that direction or how today's corrective action will influence next month's behaviour.

San Cristóbal's review makes the same broader point: when fundamentally dynamic problems are treated statically, traditional approaches can miss feedback and nonlinear relationships.

At program level, this is especially important because programs operate across longer time horizons, organisational change and multiple interdependent components. A response that helps one project this month can damage program outcomes later by consuming scarce capability, changing stakeholder behaviour or creating technical debt.

The program manager is therefore not only controlling delivery. The role includes interpreting system behaviour.

What Leaders Commonly Misread

The first misread is to assume that a visible problem has a local cause. A late workstream may be suffering from an upstream decision delay, changing requirements, resource congestion or behavioural resistance elsewhere in the program.

The second is to judge an intervention too early. Some actions create immediate improvement followed by delayed deterioration. Oehmen's system-dynamics example of overtime is powerful because the intervention initially appears to work. Fatigue accumulates later, productivity falls, issues and rework increase, and the original delay can worsen.

The third is to assume that adding resources always increases throughput. New staff require training, coordination and access to experienced people. When the system is already congested, additional labour can increase the load on the constraint.

The fourth is to equate more monitoring with more control. Monitoring provides information. It does not automatically change the causal structure producing the result.

The fifth is to treat organisational resistance as a stakeholder problem at the edge of delivery. In transformations, resistance can be emergent system behaviour produced by incentives, workload, previous change history and perceived loss of control. Communication alone may not remove the cause.

Reframing the Issue

Dynamic complexity requires leaders to ask a different question:

What feedback structure is producing the pattern we can see?

System dynamics is one method for exploring this. Oehmen et al. describe reinforcing loops, which amplify movement, and balancing loops, which counteract it. A full quantitative model can require specialist support, but a qualitative causal-loop view can still be valuable for management teams.

Consider a common transformation pattern:

Delivery falls behind.
Leadership increases reporting and escalation.
Teams spend more time preparing reports and attending reviews.
Productive capacity falls.
Delivery falls further behind.
Leadership responds with even more reporting.

Every individual decision can be defensible. The loop is destructive.

The same logic applies to resource allocation. A scarce expert becomes overloaded. More projects are assigned to the expert because those projects are important. Context switching and queues increase. Completion slows. More initiatives remain dependent on the same expert. The importance of that person's workload rises further.

This is why systems thinking is not academic decoration. It changes which intervention makes sense.

Recognising Reinforcing and Balancing Behaviour

Reinforcing loops

Reinforcing loops amplify a trend. They can create growth or deterioration.

Examples include:

stakeholder distrust causing more defensive governance, which slows delivery and creates more distrust;
delays causing overtime, which creates fatigue and rework, causing further delay;
technical debt accelerating short-term delivery, then increasing future change effort and generating more pressure for shortcuts.

Reinforcing loops need an intentional counterforce or they can run away.

Balancing loops

Balancing loops push the system toward a target or constraint.

Examples include:

workload increases until resource capacity limits throughput;
customer demand rises until service quality deteriorates and demand falls;
project initiation accelerates until scarce capability becomes the limiting factor.

Balancing behaviour is not always beneficial. A system can balance at an undesirable level.

Delays

Time delays are particularly dangerous because they separate action from consequence. Leaders may repeat an intervention because no negative effect is yet visible. By the time the effect arrives, the system has accumulated exposure.

Governance should therefore ask not only "What happened?" but "What consequences have not appeared yet?"

Decision Framework

For persistent program problems, use a Dynamic Intervention Review before escalating the same response again.

Step 1: Define the recurring pattern

Describe behaviour over time, not one data point. Is delay accelerating? Is rework cyclical? Does morale recover then fall again? Does resource demand repeatedly exceed capacity after each planning cycle?

Step 2: Identify the suspected loops

Ask what the current response changes elsewhere. More people may change training load. Faster decisions may change quality. Scope reduction may change benefits. Additional controls may change team behaviour.

Step 3: Look for delays

Which effects arrive weeks or months after the intervention? Where are decisions being evaluated before their full consequences appear?

Step 4: Find the leverage point

The best intervention may not target the visible symptom. Reducing work in process, clarifying an interface, removing a decision bottleneck or changing incentives may outperform another schedule recovery plan.

Step 5: Define learning evidence

State what pattern should change if the intervention is working. This turns governance from retrospective reporting into a controlled learning process.

Governance for a Moving System

Dynamic complexity changes what program governance should demand.

First, trends matter more than isolated status. A project moving from ten days late to twelve days late is different from one oscillating between late and recovered because the underlying mechanisms may differ.

Second, leading indicators matter. Overtime, work in process, decision queues, rework, staff turnover, unresolved interfaces and stakeholder sentiment can reveal system pressure before final milestones fail.

Third, governance should challenge the intervention logic. If leaders keep applying the same recovery action, the review should ask why the expected mechanism has not produced durable improvement.

Fourth, decisions should have review points. An intervention under uncertainty should carry an explicit hypothesis and a date for reassessment.

Fifth, the program must preserve space to learn. A system operating permanently at maximum utilisation has little capacity to absorb surprises, investigate causes or change course.

From Strategy to Execution

Immediate action is to identify one recurring program problem and map its likely causal loop. Do not attempt to model the entire enterprise. Start where repeated interventions are failing.

Medium-term capability is to redesign reporting around behaviour over time. Add trend views for rework, queues, decision latency, work in process and capacity utilisation. Train governance forums to distinguish symptom correction from structural intervention.

Long-term positioning requires leaders to build feedback-aware portfolios. Avoid loading every critical resource to its theoretical maximum. Preserve modularity where possible. Reduce simultaneous change when business absorption becomes a constraint. Build decision cycles that are shorter than the rate at which critical assumptions are changing.

Signals to Monitor

Dynamic complexity is likely to be driving results when:

the same problem returns after apparently successful recovery;
productivity falls after additional resources are added;
overtime rises while output remains flat or deteriorates;
rework grows faster than completed work;
governance interventions create increasing administrative load;
teams change behaviour to satisfy metrics without improving outcomes;
stakeholder resistance appears in new locations after local issues are resolved;
corrective actions work briefly, then performance falls below the original level.

These patterns justify causal investigation, not another repetition of the same control.

Questions for the Leadership Team

Which program problems keep returning after we "fix" them?
What delayed consequence could our current recovery action create?
Where are reinforcing loops amplifying delay, rework, distrust or technical debt?
Which constraint is actually limiting throughput?
Are we measuring the system's behaviour over time or only reporting current status?
Which intervention would reduce the cause rather than the symptom?
What management action should we stop because it may be making the system worse?

Closing Perspective

Programs fail dynamically as well as structurally.

Leaders can have clear roles, detailed plans and disciplined reporting and still produce poor outcomes if they misread feedback. The more consequential the program, the more dangerous it becomes to assume that every correction has a direct and proportionate effect.

The governance advantage comes from understanding patterns, delays and interactions early enough to change the system rather than continually forcing it back toward a baseline it can no longer sustain.

About EraNorth Insights
EraNorth Insights publishes practical analysis on strategy, projects, operations, transformation and decision intelligence for professional and organisational use. About EraNorth.