Definition
The shusa system is Toyota’s method of organizing product development around a single senior engineer who holds total accountability for a vehicle program. The shusa owns the vehicle concept from initial planning through launch: what the car should be, who it is for, what it should cost, and how all the engineering tradeoffs resolve into a coherent product. Every functional department — body, chassis, powertrain, manufacturing, purchasing — contributes engineers to the program, but none of them report to the shusa. The shusa must integrate their work through technical authority, direct engagement, and persuasion.
The system’s defining characteristic is a deliberate paradox: the shusa carries full responsibility for the vehicle’s success or failure on the market, but possesses limited formal authority over the people doing the work. This is not an oversight — it is the design. The tension forces the shusa to lead through competence and concept clarity rather than command.
Japanese Origin
Shusa (主査) combines 主 (shu, “chief” or “primary”) with 査 (sa, “investigate” or “examine”). The literal meaning is closer to “chief investigator” or “lead examiner” than to “chief engineer” — reflecting the role’s original emphasis on examining and integrating work across functions rather than directing it. Toyota’s English-language publications typically translate shusa as “Chief Engineer” (CE), which is now the standard term in both Toyota and the broader lean product development literature.
History at Toyota
The Crown Project and the Origin of the Role (1950–1953)
The shusa system emerged from Toyota’s first fully domestic passenger car project — the Crown (RS model). By the early 1950s, the technical demands of a modern passenger car had become too interdependent for Toyota’s functional departments to manage in isolation. Body engineers, chassis engineers, and production preparation groups each optimized within their own domains, producing conflicts that no one was accountable for resolving at the vehicle level.
On May 1, 1953, Toyota reorganized its engineering departments and created a “Project General Manager Department” (主査室, shusa-shitsu). Kenya Nakamura was appointed as the first shusa for the Crown development. The role was created by Eiji Toyoda, who deliberately placed it “outside the organization” — giving Nakamura responsibility for the whole vehicle without placing him above any functional department head.
Nakamura established the role’s legitimacy through personal credibility. A body engineer who had built Toyota’s in-house 2,000-ton Clearing press, he earned trust across functions by understanding their constraints deeply. He led by walking the floor, engaging directly with engineers in every department, and holding sign-off authority on every engineering drawing.
Codification by Tatsuo Hasegawa (1955–1965)
Tatsuo Hasegawa, who served as Nakamura’s sub-chief (副主査, fuku-shusa) on the Crown, transformed the role from one man’s practice into a scalable system. An aeronautical engineer who had designed high-altitude interceptors during WWII, Hasegawa brought a systems engineering mindset to Toyota.
As shusa for the Publica, Sports 800, first-generation Corolla, Celica, and Carina, Hasegawa introduced key methods:
- Target Costing (原価企画, Genka Kikaku) — adapting aviation weight-budgeting logic to cost management
- Ten Core Principles defining what an effective chief engineer should be and do
- “Collecting Wide Knowledge” (広い知識を集める) — formalizing the shusa’s responsibility to actively seek information from every function before making decisions
In 1965, Hasegawa established the Product Planning Office, creating the organizational home that allowed the shusa system to survive beyond its founders.
Evolution: Development Centers and Platform Governance (1990–Present)
By the early 1990s, Toyota’s growing product lineup revealed a structural tension: strong shusa autonomy produced excellent individual vehicles but also avoidable variation across similar models. Shusas optimizing for their own programs could justify unique parts and specifications that increased fleet complexity.
In September 1992, Toyota restructured into Development Centers organized by platform type (rear-wheel-drive, front-wheel-drive, commercial vehicles, and powertrain). This added a platform-governance layer above the shusa, encouraging parts commonality and shared architectures while preserving the shusa’s role in vehicle concept and customer focus.
Under Akio Toyoda’s presidency (2009–2023), the system was further reorganized through TNGA (Toyota New Global Architecture) and eventually the company system — splitting Toyota into product-based companies to push decision-making closer to the vehicle level. Through every reorganization, the core shusa principle has been preserved: one person, accountable for the whole product.
How the System Works
Drawing sign-off authority — The shusa does not manage people, but controls the product. As former Chief Engineer and Executive Vice President Akihiro Wada stated: “If the shusa didn’t sign, the drawing didn’t live.” This gives the shusa hard power over product-process design decisions without line authority over engineers.
Vehicle-level integration — Functional engineers remain in their specialist departments (body, chassis, powertrain, etc.) to develop deep expertise. The shusa pulls them together for the vehicle program, resolving conflicts that functional optimization cannot settle. This matrix structure preserves both specialist depth and product coherence.
Direct engagement over rank — Shusas are expected to surface constraints early, force tradeoff discussions into the open, and persuade specialists through data and concept clarity. The role demands broad technical knowledge and the ability to understand every function’s constraints well enough to make integrated decisions.
Cost and concept ownership — The shusa manages the vehicle’s target cost through genka kikaku, allocating cost budgets to each subsystem and managing tradeoffs across the entire vehicle to hit profitability targets.
Single-point accountability — One person is responsible for the vehicle’s success or failure in the market. This clarity of ownership is the system’s greatest strength: when something goes wrong, there is no ambiguity about who must fix it.
How It Differs from Western Program Management
In most Western companies, “program managers” coordinate schedules and budgets across functions. They are administrators of the development process. The Toyota shusa is fundamentally different — a senior technical leader who owns the product concept end-to-end: what the car should be, not just when it will be done. The shusa’s authority comes from technical depth and earned respect, not from an org-chart position above the engineering staff.
Academic researchers Clark and Fujimoto (1991) termed this the “heavyweight project manager” — distinguishing it from the “lightweight” coordinators common in Western firms. Various outside observers have studied aspects of the system — notably Allen Ward and Durward Sobek on set-based design, and James Morgan and Jeffrey Liker on product development broadly — but these accounts reflect limited access to specific parts of Toyota’s development process and should not be taken as comprehensive descriptions of the whole system.
Common Mistakes
Treating the role as project management. The shusa is not a scheduler, coordinator, or administrator. Companies that adopt the “chief engineer” title but fill it with project managers who track Gantt charts and hold status meetings miss the point entirely. The role requires deep technical breadth and the ability to make engineering tradeoff decisions across every vehicle subsystem.
Giving line authority. When the chief engineer is also the boss of the engineers, the creative tension that makes the system work disappears. Engineers comply rather than challenge. The deliberate separation of product authority from people authority forces better decisions by requiring the shusa to earn agreement through technical merit.
Rotating the role too quickly. The shusa system works because the chief engineer develops deep knowledge of the vehicle, the customer, and the competitive landscape over time. Rotating people through the role on short cycles (as some companies do with program managers) prevents this depth from developing.
Weakening the role during platform standardization. When platform governance becomes too strong, the shusa’s ability to differentiate the vehicle for the customer can be diluted. Toyota itself has wrestled with this balance through multiple reorganizations. The system works best when the shusa retains genuine authority to override platform defaults where the customer would notice the difference.