A database does not exist in isolation. Neither does a team, a model, or a training program. They participate in a system — inputs, outputs, delays, feedback loops, and the occasional surprise that arrives precisely because someone optimized a local metric and ignored the whole.
That is the lens I call systems thinking, and it is one of the through-lines connecting my engineering work, Expert Vision research, and how I advise organizations through complex change.
Seeing the whole
Novices troubleshoot components. Experts troubleshoot relationships — what depends on what, what fails silently, where information degrades, which incentives pull behavior away from stated goals.
In production systems, that means tracing data lineage, failure domains, and operational habits alongside service diagrams. In learning environments, it means asking how feedback reaches the learner, and whether practice conditions match performance conditions. In AI adoption, it means treating governance, platform, and culture as a single architecture — because that is what they are.
Why this belongs in research
Systems thinking is not a buzzword on a whiteboard. It is a researchable stance: you can observe how organizations respond to platform shifts, how teams absorb new tools, how experts re-anchor under pressure, and how small design choices compound over quarters.
Expert Vision studies perception and decision at the individual level. Systems thinking asks the adjacent question: what environment makes those perceptions and decisions better or worse? The two inform each other.
What I look for
When I evaluate a complex environment — technical or organizational — I keep returning to a short list:
- Where are the feedback loops? Can people see outcomes of their decisions quickly enough to learn?
- Where are the boundaries? What fails independently, and what fails together?
- What is being optimized locally at the expense of the whole?
- What expertise is trapped in individuals instead of encoded in systems that respect human judgment?
An open question
We talk about “scaling” constantly. But scale what — throughput, reliability, learning, trust?
Maybe the honest answer is that we scale what we measure. Which suggests a quieter discipline: choose better measures of the whole system, not just the loudest subsystem.
That is the work I am interested in. Not drawing bigger boxes. Learning to see the arrows between them.