Systems thinking and craft: ideas from engineers that help everyday reasoning

Stocks and flows describe what keeps accumulating

A full laundry basket tells you something different from a busy washing machine, because the clothes waiting are a stock while clothes entering and leaving are flows. In Thinking in Systems: A Primer (2008), Donella Meadows uses this distinction to explain that a stock changes only through its inflows and outflows, which is why a backlog can keep growing even while people work hard inside the system. If you wash more each week but dirty clothes arrive even faster, the basket continues filling.

The definitions come from systems modelling, whereas the household application here is practitioner wisdom: it invites you to observe both arrivals and departures before you blame a backlog on laziness. At work, count the requests arriving as well as the requests completed, and check whether the apparent completions stay finished. A queue can grow because demand changed, because completion slowed or because jobs that looked finished returned for repair. Each explanation points towards a different experiment.

Feedback and delays explain recurring trouble

A reinforcing loop amplifies a change, while a balancing loop pushes against it. Imagine that unfinished household jobs make tools harder to find, which creates rework and adds further jobs, so the backlog feeds itself through reinforcing feedback. A growing backlog might also prompt the household to set aside more time for work, which increases completions and shrinks the backlog through balancing feedback, provided the extra time produces finished work.

The diagram below describes an imagined household with invented quantities, and its arrows are proposed causal links that would need checking in a real home. If a family responds to unfinished jobs by starting further tasks, leaving tools scattered and abandoning work whenever a request arrives, the arrival rate may itself depend on the size of the backlog, so it pays to check that link before allocating more time. A delay between setting aside time and seeing jobs finished means an intervention can look ineffective before its consequences have arrived. Changing the plan again during that interval could stop you from learning whether the earlier change helped.

Schematic, not data: the imagined household starts with 20 unfinished jobs, receives 10 jobs per week and completes 10 jobs per week, with a response delay of 10 days. These quantities illustrate stocks, flows and delayed feedback without predicting a household's workload.

Element	Illustrative value or relationship
Starting stock	20 unfinished jobs
Inflow	10 new jobs per week
Outflow	10 completed jobs per week
Response delay	10 days
Reinforcing loop	Unfinished jobs increase searching and rework, which adds new jobs.
Balancing loop	Unfinished jobs prompt more work time, which increases completions after a delay and reduces the stock.

Meadows also distinguishes places to intervene in a system, including information flows, rules and a system's goals, and she ranks them by how much leverage they tend to offer. Her ranking is best read as practitioner wisdom informed by modelling, because the right place to intervene depends on the context. Asking everyone to wash faster changes a rate; agreeing when washing happens changes a rule. A visible basket may provide information that was missing, while deciding that clothes must always be immediately available changes the goal. Try recording the proposed mechanism before choosing an intervention.

Goodhart's law warns that targets change behaviour

Charles Goodhart's Problems of Monetary Management: The UK Experience (1975, reprinted in 1984) warned that an observed statistical regularity tends to break down once pressure is placed on it for control purposes. Marilyn Strathern gave the familiar wording in her 1997 paper on university auditing, published in European Review: “When a measure becomes a target, it ceases to be a good measure.” Her paper examines audit practices in universities, so the wording is best read as a warning about incentives and not as a measured rule that covers every target.

Suppose a workplace rewards the number of requests closed, giving staff a reason to close difficult requests prematurely and improve the count while increasing the customer's work. At home, the same mismatch can appear when someone tidies until the bench looks empty, with everything displaced into drawers. As practitioner wisdom, the law suggests checking whether people can improve the indicator while making the underlying purpose harder to achieve. Compare the visible count with a sample of what happened afterwards.

Brooks explains why extra help can create work

In The Mythical Man-Month: Essays on Software Engineering (1975), Frederick Brooks argues that adding people to a late software project makes it later. Brooks's law is practitioner wisdom about training and coordination costs, and he explicitly presents it as an oversimplification. New colleagues need explanations from people whose time was already committed, while divided work creates more boundaries to manage.

A crowded kitchen makes the mechanism visible: another cook can prepare vegetables independently, yet someone asking where every pan belongs can interrupt the cook managing the stove. Whether help saves time depends on the task, the helper's familiarity and the remaining time for their contribution to repay the teaching. Before recruiting, identify a bounded piece of work and the explanation it will require.

Brooks's No Silver Bullet: Essence and Accidents of Software Engineering (1986) separates complexity belonging to the problem from accidental complexity introduced by the means of doing it. This distinction is also practitioner wisdom when applied beyond software. A shared household calendar can remove the nuisance of copying appointments, while conflicting shifts and caring responsibilities still require negotiation. Describe those constraints before expecting a new tool to reconcile them.

Conway connects arrangements with communication

Melvin Conway's How Do Committees Invent? (1968), Datamation argues that organisations designing systems produce structures that reflect their communication arrangements. Conway's law is an observation and argument from design practice, rather than a measured guarantee that every organisation copies its chart exactly. Used as practitioner wisdom, this observation encourages you to look at who can exchange information before blaming the resulting process.

Imagine a workplace where booking staff learn what customers want while delivery staff learn what can be supplied, with both groups communicating only through a manager. The booking process may reproduce that bottleneck. A household can develop a similar gap when the person buying food never hears which lunches went uneaten. Sketch the route taken by a request, then investigate the handover where useful information disappears.

Feathers offers a way to change inherited routines

Michael Feathers's Working Effectively with Legacy Code (2004) teaches characterisation tests, which record how existing software behaves before changes are made. They preserve knowledge of current behaviour, including behaviour that might be undesirable, so a changed result requires judgement about whether the change was intended. His approach provides practitioner wisdom about managing change, with a useful analogy for routines whose purpose has become obscure.

Before changing a household shopping arrangement, record who adds missing items, when someone buys them and which supplies repeatedly run out. That record gives you a baseline without declaring the current arrangement correct. Feathers also describes seams, places where software behaviour can be varied without editing the code at that location. For shopping, the analogy is a handover where you can substitute a method while keeping meals and responsibilities stable enough to observe its effects.

Chesterton asks you to investigate before removing

Gilbert Keith Chesterton's fence appears in The Thing (1929): understanding why a fence exists gives you grounds for deciding whether it should remain. His thought experiment expresses practitioner wisdom about investigating inherited arrangements. A rule may have served a purpose that has vanished, or it may still prevent a problem you have never encountered because the rule prevents it.

A kitchen might keep separate cleaning cloths despite the inconvenience, giving you a reason to investigate whether the separation protects against contamination or reflects an abandoned habit. Investigation also has limits, because people may disagree about the original purpose and records may be absent. Set a proportionate period for finding out, then make the uncertainty explicit when deciding whether to retain the rule or test a replacement.

Questions about using systems and craft ideas

Are these laws scientific predictions about daily life?

The named laws here are practical generalisations, with different origins and limitations, so their usefulness depends on whether the proposed mechanism fits your situation. A causal diagram states what you think happens. Use a prediction you can check, such as whether clearer handovers reduce repeated requests.

Should every household problem become a systems diagram?

A diagram earns its effort when several changes interact or a problem keeps returning, whereas searching the usual location may suffice for an isolated misplaced key. Repeatedly misplaced keys invite observation of the arrival routine and where interruptions occur before choosing a new storage place.

Does investigating an old rule mean keeping it indefinitely?

Understanding a rule's history helps you judge the consequences of changing it. That history can reveal a reason to remove it, including a purpose that no longer deserves support. Record the explanation and the expected consequences, then check what follows a proportionate change.