The Most Important Question

I was in a warehouse morning stand-up meeting years ago.

Like most stand-ups, the goal was to keep it under five minutes. Safety, staffing, priorities, goals for the shift…then get everyone to work.

That morning, someone mentioned there had been a safety incident the night before.

Our site leader was there, and it was the first she’d heard about it.

The notification process had failed.

The meeting immediately shifted into problem-solving mode.

What happened?

Who was notified?

Why wasn’t leadership informed?

How did the process break down?

Everyone focused on understanding the incident.

Then the meeting ended.

As we walked out, my boss turned to me and said something I’ve never forgotten.

“No one asked the most important question.”

I looked at her, confused.

She said,

“Is the employee okay?”

Not one of us had asked.

I was just as guilty.

I’d become so focused on the process that I’d forgotten about the person.

That moment changed the way I think about leadership.

Processes matter.

Root cause matters.

Corrective actions matter.

But people always come first.

Sometimes the most important question isn’t about what happened.

It’s about who it happened to.

Heroes Don’t Scale

One of the most interesting consulting engagements I’ve worked on involved a company preparing to move into a much larger warehouse.

They wanted to document their existing processes so they could replicate them in a new facility four times the size.

There was just one problem.

Most of their processes hadn’t been designed.

They had evolved.

Over the years, people solved problems, created workarounds, and made small adjustments until the operation functioned. It worked…but only because everyone knew the unwritten rules. The tribal knowledge.

That’s not a scalable process.

Scalable processes have three characteristics:

They’re simple.
They’re repeatable.
Most importantly, they don’t depend on a single person.

Too many organizations rely on heroes.

The person who knows every shortcut.

The one everyone calls when something breaks.

The one who can fix almost anything.

Most leaders celebrate that person.

I don’t.

Not because high performers are bad.

But what happens if they’re not here tomorrow?

If your operation can’t survive the absence of one person, you don’t have a high performer.

You have a dependency.

The goal isn’t to eliminate great people.

The goal is to build great systems that allow ordinary people to achieve extraordinary results.

That’s what makes an organization truly scalable.

Have you ever worked somewhere that depended on a hero?

Don’t Forget

The first Master Black Belt I worked with said something that stuck with me:

“I can tell you in 30 seconds whether a leader will fail when they try to implement change.”

Want to know how?

It’s easy.

If they start by saying “Don’t forget to…”

Or “Remember to…”

They’ve already failed.

Sometimes people go one step further and create a sign. A visual “don’t forget.”

Yesterday I saw a perfect example.

I was walking a warehouse with one of their senior leaders. We stopped at a sortation area where associates were building outbound pallets.

A system coding change was coming that would eliminate a problem. Until then, they had designed a temporary workaround.

Each pallet had a three sided cone with a barcode on each side. Bolted on top was a handheld tally counter. The sorter would physically move the box to the right pallet, scan the cone, then tap the counter. At the end of sortation, the quantity on the counter should match the quantity the system said. It was simple. It was brilliant. And…it wasn’t working. The first pallet I looked at had 9 boxes on it…and the counter said 0000.

Nobody was using it.

The problem was not that people forgot. The problem was that the process depended on people remembering.

When your improvement relies on memory, reminders, or signs, you’ve created a system that requires perfect human behavior.

Perfect human behavior doesn’t exist.

The best operational improvements don’t ask people to remember.

They make the right action the easiest action, or the only action.

That’s the difference between training people…and designing systems.

Leaders often assume compliance problems are people problems. More often, they’re design problems. If a process depends on memory, reminders, or discipline, it will eventually fail. Great operational leaders don’t build systems that require people to remember. They build systems where the right action happens naturally.

Cruel Summer

The forecast calls for 39°C (102°F) in Paris today.

And it’s still June.

In 2018, I was responsible for Amazon Prime Now refrigeration systems across Europe. Paris. Rome. Berlin. Munich. Barcelona. Madrid.

At the time, I kept hearing the same solution:

“We just need more inspections.”

“We need more preventive maintenance.”

“We need to pay closer attention.”

The problem was that attention wasn’t the issue.

The refrigeration units were designed for a maximum operating temperature of 35°C (95°F).

Climate conditions had changed. The equipment was being asked to operate outside its design parameters.

My argument, which I failed to convince enough people of at the time, was simple:

This wasn’t a maintenance problem.

It was a design problem.

No amount of inspections, checklists, or vigilance could reliably compensate for equipment operating beyond the conditions it was built for.

