Stop Fixing People, Start Fixing Processes
What process could you fix tomorrow?
When work is not going the way we want, the most natural explanation is a people problem.
Someone is careless.
Someone is resistant.
Someone is not following through.
Someone is missing the skill set.
Someone knows better but does not do better.
This way of framing failure is deeply human, and it is usually wrong.
Most of the behaviors we label as personal shortcomings are better explained as predictable responses to the system people are working inside. The system shapes what is easy, what is risky, and what gets rewarded. Behavior follows those contours far more reliably than it follows good intentions.
That does not mean understanding people does not matter. It matters a great deal. But the point of understanding behavior is not to assign blame. It is to see what the system is asking people to do, whether anyone meant to ask for it or not.
Once you start looking this way, a subtle shift happens.
Instead of asking why someone failed, you start asking what made that behavior the sensible option in that moment. That question opens the door to change.
This way of thinking is not new. There is an entire field devoted to it.
Long before modern knowledge work, factory settings were studied how work actually flowed through a system. Process improvement emerged from careful observation of existing conditions, not from lectures about effort or attitude. The focus was always on what people did repeatedly and what the system made likely.
At the same time, behavioral psychologists were studying how behavior changes at the individual level. They were not interested in moral character. They were interested in causes. What conditions increase the likelihood of one behavior over another. What feedback strengthens or weakens a response. What happens when constraints change.
Eventually, these two lines of work came together. Behavioral engineering emerged as a discipline that asks a simple but demanding question:
…what behavior do we want, and what conditions will reliably produce it.
Frameworks like the Six Boxes model came out of this tradition. They are rigorous, comprehensive, and effective when you have authority, budget, and organizational reach. They assume you can redesign roles, incentives, information flow, and tooling in a coordinated way.
But what you actually have is a team doing real work under real constraints. You see behaviors that create friction, rework, or risk. You want a different set of behaviors to show up, but you do not control the whole system that produces them.
This is where keystone behaviors matter.
Keystone behaviors are not about fixing people. They are about nudging processes. They are small, observable actions that slightly alter how work flows, what gets noticed, or what happens next. Because they live inside existing processes, they do not require permission or persuasion. They quietly change the shape of the system.
When chosen well, a keystone behavior has a ripple effect. One tiny shift makes other better behaviors easier or more likely. Not because people suddenly believe something new, but because the work itself has changed.
This article is about making that shift in perspective. Away from personal blame and toward process design. Away from pushing people and toward nudging systems.
As you read, hold one simple question in mind.
What process could you fix tomorrow?
