When Data Lies

Apparently, your astrological sign can determine whether aspirin saves your life.

At least, that’s what one analysis of a major heart attack study seemed to suggest.

In 1988, researchers published results from ISIS-2, a large clinical trial examining treatments for patients experiencing a suspected heart attack. The study found that aspirin reduced the risk of death.

The results attracted considerable interest, including requests to break the data down into increasingly specific subgroups.

And that’s where the story gets interesting.

When the results were examined by astrological sign, aspirin appeared to provide no benefit to patients born under Gemini or Libra.

Wait. What?

Did aspirin somehow work differently depending on when you were born?

Of course not.

The finding became a memorable illustration of a fundamental problem in data analysis: if you slice data enough different ways, eventually you’re going to find a pattern that looks meaningful but isn’t.

The problem wasn’t necessarily the data. It was the conclusion someone might draw from it.

This is something I think about a lot as an operations leader.

We break productivity down by shift, department, supervisor, tenure, product, location, and day of the week.

We find a correlation and immediately start looking for a cause.

We build a dashboard, identify an outlier, and launch an initiative to fix it.

But before we act, we should ask a few questions.

  • Is the pattern truly meaningful? Or did we find it because we looked at enough combinations?
  • Is there a plausible explanation? Can we explain why the result occurred, or are we just observing that it did?
  • Can we reproduce it? Does the pattern persist when we collect more data or test it under different conditions?
  • Would this change our decision? If the metric moves, do we actually know what action to take?

I’m a big believer in data. You can’t manage what you don’t understand, and data can expose problems that intuition alone will miss.

But being data-driven doesn’t mean believing every number we produce.

It means understanding how the data was collected, recognizing the limitations of the analysis, testing our assumptions, and being willing to challenge a result that doesn’t make sense.

Data should inform our judgment, not replace it.

The objective isn’t to find a pattern.

It’s to understand the system well enough to make a better decision.

How do you distinguish a meaningful signal from statistical noise in your own operation?

LLM vs. AI

I’ve been thinking a lot lately about the way we talk about artificial intelligence.

Specifically, how often we use the term AI when what we’re really talking about is an LLM, or large language model.

That’s not a criticism of LLMs.

They’re incredibly useful tools.

But I think we’re starting to blur the distinction between what these systems actually do and what we assume they can do.

What an LLM Actually Does

At a basic level, an LLM is exceptionally good at working with language.

It has been trained on enormous amounts of information and can use that training to generate remarkably useful responses to questions, summarize information, identify patterns in language, create content, translate, classify information, and perform many other tasks.

That’s powerful.

But there’s an important distinction between generating an answer based on patterns in information and actually analyzing a business problem using operational data and arriving at a reliable conclusion.

Those aren’t necessarily the same thing.

If I give an LLM a description of a warehouse process and ask it to identify potential bottlenecks, it can give me some very interesting ideas.

But if I give it several years of actual warehouse operating data and ask:

Where is the operation losing capacity?

Why is it happening?

What changed?

What should we do about it?

What will happen if we make that change?

That’s a different problem.

And that’s where I think we need to be more careful with the word AI.

The Operations Problem

I’ve spent most of my career in operations and continuous improvement.

One of the things I’ve learned is that before you try to optimize something, you need to understand what is actually happening.

That’s surprisingly difficult.

Companies have systems that don’t talk to each other.

They have spreadsheets sitting between systems.

They have manual workarounds.

They have people who know how to make things work because they’ve been doing it for 15 years.

Eventually, the process works, but nobody can really explain why.

Then someone comes along and says:

“We should automate this with AI.”

Maybe.

But first I want to understand what we’re actually automating.

If the process is broken, AI isn’t necessarily the answer.

It may simply become another layer sitting on top of the problem.

Where I Think LLMs Are Really Valuable

None of this means LLMs don’t have tremendous value in operations.

They do.

In fact, I think we’re probably still underestimating some of their practical applications.

