What I walked into
The plant made drill bits for the industrial market — a $25M facility in Chisholm, Minnesota, part of a private equity-backed premium tools company. When I took it over as GM, we had $1.2 million in back orders and lead times running over a year. The production team was hitting their numbers every month.
107 machines across five departments. Different ages, different makes, no standardized operator positions, no safety markings. Parts moved through the plant in large batches: made in Drilling, parked until enough accumulated to justify moving them, then transferred to Grinding, parked again, and so on through five operations before anything shipped.
The team was not failing. They were doing exactly what the system rewarded them to do. That is where the diagnosis had to start.
The flow problem, visualized
The core issue was batch production: every department ran large batches before passing anything downstream. A part spent a few days being processed and weeks sitting in queues. The diagram below shows what that looks like — and what it looks like after the switch to one-piece flow.
Representative diagram only — company and product details are confidential under NDA. Metrics are accurate; specific identifiers have been omitted.
Every waste was running
In lean manufacturing, waste falls into seven categories. Every one of them was present at this plant. None showed up in the production report.
The seven wastes — how each appeared at the plant
All seven were present. None appeared in the monthly production report.
Find the constraint, put everything there
The temptation in a distressed operation is to fight fires everywhere. There were fires everywhere. The discipline is to not do that — to identify the one area limiting everything else and concentrate all resources there first.
At this plant, the constraint was the cells area: the production cell where parts went through the highest-complexity operations. Everything upstream fed it. Everything downstream waited on it. It was understaffed, undermaintained, and the firefighting had been distributed across the whole floor so that no one had named it clearly as the bottleneck.
I put the best operators there. I directed HR attention there. I made it the highest-paying area in the plant and told people exactly why. Not everyone was happy. My approach was to tell the truth about the logic and let people decide. The constraint is the constraint. You do not make progress by treating every problem as equally urgent.
The incentive was pointed the wrong direction
The production team was rational. Pay was tied to units produced, not units shipped. Running large batches maximizes production numbers per setup and therefore maximizes bonuses. The fact that large batches were generating the back orders was invisible to them, because the incentive did not ask them to care about it.
I changed the structure. Pay tied to what ships, not what is made. Profit sharing on top, so when the business does better the team does better. Once the connection was clear, the team started pushing to clear the back order pile themselves. The incentive and the business objective were finally pointing the same direction.
The training was the hidden bottleneck
One-piece flow requires operators who can move between stations. The plant had operators who had been on the same machine for years, trained by six VHS tapes and whatever the person beside them could demonstrate. Cross-training was theoretically possible but practically blocked — not because of the people, but because the knowledge had never been documented in a form anyone could transfer.
I partnered with a local university to build a curriculum on iPad — structured by machine type, with clear progressions. This was not optional. You cannot implement one-piece flow if operators cannot follow the work through the cell. The constraint was not the machines. It was undocumented knowledge locked inside individual operators that had never needed to move before.
The resistance
People pushed back. Some quit. That is honest.
My approach was the same one I use everywhere: I ran the machines. Not to perform. Because you cannot ask people to change how they work if you do not understand what they are actually doing. Once you have worked the setup sequences yourself, the argument that you do not know what you are asking disappears. The conversation shifts from defending the current state to debating the solution. That is a far more useful argument to have.
The same method, a different floor
A large property management company managed HOA boards, condo communities, and high-rises across a large region. I came in as VP of Operations. Before I changed anything, I went to where the work happens.
In property management, the floor is the building. It is the 9 pm board meeting. It is the maintenance call on a Saturday morning. To understand what the property managers were actually dealing with, I got licensed as a property manager and ran properties myself — a full license, earned in four months. The role did not require it. I did it because the biggest excuse in the organization was the license: a signal that the work was too specialized for anyone without it to fully understand.
Getting licensed took away that excuse. Once I had run the properties, sat through the board meetings, handled the calls, I was no longer an outsider asking people to change. That matters more than most operators realize.
What I found when I did the job
Property managers were running eighty evening board meetings a month. By the time a manager arrived at work in the morning, they had already spent the previous evening in a two-hour board meeting. They were drained before the day started, and their admin queues reflected it — routine tasks that had never been automated were sitting unfinished because no one had capacity to get ahead of them.
The business also held a belief that had calcified into policy: change the property manager on an account and you lose the building. This belief was protecting underperforming managers and blocking any restructuring. When I looked at the data, it was correlation, not causation. Manager changes were happening in response to accounts already at risk — not causing the loss. The sequence in the organizational memory was backwards.
And the portfolio had a small-customer drag: a large number of small, high-maintenance accounts consuming disproportionate manager time relative to what they generated. The instinct was that every customer matters equally. The reality was that these accounts were pulling capacity away from the large, profitable buildings where retention actually moved the numbers.
The excuse stack
What I found — and what replaced each excuse
What changed and what it produced
The structural changes were straightforward once the excuses were gone. Automate the admin. Reassign the portfolio. Restructure the comp. Release the accounts consuming more than they generated. Focus retention effort on the buildings where losing a contract actually moved the P&L.
Client retention went from 90 percent to 96 percent. In property management, where contracts are annual and acquisition is expensive, six percentage points on a large portfolio compounds quickly. EBITDA doubled in twelve months.
The method is industry-agnostic
A drill manufacturing plant in northern Minnesota and a property management company in Vancouver have nothing in common on paper. Different product, different customer, different regulatory environment, different cost structure.
The diagnostic was identical. Go do the work. Map where value gets stuck. Identify the constraint. Find the excuses that have built up around the real problem and remove them. Fix the incentive so it points at the outcome the business actually needs. Build the operating system around flow, not around what is convenient for the machine or the manager.
In manufacturing, value stream mapping makes the waste visible: you draw every step, every wait, every handoff, and the places where time piles up become impossible to ignore. In a service business, doing the job yourself is the equivalent diagnostic. You find where the capacity is actually going. You see which constraints are real and which ones exist only because no one has tested them lately.
The license was not the point. Running the machines was not the point. The point was that both businesses had built up a set of assumptions about what the constraints were — and none of those assumptions had been seriously tested in years. Going to where the work happens is the fastest way to test them. You find the waste. You remove the excuses. Then you can fix the actual problem.