When I first read Donella Meadows talk about her slinky lesson, it landed with a poignancy that is hard to describe. Meadows talks about bringing a slinky to class, unboxing it and holding it in one hand, using her other hand to support the bottom, then removing that support and letting the slinky expand toward the floor.

She asks her students what caused the slinky to behave and move in that way, and almost unanimously, she gets: your hand caused the behavior.

So she picks up the box the slinky came in, holds her hands the same way, and releases one of them to illustrate that the box does not move in the same way with the same hand movements.

The movement of the slinky is a feature of the structure and system of the slinky.

Drawing a line between an outcome in a system and the structure that produced it was one of the most eye-opening perspectives that I have come across.

I’ve always tended to think in systems, to have a sort of buggy first-principles need to find the ontology, even if it hurt my interest in any given situation.

Understanding that causal power likely belongs in the structure of an organization, instead of only in the responsibility of its constituent parts, allows one to look for real solutions.

You can make this analogy with almost anything, and it seems intuitively or philosophically self-evident if we say that when a car runs off the road and takes out a fence, the outcome was based on some feature of the system.

Maybe the lug nuts were not properly fastened, a tire worked its way off, and caused the incident. Even a human using their phone, paying attention to the wrong stimulus, and causing this sort of accident can be framed from a system perspective.

In fact, maybe that is the most insightful takeaway. The sociotechnical, psychological, cognitive human interface with a system is a system in and of itself that deserves scrutiny, description, and measurement.

Measuring human behavior, human psychology, and human cognition on one hand, and mapping the system, the workflow, and the less animate side of the equation on the other, is a combinatory prerequisite to understanding the ultimate system.

It reminds me of measuring particle collisions or thermonuclear reactions. What we are interested in is drawing a circle around anything that has an input into the system and considering the implications, design, outcome, optimization, or any other feature of these interactions.

I see both done regularly in my psychology department. We discuss the dark triad or learning and development. I spend a lot of time trying to map workflows to understand ERP business processes.

Rarely do we try to map both at the same time, probably because it is difficult, and often because we are ignorant.

My takeaway after working in academic affairs and student support can feel reductive, but it is this: systems produce outcomes.

This hit me very hard because a lot of my work, the satisfying part of my work, comes when a student is sitting across from me and we develop learning strategies, or a student builds a sense of self-efficacy.

And it feels dry, and the meaning feels less important, but the impact that this system has on the entire population of students is hard to overstate.

I think I was always looking for a way to explain my immediate turn toward systems analysis. In almost any problem, I find myself wanting to move backward from the visible issue into the structure that produced it. That instinct is useful, but it can also be awkward. Most people inside a system are not asking for the first principles of academic advising, student appeals, or administrative workflow. Often, they just need the next step.

That tension has probably cost me some development in the middle ground between one-on-one support and fundamental systems reorientation. But it has also helped me understand what I can offer students when they begin an academic journey: not only a solution to the immediate problem, but a way to understand the environment they are entering, model the long, intermediate, and next steps, and build confidence in their ability to see the implications of an action.

Psychology studies humans and their behavior. Business process analysis studies workflows. User experience looks narrowly at interfaces. Organizations usually separate these things, if they name them at all.

The real system ontology contains all of these simultaneously.

What Meadows’s slinky helped me realize was that the human in the loop is not outside the system being studied. They are as impactful as any other node.

This insight is what makes me want to learn, design, and build the new systems that we interact with from the human cognition side of the equation.

The hard part is remembering that the ontology is not the workflow, the person, or the technology. It is the whole arrangement. If we want a useful account of causation, or a serious roadmap for improvement, we have to draw the circle wide enough to include all of it.

The Power of Systems Thinking

A lot of organizational problems show up first as small frustrations.

A customer gets different answers from different people. A form gets routed to the wrong place. A staff member knows the workaround, but the workaround is not written down anywhere. A report exists, but no one is sure who is responsible for acting on it. A process technically exists, but only one or two people understand how it actually moves from start to finish.

At first, these look like separate problems. In practice, they are often connected.

That is where systems thinking becomes useful.

Systems thinking is a way of looking at the structure around a problem instead of isolating one visible failure. It asks what happened before the issue appeared, who had access to the needed information, where the handoff occurred, and what made the same problem likely to happen again.

I have found this useful because most real work cuts across people, tools, policies, and timing. A single problem may involve a customer, a front-line staff member, a manager, a database, a form, a policy, a deadline, and an approval process. From the outside, the problem may look simple: “I can’t complete this task.” Inside the organization, several disconnected processes may be colliding.

When that structure is not visible, the work becomes reactive. Someone answers the email. Someone calls another office. Someone fixes the immediate issue. The person is helped, which matters, but the process that produced the issue is still there.

The same kind of problem will come back later.

A systems approach changes the question. Instead of asking only how to fix the individual case, I want to know where the process became unclear. Was someone missing information? Did the system block an action without explaining why? Did responsibility shift between teams without a clear handoff? Did a tool expose a process gap that was already there? Did people create a workaround because the official process did not match the actual work?

Those questions are not abstract to me. They are the difference between solving a case and improving a process.

Good systems do not remove the need for judgment. They create better conditions for judgment. When the routine parts of a process are mapped, named, and documented, people have more time to handle the parts that actually require interpretation. That matters in any organization where people are trying to do careful work under real constraints.

The risk of informal process is that it can look like it works until something changes. A team may rely on memory, relationships, and habit. That can function for a while, especially when staffing is stable and the workload is predictable. But when someone leaves, workload increases, a new tool is introduced, or a deadline compresses the timeline, the hidden structure becomes a problem.

I have seen this in academic operations, but the pattern is broader. It shows up in project management, service delivery, onboarding, customer support, compliance work, technology implementation, and any environment where work moves across roles. The issue is not always that people are careless or that the software is bad. Often, the issue is that no one has clearly defined the process layer between policy, technology, and day-to-day work.

That process layer includes basic questions:

Who owns the decision?
Who owns the correction?
What information is needed before action can happen?
Where does the user go first?
What happens when the normal path fails?
How does the organization learn from repeated exceptions?

These questions are simple, but they are often unanswered.

This is one reason I am interested in systems thinking, process design, and applied technology. A tool can make work faster, but it cannot define the work by itself. A new platform can expose problems that were already there. A dashboard can organize information, but it still depends on whether the underlying process makes sense.

The same principle applies to AI tools. I am interested in AI because it can help organize information, summarize patterns, and support decision-making. But AI is most useful when it is placed inside a clear system. Without that structure, it can make vague work faster instead of making the work better.

For me, systems thinking is a practical method. I use it to look for patterns in repeated problems. I use it to separate one-time exceptions from recurring process failures. I use it to think about how people, tools, policies, documentation, and decisions interact.

The goal is not to make an organization mechanical. The goal is to make the work easier to understand, easier to repeat, and less dependent on hidden labor.

A better system does not solve every problem. It does make problems easier to see. It shows where information is missing, where responsibility is unclear, and where a process needs to be redesigned instead of explained again.

That is the value of systems thinking. It gives us a way to stop treating recurring problems as isolated incidents and start treating them as evidence.