Reading notes: Thinking in Systems, by Donella Meadows

A queue grows even while everyone works. Counting only tasks completed today can miss how many arrived and how many actually left the process.

Thinking in Systems, by Donella H. Meadows offers concepts for examining these relationships. These reading notes focus on stocks and flows, introduced in the excerpt shared by the Donella Meadows Project. The Brazilian edition published by Sextante is titled Pensando em sistemas.

The Amazon link is an affiliate link.

The following team example is my own application using a hypothetical case. It explores the concepts without attributing a specific recommendation about that business to the author.

A quantity that changes over time

Meadows draws attention to stocks, accumulated quantities, and the flows that change them. In a bathtub, the volume of water is the stock; water entering and leaving changes that volume. If more enters than leaves, the stock grows.

This distinction lets you examine a quantity and the process changing it. A stock observed at one moment reflects earlier events. Changing a flow may take time to change the accumulated quantity.

To apply the concept, define what you are counting. A queue of orders, an amount of material and a measure of trust require different observations. Calling them all "stocks" does not make them equally precise.

An example of accumulated work

Imagine a fictional team receiving change requests. During one period, ten arrive and six reach the completion point defined by the team. With no other arrivals or departures, the queue grows by four.

The numbers are illustrative. Completing six requests alone does not establish whether the situation improved. The result also depends on arrivals, departures through other routes and what was already accumulated.

Before using the calculation, define what counts as a request. A message containing several requests could count as one item or several. A canceled request leaves the queue too, although it was not delivered. Combining these departures changes the interpretation.

Those definitions let you check whether the record represents the work you want to understand.

Why a snapshot can mislead

A small queue on one day may reflect an exceptional delivery, lower demand or several cancellations. To interpret behavior, follow a period and the events changing arrivals and departures.

Likewise, a large queue may have formed before an improvement. If the team now completes more requests than it receives, the quantity can be falling while still looking high in isolation.

Ask how long each item remains open and whether the group includes abandoned tasks nobody removed. A count may combine urgent work, requests missing information and ideas that should not share a queue.

Define the stock according to your question. Mixing these types of outstanding work can hide precisely the difference you need to observe.

An intervention needs a mechanism

If the queue grows, hiring may be an option. First investigate what limits completion. The team might have execution capacity and depend on slow approval. Incomplete information may create rework.

A proposed change needs to explain which flow it affects and how. More people executing tasks may increase work ready for review without increasing final deliveries. Better request information may reduce returns, provided missing information is a relevant cause.

An intervention can also change arrivals. Limiting new commitments or negotiating scope affects customers and revenue. Consider those consequences rather than treating queue reduction as the only objective.

Where the application has limits

A task queue does not behave exactly like water. Items can differ greatly in complexity and change size during execution. Counting captures one aspect of work without representing all the necessary capacity.

You can track request types separately or add effort and age information. The question determines the choice. A complex record nobody maintains may become less useful despite appearing more precise.

The model also needs a boundary. If the team finishes its task and transfers the problem to another area, its local queue shrinks while customer delivery may remain stalled. Define which result marks exit from the process you are studying.

A way to try the reading

Choose a queue you already track. Describe what enters, what leaves and what keeps an item there. Observe a period that includes relevant routine conditions.

Then propose a possible change. If you believe incomplete information causes returns, compare complete and incomplete cases before changing the whole process.

Use the problem investigation worksheet to preserve observations and separate your explanation from the records. When you return to the reading, ask a concrete question: which behavior did this representation help explain, and what did it leave out?