In August 2018, the heat arrived.

Multiple sites experienced major refrigeration failures, resulting in significant product loss and operational disruption.

I’ve carried that lesson with me ever since:

When a system is operating outside its design limits, asking people to work harder is not a strategy.

Sometimes the process isn’t broken.

Sometimes the assumptions the process was built on are no longer true.

Five symptoms. One root cause.

I spent several hours walking a warehouse last week.

Within 30 minutes I found:

Inventory that had been sitting for years
Overflow space being rented while mezzanine space sat largely unused
Paper-based picking processes
No formal vendor appointment scheduling
Product waiting weeks for putaway

None of these were the root problem.

The root problem was visibility.

The operation couldn’t easily answer:

How full are we?
How long does putaway take?
Where are the bottlenecks?
Which inventory is aging?

Most operational problems aren’t people problems.

They’re information problems.

You can’t improve what you can’t see.

What’s the first KPI you look for when evaluating a warehouse?

Measuring Everything, Managing Nothing

Up is good.

Down is good.

I can’t count how many times I saw those words on Air Force dashboards.

I sat through countless meetings reviewing performance metrics. Break Rates. Repeats. Recurs. FMC rates.

Many of the charts had graph with an arrow in the corner accompanied by one of those simple reminders.

That guidance always struck me as odd.

If someone reviewing the dashboard needs a reminder about whether a metric should go up or down, perhaps the metric isn’t telling the story as clearly as we think it is. If a decision maker needs guidance on whether the metric should be moving one way or another, maybe it’s not even an important thing to be tracking.

Which raises some larger questions:

What does a good dashboard actually look like?

How many KPIs should an organization be tracking?

There is no shortage of things to measure. In fact, many organizations today are moving toward hyper-tracking, collecting data on nearly every action an employee takes throughout the day.

The technology exists to measure almost everything.

The challenge is deciding what actually matters.

A dashboard should not be a collection of every metric available. It should be a decision-making tool.

The best dashboards answer three simple questions:

Are we winning?
Where are we struggling?
What action should we take next?

I’ve always believed every KPI should pass a simple test:

If the metric moves significantly tomorrow, what would I do differently?

If the answer is “nothing,” it probably doesn’t belong on the dashboard.

Too many organizations confuse measuring with managing.

More data isn’t always better.

Sometimes it’s just more data.

The goal isn’t to track everything.

The goal is to understand enough to make better decisions.

Where Should the Pack Table Go?

Years ago, I heard a facility manager dismiss Six Sigma and Continuous Improvement as a sham.

His example:

At his warehouse, the pack stations had been rearranged over and over again across the years. The pack table moved from one side of the work area to another…9 o’clock, 12, 3, 6…and eventually right back where it started.

His conclusion:
“All that Lean effort just ended up exactly where we began.”

But my first question was:
Did it?

The layout may have looked the same. The operation probably wasn’t.

The workforce changes.
The product mix changes.
Volumes change.
Customer expectations change.

A healthy operation adapts constantly, even if some solutions eventually cycle back around.

That’s the part people miss about continuous improvement:
it isn’t a one-time event or a quarterly initiative. It’s a culture.

At its core, it really comes down to three things:

Teams that feel empowered to identify problems and suggest changes
A disciplined process to evaluate and implement improvements
Reliable measurement to determine whether the changes actually worked

Simple in theory.

Very difficult in practice.

Continuous Improvement Is Not an Event

A few weeks ago, while touring a large 3PL warehouse near my home, the site leader proudly told me they require one continuous improvement event per quarter.

What struck me was that someone at his relatively senior level viewed continuous improvement as an event…a one-time thing…a task performed on a regular basis, instead of something every person should be doing every single day.

It reminded me of a story from World War II. Eisenhower was once quoted as saying:

“I don’t know what the hell this ‘logistics’ is that Marshall is always talking about, but I want some of it.”

A surprising number of senior leaders seem to have the same surface-level understanding of continuous improvement. They know a few buzzwords, and they know they’re supposed to do this thing, but the deeper philosophy is missing.

I imagine the reason a quarterly requirement exists is because it’s easy to measure. You can check the box, show that you completed it, and create a visible display of action.

In fact, I’ve been in meetings where someone mentioned an idea for a CI initiative, and someone interrupts:

“Wait, didn’t we just do one last month?”

