How Toyota Turned America's Worst Car Plant Into Its Best

In the early 1980s, roughly one in five workers at General Motors' car plant in Fremont, California didn't bother showing up on any given day. The ones who did show up filed grievance after grievance, went on wildcat strikes and, according to people who worked there, occasionally sabotaged the cars on purpose. The plant built some of the worst-quality vehicles in GM's entire system. In 1982, GM gave up and closed it.

Two years later it reopened under a joint venture with Toyota, called NUMMI. Same building. Same union. Largely the same workers, including, as one Toyota manager who was there later put it, "the old troublemakers." Within a year it had the best quality in GM's system. Absenteeism settled at a steady 2%.

Nobody got replaced. One rule got added.

The plant GM had given up on

The account that matters here isn't a blog post or a case-study slide — it's from someone who was actually there. John Shook, hired by Toyota in 1983 to help transfer its production system to the new joint venture, wrote up what happened in MIT Sloan Management Review. His description of the old Fremont plant isn't subtle: "The work force in those days had a horrible reputation, frequently going out on strike (sometimes wildcat strikes), filing grievance after grievance and even sabotaging quality. Absenteeism routinely ran over 20%." GM's own people, he says, doubted the plan from the start.

Toyota didn't bring in new staff, new management consultants with a 90-slide deck, or an incentive scheme. It installed its production system, including one specific mechanism GM had never had: a cord, running the length of the assembly line, that any single worker could pull the instant something was wrong.

One rule: everyone gets the obligation to stop

The mechanism is called jidoka — Toyota's own description, on its official company site, calls it "automation with a human touch": the equipment (or the worker) detects an abnormality and stops, rather than letting a defect travel further down the line.

GM's people on the joint venture pushed back hard on the idea before launch. Shook recalls the exact exchange: "Some of our GM colleagues questioned the wisdom of trying to install andon there. 'You intend to give these workers the right to stop the line?' they asked. Toyota's answer: 'No, we intend to give them the obligation to stop it — whenever they find a problem.'"

That's the whole trick, and it's worth sitting with. Not a right you might use if you're brave enough. An obligation, built into the job description, backed by a promise from management: find a problem, flag it, and help arrives before you've even finished the sentence.

It's also less dramatic in practice than "stop the line" sounds. The cord doesn't slam the whole plant to a halt. Shook explains the mechanic: pulling it lights a signal and calls the team leader, who tries to fix the problem within the worker's normal job cycle — about a minute, on a line like that. Only if it isn't resolved by a fixed point further down the line does production actually stop. Most pulls never stop anything. They just guarantee that somebody with the authority to fix it shows up, fast, every single time.

The numbers that actually moved

No new hires, no layoffs of "the bad ones," no culture off-site. Shook is blunt about what actually did the work: "The only thing that changed was the production and management system — and, somehow, the culture." His argument, which won an award from the same journal that published it, is that you don't talk your way into a new culture. You give people a concrete, reliable way to do their job properly, and the culture follows. "It's easier to act your way to a new way of thinking than to think your way to a new way of acting."

What happens with no cord to pull

Shook also describes what the opposite looks like, from a Big Three plant he visited around 1995. A worker on an assembly line made a mistake — fitted the wrong part during a workaround — and realised it almost immediately. But there was no cord within reach, no team leader nearby, nothing except a red emergency button roughly thirty paces away that would halt the entire line and summon a supervisor he didn't particularly want to see. So, in Shook's words, "he did nothing. To this day, no one knows what happened there except that worker and me."

That's not a story about one lazy worker. It's a story about a plant that had made the cost of reporting a problem higher than the cost of hiding it. Every office we've worked in has a version of that red button: the bug nobody filed because the tracker takes fifteen fields, the client complaint that sat in someone's inbox because "it's probably fine," the stock discrepancy nobody mentioned until the quarterly count. Same instinct as the Fremont worker in 1995 — just slower, and in spreadsheets instead of sheet metal.

Building your own andon cord (no assembly line required)

You don't make cars, so you don't need a literal rope. You need the three things the rope actually provided:

1. A specific, named signal for "something's wrong." Not a general Slack channel where problems go to get buried under lunch orders. One place, one format: what broke, who's affected, since when.
2. A guaranteed, fast response — not "someone will get to it." Shook's NUMMI promise was help within the worker's own job cycle, about a minute. Yours doesn't need to be a minute, but it needs to be a stated number, publicly kept, not "whenever."
3. No penalty for pulling it. The instant flagging a problem makes you look bad, people stop flagging problems — see: the Detroit worker and his red button. The best fix for most SMEs isn't a new HR policy, it's making the honest path the easy one: build the reporting step into the normal workflow instead of bolting it on as an extra chore nobody does under pressure.

Where this plugs into actual tools: a support ticket that auto-escalates if it sits untouched past your stated response time, a dashboard that someone actually has to look at rather than a report that gets generated and archived, or a simple AI agent watching your order queue, your form submissions or your error logs and raising a flag the moment something looks wrong instead of a human discovering it three weeks later in a spreadsheet nobody opens on Fridays. None of that is exotic engineering. Most of it is a webhook, a rule and the willingness to actually staff the other end of it.

Where this goes wrong

Honesty first, because "give everyone the right to stop everything" is a genuinely bad idea if you implement it badly.

• If nobody actually responds, you've built the Detroit red button, not the NUMMI cord. The promise only works if it's kept every time, not most times. A flagging system with no SLA behind it trains people to stop using it within a month.
• Not every problem deserves a full stop. NUMMI's own cord usually didn't stop the line — it summoned help within the job cycle. Define what's a flag-and-fix and what's a genuine full halt, or you'll stop everything for typos and nothing for the thing that actually matters.
• It needs a blame-free "five whys," not a blame-first "five whos." Shook describes exactly this fight at NUMMI: trainees came back wanting to focus on the root cause, not on finding the person to blame. If your version of this system ends with someone getting shouted at, people will do what the Detroit worker did — quietly nothing.
• Small teams can usually start with a person, not software. You don't need a platform to promise "tell me and I'll handle it within the hour." You need to actually mean it the first ten times someone tests you.

The mechanism isn't complicated. What's hard — at Fremont in 1984 and in your office now — is actually honouring the promise once someone pulls the cord.

Not sure where your own problems are quietly piling up before anyone pulls the cord? The scorecard takes ten minutes and tells you what to fix first.

Written by Markus

Founder & Chief Unicorn Officer at VEONIO. Leads every engagement personally. Still can’t say no to a good idea.