Problem-Solving Processes Used by Industry Leaders — and How to Integrate Them into Software Engineering Work

Research compiled 2026-10-18. Primary-source driven; every quote below is either verified verbatim from a URL fetched this session, or explicitly marked as paraphrased / secondary-traced.

TL;DR

The most durable problem-solving processes in modern industry share one skeleton: stop, look at reality, form a hypothesis, run a small experiment, and let the evidence—not hierarchy—decide. Toyota built this out as the Toyota Production System (jidoka, Just-in-Time, 5 Whys, A3, Kata); Deming gave it its statistical backbone (PDSA, the System of Profound Knowledge); Goldratt pointed it at the single biggest bottleneck (Theory of Constraints); Ries and Blank ported it into product development (The Lean Startup); Amazon industrialized decision-making around it (Working Backwards PR/FAQ, one-way vs two-way doors, "Day 1"); SpaceX compressed it into a ruthless 5-step "algorithm"; Pixar solved the social problem of making candor safe (the Braintrust); the British Design Council gave it a visual map for ambiguous problems (Double Diamond); John Doerr made it measurable (OKRs); and Google SRE turned the whole thing into culture with blameless postmortems. None of these require buying anything: a software team can start this sprint with a postmortem template, a one-page A3 instead of an RFC, a 20-minute kata coaching cadence, and a "delete before optimize" rule. The final section of this document is a concrete integration playbook.

1. Toyota Production System / Lean — Taiichi Ohno, Jidoka, Just-in-Time, and the 5 Whys

Origin & who used it

