A FEELING IS A HYPOTHESIS, NOT AN AUTHORIZATION

One operations manager to another If you have ever inherited an operation from somebody who says, “I just feel like we should run it at sixty percent tonight,” you know the particular kind of headache I am talking about. I like intuition. I use intuition constantly.

I can look at a merge and think, that does not sound right. I can look at a staging area and think, we are going to bury ourselves in cages. I can look at a rate and think, that number is technically fine and operationally dangerous. I can look at a photograph of a building years later and remember the cadence.

That is intuition. It is useful because pattern recognition lets an experienced operator notice something before the formal metric has finished introducing itself. But a feeling is not an authorization. A feeling is a hypothesis.

That distinction has saved me from a lot of bad ideas, including my own.

THE TWO-YEAR PROBLEM

The longer you operate the same system, the more dangerous confidence can become. You have seen Christmas. You have seen Prime. You have seen weather.

You have seen low staffing. You have seen overstaffing. You have seen equipment failure. You have seen a weird Tuesday where nothing made sense and then discovered one small upstream change had created half the mess.

Eventually you develop a sense of the building. That is real expertise. But the building does not owe you obedience because you have experience. Conditions change.

Volume mix changes. Equipment changes. People change. Downstream capacity changes.

A new process can alter an old relationship. That is why I like long periods of data. Not because I worship spreadsheets. Because two years of operating history can tell you which “obvious truths” are actually seasonal accidents.

One week can tell you what happened. A month can show a pattern. A year can reveal seasonality. Two years starts giving you enough repeated conditions to ask whether the relationship survived another cycle.

That is where rate and volume stop being the same story.

VOLUME IS WHAT ARRIVED. RATE IS HOW THE SYSTEM BEHAVED.

Managers mix these up constantly. A high-volume day can have a mediocre rate. A low-volume day can show a fantastic rate and still tell you almost nothing about maximum operating capability. Suppose your building moves 20,000 units.

Is that good? I have no idea. How long did it run? How much labor was present?

What equipment was available? What was the volume profile? How much did it dwell? What quality did you hold?

What did downstream receive? What was the departure cadence? Were you starved for work? Were you flooded?

Did you create rework? Did you consume tomorrow's capacity? The volume is true. The meaning is missing.

Rate is not automatically the answer either. A beautiful rate can be produced during a narrow interval when the operation had exactly the easiest work available and everything downstream was clear. Congratulations. You have proven that one piece of the system can sprint downhill with a tailwind.

I want to know what it can sustain.

THROUGHPUT IS A RELATIONSHIP

Throughput is not simply “units per hour.” It is the result of relationships. Labor. Flow.

Equipment. Staging. Routing. Quality.

Doors. Trailers. Downstream capacity. Time.

If I make one component faster and the next component cannot absorb the output, I did not necessarily increase throughput. I may have increased inventory between processes. That is why I get twitchy when someone says, “We just need to get the rate up.” Which rate?

Where? For how long? And what happens next? The next question is always where I live.

THE SCOREBOARD CAN BE RIGHT AND STILL MISLEAD YOU

One of the most useful lessons I learned in larger network operations is that a metric does not have to be wrong to lie to you. The number can be perfectly accurate. The boundary around it can be wrong. Your building clears all available outbound freight.

Great. Maybe the building metric turns green. But perhaps the final trailer left badly utilized. Perhaps another site in the region needed that transportation capacity.

Perhaps you consumed shared equipment that the next site now lacks. Perhaps the downstream node received more than it could process. Perhaps the next shift inherited a mess. The building did exactly what the scoreboard asked.

The network lost. Nothing in the local number was false. It was incomplete. That is why I want managers to understand how metrics are designed, not merely read them.

What behavior is this metric supposed to produce? What behavior can somebody accidentally optimize instead? What consequence exists outside the measurement boundary? Those are grown-up metric questions.

THE 60,000-UNIT LESSON

I have one building in my history that I use as a private calibration point because the change in its operating envelope was so dramatic. At one stage, around 20,000 pieces could feel like a huge event. Later, ordinary days could exceed that. High-volume events eventually moved north of 60,000 units per day.

