There’s something useful about seeing familiar work from a different vantage point. The problems may look different on the surface—different industry, different team, different language, different pressures—but once you spend enough time inside organizations, certain patterns repeat themselves. A process that made sense at one point no longer fits the way work actually happens. A team has adapted around a system instead of through it. Leaders are measuring activity when what they really care about is outcome. People are working hard, but the work is harder than it needs to be.
Somewhere in the middle of all of that, there is usually a gap between intention and execution. That gap is often where the most interesting work begins.
The work of organizational improvement is not new to me. What has been especially energizing is getting to look at it from a wider angle—across different organizations, industries, and types of challenges. And the view from here has reinforced a few things I already believed while sharpening a few others.
Most organizations do not need more ideas. They need more clarity.
Most organizations are full of people who care about doing good work and who can see at least part of what is getting in the way. The challenge is that organizations accumulate complexity. Processes get layered, roles blur, workarounds become normalized, measures multiply, and decisions drift upward. Meetings get added to solve problems created by other meetings. Eventually, people become very good at navigating the system they have, even when the system itself is making the work harder.
That is why improvement work starts with clarity. What are we actually trying to accomplish? What does the current process look like—not the version we think exists? Where does the work slow down? Where does ownership become unclear? What are people doing manually that the system should be doing for them? What are we measuring, and does it actually tell us anything useful?
Sometimes the most valuable thing you can do is help people see what is already there.
The gap between intention and execution is where systems reveal themselves.
Most organizations have a plan. They have policies, workflows, strategy documents, expectations, and goals. Then there is Tuesday afternoon. Someone is out, demand spikes, a customer needs something unexpected, a handoff does not happen exactly as designed, and the team has to make a decision.
That is where we learn whether a process actually works.
A good process does not have to anticipate every possible scenario. It should work reliably for the vast majority of situations—maybe 80 or 90 percent of the time—while giving people enough clarity to think critically through the rest. The question is not whether we can eliminate variation entirely. It is whether we have designed the right guardrails around that variation.
What is truly non-negotiable because of safety, compliance, quality, or risk? Where can employees exercise judgment? When should they escalate? What outcome are we protecting even if the exact path to get there needs to change?
Those distinctions matter. When everything in a process is treated as equally non-negotiable, people eventually encounter a situation the process cannot accommodate. If they have not been given permission or guidance to adapt, the work does not simply stop. People create workarounds.
And often, those workarounds become invisible.
That may be one of the biggest risks of overly rigid process design. We can unintentionally push problem-solving underground when what we really need is to bring it into the open. A workaround is information. It tells us where the process met reality and reality won.
Rather than asking only, “Why didn’t you follow the process?” we should also be asking, “What did the process not account for?”
The goal is not uncontrolled flexibility. It is disciplined flexibility: clear non-negotiables, understood guardrails, appropriate decision-making authority, and a mechanism for bringing exceptions back to the team so we can learn from them.
If the same “exception” keeps happening, it probably is not an exception anymore. It is feedback about the design of the system.
That is the difference between allowing people to quietly work around a process and creating an organization where people can openly improve one.
Good improvement work is diagnostic before it is prescriptive.
There is a natural temptation in consulting—and in leadership—to move quickly to the answer. It feels productive. We see the problem, recommend the fix, assign action items, and move on. But speed can create its own kind of waste. If you diagnose the wrong problem, you can implement the wrong solution very efficiently.
Good improvement work requires enough discipline to understand before acting. What problem are we really solving? How do we know? Who experiences it? Where does it occur? What conditions make it better or worse? What assumptions are we making? What is the data telling us, and what is it not telling us? Most importantly, what do the people closest to the work see that we cannot see from the outside?
The goal is not endless analysis. It is shared understanding. Once a team is aligned around the actual problem, the work usually moves much faster.
The people closest to the work are part of the data.
One of the most consistent lessons across industries is that the people doing the work every day know things that will never show up on a dashboard. They know which step gets skipped, where the workaround lives, which policy creates three extra steps, where handoffs break down, what customers ask for, and what happens when staffing gets tight.
That does not mean every idea becomes the solution. It does mean front-line experience should be treated as operational intelligence rather than anecdote. The best improvement efforts create enough structure to hear that information clearly—and enough trust for people to say it.
Small changes are often more powerful than they look.
Organizational improvement sounds grand. Transformation. Optimization. Excellence. In reality, some of the most meaningful changes are remarkably ordinary: a clearer role, one less handoff, a better schedule, a simpler form, a more useful meeting, a decision made closer to the work, or a process that takes five steps instead of eight.
None of those things are especially dramatic, but they compound. Less rework creates capacity. More capacity improves responsiveness. Better responsiveness reduces frustration. Less frustration improves employee experience. And employee experience inevitably affects customer experience.
That is the interesting part about systems: a seemingly small process change rarely stays small.
Process problems are not always process problems.
The wider the lens, the more obvious this becomes. A workflow issue may actually be an accountability issue. A communication issue may actually be a role-clarity issue. A performance problem may be a leadership-system issue. Resistance may be a credibility problem created by previous change efforts that were launched and abandoned. A strategy problem may actually be a prioritization problem.
This is why process improvement cannot live in isolation. People, process, structure, leadership, measurement, and culture interact whether we acknowledge it or not. If the operating environment does not support the process, redesigning the process alone will not hold.
Measurement should create learning, not just reporting.
Organizations are rarely suffering from a shortage of metrics. There is plenty of data. The better question is whether the data helps anyone decide what to do next.
A useful measurement system should help a team understand whether the outcome is improving, whether the process is becoming more reliable, where variation exists, and what the team is learning. It should help answer whether to stay the course, adjust, or pivot.
That is different from reporting numbers because the numbers are available. Measurement should help people think. If it does not, it is probably just decoration.
Change management is not separate from improvement.
A technically sound process can still fail because people do not understand it, believe in it, or know what is expected. Process improvement and change management are often treated as separate disciplines, but in practice they are inseparable. A process change is a behavior change.
People need to understand why the change matters, what will be different, what good looks like, how they can give feedback, and whether leaders are actually going to stay engaged long enough to learn. That last part matters. People become understandably skeptical when organizations repeatedly launch changes and quietly abandon them a few weeks later.
Consistency creates credibility, and credibility makes improvement easier.
Experience matters. So does curiosity.
One of the things I appreciate most about working across different organizations is the reminder that experience is valuable only if it stays flexible. Pattern recognition matters. Frameworks matter. Knowing what good looks like matters. But so does being willing to say, “I have seen something like this before,” and then immediately ask, “What makes it different here?”
That is the balance. Bring expertise, structure, and perspective—but do not become so attached to the answer that you stop listening.
Good consulting is not about proving you already know. It is about using what you know to help people see more clearly.
The view from here
The more organizations I get to learn from, the more convinced I am that improvement is less about finding the perfect solution and more about creating the conditions for better thinking: better questions, clearer processes, stronger measures, more useful conversations, better accountability, more trust, and more willingness to test, learn, and adjust.
And yes, usually a fairly impressive number of sticky notes.
Recently, I saw a message on a client wall:
You are brave. You are a creator. You are an explorer. You can change the world.
I like it—not because improvement work needs to be dramatic, but because it does require some bravery. It takes bravery to question something that has always been done a certain way, admit that a process is not working, test something new, listen when the answer is not what you expected, and stay curious enough to keep looking.
From here, that feels like a pretty good place to start.