The Toyota Production System (TPS) grew out of the Toyoda family's automatic loom business. Sakichi Toyoda's loom not only automated work but "built the capability to make judgments into the machine itself" — the origin of jidoka (stop the machine when something goes wrong). His son Kiichiro Toyoda originated Just-in-Time; Taiichi Ohno, backed by Eiji Toyoda, "built the foundation of the Toyota spirit of monozukuri by helping establish the Toyota Production System, and creating the basic framework for the Just-in-Time method" (Toyota's own biography text on the TPS page).

The process

Toyota's official TPS page defines two pillars, verified verbatim this session:

• Jidoka — "automation with a human touch," where "when an abnormality occurs... the machine or equipment can detect the abnormality and stop automatically, or the operator can stop the line by pulling the stop cord themselves."
• Just-in-Time — "making only what is needed, when it is needed, and in the amount needed."

The page also names the continuous background activity: "all employees implement daily incremental kaizen," i.e., improvement is not a project; it is the job.

5 Whys. The interrogative root-cause method is attributed to Ohno at Toyota. The Lean Enterprise Institute's lexicon entry reproduces Ohno's canonical example (cited to Ohno 1988, Toyota Production System, p. 17): a machine stops → fuse blew (overload) → bearing not lubricated → lubrication pump not pumping → pump shaft worn → no strainer attached, metal scraps got in. LEI's own commentary, verified verbatim:

"Without repeatedly asking why, managers would simply replace the fuse or pump and the failure would recur. The specific number five is not the point. Rather it is to keep asking until the root cause is reached and eliminated."

Note the twin dangers the method's critics (including Toyota insiders) have flagged: stopping at symptoms, and single-rope causal chains. Toyota's own 2014 Annual Report still lists "The 'Five Whys'" as a section of what sets the company apart.

Verified quotes

• Toyota (official brand text, toyota-global): "The basic philosophy of the Toyota Production System is based on two pillars... The first pillar is jidoka... The second pillar is Just-in-Time." (TPS page)
• Kiichiro Toyoda, quoted verbatim on Toyota's TPS page: "A complete car cannot be built if even one part is missing. Coordinating this is no small task. However, without this control, we could have a mountain of parts and still not be able to build a car."
• Ohno's lubrication-pump 5-Whys example as reproduced and sourced by LEI; direct wording of Ohno's original book pages not independently fetched this session — treat the numbered example as LEI's verified rendering of Ohno 1988.
• Paraphrased from Ohno (as sourced on Wikipedia's Five Whys entry, which cites a Toyota Motor Asia Pacific piece, 2006): "Ask 'why' five times about every matter" — a Toyota-published phrasing I could not fetch directly.

How it maps to software

• Jidoka = stop the line. A failing build, a broken deploy, a production regression: fix the system that let it happen, not just this instance. CI breaking should block merges, like an andon cord that halts the line.
• Just-in-Time = small batches and WIP limits. Work is delivered "in the amount needed"; large queues of inventory in software are untested code, unbilled scope.
• 5 Whys = root cause before patching. Replace-the-fuse behavior is git revert and moving on. Five whys is: why did the revert even need to happen (missing test? missing review? ambiguous requirement?).

Sources

• Toyota Production System — Toyota official
• 5 Whys — Lean Enterprise Institute lexicon
• Toyota Annual Report 2014

2. PDSA / PDCA — Deming's System of Profound Knowledge and Out of the Crisis

Origin & who used it

Walter Shewhart at Bell Labs originated the Plan-Do-Check-Act cycle; W. Edwards Deming spread it through Japanese post-war industry (the best-known adopters) and then back into Western management. Today this is the engine under SRE, DevOps improvement cycles, and almost every "continuous improvement" program.

The process

Deming.org's PDSA page (the W. Edwards Deming Institute — the authoritative source) explains the cycle — verified verbatim:

"The PDSA Cycle (Plan-Do-Study-Act) is a systematic process for gaining valuable learning and knowledge for the continual improvement of a product, process, or service... The cycle begins with the Plan step. This involves identifying a goal or purpose, formulating a theory, defining success metrics and putting a plan into action... Next comes the Study step, where outcomes are monitored to test the validity of the plan... The Act step closes the cycle, integrating the learning generated by the entire process."

Crucially, Deming himself preferred PDSA over PDCA — the same page states the Institute's position: "Dr. Deming emphasized the PDSA Cycle, not the PDCA Cycle, with a third step emphasis on Study (S), not Check (C)." Plan, Do, Study, Act — you are running an experiment and comparing it to theory, not merely checking for pass/fail.

Deming's larger frame, the System of Profound Knowledge, integrates four areas: appreciation for a system, knowledge of variation, theory of knowledge, and psychology. The Institute quotes The New Economics (chapter 4) verbatim:

"The first step is transformation of the individual. This transformation is discontinuous. It comes from understanding of the system of profound knowledge."

The Institute also hosts Deming's own chapter-4 sentence, verified verbatim on the SoPK page: "One need not be eminent in any part nor in all four parts in order to understand it and apply it. The 14 points for management (Out of the Crisis, Ch. 2) in industry, education, and government follow naturally as application of this outside knowledge, for transformation from the present style of Western management to one of optimization."

(Note: Out of the Crisis itself is under copyright; its central argument — paraphrased — is that management should optimize the whole system rather than its individual components. The book text could not be verified this session, so verbatim attribution here is limited to what deming.org hosts.)

Verified quotes

• Deming via deming.org (SoPK page), quoting The New Economics ch. 4: "The first step is transformation of the individual... The individual, transformed, will perceive new meaning to his life, to events, to numbers, to interactions between people."
• deming.org PDSA page: "Dr. Deming found that the focus on Check is more about the implementation of a change, with success or failure. His focus was on predicting the results of an improvement effort, studying the actual results, and comparing them to possibly revise the theory."

How it maps to software

• Make improvement explicit experiment cycles: hypothesize (Plan) → ship behind a flag (Do) → look at the metric with the theory in mind (Study) → standardize, revert, or scale (Act).
• "Study, not check" is exactly the difference between "the pipeline is green" and "did lead time actually drop?"
• Deming's system-of-variation lens kills schedule guessing: if review latency or incident rate varies wildly week to week, that's the problem, not the mean.

Sources

• The Deming System of Profound Knowledge — W. Edwards Deming Institute
• The PDSA Cycle — W. Edwards Deming Institute

3. Toyota Kata and A3 — Mike Rother and John Shook: coaching the scientific loop

Origin & who used it

After studying Toyota's internal management system, Mike Rother published Toyota Kata (2009) and distilled two routines — the Improvement Kata (learner side) and the Coaching Kata (coach side). John Shook's Managing to Learn (Lean Enterprise Institute) documented the A3 one-page management process. These are how Toyota actually turns "ask why + experiment" into a daily habit that survives turnover.

The process

Improvement Kata. From Rother's own Toyota Kata site (the University of Michigan mirror of his official site), verified:

"Toyota Kata is a skill-building process that shifts you and your team from a natural tendency to jump to conclusions ... to thinking, working and reacting more scientifically. Best of all, you only need to practice 20 minutes a day, under the guidance of your coach."

The Improvement Kata page describes it as "a four-step model of scientific thinking, with practice routines" — in practice: (1) a direction/challenge from long-term entails gettingPicture the target condition, (2) grasp the current condition, (3) experiment against the next obstacle, (4) review what was learned. On its own site Rother is explicit about why: "Today's prescriptions probably won't fit tomorrow's problems... Your best bet is to practice a universal means of developing your own solutions."

Coaching Kata. The Coaching Kata page describes the coach's five-question card (a "Starter Kata" for the coach): one coaching cycle = coach asks the learner the five questions while the learner consults the storyboard; once per day at a scheduled time, "20 minutes or less each time." Verification note: the card's five questions themselves live in an image/PDF I could not extract this session; widely circulated wording is approximately: What's the target condition? What's the actual condition now? What obstacle are you addressing now? What's your next experiment and its expected result? When can we check what we've learned? — treat this wording as paraphrase, anchored by the verified "five Coaching Kata questions" terminology on Rother's page.

A3 problem solving. John Shook's Managing to Learn (Lean Enterprise Institute) is the reference text; the LEI lexicon's A3 entry describes the discipline verbatim:

"An A3 Report is a Toyota-pioneered practice of getting the problem, the analysis, the corrective actions, and the action plan down on a single sheet of large (A3) paper, often with the use of graphics... But it is much more than a sheet of paper with facts and figures. It is a management process learned through dialogue about concrete problems."

The A3 flows left side = current condition + problem analysis; right side = countermeasures, experiment plan, and follow-up; ownership sits with a named author in the upper right-hand corner. LEI adds: "leaders coach by asking questions versus providing answers, ensuring responsibility remains with the subordinate."

Verified quotes

• Rother (Toyota Kata homepage): "Toyota Kata is about starter practice routines for developing scientific thinking. From there each individual & team can develop their own way."
• LEI A3 lexicon: "Individuals earn the authority to take action through the manner in which they frame the issue... A3 management can best be understood as neither 'top-down' nor 'bottom-up.'"

How it maps to software

• The Improvement Kata is a natural fit for tech-debt reduction: the challenge is the architectural pivot; the target condition is measurable ("each service builds in under 5 minutes"); each week one obstacle gets one experiment behind a flag.
• A3 is the anti-RFC: one page, one owner, dialogue-driven, records decisions and experiments, not prose. It pairs with ADRs (architecture decision records) as the completed artifact.
• The 20-minute daily coaching cadence can be a standing 1:1 slot: five questions, learner's storyboard (= their A3 or kanban), coach as coach, not as fixer.

Sources

• Toyota Kata website — Mike Rother (and Improvement Kata / Coaching Kata pages)
• A3 — Lean Enterprise Institute lexicon; Shook, Managing to Learn, Lean Enterprise Institute (book page)

4. Theory of Constraints — Goldratt's The Goal, and DevOps via The Phoenix Project

Origin & who used it

Israeli physicist Eliyahu M. Goldratt introduced TOC in his 1984 business novel The Goal; his organization, the Goldratt Group, carried the work forward. Software re-adopted it wholesale through Gene Kim / Kevin Behr / George Spafford's The Phoenix Project — publisher IT Revolution's book page explicitly lists "Learn the Three Ways and the Theory of Constraints" and "Discover the four types of work" as the book's Teaching Pillars.

The process

The Goldratt Group site puts flow first, verbatim:

"We tend to see many separate objectives: output target, due date performance, operating expenses, quality and safety... However, when we focus on improving the system's flow, we are likely to achieve all of the above."

and identifies the counter-intuitive failure mode: "Doing more and starting earlier are the intuitive ways we try to protect flow, but these actions typically achieve the opposite... Too much Work In Process (WIP) increases the internal friction."

TOC's operating algorithm is the Five Focusing Steps (as described by the Theory of Constraints Institute) — essentially Lean/TOC PoOGI: Identify the system's constraint → Exploit it (squeeze full value from what you already have) → Subordinate everything else to that decision → Elevate the constraint (invest to raise its capacity) → Avoid inertia; when the constraint moves, go back to step 1.

Verified quotes

• Dr. Eli Goldratt, quoted on the Goldratt Group site: "The four concepts of flow: 1. Improving flow is a primary objective of operations. 2. This primary objective should be translated into a practical mechanism that guides the operation when not to produce (prevents overproduction). 3. Local efficiencies must be abolished. 4. A focusing process to balance the flow must be in place."
• The Goal and The Phoenix Project content (Herbie, the four types of work, "the constraint is the leverage point") is paraphrased from Goldratt's The Goal (Kelly/North River Press) and Kim/Behr/Spafford's The Phoenix Project — full-text quotes were not obtainable this session; the publisher's book page verifies the book's framing ("In a novel about IT... Bill... must fix the mess in ninety days... three luminaries of the DevOps movement").

How it maps to software

• Find the constraint in the delivery pipeline by measurement, not opinion: is the bottleneck code review, CI queue time, test duration, deploy cadence, or sign-off? Measure where PRs queue.
• Exploit first: don't buy a bigger CI box until reviewers are paring review time, authors are splitting PRs, and WIP limits exist. Over-building pipelines with idle downstream stations is the classic "transformation vs. throughput" mistake.
• Subordinate: once the constraint is clear, everything else adapts to it — the way DevOps teams protect a slow-to-change constraint rather than linting ahead of it.

Sources

• Theory of Constraints Institute — Goldratt & TOC
• Goldratt Group — Operational flow
• IT Revolution — The Phoenix Project

5. The Lean Startup — build–measure–learn (Eric Ries; Steve Blank's HBR essay)

Origin & who used it

Eric Ries's 2011 book The Lean Startup adapted Toyota's kaizen/learning-loop thinking into product development. Steve Blank's influential 2013 Harvard Business Review essay — "Why the Lean Start-Up Changes Everything" — is Steve Blank's own article (a common mis-attribution to Ries): "A faster, smarter methodology for launching companies may make business plans obsolete," by "Steve Blank... who has been either a cofounder or an early employee at eight high-tech start-ups."

The process

From theleanstartup.com/principles (Ries's own site), verified:

"A core component of Lean Startup methodology is the build-measure-learn feedback loop. The first step is figuring out the problem that needs to be solved and then developing a minimum viable product (MVP) to begin the process of learning as quickly as possible."

And on what to measure: "actionable metrics that can demonstrate cause and effect."

Ries's own framing of why a process matters: "Using the Lean Startup approach, companies can create order not chaos by providing tools to test a vision continuously." Progress itself is redefined: "The unit of progress for Lean Startups is validated learning — a rigorous method for demonstrating progress when one is embedded in the soil of extreme uncertainty."

Verified quotes

• Ries, theleanstartup.com: "Startup success can be engineered by following the process, which means it can be learned, which means it can be taught." (Also Ries's definition, verbatim on the same page: "a human institution designed to create a new product or service under conditions of extreme uncertainty.")
• Blank, HBR May 2013, summary block, verified from the article page: "In the past few years, a new methodology for launching companies, called 'the lean start-up,' has begun to replace the old regimen." (Full body behind HBR's paywall; the summary and billing are what I verified this session.)

How it maps to software

• Build–measure–learn is the sprint loop behind the feature flag: hypothesis → smallest experiment (dark launch / A-B test / prototype) → metric decision (ship, revert, pivot).
• Validated learning is the unit of delivery in production: stop measuring "tickets closed" and start measuring which hypotheses survived contact with the metric.
• A lean feature spec is one A3: hypothesis on the left, metric and experiment on the right.

Sources

• theleanstartup.com — Principles
• Steve Blank, "Why the Lean Start-Up Changes Everything," HBR, May 2013

6. Amazon's Working Backwards — PR/FAQ, one-way vs two-way doors, "Day 1"

Origin & who used it

Amazon formalized its product-decision process in the books Working Backwards (Colin Bryar & Bill Carr, 2021) and institutionalized the thinking in Jeff Bezos's shareholder letters and Amazon's Leadership Principles.

The process

Long-term orientation. Amazon's original 1997 letter, reprinted by Amazon, is anchored by the heading "It's All About the Long Term" and introduces the "Day 1" idea: "But this is Day 1 for the Internet and, if we execute well, for Amazon.com." Bezos's operating principles from that letter (verbatim, verified): "We will continue to make investment decisions in light of long-term market leadership considerations rather than short-term profitability considerations" and "We will continue to focus relentlessly on our customers."

One-way vs two-way doors. In the 2015 letter (Amazon IR, PDF), verified in the letter text (pulled this session via the letter's full text on Amazon's IR CDN):

"Some decisions are consequential and irreversible or nearly irreversible – one-way doors – and these decisions must be made methodically, carefully, slowly, with great deliberation and consultation... But most decisions aren't like that – they are changeable, reversible – they're two-way doors... Type 2 decisions can and should be made quickly by high judgment individuals or small groups."

and the warning:

"As organizations get larger, there seems to be a tendency to use the heavy-weight Type 1 decision-making process on most decisions, including many Type 2 decisions. The end result of this is slowness, unthoughtful risk aversion, failure to experiment sufficiently, and consequently diminished invention."

Day 2 is stasis. The 2016 letter, fetched verbatim:

"Day 2 is stasis. Followed by irrelevance. Followed by excruciating, painful decline. Followed by death. And that is why it is always Day 1."

Same letter, verbatim on decision velocity:

"First, never use a one-size-fits-all decision-making process. Many decisions are reversible, two-way doors... Second, most decisions should probably be made with somewhere around 70% of the information you wish you had... Third, use the phrase 'disagree and commit.'"

First-party operation text. Amazon's own Leadership Principles page names the working backwards mechanism: "Leaders start with the customer and work backwards," plus the review-safety tenet — "Leaders are vocally self-critical, even when doing so is awkward or embarrassing" — under Earn Trust.

PR/FAQ. The press-release-and-future-FAQ artifact (write the press release and FAQ before building) is the signature practice of Working Backwards. Verification note: description here is paraphrased from Bryar & Carr's Working Backwards (Currency/Penguin Random House, 2021); I could not fetch book text this session.

Verified quotes

See inline quotes above — the 1997 and 2016 letters were fetched page-verbatim from Amazon's own site; the 2015 letter's passages came from the letter itself as hosted on Amazon's investor-relations CDN (PDF).

How it maps to software

• Two-way-door classification kills RFC escalation theater: a flag-gated UI change is a two-way door — skip the committee.
• PR/FAQ for a new service is a cheaper experiment than the build: it forces customer value and competitive-landscape questions before code exists.
• "Day 1" for an engineer means treating the stack as if it must be reinvented: the happiest teams treat refactors/regressions as continuous learning, not as unrecoverable technical credit.

Sources

• Amazon's 1997 letter to shareholders / 2016 letter ("Day 2 is stasis") / 2015 letter PDF (Amazon IR CDN)
• Amazon Leadership Principles
• Bryar & Carr, Working Backwards — paraphrase (book text not fetched this session)

7. SpaceX / Elon Musk's "The Algorithm" (5 steps) — Everyday Astronaut Starbase tour, 2021

Origin & who used it

In July 2021, Everyday Astronaut's Tim Dodd toured Starbase with Elon Musk; in the on-camera interview Musk walked through his five-step engineering process. (Isaacson's 2023 biography Elon Musk later codified it as "the algorithm." — a secondary book I did not fetch this session.)

The process

The Everyday Astronaut write-up (by the interview host himself, Trevor Sesnic, Aug 11 2021) lays out the five steps, verified from that page (host's summary of the interview — the full video is the primary source):

1. "Make the requirements less dumb." "The requirements are definitely dumb; it does not matter who gave them to you." Musk added that it's dangerous when an intelligent person issues requirements, because no one questions them. He said: "Everyone's wrong. No matter who you are, everyone is wrong some of the time."
2. "Try very hard to delete the part or process." "If parts are not being added back into the design at least 10% of the time, not enough parts are being deleted." Each requirement must come "from a name, not a department, as a department cannot be asked why a requirement exists, but a person can."
3. "Simplify and optimize the design." After deletion, "the most common error of a smart engineer is to optimize something that should not exist."
4. "Accelerate cycle time." Musk: "you're moving too slowly, go faster! But don't go faster until you've worked on the other three things first."
5. "Automate." Last — and drop in-process testing once problems are diagnosed.

Musk's design-philosophy summary in the same interview, verified via the page: "all designs are wrong, it's just a matter of how wrong."

Verified quotes

All direct quotes above are from the Everyday Astronaut interview article (fetched this session); the underlying source is the two-hour Starbase Tour interview video/YouTube series. Isaacson's numbers ("Question every requirement... / Delete any part or process you can... / Simplify and optimize... / Accelerate cycle time... / Automate") are widely reproduced from Elon Musk (Simon & Schuster, 2023) but I did not verify that book text this session — use the EA version above.

How it maps to software

• Delete before refactor, literally: close a feature, check usage, and remove the code first — the fastest code is code that doesn't exist, costs nothing, and can't go wrong.
• Requirement ownership: every spec line gets a named owner who can explain why, not "legal" or "the platform team."
• Accelerate cycle time last: don't build a fancier pipeline around code that should be deleted; don't ask the pipeline to survive code that needs to die.

Sources

• Starbase Tour and Interview with Elon Musk — Everyday Astronaut (write-up of the July 30, 2021 interview)

8. Pixar's Braintrust — Ed Catmull on candor and authority

Origin & who used it

Pixar president Ed Catmull describes the Braintrust — the group that gives directors periodic, fearlessly candid film feedback with no authority over the director — in How Pixar Fosters Collective Creativity (HBR, 2008) and in Creativity, Inc. (Random House, 2014).

The process

Catmull's own words, from his authorized excerpt in Fast Company (a Reprint of Creativity, Inc., fetched verbatim this session):

"Candor is the key to collaborating effectively. Lack of candor leads to dysfunctional environments. So how can a manager ensure that his or her working group, department, or company embraces candor? By putting mechanisms in place that explicitly say it is valuable."

The mechanism; quote verified from the same page:

"One of Pixar's key mechanisms is the Braintrust, which we rely on to push us toward excellence and to root out mediocrity. It is our primary delivery system for straight talk... Its premise is simple: Put smart, passionate people in a room together, charge them with identifying and solving problems, and encourage them to be candid."

The two-part secret, from Catmull's own account (via the Stanford eCorner talk "Inside the Braintrust" and the Fast Company excerpt): (1) peers of comparable craft, and (2) no authority — the director decides what to do with the notes.

Verified quotes

• Catmull, HBR 2008 opening paragraphs, fetched: "His belief is rooted in a misguided view of creativity that exaggerates the importance of the initial idea in creating an original product." and "I couldn't disagree more with the studio executive." (Body of the HBR article beyond the opening is behind the paywall this session; the "Braintrust has no authority" passage on HBR was not verbatim accessible — use the Fast Company excerpt, which is Catmull's own, for verbatim quotes.)
• Catmull, Fast Company excerpt of Creativity, Inc. (fetched): "Pixar films are not good at first, and our job is to make them so — to go, as I say, 'from suck to not-suck.'"

How it maps to software

• Design-review and code-review get a rule pairing: peers, not gatekeepers; critique the work, not the person; the owner of the diff chooses how to respond.
• "No authority" is the candor unlock. People respond differently to "you're wrong about adoption because senior users already have a workflow" than to "change it back, per platform policy" — the same observation, attached to authority, invites defensiveness instead of honesty.
• Cadence matters: the Braintrust meets on a schedule tied to milestones (a working prototype, a season-end demo), not only when someone is panicked.

Sources

• Ed Catmull, "How Pixar Fosters Collective Creativity," HBR, September 2008
• Catmull's authorized excerpt, "Inside The Pixar Braintrust," Fast Company, March 2014
• Catmull, "Inside the Braintrust," Stanford eCorner clip

9. Double Diamond — British Design Council

Origin & who used it

The UK Design Council published the Double Diamond in 2004 (from its 2005 study of product-design methods) and updated it in 2019 as the Framework for Innovation. It's the standard industry-facing map of design problem-solving.

The process

From the Design Council's own page, verified verbatim this session: "The two diamonds represent a process of exploring an issue more widely or deeply (divergent thinking) and then taking focused action (convergent thinking)."

• Discover: "The first diamond helps people understand, rather than simply assume, what the problem is."
• Define: "The insight gathered from the discovery phase can help you to define the challenge in a different way."
• Develop: "The second diamond encourages people to give different answers to the clearly defined problem."
• Deliver: "Delivery involves testing out different solutions at small-scale, rejecting those that will not work and improving the ones that will."

And the governing principles, verified verbatim:

"Put people first. Start with an understanding of the people using a service, their needs, strengths and aspirations." "Communicate visually and inclusively." "Collaborate and co-create." "Iterate, iterate, iterate. Do this to spot errors early, avoid risk and build confidence in your ideas."

The Design Council is explicit that this is not a waterfall, on the same page: "This is not a linear process as the arrows on the diagram show."

Verified quotes

All quotes above from Design Council, Framework for Innovation, fetched this session.

How it maps to software

• Any "redesign this feature" or "rework this service" project is a Double-Diamond moment: talk to users and instrument the analytics (first diamond) before writing tickets; prototype both low- and high-fidelity variants in the second diamond before converging.
• "Put people first" is a two-way street for engineers: the people using the service and the people operating the service — both are users of the system you're proposing.
• The four phases map neatly onto a design-doc outline: problem evidence → re-framed problem statement → alternatives considered → recommendation + experiment plan.

Sources

• Design Council — Framework for Innovation (Double Diamond)

10. Google SRE: blameless postmortems and incident management

Origin & who used it

Google's Site Reliability Engineering practice operates large-scale distributed systems at Google; the SRE book is free at sre.google (the publisher's own hosting).

The process

From Chapter 15, "Postmortem Culture: Learning from Failure," verified verbatim:

"A postmortem is a written record of an incident, its impact, the actions taken to mitigate or resolve it, the root cause(s), and the follow-up actions to prevent the incident from recurring."

The core rule, from the same page:

"Blameless postmortems are a tenet of SRE culture. For a postmortem to be truly blameless, it must focus on identifying the contributing causes of the incident without indicting any individual or team for bad or inappropriate behavior... If a culture of finger pointing and shaming individuals or teams for doing the 'wrong' thing prevails, people will not bring issues to light for fear of punishment."

Systems over people, from the same page:

"When postmortems shift from allocating blame to investigating the systematic reasons why an individual or team had incomplete or incorrect information, effective prevention plans can be put in place. You can't 'fix' people, but you can fix systems and processes to better support people making the right choices."

And the epigraph of the chapter, from SRE Devin Carraway: "The cost of failure is education."

The structural connection to Toyota is direct: the SRE method lineage that the chapter's own references (and the industry more broadly) trace through healthcare/aviation safety culture and through Toyota's kaizen; Google even keeps a chapter on Incident Management (Ch. 14) and a Workbook chapter on postmortems and the 5 Whys.

Verified quotes

Every quote above is verbatim from sre.google, fetched this session.

How it maps to software

• Define objective postmortem triggers before incidents happen — Google's, verbatim: "User-visible downtime or degradation beyond a certain threshold / Data loss of any kind / On-call engineer intervention... / A resolution time above some threshold / A monitoring failure."
• Blamelessness is a condition for learning, not a nicety: if finger-pointing prevails, "people will not bring issues to light for fear of punishment," and the same incident keeps recurring.
• And the 5 Whys lives directly inside Google's postmortems: 5 Whys is explicitly listed as an accepted RCA technique in The SRE Workbook's postmortem chapter, and Google's postmortem template builds root-cause analysis into the document structure.

Sources

• SRE Book, Chapter 15: Postmortem Culture — Google
• SRE Book, Chapter 14: Managing Incidents — Google
• SRE Workbook, postmortem-analysis chapter — Google

11. OKRs — Andy Grove at Intel, John Doerr at Google (via whatmatters.com)

Origin & who used it

WhatMatters.com (John Doerr's book site for Measure What Matters) documents the lineage: "The OKR methodology was created by Andy Grove at Intel and taught to John Doerr by him... Doerr was the one who crafted the name 'OKRs.' He introduced the philosophy to Google's founders in 1999."

The process

Objective + Key Results, from whatmatters.com, verified verbatim:

"An Objective is simply what is to be achieved, no more and no less. By definition, Objectives are significant, concrete, action oriented, and (ideally) inspirational. When properly designed and deployed, they're a vaccine against fuzzy thinking and ineffective execution."

"Effective KRs are specific, time-bound, and aggressive yet realistic. Most of all, they are measurable and verifiable. You either meet a Key Result's requirements or you don't — there is no gray area, no room for doubt."

The canonical one-sentence form, from the same page:

"I will (Objective) as measured by (Key Results)."

Types include committed vs. aspirational ("moonshot") OKRs, and learning OKRs for genuinely uncertain outcomes ("What is the most important thing we're trying to learn in the next 90 days?"). Doerr's benefits summary on the site is the F.A.C.T.S. framework: Focus, Alignment, Commitment, Tracking, Stretching.

Verified quotes

All quotes from whatmatters.com, fetched this session.

How it maps to software

• OKRs give the whole loop (postmortem, kata, lean experiment, TOC fix) a shared direction and a cadence: what one multi-quarter improvement is your team aiming at?
• The rule "measurable and verifiable... no gray area" comes directly from Deming via Grove — in SRE terms, it's an SLO-like formulation: "reduce p95 checkout latency from 800 ms to 300 ms" beats "make checkout feel faster."
• Don't grade outputs, grade outcomes: "PRs merged" is a proxy metric — apply Bezos's "Resist Proxies" test (2016 letter, §6 above); "we cut p95 signup latency in half" is a key result.

Sources

• whatmatters.com — "What is an OKR?"

The Integration Playbook: making these processes work in a software team

None of the disciplines above require a budget. They require a trigger, a template, and a cadence. Here's the hands-on version for a typical product team.

1. Incident review = blameless 5-Whys postmortem (SRE + Toyota)

Trigger (write yours first, before the next incident): any Sev1/Sev2, any data loss, any deploy interference by a human, any monitoring gap. (SRE-book-style triggers, from sre.google.)

Template (skeleton)

Incident: <short title>   Date: <date>   Severity: <sev>
Author/Owner: <named person, per A3 ownership rule>

Impact
  - Users affected / duration / revenue or SLO impact (numbers, not adjectives)

Timeline
  - t0 detection → t1 mitigation → t2 resolution (auto-collected if possible)

Root cause (5 Whys — one causal chain per symptom; branch if needed)
  1. Why did users see errors?  ...
  2. Why was the faulty path live?  ...
  3. Why did testing not catch it?  ...
  4. Why was that gap there?  ...
  5. Why does that gap exist in our process, not our intentions?  ...

Contributing factors (system, not people — blamelessness rule)
  What information did the people involved lack at decision time?

Action items (each: owner = name, due date, ticket link)
  - FIX      <what>, owner, date, link
  - MONITOR  <what>
  - PROCESS  <what>   ← usually the highest-value item

Rules of the meeting (from the SRE book's best practices): no performance reviews in this room; action items must have owners and dates; ask "did we share the outcome with relevant stakeholders?" before closing.

2. A3-style one-page design docs (Lean / Toyota) — replacing heavyweight RFCs

Replace the 15-page RFC with an A3 for non-trivial design problems (LEI's A3 definition). Six quadrants, one page:

Owner's name goes in the top-right corner — A3 management's signature move. Review with questions ("what metric will you need to see to feel safe this worked?"), not with edits.

3. Kata weekly coaching cadence (Toyota Kata) — for the multi-quarter target

Pick one standing 20-minute slot per week, rotating through team members:

1. Learner opens their storyboard — their A3 (or a sticky for each quadrant).
2. Coach fires the five Coaching Kata questions (see §3 of the body above) and, crucially, does not propose answers.
3. Learner commits to one next experiment with an expected outcome and a check date ("when can we go and see what we've learned?").
4. Kanban note: experiments live as visible cards with expected results — PDSA made physical.

Good first applications: tech-debt reduction (challenge: "p95 build time under 5 minutes"; kata target: "the flakiest suite now runs in CI every PR"), on-call pain ("page-free daytime"), and onboarding time.

4. Working Backwards: PR/FAQ + one-way/two-way door classification

• PR/FAQ before spec (Amazon Working Backwards style — see Bezos's letters in §6): if you can't write the customer-facing press release and the hard FAQ questions honestly, the feature isn't ready. Cheap and it kills over-engineering in principle.
• Door-classification in ADRs (architecture decision records): add one field — Door: one-way | two-way — plus a plane for rollback. Two-way doors under a flag get quick review and fast ship (2015 letter, verbatim in §6) — matching Amazon's own bias-for-action principle: "Many decisions and actions are reversible and do not need extensive study."
• Disagree and commit in code review: voice disagreement, then commit to the decided path. It's a stated Leadership Principle for a reason.

5. Lean Startup loop: hypothesis → smallest experiment → production metric

Per sprint or per milestone, the Ries loop (from theleanstartup.com, verbatim in §5):

"The fundamental activity of a startup is to turn ideas into products, measure how customers respond, and then learn whether to pivot or persevere."

Mechanic: every feature ticket gets a hypothesis line: "We believe <change> will <metric> move <N>% for <audience> because <reason>." Ship it as the smallest test: flag-gated rollout, dark launch, A-B variant, or a fake-door prototype. Shadow-launch, snapshot the metric, decide. Frame successful ships and successful rejections as validated learning.

6. Theory of Constraints in the delivery pipeline

Run this diagnostic once per quarter (TOC Five Focusing Steps, §4 above):

1. Identify the constraint by measurement, not impression. Pull a time-in-queue histogram: code review? CI minutes? Post-merge wait? Design? The slowest shared step is the constraint.
2. Exploit it first — no spend. If reviews are the constraint: smaller PRs, review SLAs, rotated review owners, and an explicit rule that approved PRs never wait to merge.
3. Subordinate everything else. If CI is the constraint, change WIP limits per team so the pipeline stays fed but never flooded — Goldratt Group's point that "Too much Work In Process (WIP) increases the internal friction" applies to PRs as much as to parts.
4. Elevate only after 2 and 3 — and then re-check: someone else's wait just became the new constraint.
5. Also track WIP: find the four types of work blocks in your backlog (The Phoenix Project): Business projects, Internal IT projects, Changes, Unplanned work. Unplanned work above ~20% is usually a smell that constraints elsewhere aren't being treated.

7. The Algorithm (Musk's 5 steps) as a deletion-first culture rule

Adopt the Everyday Astronaut-verified five steps as a literal check-in on any proposal:

1. Less-dumb requirements: every spec line has a name attached, not a department. Apply: ticket fields, alert thresholds, "requirements" in design docs.
2. Delete before refactor: in the A3's "Countermeasures considered" box, always include a "delete the feature / process / integration entirely" option. The 10% add-back rule is the discipline: if you never miss anything you deleted, you didn't delete enough.
3. Then optimize what survived.
4. Then accelerate cycle time — faster CI, faster deploys, faster feedback loops.
5. Automate last. Automating a broken process just moves the mistake into faster loops.

Practical trigger: any time a proposal mentions "add a tool," require that the "delete" option above it be genuinely argued first.

8. Braintrust rules for design/code review

From Catmull's Fast Company excerpt (verbatim in §8 above):

• Notes are observations, not commands — "I noticed X" is data; directives ("just change Y") are the manager habit to drop, exactly as Catmull's candor premise describes: "Put smart, passionate people in a room together, charge them with identifying and solving problems, and encourage them to be candid."
• The reviewer has no authority — the author owns the resolution. For code review this sounds like teaching, not like "this is blocking until you do my thing."
• The manager's job is to protect the compact, not to be the candor hero: "my primary role is making sure that the compact upon which the meetings are based is protected and upheld."
• Cadence: demo-driven, not crisis-driven (a working artifact, every converged cycle, is the Pixar reel analog).

9. Double Diamond for problem discovery / UX redesign

For any "let's redesign X" work, run the four phases on the Design Council page (verbatim principles in §9 above). Practical engineering anchors:

• Discover = instrument, not opinion: pull analytics, watch 3 recorded sessions, read support tickets, run 5 user interviews. "Understand, rather than simply assume, what the problem is."
• Define = reframe the problem before writing solutions — this is the A3's left side.
• Develop = alternatives in both directions, cheap prototypes (from UI mock to a parallel service-in-shadow) before converging.
• Deliver = the build–measure–learn loop from §5. Double Diamond and Lean are the same animal from two directions.

10. OKRs to aim the loop (keep everything outcome-focused)

Per whatmatters.com's F.A.C.T.S.: set one Objective per quarter per team and 3–5 Key Results. Ideal SWE KR verifiable form: "I will <objective> as measured by <verified metric>." Keep committed vs. aspirational goal types clearly labeled; every postmortem, kata, TOC fix and lean experiment should be executed in service of a KR, and its A3's Target Condition block should point back to it. This is where process stops being ceremony: improvement work that doesn't serve a declared KR is free parking.

When to use which discipline (first-move matrix)

Final consolidated source list

1. Toyota Motor Corporation official — The Toyota Production System
2. Toyota Motor Corporation — Annual Report 2014 (official history of kaizen, genchi genbutsu, jidoka, "Five Whys" section)
3. Lean Enterprise Institute — A3 lexicon entry and 5 Whys lexicon entry (referencing Ohno 1988)
4. Lean Enterprise Institute — John Shook, Managing to Learn
5. W. Edwards Deming Institute — System of Profound Knowledge and The PDSA Cycle
6. Mike Rother — Toyota Kata website (Rother's own site) and its mirror (Toyota Kata root)
7. Theory of Constraints Institute — Theory of Constraints, Eli Goldratt profile
8. Goldratt Group — Operational: The primary objective of operations is flow
9. IT Revolution — The Phoenix Project, Kim / Behr / Spafford
10. Eric Ries — theleanstartup.com, Principles
11. Steve Blank — Why the Lean Start-Up Changes Everything, HBR May 2013
12. Amazon IR / aboutamazon — 1997 letter to shareholders, 2015 letter (IR PDF), 2016 letter ("Day 2 is stasis")
13. Amazon — Leadership Principles
14. Everyday Astronaut — Starbase Tour and Interview with Elon Musk, Aug 2021 (host-author write-up of the interview video)
15. Ed Catmull — How Pixar Fosters Collective Creativity, HBR Sept 2008; Inside the Pixar Braintrust — authorized excerpt, Fast Company 2014; Inside the Braintrust clip, Stanford eCorner
16. Google SRE Book (Google's official hosting) — Ch. 15 Postmortem Culture, Ch. 14 Managing Incidents; SRE Workbook postmortem chapter
17. Design Council — Framework for Innovation / Double Diamond
18. WhatMatters.com — What is an OKR?

Paraphrase-only items (attributed content not fetched verbatim this session): Goldratt's The Goal (content verified only via the TOC Institute / Goldratt Group pages), Kim/Behr/Spafford's The Phoenix Project (via the IT Revolution publisher page), Bryar & Carr's Working Backwards (PR/FAQ practice), Ohno's own Toyota Production System wording (used here via LEI's sourced recreation of the 1988 example), Steve Blank's HBR article body (paywalled; the article's summary/abstract was verified), the Pixar HBR article body (paywalled; the authorized Fast Company excerpt was fetched instead), and Walter Isaacson's Elon Musk (secondary; all Algorithm quotes above use the Everyday Astronaut interview page instead).