One operations manager to another about walking into a site you do not know The first time you walk into somebody else's building, everything looks wrong. The lanes are in the wrong place. The doors are numbered wrong.
The staging areas are shaped wrong. The people use slightly different language. The conveyor does something yours does not. The break room is apparently on another continent.
Some local expert says, “Well, this site is different,” with the special tone people use when they mean, “Please stop bringing your outside ideas into my weird little kingdom.” And they are right. The site is different. They are also often wrong in the way that matters.
The building is usually not as different as it looks.
THE HARD PART IS KNOWING WHAT IS STRUCTURAL AND WHAT IS LOCAL
When I started working across multiple sites, I could no longer depend on memorizing every odd corner. Inside one building, you can know the sound of the conveyor. You know which door is annoying. You know where the floor gets congested.
You know the associate everybody calls when a particular thing breaks. You know the quirks so deeply they start feeling like laws of nature. Then you walk into another building and none of the scenery matches. That forces you to decide what your expertise actually is.
If expertise means “I know door 142,” you are local. If expertise means “I understand what a dock door does inside the flow system and what relationships determine whether it is useful,” now you can travel. That is a different skill.
THE TRANSFERABLE QUESTIONS
When I arrive somewhere unfamiliar, I want questions before answers. What enters? What leaves? Where does work dwell?
What is the clock? What is the limiting process? Where can work buffer? How much can buffer?
Which equipment is shared? Where does physical reality disagree with system state? What is the normal exception? What happens when the exception fails?
What does upstream believe this site can absorb? What does downstream actually experience? Who knows the weird thing? Those questions work almost anywhere.
The answers change. That is the point. A method should survive local variation without pretending local variation does not exist.
THE FIRST WALK IS NOT AN AUDIT. IT IS ORIENTATION.
I do not like walking into a site and immediately telling people what is wrong. That is a fantastic way to announce you are an idiot before lunch. First, orient. Watch the path.
Ask the operator what the work is supposed to do. Ask what usually goes wrong. Look at the metric. Then look at the floor.
Do they agree? Ask what changed recently. Ask what everybody has learned to work around. The workaround is often where the interesting information lives.
An experienced team may have adapted so successfully to bad architecture that the problem is invisible to leadership. They just carry it. Walk farther. Click more.
Remember more. Move the cage twice. Fix the label. Call Susan.
That is system debt hiding inside competence.
THE BUILDING MAY LOOK DIFFERENT BECAUSE THE HISTORY IS DIFFERENT
Two sites can perform the same function and end up with different physical habits because they grew under different constraints. Maybe one building was opened with different equipment. Maybe another inherited a temporary process that became permanent. Maybe one volume profile demanded more staging.
Maybe the door topology forced different movement. Maybe a software release landed at different points in the site's maturity. Maybe the local team solved a problem creatively and the workaround became standard. Do not erase history before understanding it.
A strange process may be stupid. It may also be carrying a requirement you have not seen yet. That is why I ask: What problem did this solve when it was created?
That one question saves a lot of damage.
THE BEST PRACTICE IS NOT A PHOTOCOPIER
I dislike “best practice” when people use it to mean: Site A did this. Make Site B do this. No.
Site A's result may contain something transferable. The exact implementation may not. If one building succeeds because a staging area sits ten feet from the correct door relationship, copying the staging process into a building where the same area sits fifty feet away may create nonsense. Transfer the principle.
Not the wallpaper. What condition was the original practice protecting? Reduced touches? Better visibility?
Lower dwell? Cleaner priority? Better equipment balance? Safer movement?
That is what we carry. Then we redesign the implementation for the new building.
THE SITE THAT SAYS “WE'RE DIFFERENT”
Every multi-site operator has met this site. “We are different.” Yes. Tell me how.
Not sarcastically. I want the list. Different volume? Different mix?
Different equipment? Different downstream relationship? Different staffing? Different physical layout?
Different departure cadence? Different customer promise? Different legal or safety constraint? Good.
Those differences are inputs. Now we can reason. “Different” is not a shield against improvement. It is a requirement for a better model.
THE SITE THAT SAYS “CORPORATE DOESN'T UNDERSTAND”
That site is sometimes right too. Central models flatten reality. A regional plan sees nodes. The local team sees a broken printer, three absent people, a blocked aisle, one weird trailer and a thunderstorm.
Both views matter. The regional model protects the network. The local operator protects reality. A good multi-site manager translates between them.
Do not let the local site pretend the network does not exist. Do not let the network pretend the floor is a spreadsheet. That middle layer is where a lot of useful leadership lives.
YOU NEED ENOUGH ABSTRACTION TO SCALE AND ENOUGH DETAIL TO STAY HONEST
This became one of the hardest balances in my career. Too local and you cannot scale. Too abstract and you make decisions about fictional buildings. I want a model that is simple enough to travel and detailed enough to survive contact with the floor.
Flow. State. Capacity. Clock.
Buffer. Exception. Owner. Dependency.
Those concepts travel. Door 142 does not. That is why experience eventually feels less like remembering facts and more like carrying a model.
THE TINY MESSAGE THAT LOADS A BUILDING
After enough time in an environment, somebody can send you a tiny exception. A site name. A weird behavior. Six words.
And the rest loads. You remember the operating pattern. Likely failure modes. Which questions matter.
Where to look first. That is expertise becoming compressed. But the interesting part is not the memorized detail. It is that the detail is indexed by relationship.
You hear the exception and know which part of the model it touches. That is what I want to teach the next manager. Do not only memorize your building. Learn why your building behaves that way.
Then you can take the knowledge with you.
THE BUILDING DEBUGS YOU
A new site will always reveal something your model missed. Good. That is why we go. If you believe every building is identical, you will be wrong arrogantly.
If you believe every building is completely unique, you will never transfer knowledge. The useful stance is: I know a lot about this class of system. I know almost nothing about this exact instance yet.
Now inspect. That is a comfortable place for an experienced manager to stand. Confident enough to ask strong questions. Humble enough to change the answer.
THE FIRST HOUR
If I had one hour in a new site, I would not spend it in a conference room. Walk the happy trail. Follow one unit or one class of work. Where does it enter?
Where is it identified? Where can it stop? What makes it eligible for the next state? Where does it wait?
What is the clock? Who touches it? Which touch adds value? Which touch exists because architecture requires recovery?
Then follow one exception. That is often more educational than looking at a hundred averages. The normal path tells you the intended system. The exception tells you how the real system survives.
THE FIRST DAY
Now compare the floor to the metrics. What does leadership believe is happening? What does the operating data say? What do associates describe?
Where do those three stories disagree? Do not rush to pick a winner. Reconcile. Maybe the metric is correct but incomplete.
Maybe the operator sees a local symptom and not the upstream cause. Maybe leadership is working from a historical assumption. The mismatch is information. This is where outside eyes can help without becoming insulting.
I am not there to prove the local team is wrong. I am there to see the relationship they may no longer notice because they live inside it.
THE FIRST WEEK
By the end of the first week, I want a map. Not necessarily a fancy one. Current flow. Constraints.
Recurring exceptions. Key clocks. Buffers. Owners.
Known workarounds. Metrics that matter. Metrics that distract. Downstream consequence.
Then I can start asking: Which relationship has the highest leverage? Not: Which thing looks most annoying?
Those are not always the same.
THE SITE LAUNCH VERSION
Opening sites taught the same lesson under different pressure. A new building has almost no local tradition. That sounds wonderful. It also means you are manufacturing the traditions in real time.
Every temporary answer is at risk of becoming “how we do it here.” That makes early logic important. If the initial process is clear, people build habits around something coherent. If the initial process is sloppy, the workaround becomes culture.
The physical building may be new. The system still needs the same fundamentals. Flow. State.
Ownership. Clock. Exception. Training.
THE BALTIMORE MEMORY
I have talked about opening a sort center in Baltimore and how much I loved moving around. That part of my personality matters here. I never wanted to be permanently pinned to one site because I loved the larger machine. A site is fascinating.
A network is irresistible. Each new building teaches you which parts of your knowledge were real and which parts were merely familiarity. That is a wonderful test. If your method survives another building, you may actually understand the system.
LEAVE CAPABILITY BEHIND
The worst multi-site model is the hero tour. Jamie arrives. Jamie fixes everything. Jamie leaves.
Site falls apart. Jamie returns. Congratulations. We created dependency. I want the improvement to survive the person.
That means plans. Training. Standard work. Measurement.
Escalation. Tools. A clear explanation of why the new process exists. The goal is not to prove I can rescue a site.
The goal is to make rescue less necessary after I leave. That is a much better legacy.
THE BUILDING THAT LOOKED WRONG STARTS MAKING SENSE
This is one of my favorite moments. You spend the first day thinking: Why in God's name is that over there? Then you learn the history.
The constraint. The downstream relationship. The local workaround. Suddenly the weird layout tells a story.
Sometimes the answer is: Oh. That is actually smart. Sometimes the answer is: Oh. That was smart three years ago and now it is killing you.
Either way, now we can work. That is why I do not want instant judgment. I want understanding fast enough that judgment becomes useful.
WHAT I WOULD TELL ANOTHER OPERATIONS MANAGER
When you walk into the next building, do not leave your expertise at the door. And do not carry your last building in like a stencil. Carry the questions. Carry the model.
Carry the habit of tracing consequences. Carry the respect for local knowledge. Carry the willingness to look at the floor when the metric says everything is fine. Carry the ability to distinguish a rule from the reason the rule exists.
Then learn the new site. The building will be different. Of course it will. The doors will be wrong.
The lanes will be weird. The break room will still somehow be too far away. But under the scenery, work still has to enter, change state, move through capacity, survive exceptions, meet a clock and leave somewhere useful. That is the part you know.
And once you can see that, the building stops being foreign. It becomes another version of a system you already know how to learn.
THE SECOND VISIT SHOULD FEEL DIFFERENT
When I return to a site, I want to see whether the first visit left anything behind. Did the team retain the logic? Did the metric hold? Did the workaround disappear?
Did a new constraint emerge? Did the plan survive a different shift? If the answer is no and everything depends on me standing there again, the first visit was not an improvement project. It was a performance. That is a hard standard, but it matters.
Multi-site work becomes valuable when each site increases the network's reusable knowledge. The building teaches us something. We capture it. Another building tests whether the lesson transfers. The model gets better. That is how regional capability grows. Not by finding one genius who knows every door number.
By building a method that lets many people understand why the doors matter.
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 THIRD BUILDING IS WHERE YOU FIND OUT WHAT YOU ACTUALLY KNOW
One building teaches you the process. A second building teaches you that your first building had quirks. A third building starts revealing the abstraction. That is where I think multi-site work becomes addictive.
You begin separating the local costume from the operating skeleton. The color of the tape changes. The naming changes. The physical dimensions change.
But flow still has direction. Queues still consume capacity. Deadlines still create priority. Humans still develop workarounds when systems do not fit.
Exceptions still need ownership. Once you can see that skeleton, a new site stops feeling like starting over. It becomes a new puzzle built from familiar classes of relationships. And I love puzzles.
THE MAP SHOULD GET SMALLER AS YOUR UNDERSTANDING GETS BETTER
At first, you need every detail. Then relationships begin replacing detail. Eventually a few well-chosen states tell you where to look. That is what I want from expertise.
Not an enormous pile of memorized facts. A compact model that points toward the right facts quickly. That is why I can love local detail without becoming trapped by it. The detail teaches the model.
The model lets you travel.