When Leadership Lets the System Drift

The system did not break, it adapted.

Observe the delivery system of almost any organisation under strain. Boards remain full, work continues to move, and a significant proportion of items hover in a perpetual state of “almost done”. Reviews accumulate, quality assurance absorbs growing pressure, and yet the overall impression remains one of activity and control.

That impression proves misleading.

Over time, the system internalises a simple rule: initiating work carries less risk than completing it. That rule rarely originates within teams themselves, it emerges from the signals set above them.

1. This Is Not a Team Problem

Teams do not design these conditions, they operate within them. At leadership level, priorities accumulate without corresponding removal. Initiatives stack, often justified in isolation, while the rate at which work is authorised exceeds the rate at which it is completed.

Each individual decision appears reasonable. Collectively, they alter the equilibrium of the system.

Completion ceases to act as a constraint. As a result, the system begins to drift.

2. Leadership Signals, Teams Follow

Teams respond less to declared strategy than to observed behaviour. What leaders attend to, reward, and tolerate defines the operating model in practice.

Where visibility attracts recognition, visibility increases. Where urgency dominates discourse, reactivity becomes the norm. Where unfinished work is accepted, completion gradually loses importance.

This phenomenon does not stem from culture in the abstract, it results from the design of signals within the system.

3. The Executive Blind Spot

A recurring pattern appears at senior levels: increasing distance from execution. Leaders rely on summaries, dashboards, and curated narratives, which, over time, degrade their ability to read the system directly.

As this distance grows, signals begin to deteriorate. Cycle times extend, queues lengthen, and completion rates decline. However, the surface of the system continues to display movement.

This pattern has been observed repeatedly in large-scale studies of software delivery performance, where increased distance from execution correlates with degraded flow and longer lead times.

The result is a misleading sense of health. Activity remains visible, while degradation remains largely undetected.

4. The Fallacy of Separation

A widely accepted but flawed assumption reinforces this dynamic: that business and execution should operate as separate domains. Strategy resides on one side, delivery on the other, with limited overlap between the two.

In practice, business must carry execution. Without direct engagement in how work flows, leaders relinquish control over outcomes. They continue to manage intent, yet intent alone does not produce results.

This separation is often institutionalised through roles and structures that sit between business and technology, claiming to translate, prioritise, or direct work without owning its execution. These layers create distance rather than clarity.

From that distance, it becomes easy to focus on what is visible and measurable: activity, reporting, status, and artefacts. Noise becomes easier to measure than progress, and therefore replaces it. Dashboards turn green, not because the system delivers, but because it reports.

This isolation gradually turns the organisation into a factory. Flow is no longer understood end to end, work becomes fragmented into stages, each optimised locally but disconnected globally. Operational constraints, which ultimately shape business outcomes, disappear from view.

Most critically, feedback loops weaken or break entirely. Signals from execution no longer travel back to decision-makers with sufficient fidelity or speed. What remains is a delayed, filtered, and often sanitised version of reality.

The illusion sustains itself. Leaders believe they are directing technology. In reality, they are observing a system they no longer control.

Execution, left insufficiently constrained, follows its own path.

5. The WIP Illusion

Work in progress rarely aligns with how it is represented. It does not reside within a single column or stage, it encompasses everything between TODO and DONE.

Most systems, however, fragment this reality into localised views, each appearing manageable. Limits may exist at the column level, yet the overall system load remains unbounded.

Queues distribute across stages, and progression towards completion slows accordingly. Activity increases, creating the appearance of productivity, while throughput declines.

As visibility degrades, organisations often compensate with the wrong measures. They begin to count what is easy to count: commits, lines of code, tickets created, or activity per individual. These signals feel objective, yet they track volume rather than outcomes.

This follows a well-known dynamic: once a measure becomes a target, it ceases to be a good measure. Metrics such as commits or lines of code optimise for activity, not outcomes.

