How to Compare the Six Pillars in Operations

The green pillar that is lying to you#

A pillar that looks healthy can be the reason the rest of the operation is smoking. That shows up all the time in a six pillars operations diagnostic, especially when Quality or Customer Service is carrying a lot of hidden work that never makes it into the score.

If you’re asking, “How do you compare performance across the six pillars in an operations diagnostic when one pillar looks healthy but is actually masking downstream issues?”, start by assuming the green number is incomplete, not correct. The comparison problem is usually not the score itself. It’s the work hidden behind the score.

I’ve seen this in Remote / nationwide operations more than once: one team reports clean metrics, another team is drowning in exceptions, and leadership thinks the issue is isolated because the dashboard says so. It isn’t isolated. It’s just being absorbed somewhere else.

Don’t compare pillar scores until you know what each score is made of#

The fastest way to get fooled is to treat the six pillars as if they’re independent. They rarely are.

A strong People score can be propping up weak Flow because supervisors are spending hours on manual workarounds. A healthy Safety pillar can hide deferred maintenance, because the team is choosing not to report near misses or is pushing corrective work into next week. A solid Customer Service score can look fine while backlog is quietly building in fulfillment, dispatch, or billing. A clean-looking Systems & Data pillar can hide manual reconciliation happening off-book, where a person is doing the handoff between two tools that should already be connected.

That is the mistake: people compare pillar scores as if they were separate lanes instead of linked parts of one flow. The evidence you need before trusting a strong pillar is not the score. It’s whether the output of that pillar creates extra load, delay, or rework in the next one.

For a real operations diagnostic, compare:

• volume in
• volume out
• age of exceptions
• rework rate
• handoff delay
• backlog trend

If a pillar looks healthy but its downstream handoff is getting slower, that pillar is not healthy. It is buffering pain.

Key takeaway: A green pillar is only useful if the work leaving it is not creating hidden cost, delay, or exception handling somewhere else.

What to look at first when the dashboard is green but the floor is not#

When the dashboard says everything is fine and frontline teams keep reporting fires downstream, I do not start by arguing with the dashboard. I start by checking whether the dashboard is measuring completed work or just completed tickets.

That distinction matters. A pillar can look healthy because it is benefiting from deferred work, backlog buildup, or hidden exception handling.

The first things I look at are:

1. Ageing work

   • Open items by age bucket
   • Stale exceptions
   • Aging customer cases, work orders, or corrective actions

2. Backlog movement

   • Is the backlog shrinking because work is done, or because work is being reclassified?
   • Are items being pushed into another queue, another shift, or another team?

3. Manual overrides

   • How often are people bypassing the normal process?
   • Who is making the exception call?
   • Is that exception handling visible anywhere, or just living in Slack, email, or a supervisor’s head?

4. Downstream rework

   • Returns, corrections, reopen rates, repeat contacts, scrap, or re-inspections
   • If the first pillar is truly healthy, rework should fall, not just move

If you want one practical rule, use this: a pillar is not healthy if it creates work that shows up later under a different owner. That is the cleanest way to catch masking downstream issues before they spread.

The comparison method that actually surfaces masking effects#

If you’re trying to answer, “How do you compare performance across the six pillars in an operations diagnostic when one pillar looks healthy but is actually masking downstream issues?”, trend-by-trend analysis is useful, but it is not enough on its own.

Normalized scorecards help when teams use different raw units, but they can flatten the story. Process flow mapping is the most reliable way to expose masking effects because it shows where work waits, loops back, or gets handled off-book.

What works best in practice#

I usually use all three, but in this order:

Method	What it catches	Where it fails
Trend-by-trend analysis	Direction changes, sudden deterioration, seasonal shifts	Misses hidden handoffs and local workarounds
Normalized scorecards	Lets you compare different pillars on one scale	Can hide the real volume and context behind the score
Process flow mapping	Shows where work piles up, loops, or gets reworked	Takes more effort to build, especially if data definitions are sloppy

If I had to choose one method to surface masking effects, I would choose process flow mapping paired with a downstream impact assessment. In plain English, that means tracing what happens after the green metric is posted.

For example, if Customer Service looks strong because calls are answered quickly, but the call center is escalating unresolved issues into Flow, then the “healthy” pillar is just moving pain. The map will show it. A scorecard may not.

That is why a six pillars operations diagnostic should not stop at pillar-level averages. It needs to follow the work.

How to handle different definitions across teams without fooling yourself#

