This is the first in a series we're calling Flow. It climbs a ladder: one station on the floor, then the front office, then the whole shop running with fewer hands on it, then the work that moves between shops — and finally what happens when enough shops can pass work to each other without a phone call. Software shows up on most rungs. It is never the first rung.
The first rung is a roll of painter's tape.
The question behind "we need a system"
Most conversations with a shop start the same way: we need a system. The office is buried, the floor doesn't know what's next, the owner is expediting by walking around. All true. But "a system" is the answer to a question nobody has asked yet, and the question is almost always this:
Where does the queue form?
Almost every shop has a station where work piles up, and usually everyone knows which one. It's the one with the cart parked in front of it, the one the owner checks first in the morning. That station sets the shop's throughput — how much work gets finished. The whole building ships at the rate that station clears, and not one job faster. Buying software for the other eleven stations changes nothing.
So before anyone quotes you a system, measure that one station. For a week. With what you already have.
Three numbers and a clipboard
Tape a sheet to the wall. Every job that arrives at the station gets a timestamp. Every job that leaves gets a timestamp. At the end of each day, count what's sitting in front of it. That's it. You now have three numbers:
- Arrivals per day — how fast work is being released to the station
- Completions per day — its actual throughput
- WIP (work in process) — the pile waiting in front of it
And one rule from queueing math — Little's Law, proven in 1961 — that needs no software to apply:
Average time a job waits = WIP ÷ completions per day.
Forty jobs on the cart, ten cleared a day: the average job waits about four days at that station before anyone touches it. Not because the machine is slow — because forty jobs were released to a station that clears ten. The release was the problem.
In our experience, that is one of the most common findings of a discovery (our paid first look at a shop), and it's found with a pencil.
Kanban with tape
This is kanban: a full spot on the floor is the signal to stop sending work. Here's the move that costs almost nothing: cap the pile. Put a tape rectangle on the floor in front of the station big enough for, say, twelve jobs. When the rectangle is full, nothing else gets released to it. Nothing. The upstream station stops feeding it and goes to work on something else — or, more honestly, discovers it has nothing else, which tells you something too.
A WIP cap makes over-release visible. Before the tape, the cart grew and everyone assumed the station was slow. After it, the upstream operator is standing there with a job and nowhere to put it, and the real conversation can happen: why are we cutting parts on Monday for a station that can't see them until Friday?
Most "we need scheduling software" turns out to be "we release work too early, and the pile hides it."
The fixes that measure in days
Once the queue is visible, the fixes are often mechanical and cheap, and the clipboard tells you which one is worth doing:
- Resequence. If the station changes over twice a day and each changeover is forty minutes, group the like jobs. You just bought back an hour of throughput without buying anything.
- Move a step. Deburr happening at the bottleneck station instead of after it is throughput being spent on work any bench can do.
- A second fixture. Load the next part while the current one runs. A fixture often costs less than one week of the queue.
- Protect it. The bottleneck never waits for material, never waits for a print, never waits for inspection. Everything else can wait. That station cannot.
Each of these is a measured experiment: change one thing, keep the clipboard going, see if completions per day moved. If it didn't, undo it. That discipline — one change, one measurement, keep or revert — is the entire method, and it's the same method we use when the change is a piece of software instead of a fixture.
Where software finally earns its place
The tape proves the change. Then software keeps the measurement honest once nobody is standing there with a clipboard: a scan in, a scan out, a WIP count that updates itself, a red number when the cap is breached. That's a small tool — a sprint, not months — and it only makes sense after the tape has shown which number is worth watching.
Software laid over a broken flow doesn't fix the flow. It produces a faster, prettier report of the problem. We've been asked to build that report more than once, and the first thing we do is walk out to the floor and ask where the cart is.
What this has to do with hiring us
A discovery starts here — not at the server, at the station. Each two-week sprint we sell is judged by one KPI (key performance indicator: a number written down before the work starts). The first sprint's KPI is often one of the three numbers above, because those are the ones that turn into shipped jobs and cash.
And plainly: most of what's on this page doesn't require us. The tape, the cap, the resequencing — that's yours to do on Monday. If the queue drops, you've saved a discovery fee and learned exactly which number to show the next person who tries to sell you a system.
Next in the series: the piece of paper that gets typed into three different programs on its way through the office, and the small tool that makes it stop.