← ArticlesSystems Thinking for Operational PerformanceEngineering · ManufacturingLesson 29/32← PrevNext →
GuidePublished 14 Aug 20265 min readBy Kevin JoginManufacturingOperational ExcellenceSystems Thinking for Operational PerformanceContext and scope

Engineering · Manufacturing · Operational Excellence

Systems Thinking for Operational Performance

Engineering handbook for systems thinking for operational performance, covering context and scope, the pattern you can't unsee, the uncomfortable truth.

Executive summary

This handbook section converts the supplied engineering material into a practical, source-controlled reference. It concentrates on the following learning outcomes.

Context and scope
The Pattern You Can't Unsee
The Uncomfortable Truth
What This Means For You
Three Questions to Ask Before You Judge Anyone
How to Spot a Bad Process

Context and scope

the practitioner nearly punched a stranger over a plastic chair. And he's one of the kindest people I know.



The Pattern You Can't Unsee

Once the practitioner started looking, he saw it everywhere:

  • The DMV clerk who seems deliberately slow? She's navigating a computer system from 1997 with seventeen required fields and no error messages.
  • The customer service rep who keeps putting you on hold? They're juggling three different software systems that don't talk to each other, with a script that forbids them from saying "I don't know."
  • The doctor who seems rushed and dismissive? They've been allocated exactly seven minutes per patient by administrators who've never treated anyone.
  • Your coworker who "always drops the ball"? They're receiving critical information from three different Slack channels, two email threads, and one voicemail that arrived after they left for the day.

The Uncomfortable Truth

When you put good people into bad processes, they become:

  • Mean-spirited (because they're exhausted and defensive)
  • Foul-mouthed (because no one's listening to polite requests)
  • Even violent (because every other option has been removed)

And here's the kicker: Ask anyone involved to identify the problem, and they'll blame everyone else.

The passengers blame the "petty bureaucrat" check-in agent.

The agent blames the "crazy passengers."

Management blames the "tight-fisted" airline.

The airline blames the "unpredictable" passengers.

Nobody steps back to examine the process itself.



What This Means For You

You're surrounded by bad processes every single day. And you're probably:

  1. Blaming the people instead of the process
  2. Becoming "the bad person" yourself when you're trapped
  3. Missing opportunities to fix what's actually broken

Three Questions to Ask Before You Judge Anyone

Before you blame a person, ask:

  1. What process are they operating within? Map it out. Where are the bottlenecks? Where is information lost? Where are the impossible tradeoffs?
  2. What would a good person do differently in this process? If the answer is "nothing"—the process is the problem.
  3. What would happen if you replaced this person with someone 'better'? If they'd fail in the same ways, the person isn't the issue.

How to Spot a Bad Process

  • The same problems keep happening with different people
  • Good performers suddenly become "difficult" after a role change
  • Everyone's working hard but nothing's getting done
  • The first response to failure is always more oversight, not process redesign
  • "That's just how it is here" becomes an accepted phrase

The Test That Never Fails

Next time you catch yourself thinking "What is wrong with these people?"—pause.

Ask instead: "What process is turning these people into this?"



The Real Opportunity Here

The existence of bad processes everywhere isn't depressing.

It's a massive opportunity.

Every frustrating interaction, every "difficult" person, every system that makes you want to scream—these are all invitations to think differently.

Because here's what happens when you fix the process instead of blaming the person:

  • The "difficult" employee becomes your highest performer
  • The "rude" service provider becomes a customer loyalty machine
  • The "chaotic" team becomes your most reliable unit
  • The "impossible" customer becomes your biggest advocate

The people were never the problem. They were just the most visible symptom.



What the practitioner Does Now

the practitioner still travels through Heathrow sometimes. The check-in process hasn't changed much.

But he has.

When he sees the line snake around the corner, he doesn't feel rage anymore. He feels curiosity.

"What process created this? What would need to change? Who has the power to change it? What would I do if I could redesign this from scratch?"

He's brought this thinking to every organization he's worked with since that Monday morning meltdown.

And here's what he's learned: The people at the front lines almost always know what's wrong. They've just been told the problem is them, so they've stopped saying anything.

Ask them. Listen. Redesign.

You'll be amazed at what "bad people" become when you give them a good process.



Your Turn

Think about the last time you were frustrated with someone—a coworker, a service provider, a family member.

Now ask yourself: What process were they trapped in?

Drop a comment below with your answer. I'd love to hear what you discover when you start seeing systems instead of villains.


Have you ever been the "bad person" because you were stuck in a bad process? What did it feel like? What changed?

Engineering use and verification

Choose and control a process from the required function, material, geometry, tolerance, surface condition, volume, safety and inspection plan. Confirm the process window with representative trials, identify the variables that move quality, and connect each critical characteristic to an observable control and reaction plan. Do not convert a successful source example into a universal limit; validate capability using the actual machine, tooling, material batch and operating conditions.

Handbook workflow

Use the material in four passes. First, define the problem and mark every input that comes from the project rather than from the supplied source. Second, trace the mechanism or calculation from inputs to outputs and test the units at each step. Third, compare the result with a physical estimate, a second method or representative measurement. Finally, record the decision, evidence and remaining uncertainty in the controlled project record. This workflow prevents a reference value from being copied into a design without its original assumptions.

For training, work through one simple case before a production case. Ask the learner to explain the load path, process chain or governing relationship in plain language, then identify what could change the answer. Competence is demonstrated when the method can be transferred to a new case, limitations are stated and verification is selected deliberately.

  • Confirm scope, assumptions, interfaces and required outcome.
  • Use one controlled unit system and show every conversion.
  • Identify current project, customer and regulatory requirements.
  • Separate source examples from mandatory acceptance criteria.
  • Check calculations, tables and selections by an independent method.
  • Verify safety, maintainability and credible failure modes.
  • Record evidence, revisions, approvals and unresolved limitations.
  • Validate the result under representative operating conditions.

Continue learning

Workstyles, Communication and Team RetentionGuide · ManufacturingNEXT LESSON →Operational Rhythm, Buffers and Forecast DisciplineGuide · ManufacturingExperiential Training and Workforce CapabilityGuide · ManufacturingApplying Lean Principles Beyond ManufacturingGuide · Manufacturing