That does not mean the conveyor suddenly learned to run three times faster. The surrounding system changed. Staging. Doors.

Trailers. Flow. Maintenance. Labor.

Scheduling. Equipment. Downstream buildings. The relationship among those components evolved.

That is the important part. If I show you only the 60,000 number, I have given you a trophy. If I show you how the operating envelope changed, I have given you something you might actually use.

THE OPERATING ENVELOPE

This is the phrase I want managers to think in. What is the operating envelope? Not the record. Not the design maximum.

Not the best five-minute interval. The range of conditions in which the operation can perform reliably without creating a larger failure. That includes quality. Safety.

Recovery. Downstream consequence. A record is fun. An envelope is useful.

Once you understand the envelope, you can test its edge. Deliberately. One variable at a time when possible. Document what changed.

Observe. If the system responds well, the known envelope expands. If it responds badly, congratulations. You just bought information. That is improvement.

“I feel like sixty percent would be better” is not improvement. It is a hypothesis looking for a test plan.

THE BUILDING DEBUGS YOU BACK

Physical operations are wonderful because they have no respect for your self-esteem. You make a change. The building responds. Sometimes the response is exactly what you predicted.

Sometimes the visible failure appears nowhere near your change. A merge backs up because downstream slowed. A lane overloads because allocation changed upstream. A package recirculates because an eligibility condition was wrong.

The problem appears here. The cause lives over there. That is debugging. Where did this enter?

What touched it? What changed its state? What rule routed it here? Where should it have gone?

What was different this time? You do not solve that by yelling at the pile. You trace.

THE HUMAN WHO “KNOWS” CAN BE THE BIGGEST RISK

Experienced operators are incredibly valuable. They can also become dangerous if the organization cannot distinguish expertise from personal mythology. “I have done this for ten years.” Wonderful.

Show me the relationship. What condition are you reading? What evidence supports the change? What would falsify your hypothesis?

When would you stop? What downstream metric do we watch? If an experienced person cannot explain any of that and the entire argument is “trust me,” I am not saying they are wrong. I am saying we are not done.

The goal of expertise is not to eliminate verification. It is to make verification faster and more intelligent. Pattern recognition should narrow the search. Data should decide whether the pattern still applies.

A FEELING IS OFTEN WHERE THE BEST WORK STARTS

I do not want to sound anti-intuition because that would be absurd. Some of the best operational improvements start with a person saying: That looks wrong. That sounds wrong.

Why are we doing this? Why does this package stop here? Why does the associate walk all the way over there? Why does this report take three hours?

Why are we staging freight that could go directly to the trailer? That discomfort is valuable. It is the moment somebody notices friction. Then we convert the feeling into a question.

Can we measure it? Can we observe it? What would happen if we removed the step? What constraint would move?

Who receives the consequence? That is how intuition becomes engineering.

THE DIFFERENCE BETWEEN VOLUME AND RATE BECOMES A MANAGEMENT HABIT

Once you really understand this distinction, you start seeing it everywhere. Sales volume versus conversion rate. Customer contacts versus resolution rate. Applications versus acceptance.

Production units versus defect-adjusted throughput. Traffic versus revenue. Hours scheduled versus productive capacity. A business owner can brag about volume and still be losing money.

A warehouse can brag about rate and still be exporting failure. A team can be busy and still be accomplishing almost nothing. The numerator is not the system. The relationship matters.

And the time window matters.

WHAT I WANT FROM A DAILY REVIEW

If I am sitting down with another operations manager after a shift, I do not want a theater production. I want state. What did we expect? What happened?

Where did reality differ? What was volume? What was rate? Where was dwell?

What changed during the shift? What quality did we hold? What exception consumed attention? What happened downstream?

Which part of the result was structural? Which part was one-time noise? Then: What do we want to test tomorrow?

That meeting can be ten minutes if the system is legible. It can be ninety minutes if everyone arrives with a different private version of reality. That is why data quality and state visibility matter so much. They reduce argument.

THE TWO-YEAR VIEW PROTECTS YOU FROM FALLING IN LOVE WITH YOUR OWN STORY

This is where the long history earns its keep. Humans remember drama. The spectacular failure. The record day.

