You fix a performance issue, and another component becomes slower. You increase a buffer to prevent data loss, only to discover that latency has increased. You introduce retries to make a service more reliable, but under heavy load, those retries make the outage worse.
None of these decisions is necessarily wrong when considered in isolation. The problem is that engineering decisions rarely operate in isolation.
As engineers grow in their careers, one of the most important skills they develop is the ability to anticipate how a local change affects the larger system. This is where systems thinking becomes valuable.
A well-known example comes from NASA’s Mars Pathfinder mission. In July 1997, shortly after landing, the lander began resetting its computer. The engineers reproduced the fault on a replica on the ground, and their own account explains it. A high-priority task that managed the data bus needed a lock held by a low-priority weather-data task. Several medium-priority tasks kept pre-empting the low-priority task, so it could not finish and release the lock. A check noticed that the high-priority task had missed its cycle and, as designed, reset the computer.
The task priorities were correct. The deadline check worked. The reset kept the spacecraft safe. A feature called priority inheritance was off by default, a choice the vendor had made for performance and one the team did not know to change. The failure came from these correct parts working together, under data rates higher than the “best case” the tests had used. The team had seen the reset before launch, could not repeat it, and ranked it as low priority. The fix was to switch priority inheritance on, through a change uploaded to the spacecraft.
Every part met its own specification, and the system still failed.
Why systems thinking becomes important as your engineering career progresses
Early in an engineering career, success is often measured by how well you complete an assigned task. Can you implement a feature, fix a bug, or optimise a function?
As responsibilities grow, the questions change. What happens when your component interacts with another team’s work? Will a performance improvement increase resource contention elsewhere? Could a local fix create a production problem?
The transition from executing tasks to making engineering decisions requires a broader understanding of the system. This is one of the important distinctions between an engineer who can solve a problem and an engineer who can anticipate the consequences of a solution.
Systems thinking helps develop that judgement. It becomes increasingly useful in architecture discussions, design reviews, incident investigations, and technical leadership.
Solving the problem in front of you and foreseeing what the solution will do elsewhere are two different skills.
How feedback loops keep a failure going
In April 2011, a network change in one Amazon Web Services Availability Zone (a group of data centres) cut many storage nodes off from their replicas. Each node followed a rule that is correct for one node: if my mirror is gone, create a new one. When a large number of nodes did this at once, free capacity ran out and nodes kept searching the cluster for space. Amazon’s own summary calls it a “re-mirroring storm”. The recovery mechanism became the load that kept the outage going.
Researchers call these metastable failures. A trigger, such as a short network problem, pushes the system into a bad state, and a feedback loop keeps it there after the trigger is gone. In a study of 22 such incidents from 11 organisations, retries were that loop in more than half. The original paper notes that the root cause is often a feature that improves the efficiency or reliability of the system.
The features that make the normal case faster are often the ones that keep a failure going.
Why technical knowledge does not guarantee systems intuition
A stock is anything that accumulates: water in a tank, data in a buffer, tickets in a queue. A flow is the rate at which it fills or drains.
In one experiment, MIT graduate students, all with calculus and most with engineering, mathematics or science degrees, were shown a graph of people entering and leaving a store. Almost all read the entry and exit rates correctly. Fewer than half could say when the store held the most people. Presenting the data differently did not help; in a later experiment, repeated attempts with feedback did.
These were students, not engineers working on their own systems. But a receive buffer, a task queue and a review backlog are all stocks, and a real system has many of them. Technical knowledge alone does not make their behaviour obvious.
Three ways of thinking that make the system visible
1. Think in stocks, flows and work in flight
For any part you are changing, ask what accumulates there, what fills it, what drains it, and what has already been sent but not yet delivered. A buffer smooths a burst; it cannot fix a drain rate that is lower than the fill rate. A retry adds to the work in flight; it does not reduce it. Network equipment showed this when larger buffers, added to avoid dropping packets, delayed the signal that tells senders to slow down and made delays worse for everyone. The problem became known as bufferbloat.
Ask: before increasing a buffer, queue size or retry count, am I solving the underlying problem, or merely allowing more work to accumulate?
2. Every controller acts on its own model of the system
MIT safety researcher Nancy Leveson describes a system as a set of controllers, human or automated, each acting on a model of the process it controls, built from what it can measure. Many accidents happen when that model no longer matches the real system. A thermostat, a task scheduler, a test gate in a build pipeline and a release manager are all controllers in this sense. This is an analysis method rather than an experimental result; its value is in the questions it makes you ask.
Linux once had a simple case. The part that frees memory in an emergency acted only when it could no longer free any. On fast storage it almost always could, so it did not act even while the machine was frozen. By the only signal it watched, nothing was wrong. The fix was to measure how long programs are kept waiting.
Ask: when something behaves unexpectedly, what information is the controlling component using to make its decision, and what important information might it be missing?
3. Where you change the system matters more than how much
Donella Meadows ranked the places where you can intervene in a system. Numbers such as limits, sizes and thresholds came last, below delays, feedback, information flows, rules and goals. She wrote: “Probably 90, no 95, no 99 percent of our attention goes to parameters, but there’s not a lot of leverage in them.” Her ranking is expert judgement, not measurement, but it fits the cases above. Pathfinder’s fix changed a rule: a task holding a lock inherits the priority of the task waiting for it. Linux changed the information it measured. Amazon changed the loop, with retries that back off and limits on work accepted under stress.
Ask: before adjusting a threshold or timeout, does the real problem lie in feedback, information flow, coordination, or the rules of the system?
Before you change a number, ask whether the part is measuring the right thing.
Is systems thinking still worth learning when AI writes the code?
Yes. The evidence is still developing, but it supports that answer. Google’s DORA programme surveys thousands of software professionals each year. Its 2024 report estimated that as AI adoption rose, individual productivity went up slightly while delivery stability went down. In 2025, throughput had improved but instability still rose, and the report described AI as an amplifier: it “magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones.” The authors point to system-level practices, such as small batches and strong version control, as what decides the outcome. These are survey associations, not experiments.
Leveson’s model applies to the tools as well. An AI assistant is a controller, and its decisions rest on the information it has: the prompt, the code it read, test results, and in some setups telemetry or other operational data. That can be a great deal of information, but it is rarely all of it. AI-assisted decisions are only as well grounded as the information and verification available to them.
AI is changing the economics of software development. Writing a function, generating tests, or exploring an unfamiliar API may require less effort than before. But making code easier to produce does not automatically make engineering decisions easier.
When implementation becomes faster, teams can also introduce changes faster. The challenge then shifts towards understanding dependencies, evaluating trade-offs, and recognising consequences that are not immediately visible.
More changes in less time means more interactions to judge.
For engineers thinking about their long-term careers, this suggests an important direction: develop the ability to define problems, question assumptions, evaluate solutions, and understand system-wide consequences. These skills remain valuable even as the tools used to implement solutions evolve. Our article on why judgement lasts longer than tool knowledge looks at this in more detail.
How to develop systems thinking throughout your engineering career
1. Understand the system before optimising a component. When assigned a task, understand what happens before and after your component processes information. Identify dependencies, shared resources, and possible bottlenecks.
2. Learn to ask system-level questions. During design discussions and code reviews, ask what other components may be affected by a proposed change. Consider normal operation, heavy load, and failure conditions.
3. Study failures, not just successful implementations. Technical incidents are valuable learning opportunities. Examine what triggered the failure, what allowed it to spread, and why existing safeguards did not prevent it.
4. Make predictions and compare them with reality. Before changing a system, predict the expected behaviour. After implementation, compare those predictions with observations. This helps develop more accurate mental models. Our article on why years of work are not the same as years of experience explains why that comparison matters.
5. Participate in design reviews and technical discussions. Discussing a problem with experienced engineers can expose assumptions that you might otherwise overlook.
6. Use AI to explore alternatives, not replace judgement. Ask AI tools to identify dependencies, propose failure scenarios, and challenge assumptions. Validate those suggestions against the real operating environment. For the risk of keeping a suggested fix without knowing why it works, see the danger of cargo-cult engineering.
Two exercises with direct research support
- Build one small simulation. Model a queue with a fill rate and a drain rate in a spreadsheet or a short script. Change one rate, predict the result, then run it. A short course in this kind of modelling is the one intervention that has measurably improved performance on stock-and-flow tasks.
- Sketch, then check. For a buffer, queue or backlog you work with, draw how its contents will change for a given input, then compare with the real behaviour. Feedback on your own attempt is what corrected the error in the experiments. They did not test transfer to new problems, so practise on several different examples.
From solving problems to understanding systems
Engineering expertise is not built only by learning more technologies, frameworks, or programming languages. It also develops through experience: understanding how components interact, recognising patterns across failures, and learning to anticipate the consequences of technical decisions.
Systems thinking helps engineers make that transition. It encourages us to look beyond the immediate problem, question assumptions, and consider the behaviour of the larger system before choosing a solution.
As AI makes implementation increasingly accessible, the ability to exercise sound engineering judgement becomes even more important.
Much of this judgement is learned by having your reasoning examined by people who see the system differently. That is why TECH VEDA’s sessions are live and mentor-led, and built around problem scenarios where a proposed fix is discussed for its effects on the rest of the system.
The next stage of engineering growth is not simply about solving harder problems. It is about understanding the systems in which those problems exist.
Sources and further reading
- Glenn Reeves (JPL), reply to “What really happened on Mars?” (email, December 1997), the engineer’s own account of the Pathfinder resets.
- Amazon Web Services, “Summary of the Amazon EC2 and Amazon RDS Service Disruption in the US East Region” (April 2011).
- N. Bronson et al., “Metastable Failures in Distributed Systems” (HotOS 2021), and L. Huang et al., “Metastable Failures in the Wild” (OSDI 2022).
- M. Cronin, C. Gonzalez and J. Sterman, “Why don’t well-educated adults understand accumulation? A challenge to researchers, educators, and citizens” (2009).
- J. Gettys and K. Nichols, “Bufferbloat: Dark Buffers in the Internet” (ACM Queue, 2011).
- Nancy Leveson, Engineering a Safer World (MIT Press, 2011, open access).
- Donella Meadows, “Leverage Points: Places to Intervene in a System” (1999), and Thinking in Systems (2008).
- DORA, Accelerate State of DevOps Report 2024 and State of AI-assisted Software Development 2025.
— Raghu Bharadwaj
