OPERATIONS
I’ve Never Fit Neatly Into One Functional Box
Looking back over more than 20 years of leadership, business ownership, operations, and organizational growth, I’ve realized that much of my career has followed the same pattern.
I find the problem. I learn how the work actually happens. I understand what depends on it. Then I help build whatever capability the organization needs to make it work better and, eventually, operate without depending on me.
I didn’t learn that from an operating framework. I learned it by doing the work.
Kevin’s School of Shortcuts
My career began on the technical side. Long before I had formal language for Lean or continuous improvement, I was practicing many of the fundamentals as an automotive technician. The other technicians even had a name for it: “Kevin’s School of Shortcuts.”
The joke was not that I cut corners. I didn’t. First, I learned the correct way to do the job and understood why it was done that way. Then I looked for a shorter, easier, or faster way to accomplish the same work without compromising the repair.
I learned which tools particular jobs required so I could gather what I needed before I started instead of repeatedly walking back to the toolbox. I looked for unnecessary steps and wasted movement. After every vehicle, I cleaned and reset my workbench so I was ready for the next one. When I found a better way to do the work correctly, I passed that knowledge along to other technicians.
At the time, I wasn’t thinking about 5S, standard work, waste reduction, knowledge transfer, or continuous improvement as management terminology. I was trying to become a better technician and help the people around me become better technicians.
Years later, when I began applying Lean and continuous improvement more formally, the terminology was newer than the thinking. The basic habit had been developing for years: learn the work correctly, understand why it is done that way, remove what does not add value, and pass the better method on.
The Problem Rarely Fits the Box
That way of thinking followed me into business ownership. Once you are responsible for the whole business, functional boundaries become less useful as an excuse. Pricing affects margin. Purchasing affects inventory and cash. Scheduling affects productivity and the customer. Training affects quality. A decision in one part of the business creates consequences somewhere else.
The business is a system. You are accountable for the result.
Later, in startup, high-growth, manufacturing, technology-enabled, and multi-site environments, the scale and complexity changed dramatically. The lesson did not.
Business problems rarely stay inside functional boundaries.
Over the years, I found myself working across operations, manufacturing, technology, R&D, training, customer support, project and program work, process improvement, and other areas as the business required. Eventually I realized I wasn’t moving randomly between functions. I was following the problem.
A manufacturing problem may begin in engineering. A productivity problem may actually be technology. A customer problem may be a handoff problem. A people problem may actually be an operating system problem. If you stop where your functional responsibility ends, you may fix the symptom and never reach the cause.
Understand the Work Before You Change It
One lesson I learned early is not to change something simply because I do not understand it or because it looks inefficient from a distance. Go where the work happens. Watch it. Ask questions. Understand what problem the current process is solving, what depends on it, and why people are doing it that way.
In one growing operation, I watched a person struggle through an unorganized production process. Parts were scattered around the workspace, completed units did not have a defined place, and too much time was spent moving around looking for what was needed.
I did not start by telling him how manufacturing should work. I asked him to walk me through the order in which he actually built the product. We reorganized the work around that sequence, reduced searching and movement, created defined space for the work, and improved available output when demand required it.
Then something more important happened: he began identifying additional improvements himself. That is when improvement starts becoming capability rather than a one-time project. The people doing the work should not be treated as obstacles to change. They are often the people who understand the work best.
From Solving Problems to Building Capability
In a very small organization, being willing to jump into almost anything can be a strength. Sometimes there is no department to push the problem to. Someone has to solve it.
But growth changes the leadership requirement. At some point, being the person who can solve everything becomes a constraint if everything still depends on you.
The job shifts from solving the problem to building the capability that can solve the problem repeatedly.
That capability may be a process, technology, training, governance, documentation, measurements, clearer ownership, a different workflow, additional leadership capacity, or some combination of them. And implementation alone is not enough.
A project can be delivered and still fail to change the business. A process can be documented and still not be followed. Training can be completed without creating capability. Technology can go live without improving the work.
That is why I have long believed that a project is not complete until the business sees the change.
Four Questions for Operations Leaders
Whether you are a supervisor, manager, director, VP, or COO, I believe four questions are worth asking when the same problems keep resurfacing:
1. Do I understand how the work actually happens before I try to change it?
2. Am I following the problem to its real cause, or stopping where my functional responsibility ends?
3. Am I capturing what our best people know and turning it into knowledge the organization can use?
4. Am I building something the organization can own, or something that will continue to depend on me?
What Does the Organization Need Next?
Over time, the organizations, teams, systems, and problems I worked with became larger. The operating pattern remained remarkably consistent: understand the work, find the real constraint, cross functional boundaries when the problem crosses them, build what the business needs, develop the people who will operate it, establish ownership, and let them continue improving it.
The goal is not to become indispensable. The goal is to build something the organization can own without depending on you.
For me, that leads to one of the most important questions in operations leadership:
What does the organization need to be capable of doing next that it cannot reliably do today?
Answering that question may take you outside your functional box. In a growing organization, that is not a distraction from operations leadership. Often, it is the work.
Build the capability. Stabilize it. Develop the people. Transfer the ownership. Then go build what the business needs next.
BUILD. STABILIZE. SCALE.
COO Forum Peer Membership