The night everything lined up. The day one person saved the operation. Memory is useful. Memory is biased toward narrative.

Data can remind you that the supposedly magical staffing pattern did not perform the same way the next six times. Or that the process you thought was terrible actually held quality better under a certain volume mix. Or that the “seasonal problem” appeared in April too. Or that the new standard genuinely shifted the baseline.

That is why I like both. The human remembers context. The data remembers repetition. Together they are far stronger.

WHEN THE DATA PROVES YOU WRONG

This is my favorite outcome. You believe something. You measure it. The data says no.

Good. Change the logic. That is not humiliation. That is the system improving your model.

I have no loyalty to being right yesterday. I want the operation to be right tomorrow. That attitude matters enormously in management because teams watch how leaders react to contradiction. If bad news makes the manager defensive, people learn to hide bad news.

If evidence can safely defeat the manager's favorite theory, people learn to bring evidence. That culture is operational capacity.

THE LINE I WOULD WRITE ON THE WALL

If I were back running a floor with another manager, I would write this somewhere we both had to see it:

A FEELING IS A HYPOTHESIS, NOT AN AUTHORIZATION.

Have the feeling. Please. That is experience talking. Then do the next part.

Measure the thing. Check the history. Trace the relationship. Decide what would make the hypothesis true or false.

Make the change deliberately. Watch the next process. Document the result. Then update the operating logic.

That is how a building goes from “this feels like a big day” to routinely doing what used to look impossible. Not because we stopped trusting experienced people. Because we respected their experience enough to test what they saw.

THE MANAGER'S REAL JOB IS TO PROTECT LEARNING

There is one final reason I care about this distinction. Operations is always generating experiments whether you planned them or not. Staffing changed. Volume mix changed. Equipment failed. Weather happened. A new associate entered the process. A trailer arrived late. The environment is constantly perturbing the system. A good manager notices which of those events can teach something. Do not waste the experiment. If an abnormal day forced a different operating pattern and it worked surprisingly well, capture it. If a long-held belief failed under a new condition, capture that. If a process only works when one particular person is present, capture that too.

The operation pays for every disruption. We may as well collect the learning. That is what turns experience into institutional knowledge instead of war stories. War stories are fun. I love them. But if the next manager has to experience the same failure personally before the organization learns the lesson again, we did not build memory.

Measure first. Reason second. Document the result. Update the model. Then go have the feeling about the next thing.

THE PRACTICAL TEST

Whenever I teach this idea, I come back to one practical test: can somebody else use the reasoning? A story is entertaining. A method is transferable. If another manager or owner can read the story and recognize a problem in their own environment, then the experience has become more than history. They can ask the same questions, establish their own baseline, inspect their own constraints, and build an answer appropriate to their own system. That is what I want from these stories.

Not imitation. Recognition. The specifics belong to my life. The logic should travel.

AND THEN REALITY GETS A VOTE

Every plan eventually reaches the point where discussion stops and the system answers. The truck arrives or it does not. The customer buys or does not. The queue clears or grows.

The floor accepts the design or exposes the flaw. The user understands the interface or starts inventing a workaround. I like that moment. It is honest.

You learn what part of your model survived contact with reality. Then you update it and keep moving. That loop—design, observe, learn, redesign—is probably the most consistent habit in my entire career.

THE DISCIPLINE IS WHAT MAKES INTUITION USEFUL

The funny thing about experienced operators is that the best ones can look impulsive from the outside. They make a call quickly. What you do not see is the model underneath the call. Years of relationships.

Failure modes. Timing. Pattern recognition. The speed comes from compression, not carelessness.

That is exactly why I want the disciplined loop underneath the intuition. If I can explain what condition I recognized, which metric I expect to move, what downstream consequence I am watching and when I would reverse the change, then the fast call is still controlled. That is the kind of operator I trust. Fast because they understand.

Not fast because they are certain.

ONE MORE THING ABOUT BEING WRONG

The manager who can say “I was wrong” early usually looks stronger than the manager who spends three hours protecting a bad call. The operation does not care about our pride. If new evidence says stop, stop. If the result says revise, revise.

Fast correction is not weakness. It is control. The only truly expensive mistake is the one we keep funding after reality has already sent the answer.