📖 yourdailystory Browse all stories →
Systems & Scale Thinking
Published on Saturday, 12 September 2026 · ⏱ 13 min read

Taiichi Ohno: The Circle of Observation

This morning, we’re talking about Systems and Scale Thinking. It’s a critical skill for any technical leader. And here’s the one big idea that underpins it: The greatest leverage for scaling anything – a product, a team, a company – comes from truly understanding the flow through your entire system. Not just optimizing individual parts, but seeing the whole, interconnected dance. It’s about recognizing the pathways, the delays, the hidden waste, and the feedback loops that dictate how effectively your system operates and grows.

To master this kind of thinking, we’ll break it down into four steps, like learning any new skill.

First, let’s deconstruct it. What’s the smallest, most useful, practicable piece of Systems and Scale thinking? It’s this: identifying bottlenecks and waste through direct, sustained observation. It means stepping back. It means seeing the actual work happening, not the planned work, not the reported work, not the ideal work. It means not guessing, but seeing. This might sound simple, but it’s profoundly difficult for most of us.

Here's why it’s so hard, and how we can remove that friction. Our modern work culture, especially in technical fields, trains us to jump to solutions. We’re rewarded for being busy, for fixing things, for pushing forward. The idea of standing still and just observing feels passive. It can even feel incompetent. The emotional barrier here is often the feeling of not doing enough when you’re simply watching. Your brain screams, "You should be doing something!" But that urgency is precisely the friction we need to remove. We have to treat sustained observation as a critical, active part of problem-solving. Frame it as "data collection." Frame it as "system diagnosis." Because it absolutely is.

Next, how do you learn enough to self-correct? How do you know you’re doing this kind of thinking wrong? You're doing it wrong if your "solutions" keep leading to new, unexpected problems elsewhere in the system. You’re doing it wrong if the problem you thought you fixed reappears later, or if improving one component doesn't actually make the overall system faster or more reliable. That tells you you're still addressing symptoms, not root causes. You're still seeing parts, not the whole. Self-correction means you constantly ask: "Where does this proposed solution merely shift the problem?" And most importantly: "What is the real constraint on total system flow? Where is the flow actually being impeded?"

This brings us to the fourth step: practice with focus. And for that, there's no better story than the one of Taiichi Ohno, the brilliant engineer at Toyota, and his infamous "Ohno Circle."

The Story

The year was 1950. Japan was still reeling from the war. Toyota, a fledgling automaker, was desperate to catch up with the industrial giants of America. Production was slow, quality was inconsistent, and waste was everywhere. Taiichi Ohno was a young production engineer, burdened with the immense task of improving efficiency. He was relentless, methodical, and deeply frustrated by the conventional thinking he saw around him.

He often visited American supermarkets, marveling at their efficiency. He saw how shelves were restocked only when an item was purchased – a "pull" system, driven by actual customer demand, not a "push" system that just kept stocking regardless. This simple observation ignited a revolutionary idea: what if car parts, and eventually cars themselves, were only produced when the next stage of the process, or the customer, actually needed them? This was the genesis of Just-In-Time (JIT) manufacturing. It was radical. It felt counter-intuitive. It felt slow.

Ohno encountered immense resistance. Workers were used to producing in large batches, building up huge inventories "just in case." Managers liked seeing their sections "busy," regardless of whether that output was actually needed downstream. When problems arose – and they did, constantly – the immediate impulse was to patch them. "The machine broke? Fix the machine!" "Parts are late? Buy more machines!" But Ohno saw deeper. He saw that these fixes were often superficial. They didn't address the flow of the entire factory. They didn't ask why the machine broke, or why parts were late, in a way that truly understood the system. They were fixing symptoms, not the underlying illness.

Ohno would walk the factory floor, a stern, imposing figure, his eyes missing nothing. He grew increasingly exasperated with engineers who came to him with reports, with theories, with plans – but seemed to lack a true grasp of what was actually happening on the ground. He believed they were looking, but not seeing.

So, he devised a radical training exercise. He would take a young engineer to a specific spot on the factory floor, pull out a piece of chalk, and draw a large circle on the concrete. "Stand here," he'd command. "And observe."

The instruction was simple. The experience was anything but.

Imagine being that engineer. You're a university graduate, trained in theory, eager to implement complex solutions. Now you're standing in a chalk circle, amidst the din and grime of the factory, doing absolutely nothing but watching. No talking. No taking notes, at least not at first. Just... standing.

The first hour was agony. You'd feel foolish. Unproductive. Your mind would race, wanting to jump in, to point out a flaw, to suggest a change. You'd worry what colleagues thought. This is the emotional barrier we talked about. The feeling of incompetence, of wasting time. It was deeply uncomfortable. Every instinct screamed to do something. But Ohno's instruction was clear: observe.

At first, you might see superficial things: "That machine stops for ten minutes every hour." When Ohno would return, sometimes hours later, he’d ask, "What did you see?" If you gave him a superficial answer, he’d simply say, "You saw the machine stop. But why?" And he’d walk away, leaving you to continue your silent vigil.

