SAFe and Lean: TPS, Toyota, and the Lean Heritage
SAFe and Lean: TPS, Toyota, and the Lean Heritage — Ford's 1913 flow line predates Toyota by three decades; trace the throughline to SAFe's LACE today.
Ask a Lean-Agile coach where Lean began, and most name Toyota. That answer skips three decades. SAFe and Lean: TPS, Toyota, and the Lean Heritage actually opens in a Michigan auto plant in 1913, and the fact that gets buried, what Ford’s system couldn’t do, explains why every SAFe economic-view conversation still runs into the same wall today.
Where Lean Manufacturing Began: Henry Ford’s Flow Production at Highland Park
Lean manufacturing’s first fully realized system predates Toyota by roughly three decades: Henry Ford married interchangeable parts, standardized work, and moving conveyance into what he called flow production at his Highland Park, Michigan plant in 1913, three decades before Toyota existed as a manufacturing case study Highland Park (Lean Enterprise Institute). The system turned over the company’s entire inventory every few days. It also had a boundary nobody at Highland Park could design around, and that boundary, not the assembly line itself, is the reason most retellings skip straight to Nagoya.
Ford’s 1913 Breakthrough: Interchangeable Parts, Standard Work, and Moving Conveyance
Ford’s breakthrough combined three practices that had existed separately for years and lined them up in process sequence inside a single factory for the first time. The public saw this as the moving assembly line, a dramatic and visible symbol, but the Lean Enterprise Institute’s own account of the plant’s history frames the underlying engineering as the real event: fabrication steps arranged wherever possible in process sequence, using special-purpose machines and go/no-go gauges, so that components reached the line already fitting and ready for final assembly Highland Park (Lean Enterprise Institute). A walking tour of the surviving Highland Park buildings, recorded by the Lean Enterprise Institute’s own founder, dates the world’s first continuous-flow assembly line to spring 1914 and calls the site the most important industrial and economic leap in human history (Lean Enterprise Institute). That claim sounds inflated until it is set against what came before: American manufacturing ran on general-purpose machines that produced parts needing correction later, not components that arrived already correct. Ford’s plant is where that correction step disappeared for the first time at industrial scale, and the six-story “new shops” building where the line later moved, now empty and awaiting redevelopment, stands as physical evidence of a production paradigm that started before anyone called it lean.
Flow Production Versus the American System
Flow production replaced the American System’s core assumption, that general-purpose machines grouped by process could make parts and fix the fit afterward, with sequenced, special-purpose fabrication that delivered a finished fit on the first pass.
The American System: General-Purpose Machines Grouped by Process
The American System organized factories by process rather than by product: lathes together, drills together, presses together, each machine general enough to work on many different part designs. A part moved from department to department, and workers fit it into the assembly by hand once enough tolerance had stacked up to require correction. This is the shop practice the Lean Enterprise Institute’s own history credits Ford with breaking, not refining Highland Park (Lean Enterprise Institute).
The consequence mattered more than the description: fitting work in subassembly and final assembly consumed time that never showed up as a machine problem, only as a schedule problem, and it hid inside every plant that ran this way. A factory could look busy, machines running, output shipping, while losing days to invisible correction work between stations. That invisible cost is why general-purpose flexibility, prized for its ability to make almost anything, turned into the very obstacle keeping output slow and inconsistent.
Ford’s Break: Sequenced Fabrication and Perfectly Fitting Components
Ford’s break was sequencing: fabrication steps ordered in the same order the product needed them, using special-purpose machines built for one part and go/no-go gauges that rejected anything out of tolerance before it reached the line. Components arrived at the line already fitting, assembled within minutes of being fabricated rather than days or weeks after Highland Park (Lean Enterprise Institute).
This is what let Ford turn the company’s entire inventory every few days, a cycle speed the American System’s batch-and-queue layout could never approach, because sequencing removed the queues that batch production depended on to keep general-purpose machines busy. The example that made this concrete for the public was the assembly line, but the queue elimination happened earlier, in fabrication, out of sight of anyone touring the plant floor.
Ford’s Real Limitation: Turning Inventory Fast but Offering No Variety
Ford’s system turned inventory in days but could not turn variety at all: the Model T held one specification from its introduction through the end of production in 1926, with only a handful of supplier-fitted body styles as a concession.
Every Model T chassis produced across that run was essentially identical, and the Lean Enterprise Institute’s own account is specific about why: practically every machine in the plant worked a single part number, with no changeovers built into the process at all Highland Park (Lean Enterprise Institute). That specificity was the price of the sequencing that made flow production possible: a machine tooled for exactly one part cannot be retooled overnight for a different one, and Ford never solved that trade-off. When customers wanted shorter model cycles than the Model T’s nineteen years and other automakers began offering many models with many options, Ford’s flow production lost its advantage, because the system was built to run one specification extremely well rather than to switch between several. This is the boundary the Toyota Production System would eventually design around directly, decades later, by keeping changeover time itself a target for reduction rather than an accepted cost of variety.
Lean’s Root Before Ford: The Venetian Arsenal
Ford’s 1913 plant was not the first instance of rigorous process thinking: the Lean Enterprise Institute traces that lineage back to the Venetian Arsenal in the 1450s, four and a half centuries earlier.
The Arsenal built and outfitted galleys using standardized parts and a sequenced production line inside a single walled shipyard, at a scale and speed that impressed diplomats visiting Venice at the time. The Lean Enterprise Institute cites this history specifically to make a point about ownership of the ideas: rigorous process thinking is centuries older than any single company or nation, and the periodic rediscovery of its principles, at the Arsenal, then at Highland Park, then at Toyota, says more about how easily organizations forget hard-won process knowledge than about who deserves credit for inventing it Highland Park (Lean Enterprise Institute). For a SAFe-adjacent history, the practical implication is narrow but useful: treating Toyota as the origin point of Lean thinking erases not just Ford’s decade but a lineage stretching back roughly half a millennium, and a coach citing that full lineage carries more weight in a portfolio review than one starting the story in Nagoya.
How Toyota Built the Toyota Production System While the West Thought Manufacturing Was Already Perfected
Toyota built the Toyota Production System between 1948 and 1975, during the exact decades Western manufacturers assumed Henry Ford’s refined assembly line had already solved production, with Taiichi Ohno leading the effort alongside co-creator Eiji Toyoda Eiji Toyoda (InfoQ). McKinsey’s own fiftieth-anniversary retrospective admits how total that assumption was, and naming the year it broke changes how the “apply systems thinking” principle reads for a portfolio leader today.
McKinsey’s Own Admission: The West Thought Ford’s Assembly Line Was as Good as Manufacturing Would Get
When McKinsey Quarterly’s first issue rolled off the presses fifty years ago, senior management nearly universally believed manufacturing had already been perfected by Ford’s refined assembly line.
Ewan Duncan and Ron Ritter’s account for McKinsey is specific about the confidence: Ford’s moving assembly line had been refined over five decades, had served as the arsenal of democracy during World War II, and by the mid-1960s was running efficiently at great scale across a wide range of industries worldwide World War II (McKinsey). Quietly, while that confidence held, Taiichi Ohno and his engineering colleagues in Nagoya, Japan were perfecting what they called the Toyota production system: the system the West would eventually name lean production. McKinsey’s own framing makes the timing the point: the breakthrough that would eventually force every manufacturer to rethink flow was happening at the same moment the industry’s flagship publication assumed flow had already been solved. A portfolio leader applying systems thinking today is inheriting the corrective half of that story, and McKinsey’s own retrospective is explicit that the correction took decades to surface in the West.
Building the Toyota Production System, 1948-1975
Toyota built the Toyota Production System across a specific, documented window, 1948 to 1975, rather than in a single invention moment credited to one engineer.
InfoQ’s account of the system’s origin narrows the credit question directly: the Toyota Production System was developed between 1948 and 1975, a twenty-seven-year span of iteration rather than a single launch date. Most retellings compress that span into a single name and a single year, which flattens both the timeline and the credit.
Taiichi Ohno and Co-Creator Eiji Toyoda
Taiichi Ohno is usually credited alone with the Toyota Production System, but InfoQ’s own correction names Eiji Toyoda, cousin of Kiichiro Toyoda, who founded Toyota Motor Corporation, as Ohno’s collaborator in developing the system, and Eiji Toyoda is considered its co-creator rather than a supporting figure Eiji Toyoda (InfoQ).
The correction matters for how the system gets taught: a single-inventor story implies one engineer’s insight, while a co-creator story implies sustained collaboration across a family connection to the company’s founding generation. Kiichiro Toyoda founded Toyota Motor Corporation; his cousin Eiji Toyoda worked alongside Ohno for years before the system reached the form later documented as the Toyota Way. Crediting both names accurately signals that the system was built through sustained collaboration, not a single insight.
Kaizen and Kanban: The Tools That Traveled West First
Kaizen and kanban reached Western manufacturers years before the Toyota Production System’s full logic did, and McKinsey’s own account names them specifically: kaizen workshops, where frontline workers solve knotty problems, and kanban, the scheduling system for just-in-time production World War II (McKinsey).
Tools travel faster than systems because a workshop or a scheduling board can be copied without copying the management philosophy that produced it, and that is exactly what happened with early Western adoption of Toyota’s practices. McKinsey’s own framing adds a third tool to this early wave, the andon cord, which any worker could pull to stop a production line: a level of shop-floor authority Western plants adopted as a visible practice long before they adopted the respect-for-people philosophy behind it.
Fujio Cho and the 2001 Codification of the Toyota Way
Toyota did not formally write down its own operating philosophy until 2001, when Fujio Cho delivered the document now known as the Toyota Way.
Fujio Cho, honorary chairman of Toyota Motor Corporation, delivered the Toyota Way in his own words as an effort to identify and define the company’s fundamental DNA: the managerial values and business methods summarizing what made Toyota’s culture and success distinct Eiji Toyoda (InfoQ). The gap between the Toyota Production System’s development window (1948-1975) and its formal codification (2001) is worth sitting with: Toyota ran the system for roughly a quarter-century before writing down the philosophy behind it in a form meant for people outside manufacturing. InfoQ’s own account notes a common confusion that follows from this gap; people mix up the Toyota Production System and the Toyota Way when writing, treating the two as interchangeable, when the more accurate framing is that the Toyota Way explains TPS for the non-manufacturing parts of the company. That distinction matters for anyone importing Toyota vocabulary into a SAFe transformation: the practices came first, by decades, and the philosophy document meant to translate them for people who would never touch a factory floor came second.
The West’s Name for Toyota’s System: “Lean Production”
The West did not adopt Toyota’s own name for its system: it invented a new one, calling Ohno and Eiji Toyoda’s system “lean production” rather than the Toyota Production System.
McKinsey’s own retrospective states this naming plainly: the system Ohno and his colleagues built in Nagoya is what the West came to call lean production, a label Toyota itself never used internally World War II (McKinsey). That relabeling created a permanent translation gap between how Toyota describes its own system and how everyone outside the company, including SAFe, describes it: a gap this heritage keeps running into every time a Western framework borrows the vocabulary. Kaizen and kanban survived the relabeling as loanwords, kept in their original form because a workshop format and a scheduling board translate directly. Systems thinking, the economic view, and flow, the broader philosophy Fujio Cho would codify as the Toyota Way, needed the outside relabeling to travel at all, because there was no equivalent shop-floor artifact for other companies to copy. The 1996 book that gave that relabeled philosophy its lasting Western name arrived a full two decades after Ohno’s development window closed.
From ‘Lean Thinking’ to Software: Womack and Jones’s 1996 Term and the Poppendiecks’ Two Books
James Womack and Daniel Jones popularized the term “lean thinking” in 1996 after studying Toyota’s manufacturing operations and observing what they characterized as an absence of waste, and their five Lean principles, from their earlier book The Machine That Changed the World, gave that observation a repeatable structure Machine That Changed (Harvard Business Review). The five principles are well known on their own. The publication trail behind them, and what happened to that trail a decade later inside software, is the part most retellings skip.
1996: Womack and Jones Name ‘Lean Thinking’ and Define Its Five Principles
Womack and Jones spent years studying Toyota’s manufacturing operations before naming the pattern they found in 1996: an absence of waste running through every process they examined.
Harvard Business Review’s own account of this history, from Matthew May, is direct about the year and the mechanism: in 1996, James Womack and Daniel Jones popularized the term “lean thinking”, later the title of their own book, as their expression for what they’d observed studying Toyota’s operations Machine That Changed (Harvard Business Review). That observation-first sequence, years of studying a specific company before naming a general pattern, is why the term held up outside manufacturing: a label attached to a documented absence of waste inside a real, visited factory floor gets adopted more readily than one invented in the abstract. The five principles that gave the naming its lasting structure trace to Womack and Jones’s earlier book, The Machine That Changed the World, published years before the 1996 label: define value, map the value stream, create flow, use a pull system, and pursue perfection, in that exact sequence, per Agile Alliance’s own summary (Agile Alliance). Defining value starts from the customer, because Agile Alliance’s account is specific that value is what the customer is willing to pay for, including latent needs the customer may not be able to articulate. Mapping the value stream means identifying every activity contributing to that value and treating everything else as waste, split further into work that is unavoidable and work that is not. Creating flow and using a pull system reorder those value-adding activities so work moves in a continuous sequence and gets pulled forward by actual demand rather than pushed forward on a schedule. Pursuing perfection closes the sequence as a standing target rather than a finish line: the same five-word list SAFe would later fold into its own economic-view and flow principles, three decades after Ford and five after Ohno.
The Poppendiecks’ Two Books: From Thinking Tools to Operating Practice
Mary Poppendieck and Tom Poppendieck adapted Lean’s shop-floor logic to software delivery across two books published three years apart, in 2003 and 2006.
Lean Software Development, published in May 2003 by Addison-Wesley, arrived after the first wave of agile books focused on specific practices, Extreme Programming, Feature-Driven Development, Scrum, that told teams to follow a prescribed set of rules Feature-Driven Development (Mountain Goat Software). The Poppendiecks’ book represented a second wave: learning to think in a Lean-adapted way rather than following a prescribed rule set, a distinction Mountain Goat Software’s review credits as the book’s central contribution.
Lean Software Development (2003): 22 Thinking Tools
Lean Software Development presents twenty-two thinking tools drawn directly from lean manufacturing, each written as a guideline detailed enough to put into practice, with the reasoning behind it made explicit rather than left implicit Feature-Driven Development (Mountain Goat Software). Two of the named tools carry over from manufacturing almost unchanged: pull systems, which pull work into the current step from the prior step instead of pushing it forward on schedule, and queueing theory, used to calculate the cost of delay so teams can see which bottlenecks are actually worth removing.
The distinction the review draws is between being told what works and being shown why it works, and that distinction is what let the book apply to both agile projects and more traditional, plan-driven ones. A team that understands why rapid delivery depends on pull systems and cost-of-delay calculations can adapt the tool to a context the original manufacturing example never anticipated; exactly what SAFe’s own economic-view and flow principles would later require at a multi-team scale.
Implementing Lean Software Development (2006): Seven Principles and Their Myths
Implementing Lean Software Development, published in September 2006 by Addison-Wesley Professional, restructures the Poppendiecks’ thinking as seven principles of lean software development, each paired with a myth the principle dispels Addison-Wesley Professional (Mountain Goat Software). The book’s own example, cited by Mountain Goat Software’s review, pairs the principle “build quality in” with the myth that testing exists to find defects; dispelling that myth is what makes the principle actionable instead of aspirational.
Where the first book explained why lean thinking tools worked, the second book moves from theory into what teams should do the next day: how to structure compensation and recognition, how to start a lean initiative, how to write contracts for agile projects. Each chapter closes with a “Try This” exercise, reinforcing the book’s practical intent. Three years separate the two books, and that gap marks the same shift the Toyota Way’s 2001 codification marked decades earlier: a system runs first, and the operating document that makes it teachable to newcomers follows later.
A Decade-Long Transmission: Factory Floor to Shipped Software
Lean’s vocabulary took a full decade to travel from a factory floor to shipped software, in documented steps rather than one single leap.
| Year | Event | Named Source |
|---|---|---|
| 1913 | Ford’s Highland Park breakthrough opens the transmission chain this table traces | Lean Enterprise Institute |
| 1948-1975 | The Toyota Production System takes shape, the transmission chain’s midpoint between Ford’s 1913 opening and Womack and Jones’s 1996 naming | InfoQ |
| 1996 | Womack and Jones popularize the term “lean thinking” | Harvard Business Review |
| 2001 | The Toyota Way is codified, 27 years after TPS’s development window closed, the same lag this table’s 1996-to-2006 span repeats | InfoQ |
| 2003 | The Poppendiecks publish Lean Software Development | Mountain Goat Software |
| 2006 | The Poppendiecks publish Implementing Lean Software Development | Mountain Goat Software |
Reading the rows in sequence makes the transmission mechanism visible: 1996’s borrowed vocabulary became 2003’s borrowed thinking tools, which became 2006’s operating practice, and each step needed the previous one published first. SAFe inherits the vocabulary at the far end of that sequence, which is why terms like “pull system” and “cost of delay” show up in portfolio-level guidance sounding native to software, when they arrived by way of a 1996 book title and two Poppendieck texts rather than being invented for software at all. Recognizing the full six-row sequence, not just the five principles at the start of it, is what separates a coach who can trace a term’s lineage from one who can only define it.
Why Does the Transmission Sequence Matter for SAFe Practitioners Today?
Knowing that “pull system” and “cost of delay” reached SAFe by way of Toyota, Womack and Jones, and the Poppendiecks, rather than being coined for software, changes how a Lean-Agile Center of Excellence can coach the term to teams that only ever encounter it inside a Program Increment. A coach who can trace “cost of delay” back through Lean Software Development’s queueing-theory tool to Toyota’s own shop-floor logic can explain why the calculation exists, not just recite the formula; a coach who treats the term as native to SAFe can only assert that it works. The same distinction the Poppendiecks drew between being told what works and being shown why holds at the portfolio level: SAFe’s economic view asks teams to sequence work by cost of delay, and that instruction lands differently once a team understands it inherited three decades of prior refinement rather than arriving fully formed with the framework itself.
How SAFe Operationalizes the Lean Heritage Today: the Lean-Agile Center of Excellence and the Lean Business Case
SAFe carries the Lean heritage into current practice through two named mechanisms: the Lean-Agile Center of Excellence, a small Agile team dedicated to implementing SAFe’s Lean-Agile way of working, and the Lean Business Case, a structured format for describing epics, their Minimum Viable Products, and projected business value Minimum Viable Products (Scaled Agile Framework). Both mechanisms exist because Ford’s flow-production breakthrough and Ohno’s production system solved manufacturing problems, and manufacturing solutions do not cross into an enterprise portfolio without something built specifically to carry them. SAFe 6.0 still frames these two artifacts as its primary implementation-and-economics mechanisms, extending directly from this heritage rather than replacing it.
The Lean-Agile Center of Excellence: Scaled Agile’s Definition and Its Guiding-Coalition Epigraph
Scaled Agile defines the Lean-Agile Center of Excellence as a small Agile team dedicated specifically to implementing the SAFe Lean-Agile way of working inside an enterprise.
The definition appears as article three in Scaled Agile’s own SAFe Implementation Roadmap series, positioning the LACE as an infrastructure decision rather than a training exercise Minimum Viable Products (Scaled Agile Framework). Scaled Agile’s own article opens with an epigraph from John Kotter that frames why a small dedicated team outperforms a distributed part-time effort: a guiding coalition that operates as an effective team can process more information more quickly, and it can speed implementation because powerful people inside it are truly informed and committed to the key decisions being made. That framing places the LACE as one element of what Kotter’s own change model calls a “sufficiently powerful guiding coalition”; alongside reaching the tipping point for change and training Lean-Agile change agents throughout the organization. The practical reason a coalition needs its own dedicated team, rather than relying on volunteers with full-time responsibilities elsewhere, is capacity: most people qualified to lead a Lean-Agile transformation already carry a full workload in their existing role, and a transformation depending entirely on their spare time moves at spare-time speed. Scaled Agile’s own article notes that these teams go by different names across organizations, Agile Center of Excellence, Agile Working Group, Lean-Agile Transformation Team, Learning and Improvement Center, but the staffing model stays consistent: people whose primary task is implementing and sustaining the change, not fitting it in around other duties.
Why an Effective LACE Separates Real Adoption From Agile in Name Only
Scaled Agile’s own claim is specific: an effective LACE is one of the key differentiators between companies practicing Agile in name only and those fully committed to Lean-Agile outcomes.
That claim only holds if the LACE actually does the coalition-building work Kotter’s epigraph describes, rather than existing as a name on an org chart. A LACE that meets the definition trains executives, managers, and leaders alongside frontline change agents, because Scaled Agile’s own roadmap treats leadership education and grassroots change-agent training as parallel tracks rather than a sequence; leadership buy-in without frontline capability produces mandates nobody can execute, and frontline capability without leadership buy-in produces pilots nobody scales. Companies practicing Agile in name only tend to skip the dedicated-team step specifically: they distribute LACE-equivalent responsibilities across people’s existing roles, which reproduces the exact capacity problem the dedicated-team model was built to solve. The distinguishing signal, in practice, is whether anyone can name the LACE’s members and describe what they did this quarter: a real guiding coalition produces visible artifacts and decisions, while a name-only effort produces a slide with a LACE box on it and no attached activity underneath.
The Lean Business Case: Carrying Economic Discipline Into Epics and Minimum Viable Products
The Lean Business Case is Scaled Agile’s own structured format for describing an epic, its Minimum Viable Product, and its projected business value in a single artifact.
That definition, stated directly in Scaled Agile’s glossary, makes the Lean Business Case the artifact-level descendant of the economic view Womack and Jones’s five principles established decades earlier: define value, then attach that value to a specific, boundable piece of work before committing full funding to it Womack and Jones (Scaled Agile Framework). An epic without a Lean Business Case is a large ambition without a boundary; the same epic with one has a stated MVP, meaning the smallest version that tests the value claim, and a projected business value figure letting portfolio leaders compare it against every other epic competing for the same funding. This is where the transmission history stops being background and becomes a template a Lean-Agile change agent fills out this quarter: the artifact asks the same three questions Ford’s flow production made physically visible on a factory floor; what problem are we solving, what is the smallest version that demonstrates it, and is the resulting flow of value worth the cost of building it.
Two Threads From Ford to SAFe: People and Economics
Two threads run continuously from Highland Park to a SAFe portfolio: a people-and-coalition thread and an economic-discipline thread, and SAFe names a mechanism for each.
The people-and-coalition thread starts with Ford’s factory workforce learning sequenced fabrication, runs through Ohno and Eiji Toyoda’s collaborative development of the Toyota Production System, through the Poppendiecks writing thinking tools other teams could adopt, and lands in the Lean-Agile Center of Excellence, the guiding coalition Kotter’s epigraph describes. The economic-discipline thread starts with Ford’s inventory-turn advantage, runs through the economic view established earlier, and lands in the Lean Business Case, the artifact that pairs an epic’s MVP with its projected business value before funding is committed. Neither thread is new; both are the same logic re-expressed once per generation since 1913; as a factory practice, then a production system, then a set of thinking tools, then a portfolio artifact. What changes each time is the vocabulary and the artifact, not the underlying discipline, and a Lean-Agile change agent who can name both threads is applying a century of accumulated correction rather than following instructions from a framework guide.
Lean Beyond the Factory: How the Heritage Reached Startups and Innovation Practice
Lean’s heritage reached far past manufacturing and software: Steve Blank’s lean-startup argument, built on Harvard Business School research showing that roughly 75 percent of all start-ups fail, and Paulo Caroli’s Lean Inception format both carry Lean’s logic into how new ventures and single teams plan their first week Lean Inception (Harvard Business Review). Manufacturing and software both had a company or a codebase to anchor the story. What happens when there is neither is where this heritage’s actual boundary sits.
Steve Blank and the Lean Start-Up: A Faster Way to Launch, With a 75-Percent Failure Rate as the Baseline
Steve Blank’s Harvard Business Review argument frames the lean start-up as a faster, smarter methodology for launching companies that may make traditional business plans obsolete.
Blank’s piece is explicit about the baseline problem this methodology answers: Harvard Business School researcher Shikhar Ghosh found that roughly 75 percent of all start-ups fail under the decades-old formula of writing a business plan, pitching it to investors, assembling a team, introducing a product, and selling as hard as possible Lean Inception (Harvard Business Review). That formula fails, in Blank’s framing, because it commits resources to a fixed plan before anyone has tested whether customers want what the plan describes: the same sequencing mistake the American System made decades earlier, committing general-purpose machines to a product before working out the sequencing that would make output efficient. The lean-startup response inverts the commitment order: build a minimal version, test it against real customers, and revise the business plan based on what customers actually do rather than what a pitch deck assumed they would do. Ghosh’s 75 percent figure functions the way Ford’s Model T limitation functioned earlier in this heritage: a specific, sourced number that turns an abstract argument for change into a measurable cost of not changing. A venture team quoting the 75 percent figure without naming Ghosh or Harvard Business School repeats a number without its evidentiary weight; naming both is what makes the figure a citation instead of a rumor.
Matthew May’s War on Waste: Lean as a General Business Operating Principle
Matthew May’s Harvard Business Review account moves Lean past the factory floor entirely, describing it as an organizing set of principles applicable to every business operation.
May’s own framing, filed under Harvard Business Review’s innovation-practice coverage, dates the term’s origin precisely, Womack and Jones popularized “lean thinking” in 1996 after observing an absence of waste in Toyota’s operations, before extending the term’s reach past its origin Machine That Changed (Harvard Business Review). Today, May writes, lean concepts apply to products, processes, services, and strategy alike, including entrepreneurial start-ups that have no factory floor and no manufacturing process to optimize in the first place. That extension is what makes Lean Inception and the lean startup possible as concepts at all: if lean principles required an assembly line to apply to, Steve Blank’s argument and Paulo Caroli’s format would both be category errors rather than legitimate applications. May’s piece asks directly what it really means to be lean once the factory floor is gone, and the answer his account implies is a system of principles, not a set of shop-floor tools: the same distinction the Toyota Way drew in 2001 when it separated Toyota’s underlying philosophy from the Toyota Production System’s manufacturing-specific practices.
Lean Inception: A Single Week, a Canvas, and a Minimum Viable Product
Lean Inception, documented by Thoughtworks’ Paulo Caroli through Agile Alliance, is a focused, single-week format that builds a canvas to define a Minimum Viable Product’s characteristics.
Caroli, an inception facilitator who has worked with organizations across Brazil, India, the United States, Latin America, and Europe, designed the format to answer two specific questions every agile project’s inception otherwise leaves open: what belongs in the MVP, and how does a team start with a shared plan rather than an assumed one Latin America (Agile Alliance). Naive agile, in Caroli’s own framing, has no up-front work at all; but in practice every agile project ends up doing some, and Lean Inception is the deliberate, single-week version of that unavoidable up-front work rather than an improvised one. The format borrows the startup world’s vocabulary specifically: a canvas, a single focused week, a Minimum Viable Product: not the Toyota Production System’s shop-floor tools, and not the Poppendiecks’ twenty-two thinking tools either. That borrowing is the clearest evidence of which branch of the Lean heritage produced it: Lean Inception descends from the lean-startup logic Steve Blank documented, not from the manufacturing logic Ford and Ohno built, because its entire vocabulary is startup vocabulary. A practice format built entirely outside any single company’s internal process is the furthest point this heritage reaches from Highland Park’s factory floor, and it is still recognizably the same discipline: test the smallest version of the idea before committing further resources to it.
Summary
The Lean heritage that reaches a SAFe portfolio today ran through a Michigan auto plant, a Japanese engineering team, two management books, and a startup failure statistic before it ever reached a framework guide, and reading the two threads inside that heritage changes what applying the principles actually requires.
The Two-Thread Throughline: People and Economics
Every mechanism in this heritage sorts into one of two threads: who builds the coalition that carries change, and how the organization demonstrates an idea’s value before funding it fully.
Ford’s factory workforce, Ohno and Eiji Toyoda’s collaboration, the Poppendiecks’ published thinking tools, and the guiding coalition this heritage lands in all sit on the people-and-coalition thread: each is an answer to the same question, who has to be convinced and organized before a new way of working sticks. Womack and Jones’s economic view, the earliest instance of this thread’s recurring failure mode, its most recent instance, and the Lean Business Case all sit on the economic-discipline thread: each is an answer to how an organization demonstrates a value claim before spending fully against it. A SAFe practitioner operationalizing these principles today is not choosing between the two threads; both have to run at once, because a guiding coalition with no economic discipline behind it funds initiatives nobody can defend, and economic discipline with no coalition behind it produces business cases nobody executes. Reading the heritage this way turns “apply systems thinking” and “take an economic view” from abstract principle names into specific, century-old answers to specific, recurring failures; Ford’s variety problem, the West’s decades-long blindness to Toyota, and the 75 percent of start-ups that skip proving value before spending it.
What Changes When the Heritage Runs Continuously Instead of Starting at Toyota
Treating Toyota as Lean’s starting point erases three decades of Ford’s flow production and roughly five centuries of the Venetian Arsenal’s process thinking that preceded it, and that erasure carries a practical cost.
A coach or RTE who starts the Lean story at Toyota is implicitly telling a team that this way of thinking is uniquely Japanese, uniquely manufacturing-specific, or both: a framing that makes the principles feel imported rather than applicable to whatever the team is actually doing. A coach who instead traces the line from a Venetian shipyard, through a Michigan auto plant, through Nagoya, through two Poppendieck books, to a startup failure statistic and a single-week inception format, is telling the same team that this discipline gets rediscovered constantly, in every kind of organization that produces anything for anyone. That is the orientation this history actually supports for a team already operating at scale: the signals worth watching, where value stalls, where a coalition thins out, where an epic’s business case stopped getting tested against reality, are the same signals every link in this chain was built to catch. The mechanisms change name every generation; Ford’s go/no-go gauges become Ohno’s andon cord, become the Poppendiecks’ queueing theory, become a portfolio’s WIP limits. What does not change is the discipline of watching for the failure mode before it compounds, and that discipline, not any single named framework, is what this heritage actually hands down.
Related in this cluster
- Safe_principles
- Inherited vs Invented: Per-Principle Intellectual Lineage Audit
- Principle Tie-Breakers: When SAFe Principles Conflict
- Missing Principles: What SAFe Left Out
- Principle-Practice Diagnostic: Symptoms of Principle Violations
- SAFe Framework Version History
- Competing Agile Frameworks: LeSS, Kanban, Scrum, DA