This is where a lot of diagnostics go sideways. Each pillar is often owned by a different team, and each team uses its own definitions. Quality says defect. Safety says incident. Customer Service says resolved. Flow says completed. People says staffed. Systems & Data says synced. Everyone is technically right, and the comparison still means almost nothing.

If the definitions are different, the comparison is not precise. It is decorative.

To make the pillars comparable, I ask for three things before I trust the numbers:

• One shared event definition
  • What counts as a case, a defect, a handoff, a closure, an exception?
• One shared time boundary
  • Same period, same cutoff rules, same treatment of carryover work
• One shared unit of impact
  • Cost, time, volume, risk, or customer impact, but not a random mix of all four

Then I build a cross-pillar view using the same questions for every team:

• What enters the pillar?
• What leaves it?
• What gets delayed?
• What gets reworked?
• What gets hidden in manual handling?

That is how you compare pillar performance without pretending different systems are identical.

In Remote / nationwide operations, this matters even more because teams are often spread across sites, shifts, and tools. One team is living in Excel, another in a WMS, another in Zendesk, and another in a whiteboard huddle. If you do not normalize the definitions first, your operations diagnostic metrics will look tidy and still lead you to the wrong fix.

The evidence that a strong pillar is not hiding a systemic issue#

A healthy-looking pillar is only trustworthy when the downstream evidence agrees with it. I want proof in at least three places:

1. The next pillar is not absorbing extra work

   • No rise in rework, exceptions, or queue age

2. The work is actually completed, not deferred

   • No growing backlog, no aging open items, no “we’ll handle it next week” pattern

3. The process is stable without heroics

   • No dependence on one experienced person, one shift lead, or one manual workaround

If those three are true, the pillar is probably healthy. If not, the green score is a false comfort.

A classic example: a Safety pillar shows low incident rates. Great, until you notice maintenance tickets are being closed without completion, or supervisors are coaching people not to log small events because “it makes the site look bad.” That is not safety performance. That is suppressed reporting. The score is green because the system is hiding risk.

The same thing happens in Customer Service. Response time looks excellent, but first-contact resolution is flat and repeat contacts are climbing. The pillar is not solving issues. It is just answering them faster.

And Systems & Data is a natural place for this to hide. The dashboard says the system is clean, the integration report says success, and leadership assumes the handoff is working. Meanwhile, someone is exporting a CSV, reconciling records by hand, and rekeying the exceptions off-book. The pillar looks healthy because the manual patch is invisible.

The comparison that surfaces the real bottleneck#

The most useful cross-pillar performance analysis is not a ranking from best to worst. It is a dependency check.

I compare each pillar across four questions:

• Does this pillar create work for another pillar?
• Does it reduce work for another pillar?
• Does it hide work through backlog, exceptions, or manual handling?
• Does its “good” performance depend on someone else carrying the cost?

That lens usually finds the real bottleneck faster than a raw score ever will.

If you want a simple field test, use this sequence:

1. Pick the greenest pillar.
2. Trace its output into the next two handoffs.
3. Look for rework, delay, or exception handling.
4. Compare that with the team’s own pain points.
5. If the floor says one thing and the dashboard says another, trust the flow, then investigate the definitions.

That is the answer to “How do you compare performance across the six pillars in an operations diagnostic when one pillar looks healthy but is actually masking downstream issues?” You do not compare the scores in isolation. You compare the work, the handoffs, and the hidden cost.

A two-week diagnostic catches this faster than a dashboard review#

A dashboard review tells you what is green. A two-week operations diagnostic tells you why it is green.

That short window is enough to agree on definitions, watch the work, pull the right data, interview the people doing the handoffs, and rank the findings by downstream impact. It is also long enough to catch the patterns that one meeting will miss, especially when different teams are reporting different versions of the truth.

For businesses in Remote / nationwide, that matters because scale makes masking easier. The bigger the operation, the more likely a strong pillar is being subsidized by silent work elsewhere. That is exactly where operations consulting earns its keep, because it finds what is slowing the business down and stays until the change actually sticks.

Key takeaway: If one pillar looks great while another team is firefighting, the issue is usually not the pillar score. It is the hidden transfer of work.

What to do next#

Start with one pillar that looks unusually healthy. Pull its last 8 to 12 weeks of trend data, then trace the downstream handoff for the same period. Compare backlog age, rework, exception handling, and manual overrides against what the dashboard says. If the numbers are clean but the flow is messy, you have found the masking effect.

If you want a faster path, use the two-week diagnostic template and do the comparison with structure instead of guesswork. Or, if you want it handled end to end, book a guided operations diagnostic with Ops Acceleration. It is built to compare the six pillars, surface masking downstream issues, and turn that into a fix you can actually run.