So, you’d stand there longer. Your discomfort would slowly give way to a different kind of focus. You’d start to notice subtle patterns. The machine stops. But it stops because the operator has to walk across the room to fetch a specific tool. And why isn't the tool closer? Because it's shared by two different workstations, and the other operator is using it. And why is that operator using it for so long? Because the part they're working on keeps breaking, requiring rework. And why does the part keep breaking? Ah, because the material coming from the previous station is inconsistent.

Suddenly, the "machine stopping" wasn't a problem with the machine, or even just the operator. It was a problem with the system. It was a problem of tool placement, material flow, and upstream quality control. You'd start to see the time things sat idle. The motion that added no value. The defects that propagated from one station to the next, silently, invisibly, until they caused a visible breakdown.

The Ohno Circle wasn't about finding fault with individuals. It was about revealing the structural inefficiencies that the system itself created. It was about seeing the connections that made the whole greater—or less—than the sum of its parts. Ohno was demanding. He didn't accept easy answers. He pushed engineers past their initial discomfort, past their intellectual shortcuts, until they truly saw the system.

This intense, ground-level observation, repeated endlessly, allowed Toyota to identify what Ohno called "Muda" – waste – in seven key categories: overproduction, waiting, unnecessary transport, over-processing, excessive inventory, unnecessary motion, and defects. Each of these was a symptom of a systemic breakdown in flow.

The ability to see these interconnected flows, to understand how small delays here created massive bottlenecks there, to eliminate waste not just in one step but across the entire value chain, was revolutionary. It gave birth to the Toyota Production System, which prioritized Just-In-Time and Kaizen (continuous improvement). This deep systems thinking allowed Toyota to scale massively with fewer resources, higher quality, and incredible flexibility. It eventually allowed them to surpass American auto giants, proving that understanding the system's flow was the ultimate competitive advantage.

The chalk circle on the factory floor, a silent testament to Ohno's radical pedagogy, taught engineers to become diagnosticians of the system itself, seeing beyond the individual components to the intricate dance of the whole. It taught them to truly see to scale.

The Skill

The single clear principle this story teaches us is this: Developing true Systems and Scale Thinking is about training yourself to see the hidden flows and interdependencies in any process, rather than just its visible components. It’s about understanding how parts interact to produce an outcome, and how tiny changes or hidden wastes can ripple through the entire system, affecting its capacity and quality.

Most people look at a complex system – a software platform, a business process, a supply chain – and see a collection of parts. They see a database, a microservice, a team, a machine. But a systems thinker sees the flows: the flow of data, the flow of work items, the flow of decisions, the flow of communication. They see the dependencies: how one component relies on another, how a delay in one area cascades into a bottleneck somewhere else. They see the feedback loops: how an outcome feeds back to influence future inputs.

This skill is profoundly important for technical leaders because every product you build is a system. Every team you lead is a system. Every business operation you oversee is a system. You cannot scale effectively if you don’t understand these underlying system dynamics. If you merely optimize one part of a system without understanding its effect on the whole, you might unknowingly degrade overall performance, create new points of failure, or simply shift the bottleneck elsewhere.

Your goal isn't to be a critic of individual effort. It's to be a diagnostician of the system itself. Like Ohno, you aim to reveal the structural inefficiencies, the points of friction, the hidden waits and reworks, and the emergent behaviors that dictate performance. It’s about asking "why?" not just once, but five times, until you hit a systemic root cause, not just a symptomatic one. This isn't just about efficiency; it's about resilience, adaptability, and the ability to scale your impact in a sustainable way.

Do This Today

Let’s apply this. First, as an AI-era angle for skill building, ask an AI to generate a list of 5 common failure modes (for example: race conditions, cascading failures, data staleness, deployment rollback issues, or unscalable third-party dependencies) for a technical system similar to one you currently work on. For instance, you could prompt it with: "What are 5 common failure modes for a high-traffic microservices-based e-commerce platform?" or "What are 5 common failure modes for a real-time data analytics pipeline?"

Once you have that list of 5 failure modes, pick one that feels most relevant or intriguing. Then, before your team's architecture review meeting tomorrow morning, trace how that specific failure mode could plausibly manifest in a critical part of your current project's system. Use only existing documentation or code you have access to—no new experiments needed.

Done looks like: You can articulate, in a short paragraph, a plausible scenario where that failure mode occurs in your system, identify one specific component or dependency where it would first appear, and suggest one system-level (not just component-level) impact it would have if it actually happened.

Sources

  1. Ohno, Taiichi. Toyota Production System: Beyond Large-Scale Production. Productivity Press, 1988. ISBN: 978-0915299144.
  2. Liker, Jeffrey K. The Toyota Way: 14 Management Principles from the World's Greatest Manufacturer. McGraw-Hill, 2004. ISBN: 978-0071392312. (For historical context and TPS principles).
  3. Toyota Global: About Toyota Production System (TPS). https://global.toyota/en/company/vision-and-philosophy/production-system/

This is a dramatized editorial narrative created for personal inspiration, drawn from publicly available sources listed above. It is not affiliated with or endorsed by the person, company, or their estate.

Read on yourdailystory.com →

One true story a day to get a little better. Start today's →