Understanding Delivery Through Systems Thinking

Introduction

I went through a period of sustained overwork without recognizing it immediately. The cost of sustaining that output only became visible after delivery.

This was a software project with fixed deadlines and shifting scope. I recently read Thinking in Systems by Donella Meadows. The framework helped me describe what happened without blaming management or faulting myself.

System Definition

A system can be described as a set of elements, connected through interactions, organized around a purpose. In this case, the system’s effective purpose was:

Maintain delivery momentum.

Effective purpose describes what the system consistently optimized for through its behavior. It does not describe intent or values.

While stated values included sustainable pace, the system’s behavior optimized for something else.

Elements

The system contained people with different properties:

• execution capacity
• response speed
• tolerance for uncertainty
• skill coverage
• availability

Each element was neutral on its own.

One person might respond quickly but escalate uncertainty. Another might absorb ambiguity without complaint.

Interconnections

Work flowed through interconnections that favored certain properties:

• tasks routed toward faster responders
• uncertainty routed toward higher tolerance
• unresolved ownership defaulted to available capacity
• deadlines increased routing pressure

These routing rules were implicit rather than designed.

When a question came in late Friday about an ambiguous edge case, it went to the person who had answered similar questions before. That person became the default path for ambiguity.

Emergent Behavior

Given this structure, a predictable pattern emerged:

• load concentrated along the lowest-resistance path
• execution throughput increased
• recovery debt grew
• sustainability decreased

Recovery debt accumulated as an invisible stock (a reservoir that fills and drains)—filled by rest, drained by sustained output.

As long as throughput remained acceptable, the system registered success. The cost accumulated outside the system’s primary feedback loop.

Feedback and Delay

The system contained delayed signals:

• delivery succeeded while recovery time grew
• ownership remained implicit rather than named
• alarms appeared only when stability was already compromised

These signals arrived after the system fulfilled its purpose.

The Pattern

The system did not require malicious elements. It required only a path capable of absorbing uncertainty.

Once the path existed, the system routed increasing load through it. The system stabilized temporarily, until the same dynamics produced instability again.

Closing

I now consider myself a student of systems rather than someone who exists outside them. Awareness does not change a system by itself, but it is often the first leverage point available.

For me, that meant naming the routing rules out loud—making implicit paths explicit.