Such metrics reinforce the very drift they attempt to control. They reward fragmentation, encourage superficial movement, and legitimise noise. The system appears green because it reports abundant activity, while the underlying flow continues to deteriorate.

6. Why Teams Drift Too

Teams are not oblivious to these conditions. They sense when the system resists completion and adapts accordingly. Engagement weakens, focus fragments, and ownership becomes diffuse.

In many cases, they comply. Not out of lack of capability, but out of rational self-preservation. When the system rewards activity and tolerates incompletion, aligning with those signals becomes the safest path.

These behaviours often receive superficial explanations centred on motivation or discipline. In reality, they reflect a structural response to the environment in which teams operate.

Teams do not deviate independently, they mirror the system defined by leadership.

7. The Quantitative Reality

At a certain threshold, the system exposes its underlying state. Work in progress expands to two or three times the capacity available to move items through the board.

Cycle time stretches from days to weeks. Lead time becomes unpredictable. Completion rates fall while activity continues to rise.

At that point, adding more effort resembles pouring more water into a river already obstructed by stones. The volume increases, yet flow does not improve.

Beyond this point, flow cannot stabilise. Regardless of effort, completion rates remain constrained.

The financial signal follows the same pattern. In healthy systems, engineering investment translates into measurable business outcomes with strong leverage. As coordination cost, delay, and rework increase, that leverage collapses.

When a large share of investment sustains delay, coordination, and rework rather than outcomes, the organisation has entered a danger zone. Mature systems operate with significantly higher leverage.

By the time this becomes visible in financial reporting, the system has already crossed a threshold where recovery is significantly harder.

By the time this ratio becomes visible, the system has already crossed a threshold where recovery is significantly harder.

If it is not in DONE, it does not exist. Everything else constitutes unresolved work.

8. Structural Responsibility

Responsibility for this state does not reside with teams alone. It sits with those who define the system’s constraints.

Leaders determine what enters the system, what remains, and what must reach completion. When these constraints are weak or absent, the system compensates by increasing activity rather than delivery.

This is not a failure of execution, it is a consequence of insufficient structural control.

9. Structural Correction

Correction does not arise from increased pressure on teams. It requires deliberate re-engagement from leadership with the mechanics of execution.

Work in progress must be reduced. Competing priorities must be removed, not merely reprioritised. Completion must be enforced as a condition, not an aspiration.

No new work should begin until existing work reaches completion.

Such measures do not represent process adjustments, they constitute decisions about how the system operates.

The paradox lies here: none of these corrections are complex. They reflect basic operational common sense. Yet organisations drift away from them because the system gradually disconnects leaders from execution. As feedback loops weaken and signals degrade, what was once obvious becomes invisible. Common sense does not disappear, it becomes inaccessible.

In that state, adding effort feels like progress, even when constraints remain untouched. The organisation forgets that flow is governed by removal, not addition.

Even when the system recovers temporarily, the signal often becomes distorted again. Organisations celebrate a return to normal activity, rather than questioning why drift was allowed in the first place. Stability becomes a short-term victory instead of a structural expectation.

In doing so, leadership reinforces the very pattern it seeks to correct. The system learns that recovery is sufficient, and that prevention is optional.

10. What This Costs the Business

At this point, the issue no longer sits within engineering alone.

Lead times translate directly into delayed revenue, missed opportunities, and increased cost of coordination. Decisions arrive late because feedback arrives late. Strategy becomes detached from reality because execution no longer informs it in time.

The organisation believes it operates on intent, while in practice it reacts to constraints it no longer sees.

What appears as a delivery inefficiency becomes a business risk.

Closing

The system does not fail arbitrarily. It produces outcomes consistent with the constraints applied to it.

Where leadership disengages from execution, drift becomes inevitable. Where leadership re-engages and enforces constraints, flow can be restored.

The outcome, in each case, follows from design rather than chance.

Sources

DORA / Google, Accelerate State of DevOps Reports
Goodhart’s Law, Charles Goodhart (1975)
McKinsey, Developer Productivity and Engineering Effectiveness Studies