An LLM can be very good at taking information in one form and turning it into something useful in another.

For example:

  • Matching information to a known set of requirements
  • Summarizing large amounts of information
  • Searching and retrieving information
  • Creating or modifying documents
  • Classifying information
  • Helping people interact with complex systems
  • Translating information between people, systems, or formats

Those are real productivity gains.

And they’re not trivial.

If I have an employee spending four hours a day moving information from one system into another, and an LLM-based tool can eliminate most of that work, that’s valuable.

But notice what we’re doing.

We’re not necessarily asking the system to think like an operations leader.

We’re asking it to recognize, organize, transform, and communicate information.

And that’s a very different proposition.

The Real Opportunity May Be Between the Systems

This is where I think things get interesting.

In many organizations, the biggest source of inefficiency isn’t inside an individual process.

It’s between processes.

Receiving finishes its work, but the information doesn’t make it cleanly into inventory.

Procurement has one system.

Operations has another.

Customer service has another.

Finance has another.

And somewhere in the middle is Mary, sitting at her desk with three monitors, a spreadsheet, and 15 years of institutional knowledge.

Mary is the integration layer.

She’s making the systems work together because the systems don’t actually work together.

That is an enormous opportunity for technology.

But before we automate Mary, we should understand what Mary is actually doing.

Maybe some of her work should disappear.

Maybe some of it should be redesigned.

Maybe some of it should be automated.

Maybe some of it requires a human decision.

And maybe an LLM is the right tool for part of it.

That’s the distinction I’m interested in.

We Need to Stop Asking “Can AI Do This?”

I think that’s becoming the wrong question.

Almost anything can now be framed as an AI problem.

The better question is:

What exactly are we asking the technology to do?

Are we asking it to retrieve information?

Transform information?

Recognize patterns?

Make a prediction?

Optimize a process?

Make a decision?

Execute a task?

Learn from the outcome?

Those are different capabilities.

And they don’t necessarily require the same technology.

An LLM may be an excellent tool for one and a terrible tool for another.

I’m Not Anti-AI

I’m also not an AI evangelist.

I’m old enough to remember when computers first started entering the workplace.

There were plenty of predictions that computers would eliminate jobs and fundamentally change everything.

They did change everything.

But we eventually learned that a computer is a tool.

It can make people dramatically more productive, but it doesn’t eliminate the need to understand the work.

I think we’re going through something similar now.

The technology is moving incredibly quickly.

The temptation is to start with the technology and then look for problems it can solve.

As an operator, I’d rather start in the other direction.

Start with the problem.

Understand the process.

Understand the people doing the work.

Understand where the friction actually exists.

Then determine whether AI, an LLM, automation, a better process, or simply better management is the right answer.

The technology is the tool.

The problem is still the problem.

AI

I’ve been thinking a lot lately about where AI actually fits in operations.

Not where we want it to fit.

Where it actually creates value.

One thing I keep coming back to is that companies are often trying to solve problems with technology that they haven’t really solved operationally yet.

I’ve seen this firsthand.

A process doesn’t work quite right, so someone creates a workaround.

Then another system doesn’t talk to that system, so someone creates another workaround.

Eventually you have a process held together by spreadsheets, tribal knowledge, and the one person who knows how to make everything work.

Now someone wants to automate it.

That’s where I get cautious.

Before we automate, I want to understand the process.
Is it simple?
Is it repeatable?
Can someone other than Mary do it?

If the answer is no, I’m not sure AI is the first thing we need.

But that doesn’t mean AI doesn’t have a role.

It may be very good at connecting information, identifying patterns, handling repetitive decisions, or eliminating some of the friction between processes.

The question isn’t whether AI is good or bad.

The question is: what problem are we asking it to solve?

That’s probably where I land on AI right now.

I’m neither an AI evangelist nor an AI skeptic.

I’m an operator trying to figure out where the tool actually makes the operation better.

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

Warehouse, Fulfillment

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

Refrigeration

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.

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?

Amazon Fresh London

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.