System Ontology

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.