<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	
	>
<channel>
	<title>
	Comments for Lean Blog	</title>
	<atom:link href="http://www.leanblog.org/comments/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.leanblog.org/</link>
	<description>Lean in Hospitals, Business, and Our World</description>
	<lastBuildDate>Thu, 04 Jun 2026 02:52:25 +0000</lastBuildDate>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=7.0</generator>
	<item>
		<title>
		Comment on Making Defects Visible: From Krispy Kreme to Healthcare by Mark Graban		</title>
		<link>https://www.leanblog.org/2022/03/making-defects-visible/#comment-629697</link>

		<dc:creator><![CDATA[Mark Graban]]></dc:creator>
		<pubDate>Thu, 04 Jun 2026 02:46:37 +0000</pubDate>
		<guid isPermaLink="false">https://www.leanblog.org/?p=64551#comment-629697</guid>

					<description><![CDATA[In reply to &lt;a href=&quot;https://www.leanblog.org/2022/03/making-defects-visible/#comment-629696&quot;&gt;otomatisasi&lt;/a&gt;.

I think part of what avoids panic is being able to credibly shift from discussing the defects and the problem to talking about how we&#039;ll go above solving the problem.]]></description>
			<content:encoded><![CDATA[<p>In reply to <a href="https://www.leanblog.org/2022/03/making-defects-visible/#comment-629696">otomatisasi</a>.</p>
<p>I think part of what avoids panic is being able to credibly shift from discussing the defects and the problem to talking about how we&#8217;ll go above solving the problem.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		Comment on Making Defects Visible: From Krispy Kreme to Healthcare by otomatisasi		</title>
		<link>https://www.leanblog.org/2022/03/making-defects-visible/#comment-629696</link>

		<dc:creator><![CDATA[otomatisasi]]></dc:creator>
		<pubDate>Tue, 02 Jun 2026 03:39:05 +0000</pubDate>
		<guid isPermaLink="false">https://www.leanblog.org/?p=64551#comment-629696</guid>

					<description><![CDATA[Great article, Mark! Making defects visible is much easier when you can physically see a half-fried donut. However, in software development or healthcare, &#039;defects&#039; are often buried in code or hidden due to a fear of blame. In your experience, what is the most effective first step for a leader to make invisible digital or process defects visible without causing panic?]]></description>
			<content:encoded><![CDATA[<p>Great article, Mark! Making defects visible is much easier when you can physically see a half-fried donut. However, in software development or healthcare, &#8216;defects&#8217; are often buried in code or hidden due to a fear of blame. In your experience, what is the most effective first step for a leader to make invisible digital or process defects visible without causing panic?</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		Comment on GM Spent $90 Billion on Automation &#8212; Toyota&#8217;s Advantage Was Management by Mark Graban		</title>
		<link>https://www.leanblog.org/2016/06/gm-toyota-automation-failure-lean-lessons/#comment-629693</link>

		<dc:creator><![CDATA[Mark Graban]]></dc:creator>
		<pubDate>Thu, 28 May 2026 23:14:26 +0000</pubDate>
		<guid isPermaLink="false">https://www.leanblog.org/?p=30278#comment-629693</guid>

					<description><![CDATA[In reply to &lt;a href=&quot;https://www.leanblog.org/2016/06/gm-toyota-automation-failure-lean-lessons/#comment-629689&quot;&gt;otomatisasi&lt;/a&gt;.

Great question. Only time will tell. I&#039;m sure many companies are chasing the shiny object by jamming AI into their tech product, or demanding their employee jam AI into their work.]]></description>
			<content:encoded><![CDATA[<p>In reply to <a href="https://www.leanblog.org/2016/06/gm-toyota-automation-failure-lean-lessons/#comment-629689">otomatisasi</a>.</p>
<p>Great question. Only time will tell. I&#8217;m sure many companies are chasing the shiny object by jamming AI into their tech product, or demanding their employee jam AI into their work.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		Comment on Why You Can&#8217;t Think Your Way to a Root Cause by Mark Graban		</title>
		<link>https://www.leanblog.org/2026/04/suspected-root-cause-test-it/#comment-629692</link>

		<dc:creator><![CDATA[Mark Graban]]></dc:creator>
		<pubDate>Thu, 28 May 2026 23:12:28 +0000</pubDate>
		<guid isPermaLink="false">https://www.leanblog.org/?p=84397#comment-629692</guid>

					<description><![CDATA[I asked my &lt;a href=&quot;https://www.markgraban.com/coach/&quot; rel=&quot;nofollow ugc&quot;&gt;Lean AI Coach&lt;/a&gt; this question:

Lean Coach
Mark: can we know the root cause of a problem by discussing it in a meeting room?

Coach: Short answer: rarely. The conference room is where root cause analysis goes to die.

### Why the room isn&#039;t enough

When you discuss a problem in a meeting room, you&#039;re working from memory, opinion, and secondhand accounts. People describe what they *think* happens, not what actually happens. Those are different things more often than anyone wants to admit.

Taiichi Ohno was blunt about this. **The answers are at the gemba -- the actual place where work happens.** Not in a slide deck. Not in someone&#039;s recollection. The famous story of Ohno drawing a circle on the floor and making a manager stand in it for hours was about teaching one thing: go see, and keep seeing until you actually understand.

### What the room produces instead

Meeting-room root cause analysis tends to generate:

- **Plausible-sounding causes** that match people&#039;s existing assumptions
- **Person-blame** -- &quot;the operator wasn&#039;t careful&quot; -- because that&#039;s the easy story when you&#039;re not watching the work
- **Solutions in search of a problem** -- someone&#039;s pet idea gets attached to the symptom

A 5 Whys done in a conference room often becomes 5 Guesses. You can chain together five confident answers and still be completely wrong because nobody checked any of them against reality.

### What the room is good for

The room isn&#039;t useless. It&#039;s where you:

- Frame the problem and agree on what you&#039;re trying to understand
- Share what people observed at the gemba
- Compare data -- ideally on a process behavior chart, so you know whether you&#039;re chasing a signal or just noise
- Plan the next experiment

But the *understanding* has to come from going and seeing. The room is for making sense of what you found, not for inventing it.

### The bottom line

You can discuss a problem in a meeting room, but you can&#039;t find its root cause there -- the cause lives at the gemba, and the conference room only works once you&#039;ve gone and observed the actual work.

-- Lean Coach by Mark Graban (markgraban.com/coach)]]></description>
			<content:encoded><![CDATA[<p>I asked my <a href="https://www.markgraban.com/coach/" rel="nofollow ugc">Lean AI Coach</a> this question:</p>
<p>Lean Coach<br />
Mark: can we know the root cause of a problem by discussing it in a meeting room?</p>
<p>Coach: Short answer: rarely. The conference room is where root cause analysis goes to die.</p>
<p>### Why the room isn&#8217;t enough</p>
<p>When you discuss a problem in a meeting room, you&#8217;re working from memory, opinion, and secondhand accounts. People describe what they *think* happens, not what actually happens. Those are different things more often than anyone wants to admit.</p>
<p>Taiichi Ohno was blunt about this. **The answers are at the gemba &#8212; the actual place where work happens.** Not in a slide deck. Not in someone&#8217;s recollection. The famous story of Ohno drawing a circle on the floor and making a manager stand in it for hours was about teaching one thing: go see, and keep seeing until you actually understand.</p>
<p>### What the room produces instead</p>
<p>Meeting-room root cause analysis tends to generate:</p>
<p>&#8211; **Plausible-sounding causes** that match people&#8217;s existing assumptions<br />
&#8211; **Person-blame** &#8212; &#8220;the operator wasn&#8217;t careful&#8221; &#8212; because that&#8217;s the easy story when you&#8217;re not watching the work<br />
&#8211; **Solutions in search of a problem** &#8212; someone&#8217;s pet idea gets attached to the symptom</p>
<p>A 5 Whys done in a conference room often becomes 5 Guesses. You can chain together five confident answers and still be completely wrong because nobody checked any of them against reality.</p>
<p>### What the room is good for</p>
<p>The room isn&#8217;t useless. It&#8217;s where you:</p>
<p>&#8211; Frame the problem and agree on what you&#8217;re trying to understand<br />
&#8211; Share what people observed at the gemba<br />
&#8211; Compare data &#8212; ideally on a process behavior chart, so you know whether you&#8217;re chasing a signal or just noise<br />
&#8211; Plan the next experiment</p>
<p>But the *understanding* has to come from going and seeing. The room is for making sense of what you found, not for inventing it.</p>
<p>### The bottom line</p>
<p>You can discuss a problem in a meeting room, but you can&#8217;t find its root cause there &#8212; the cause lives at the gemba, and the conference room only works once you&#8217;ve gone and observed the actual work.</p>
<p>&#8212; Lean Coach by Mark Graban (markgraban.com/coach)</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		Comment on GM Spent $90 Billion on Automation &#8212; Toyota&#8217;s Advantage Was Management by otomatisasi		</title>
		<link>https://www.leanblog.org/2016/06/gm-toyota-automation-failure-lean-lessons/#comment-629689</link>

		<dc:creator><![CDATA[otomatisasi]]></dc:creator>
		<pubDate>Tue, 26 May 2026 04:24:22 +0000</pubDate>
		<guid isPermaLink="false">https://www.leanblog.org/?p=30278#comment-629689</guid>

					<description><![CDATA[Great article, Mark. It’s fascinating how history repeats itself. With the current boom in AI and digital transformation, do you see modern tech companies making the exact same mistakes Roger Smith did, or have we genuinely learned how to integrate culture with technology this time around?]]></description>
			<content:encoded><![CDATA[<p>Great article, Mark. It’s fascinating how history repeats itself. With the current boom in AI and digital transformation, do you see modern tech companies making the exact same mistakes Roger Smith did, or have we genuinely learned how to integrate culture with technology this time around?</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		Comment on The Magic of Small, Odd Experiments: What Rory Sutherland Can Teach Lean Practitioners by Mark Graban		</title>
		<link>https://www.leanblog.org/2026/05/lean-alchemy-small-experiments/#comment-629683</link>

		<dc:creator><![CDATA[Mark Graban]]></dc:creator>
		<pubDate>Sun, 17 May 2026 23:39:53 +0000</pubDate>
		<guid isPermaLink="false">https://www.leanblog.org/?p=84615#comment-629683</guid>

					<description><![CDATA[In reply to &lt;a href=&quot;https://www.leanblog.org/2026/05/lean-alchemy-small-experiments/#comment-629682&quot;&gt;Doug Donaldson&lt;/a&gt;.

Thanks for reading and commenting, Doug. If we don&#039;t let employees experiment with &quot;it&#039;s the right thing to do&quot; situations, I wouldn&#039;t expect them to be excited about any improvement work that&#039;s directed by leaders or ROI factors.]]></description>
			<content:encoded><![CDATA[<p>In reply to <a href="https://www.leanblog.org/2026/05/lean-alchemy-small-experiments/#comment-629682">Doug Donaldson</a>.</p>
<p>Thanks for reading and commenting, Doug. If we don&#8217;t let employees experiment with &#8220;it&#8217;s the right thing to do&#8221; situations, I wouldn&#8217;t expect them to be excited about any improvement work that&#8217;s directed by leaders or ROI factors.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		Comment on The Magic of Small, Odd Experiments: What Rory Sutherland Can Teach Lean Practitioners by Doug Donaldson		</title>
		<link>https://www.leanblog.org/2026/05/lean-alchemy-small-experiments/#comment-629682</link>

		<dc:creator><![CDATA[Doug Donaldson]]></dc:creator>
		<pubDate>Sun, 17 May 2026 18:28:47 +0000</pubDate>
		<guid isPermaLink="false">https://www.leanblog.org/?p=84615#comment-629682</guid>

					<description><![CDATA[I love this! I&#039;ve worked for healthcare organizations that are happy to pursue changes &quot;so long as they have a positive ROI&quot;. The impact of some changes is harder to measure, but that doesn&#039;t mean they&#039;re not worth doing. A colleague of mine used to argue that &quot;it&#039;s the right thing to do&quot; was enough rationale, but few organizations have strong enough shared values to make those conversations easy and intuitive.]]></description>
			<content:encoded><![CDATA[<p>I love this! I&#8217;ve worked for healthcare organizations that are happy to pursue changes &#8220;so long as they have a positive ROI&#8221;. The impact of some changes is harder to measure, but that doesn&#8217;t mean they&#8217;re not worth doing. A colleague of mine used to argue that &#8220;it&#8217;s the right thing to do&#8221; was enough rationale, but few organizations have strong enough shared values to make those conversations easy and intuitive.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		Comment on Ryan McCormack&#8217;s Operational Excellence Mixtape: April 3, 2026 by Sam Rivera		</title>
		<link>https://www.leanblog.org/2026/04/ryan-mccormacks-operational-excellence-mixtape-april-3-2026/#comment-629666</link>

		<dc:creator><![CDATA[Sam Rivera]]></dc:creator>
		<pubDate>Sat, 16 May 2026 07:06:11 +0000</pubDate>
		<guid isPermaLink="false">https://www.leanblog.org/?p=84251#comment-629666</guid>

					<description><![CDATA[Quality content right here. Appreciate it. &lt;a href=&quot;https://dreamlux.ai
&quot;&gt;this one&lt;/a&gt;]]></description>
			<content:encoded><![CDATA[<p>Quality content right here. Appreciate it. <a href="https://dreamlux.ai
">this one</a></p>
]]></content:encoded>
		
			</item>
	</channel>
</rss>
