Your Line Doesn't Start When Your Shift Does

The hour you already paid for

We pulled 14 days of sensor data off a three-line packaging operation at a Midwest meat-and-meals processor. The lines are nominally identical. All three are rated, by their own peak production days, to run 20 parts per minute. Average rate across the two weeks: five to six parts per minute. Not because the equipment can't hit 20. The peak data proves it can. The lines just don't get to 20 most of the time, and the gap is almost entirely on the availability side, not performance and not quality.

Proxy OEE landed at 39.8% for Line 1 and roughly 51-52% for Lines 2 and 3. Line 1's availability proxy was 69.5% against an 80%+ benchmark. The most expensive single pattern in the data: Line 1's first parts of the day stamp at 8:00 AM when the shift starts at 7:00. Line 2 starts at 7:00 when it should be at 6:30. Line 3 is the only one starting on time. That's 30 to 60 minutes of paid, present, on-the-floor labor every morning where nothing is being made. Across two shifts and a 52-week operation, that's the headcount conversation. We have a credible path to take this floor from 10 people to 6 and eliminate the 90+ minutes of daily overtime they're running today. Same equipment. Same product. Same demand.

What actually breaks between shifts

The instinct, when you see numbers like that, is to call it a discipline problem. "They're slow getting started." That's the symptom, not the mechanism. The mechanism is information loss across the shift boundary, and it compounds in the first hour because nothing forces it to be paid down.

A shift handoff carries roughly four things that the next crew needs to be productive at minute one: the state of every machine (running, paused, in changeover, in CIP), the state of every input (staged, short, awaiting QA release), the state of every order (in progress, in queue, on hold), and the state of every operator (who's on what station, who's covering breaks, who's training). When any one of those four breaks down, you don't get a Line that runs slow. You get a Line that's nominally running but is actually walking a fault tree. The supervisor is hunting down a missing case of film. The packer is asking the QA tech whether yesterday's hold was released. The mechanic is re-clearing a jam the previous shift logged in a notebook nobody opened. None of this shows up as downtime on a sensor that's reading a rotating motor. The line looks alive. It isn't producing.

Look at the frozen-meals manufacturer we baselined three weeks ago. Frozen bowls run 48 per minute per line. Costco meals run 40 per minute per line. Two 8-hour shifts, five days a week, 14 to 28 headcount per line depending on the SKU. The operations team itself reported overtime at roughly 4% per shift, mainly concentrated around shift start and shift end. That's the same hour, expressed as money. The crew is staying late to finish what the next crew couldn't pick up cleanly, and the next crew is starting late because they had to reconstruct what the prior crew left them. It's the same dollar bleeding out of both ends of the shift, and most plants book it as "the cost of being a manufacturer" instead of as a fixable defect.

What to do this week

Three diagnostics, none of which need new sensors and none of which need a capital budget.

First: pull 10 working days of raw cycle data, one row per minute, per line. Don't pre-aggregate it. Find the first non-zero minute of each line for each day and plot it against the shift start time. If the lag is meaningfully greater than 10 minutes, the first hour is your problem. The Midwest meat operation's lag was 30 to 60 minutes. That's not noise. That's a structural pattern that pays for itself the day you fix it.

Second: redefine your stop classification before you negotiate any of this internally. The sensor data from the meat plant called events lasting 20+ minutes "micro-stops." That's nonsense, but it's nonsense that protects the status quo because it lets uptime look better than it is. Anything under five minutes is a micro-stop. Five to thirty minutes is an unplanned downtime block. Anything longer is a fault or a planned event. When the data is honest, the first-hour pattern becomes uncontestable.

Third: build a one-page handoff artifact. Not a meeting, not a system, not a software purchase. A printed sheet, signed by the outgoing supervisor and the incoming supervisor, that captures the four state vectors above. We have seen 14% throughput gains and $1.4M in annual labor savings come out of an exercise at a Tier-1 protein co-packer where the only physical change was that the outgoing crew had to write down what they were leaving behind. That's not a process improvement. It's a forcing function. The AI simulation work we did during the walkthrough ran more than 300 scenarios and found that consolidation across two lines plus a shift-window adjustment was the highest-leverage move available. The simulation found it because the handoff data made the actual constraint visible. You don't need the simulation to find this if your first hour is bleeding visibly.

Where capital confidence actually lives

The operating playbook in most rooms I sit in right now is: when the line can't hit demand, buy more line. The CapEx package quotes a faster filler, a second former, an extra changeover crew. The pro forma assumes you'll get nominal speed because that's what the vendor sold. You won't. You'll get whatever your handoff allows, which is roughly your current rate plus or minus the noise floor. The line in the Midwest meat plant can already run 20 parts per minute. The frozen-meals plant has 4% of its labor cost stacked on shift boundaries. The protein co-packer found a 14% throughput unlock without buying anything.

Capital confidence isn't about whether you can afford the equipment. It's about whether you trust the bottleneck story you've been told. If the line is already proving daily that it can hit nameplate during its best hour, the answer to "buy more line" is no. The first hour is the constraint. Fix it before you sign the order.