On this page
The Toyota Way
Ammar Najjar · Posted on August 27, 2026 · 10 min readproductivity
For an engineer, The Toyota Way (Jeffrey K. Liker, 2004) reads less like a history of a carmaker than like a field guide to building and improving systems. WIP limits, stopping when quality deteriorates, developing people instead of merely assigning work, understanding a problem before proposing a solution, and continuously improving how the system works all map surprisingly well to software engineering and technical leadership.
Liker, professor of industrial and operations engineering at the University of Michigan, spent years studying Toyota’s operations and distilled what he found into a simple central argument: Toyota’s success comes from a coherent management philosophy built around long-term thinking, effective processes, respect for people, and disciplined problem-solving. The individual production tools matter less than the thinking behind them.
That point matters more than it sounds. Companies that copy tools such as Kanban, Just-in-Time, or Andon without adopting the thinking behind them tend to fall back into their old habits.
Where it started: Sakichi and Kiichiro Toyoda
In the 1920s, Sakichi Toyoda developed an automatic loom that stopped when a thread broke. Instead of producing defective fabric, the process halted so the problem could be addressed immediately. His son Kiichiro later founded Toyota Motor Corporation, but the principle behind Sakichi’s loom became more influential than the machine itself: when something goes wrong, make the problem visible and stop it from propagating.
That idea became jidoka, building quality into the process. It runs through the Toyota Production System and reappears in the Andon system, where workers signal a problem immediately rather than allowing defective work to continue downstream. Stopping the line to fix the root cause beats letting a defect propagate and paying for it later.
The first P: long-term philosophy
Toyota’s first principle challenges organizations dominated by short-term targets: decisions should be made with a long-term perspective, even when that comes at the expense of immediate financial results.
Profit matters, but it is not treated as the only purpose of the organization. The broader objective is to create lasting value for customers, employees, partners, and society while building capabilities that allow the company to remain successful over decades.
One example discussed by Liker is Toyota’s joint venture with General Motors at the NUMMI plant in California. Toyota invested in people, training, processes, and cooperation between two very different organizational cultures.
The contrast Liker draws with Daimler and Chrysler is instructive. Their merger struggled with cultural differences and conflicting management approaches. Sustainable cooperation requires more than transferring processes from one organization to another. Culture, trust, and capability have to be developed over time.
This long-term orientation also appears in Toyota’s preference for developing important capabilities rather than treating everything as something that can simply be purchased from outside. Knowledge accumulated through experience becomes part of the organization’s competitive advantage.
The underlying principle is straightforward: optimize for long-term capability.
The second P: lean processes
Toyota’s production system is built around making work flow efficiently while continuously eliminating waste.
A central idea is One-Piece Flow: products or work items move continuously through value-adding steps with as little waiting, inventory, batching, and interruption as practical. Smaller batches and lower work-in-progress make problems visible earlier because defects cannot remain hidden behind large inventories of unfinished work.
Flow connects directly to the pull system. Work should be triggered by actual downstream demand rather than simply pushed into the system because capacity exists upstream.
This helps reduce three forms of inefficiency Toyota describes:
- muda: waste and activities that do not create value
- muri: overburdening people or equipment
- mura: unevenness and instability in the process
Heijunka, or production leveling, complements this idea by creating a more stable and sustainable work rhythm. Instead of alternating between overloaded periods and idle capacity, Toyota tries to smooth demand and workload where possible.
This stability makes another principle possible: standardized work.
Standardization at Toyota is not intended to freeze a process permanently. It establishes the best-known current way of doing something so that everyone has a common baseline. Once that baseline exists, people doing the work can identify problems, experiment with improvements, and update the standard.
Quality is also built into the process rather than inspected only at the end.
The Andon system allows workers to signal immediately when they notice a defect or abnormal condition. Depending on the situation, support is triggered and the process can be stopped until the problem is understood and corrected.
The principle is the same one behind Sakichi Toyoda’s loom: do not knowingly allow a problem to continue downstream.
The third P: people and partners
One of the most important parts of the Toyota Way is easy to overlook because lean is often reduced to process optimization.
Toyota’s system depends on people being capable of improving the system themselves.
Leaders are developed internally wherever possible so that they understand both the work and the philosophy behind it. Employees are not expected merely to execute predefined instructions. They are expected to understand problems, contribute improvements, and continuously develop their capabilities.
This changes the role of leadership.
A manager’s job is not simply to make every difficult decision or personally solve every important problem. A strong leader develops people who can understand problems and solve them independently.
Company goals provide direction from the top, but much of the intelligence about how those goals should be achieved comes from the people closest to the work.
The same philosophy extends to suppliers and external partners. Toyota does not treat every supplier relationship as a short-term transaction. Long-term partners are challenged to improve, but Toyota also invests in helping them build stronger capabilities.
The objective is to make the broader system stronger as well, ensuring Toyota benefits without pushing costs and problems onto partners.
For me, this is one of the most transferable ideas in the entire book: a leader who solves every important problem personally may produce good short-term results while weakening the organization’s long-term capability.
The fourth P: scientific problem-solving
Toyota’s approach to problem-solving is based on disciplined observation, experimentation, and learning.
The guiding concept is genchi genbutsu, usually translated as “go and see.”
Managers are expected to understand the actual situation where the work happens rather than relying only on reports, assumptions, or second-hand explanations. Before deciding what should change, they first need to understand what is really happening.
The famous Five Whys technique follows the same philosophy. The objective is not to accept the first plausible explanation for a problem, but to continue investigating until the underlying cause becomes clearer.
The general pattern resembles scientific work:
- Observe the current situation.
- Understand the problem.
- Form a hypothesis.
- Define a target condition.
- Experiment with a change.
- Observe the result.
- Adjust and repeat.
This thinking is also reflected in stories about Ohno circles, named after Taiichi Ohno, one of the key architects of the Toyota Production System. Managers were asked to stand in one place on the factory floor and observe the work for an extended period.
The exercise sounds almost trivial, but the point is important: resist the urge to immediately intervene.
Observe first, understand the actual system, then improve it.
Large problems can then be decomposed into smaller problems, investigated systematically, and solved through repeated cycles of learning rather than through one large speculative solution.
How I Apply These Ideas
Several of Toyota’s principles map to how I work as an engineer and technical leader.
-
Stop the line when something breaks: A failing build, unreliable test, or repeatedly ignored alert is the software equivalent of a broken loom thread. Continuing as if nothing happened lets defects accumulate, exactly what the Andon cord exists to prevent. My instinct is to pull the cord early: make the problem visible, create a trackable issue, and delegate its investigation instead of ignoring it. I restore that build, test, or alert to full trust only once the root cause is fixed, so it means something the next time it fires.
-
Go and see for yourself: Rather than reason from tickets and assumptions, I reproduce the problem and look at the actual system. Across teams, I join their reviews instead of relying on reports, so I see what they struggle with firsthand.
-
Standardize before you improve: You cannot safely optimize or automate a process that exists only as tribal knowledge. Whenever I take over or depend on a process that lives only in repositories, old issues, and people’s heads, I collect that distributed context, transfer ownership, and get it documented before changing anything. That written baseline is what makes the next improvement measurable and the process automatable.
-
Develop problem-solvers, not dependencies: When a problem escalates, I usually have my own view but restrain myself from imposing it. I explain the constraints, ask the team for their assessment, and challenge their reasoning through questions, letting them own the decision. The fix matters, but the real win is that the team reasons through the problem and owns it themselves, so the next one gets handled without me. I have written about the same move in Give Autonomy a Time Boundary.
-
Pull, don’t push: I start new work when capacity frees up, not merely because more work exists. Finish work before starting more: less multitasking, less partially completed work, more finishing.
My Top 5 Takeaways
- Optimize for long-term capability.
- Standardize the current process before trying to improve it systematically.
- Make problems visible and address them before they propagate.
- Develop people who can solve problems instead of creating dependencies on experts.
- Go and see the actual situation before forming an opinion or proposing a solution.
Who Should Read This Book?
Anyone who builds and improves systems for a living, whether those systems involve manufacturing, software, teams, or organizations.
It is particularly valuable for engineering leaders and senior engineers because many of its ideas apply beyond production processes. They apply to how teams ship software, how they react to defects, how technical decisions are made, how knowledge spreads, and how people develop.
If your work involves improving not only the product but also the system that produces the product, The Toyota Way provides a useful vocabulary and a strong set of mental models.
Verdict
The Toyota Way is most valuable as an explanation of what continuous improvement looks like when it becomes part of an organization’s operating system. For me, the most important lesson is the combination of process improvement and people development. A strong organization does not merely solve problems efficiently. It continuously improves its ability to solve problems.
The failure mode is cargo-culting the mechanics: adopting Kanban boards, standups, or retrospectives without the mindset behind them. Those artifacts mean little without continuous improvement and people development underneath. A board filled with cards is not Lean. Lean is making problems visible, developing people who can solve them, and improving the baseline from a stable standard. Without that, the tools are ceremony with labels.
That idea transfers remarkably well from a factory floor to software engineering and technical leadership.
Have you applied any Toyota principles in your own work?
Drop a comment below; I read every one.