I’ve always said this is the equivalent of going to the dentist twice a year…and that’s it. No brushing. No flossing. Your oral health box was already checked off last September.

True, lasting continuous improvement starts at the lowest level. It comes from individuals making small, incremental improvements to their jobs every single day.

Tiny 1% improvements that, over time, compound into something far more impactful than any quarterly event ever could.

The challenge is that those improvements are much harder to individually measure.

The organizations that truly embrace continuous improvement are not the ones that schedule it once a quarter. They are the ones that build cultures where people are expected, empowered, and encouraged to improve something every single day.

Continuous improvement is not an event.

It’s a mindset, a culture, and a daily habit.

A Scalable Process Doesn’t Depend on Heroes

What does it mean to say a process is scalable?

It’s simple.

It’s repeatable.

It doesn’t rely on Jim. Or Joe. Or Bob. Or any individual to be on shift that day.

A lot of operations look stable at smaller scale because experienced people are compensating for weak processes in real time. They know the shortcuts. They know the workarounds. They know where the problems usually happen.

But once volume increases, complexity increases, or new people enter the system, those gaps become much more visible.

That’s when organizations start confusing growth problems with operational maturity problems.

If performance depends heavily on individual heroics, the process probably isn’t scalable yet.

Small Frictions Become Big Operational Problems

One of my favorite CI projects was also one of the smallest.

A few extra seconds per transaction doesn’t sound meaningful…until it scales across an entire operation.

Lots of Continuous Improvement projects are ambitious. Some require massive investment in new tools, equipment, or warehouse reconfiguration. In fact, some leaders are convinced that all improvement needs to be on a grand scale. But my favorite CI project I’ve ever led centered around something incredibly small: one extra data entry.

At the time, I was leading a receiving operation with roughly 20 employees handling grocery inventory. Receivers would scan incoming product, stow it directly to shelf locations, and manually enter expiration dates into handheld scanners as part of the receiving transaction.

The process itself made sense. The system had expected shelf-life ranges configured by product type. If an employee entered a date outside the acceptable range, the system would prompt for a second entry as verification. That safeguard was designed to catch mistakes before inventory hit the floor.

The problem was that the product characteristic tables…the part of the code these entries would reference…was wrong. The data was bad. For most products, it was set to 1 day. A can of soup? One day. A gallon of milk? One day. So instead of prompting for re-entry only on exceptions, the system was requiring a second date entry for every single item received.

At first glance, it didn’t seem catastrophic. Nobody was stopping production. No alarms were going off. The operation continued moving.

But after spending time on the floor, it became obvious that the extra step was creating constant friction in some of the highest-frequency transactions in the building.

That observation led to a simple question:

“What is this actually costing us?”

Quantifying the Problem

The receiving team averaged roughly:

20 employees
7.5 working hours per shift
~120 units per hour per employee

That translated to approximately 18,000 units processed daily.

We estimated the unnecessary second date entry added about 2.5 seconds per item. Again, individually, almost nothing.

At scale:

18,000 units/day × 2.5 extra seconds
= 45,000 lost seconds daily
= ~12.5 labor hours per day

That equated to:

roughly 8% productivity loss
or nearly 2 full-time employees worth of capacity consumed by a software defect

Not because employees were underperforming. Not because the process design was poor. Simply because a small system issue had embedded itself into a high-volume workflow.

The Bigger Lesson

This experience reinforced something that applies far beyond warehouse operations:

Small inefficiencies become massive when attached to high-frequency work.

Most operations do not collapse because of dramatic failures. They erode through thousands of tiny interruptions:

extra clicks
duplicate entries
unnecessary approvals
avoidable motion
systems that force people to work around them

Individually, these seem trivial. Collectively, they quietly consume labor, attention, and throughput every day. They are waste.

Why Direct Observation Matters

What made this issue visible was not a dashboard or KPI report.

It started with direct observation on the floor. Watching the work happen in real time. Listening to operator frustration. Looking for moments where the process felt slower, heavier, or more repetitive than it should.

That is one of the most overlooked parts of continuous improvement.

You cannot improve work you do not truly understand.

The Outcome

Once the issue was quantified, it became much easier to prioritize and partner cross-functionally on a resolution. The discussion shifted from anecdotal frustration to measurable operational impact.

Fixing the defect effectively returned more than 12 labor hours of productive capacity back to the operation each day without adding headcount.

All from removing a few unnecessary seconds from a transaction repeated thousands of times daily.

At scale, small frictions stop being small.