Watch the recording of the webinar:
View the slides (downloadable PDF):
Listen to the recording via our podcast:
Eric Ethington opened the session with a frustration that anyone running improvement work for any length of time has lived through. The Lean team is doing good work. Smart people, well-intentioned, executing real improvements across a current process. Then a new process launches — a new line, a new clinic, a new service workflow — and the launch goes badly enough that the team that was making the existing work better gets pulled off that work to firefight the new one. By the time they have the new process functioning, the old work has degraded again. They go back to fix the old one. Another new process launches. Repeat.
He called this a development rework cycle, and the framing he and his co-author Matt Zayko built the book around is that this cycle isn't an execution problem. It's an upstream problem. The processes being launched were never designed in a way that incorporated what the organization had already learned. The learning that lives in every Lean program — about flow, about waste, about how work actually happens — fails to make its way back into how new processes are conceived. Each launch, in effect, starts from scratch and pays the price downstream.
Eric pulled in a useful term from a Jim Womack article: tozen versus kaizen. A tozen is a kaizen that should never have been necessary — an improvement made after launch that could have been avoided if the launch itself had been designed with the relevant learning already incorporated. Most CI programs are tozen factories. They get praised for the rework they do because the rework is visible. The invisible cost is that the rework was preventable.
This session is the working framework for preventing it. The Six-Con model gives the structure. The system architect role gives the ownership. And Eric's eight practical lessons for getting started keep the framework from collapsing under its own ambition.
Eric Ethington is president of LeanShift Consulting and has over 35 years of work experience at Delphi, Textron, and LeanShift. He has worked across automotive, aerospace, defense, healthcare, medical devices, energy, and logistics. He holds a Bachelor of Science in Industrial Engineering from Kettering University (formerly GMI) and an MBA in Operations from the University of Michigan, Flint campus, and earned a Six Sigma Design Black Belt while at Textron. He serves on the Board of Directors at Goodwill Industries of Mid-Michigan and on the Alumni Advisory Board for the Industrial and Manufacturing Engineering department at Kettering University. He is co-author with Matt Zayko of "The Power of Process: A Story of Innovative Lean Process Development."
Eric walked through the model as a series of lenses rather than a sequence of phases. Each lens is a way of looking at the same overall work — process development from idea to delivery — at a different level of resolution. The iteration runs throughout. The framework is not linear.
Context. What does good look like? This is where value is defined and where the needs of all the relevant stakeholders are understood. Customer value is the anchor, but Eric was careful here. An organization can drive itself out of business by meeting every customer demand without considering employees, investors, and the organization's own sustainability. The work in context is finding the intersection — the sweet spot where the value equation works across all the stakeholders that matter, not just the loudest one.
Concepts. Multiple process ideas to fulfill the value equation identified in context. Eric warned against arriving at concepts with a single idea already in mind. The universe is infinite. If your team brought one option, they probably didn't stretch hard enough. Concepts is where the team generates many possibilities, examines what's better about some than others, and develops the comparison criteria that will eventually narrow the field.
Converge. Running experiments and tests on the multiple concepts to narrow from many to fewer to one direction. The convergence isn't a vote. It's a learning process. Requirements get clarified as the concepts are tested. Some ideas turn out to be more workable than they first appeared. Others reveal hidden constraints. By the end of converge, the team has settled on a loose direction — not yet the detailed design, but the operating shape.
Configure. Tightening the loose idea into a specific design. The physical layout, the workplace details, the connections between steps. Eric flagged that he and Matt had considered making "connect" a seventh lens in its own right, because how the work connects into a value stream matters at least as much as how individual workplaces are configured. They folded it into this lens for simplicity, but the connections are the load-bearing element. A process design that nails every workplace and fails the connections between them is a process design that won't flow.
Confirm. Testing the actual configuration against the original metrics established in context. This is where physical components — installed equipment, real workflows, actual staff — get exercised in predetermined ways before launch. The PDCA cycle applied to the entire process development effort, not just to individual improvements within it. The question is whether what was designed in concept is actually performing in installation.
Continuously improve. Eric was direct that no launch is perfect, and that if it appeared to be, the team probably wasn't smart enough to know it wasn't. Continuous improvement starts the moment the new process is operating, but the starting point is higher than it would have been without the previous five lenses. The improvements being made are refinements to a well-designed system, not rescues of a poorly-designed one.
The model is iterative within each lens and across the lenses. Eric mentioned that the book walks through eight separate iterations of concept work before settling on a final direction for the case study. The model is not a checklist. It's a discipline for how learning gets organized across a long design effort.
The Six-Con model produces results only if someone owns the integration. Eric proposed the term "system architect" for that role, borrowed from a 2009 senior leader session run by Dave Logozzo while he was at the Lean Enterprise Institute. The word stuck for him because it captures what the role actually does. An architect designing a building knows enough about construction to set the vision and guide the work without swinging hammers personally. They aren't the expert in the latest construction techniques. They are the person who keeps the whole thing coherent.
Eric's framing is that the system architect is responsible for two parallel problems — or, in his analogy, two A3s.
The first A3 is the development of the physical value stream itself. The new clinic, the new line, the new service workflow. Whatever specific value stream is being built, the system architect doesn't build it personally but owns the process by which it gets built.
The second A3 is the development and spread of the new way of working — meaning the process of process development itself. The Six-Con model isn't useful if it only gets used once. The system architect's second responsibility is making this approach repeatable across the organization, so the next value stream gets developed the same way, and the one after that, and the one after that.
The system architect doesn't have to know everything. They have to be responsible for getting the organization to understand and act on these issues. In Eric's framing, they are the author of both A3s — orchestrating the work, surfacing problems, coordinating the resources, but not personally doing every step.
Eric walked through five functional dimensions of the role, each worth pulling out individually.
Resident visionary. Getting the organization aligned around the vision of the value stream being developed and the vision of how process development should work going forward. The visionary work is about generating shared mental models, not about prophesying. People need to see the same future for the work to converge on it.
Resident historian. Capturing the knowledge from this development cycle in a form that survives the cycle. Most organizations do good work and then lose the learning because they never built the capture into the work. The system architect is the historian going forward — not someone who has memorized the past, but someone who ensures the present gets recorded for the next iteration. Eric's framing of knowledge as an asset that is being burned and lost if not captured was sharp. The economic cost of redoing the same work in the next cycle is real, even if it's invisible on a spreadsheet.
Mentor and coach, at two levels. The system architect coaches the team developing the physical value stream — helping them discover process elements, workplace configurations, and how the value stream connects. They also coach the leadership team, which is often the harder problem. Leadership will want more, faster. They'll want to spread early results before the results are stable. They'll want to intervene when a team raises a problem in ways that close down the team's willingness to raise problems in the future. The system architect's job is to coach leaders into different behaviors — not by lecturing, but by showing them what better coaching and better intervention look like.
Program manager. The system architect needs program management skills to keep both A3s on timing and on performance. Hitting milestones matters. So does hitting the actual performance targets — Eric used the example of targeting a seven-month lead time from start of process development to a fully running, target-hitting installation. The program management work is what keeps the discipline visible.
Liaison. Bridging between the team developing the physical value stream and the leadership supporting them. This is often where the day-to-day work lives. Translating what a manager said into what they actually meant. Translating what the team is encountering into what leadership needs to know about it. Helping each side hear the other accurately. Eric's framing was that this liaison work is most of what the role looks like early in the journey, when the two A3s are still being learned by everyone involved.
He also offered a useful comparison Mark raised during Q&A. A system architect overlaps with a value stream manager but isn't identical. A value stream manager owns the flow of one specific value stream. A system architect owns the process by which all future value streams get developed, not just the one currently in front of them. The two roles can be paired — value stream manager focused on the operating value stream, system architect focused on the development process and the next value stream — and in the book's case study, two people shared the system architect role during the actual development cycle.
Eric closed with eight practical lessons. The full list in the slide deck has eighteen; these eight are the ones he picked as most important to share live.
Align on a shared reason for change. Without a real reason for the organization to want this, the fires of the day will pull resources away. The reason for change has to be specific enough to anchor focus.
Pick something meaningful and try. The work has to attach to an actual project that needs a process developed. Theoretical discussions of process development don't survive contact with operational reality. The improvement is in the doing.
Have a bias toward organizational stability. This one carries some weight. Eric was direct that he has been in plants where he, as the CI person, was the highest-tenure leader in the leadership team at fourteen months — because the organization kept reorganizing. Continuous reorganization makes process development impossible. People rotate out before learning compounds. Mentor and Coach should still bring new people in, but the cadence of structural change has to slow down enough for anything to stick.
Help needs to feel like help. Eric attributed this to his colleague Jim Morgan. When a leader's version of "help" is doubling the reporting cadence for a team that's off-target, that isn't help. That's surveillance dressed up as support. The system architect's liaison role often surfaces when leadership's helping behaviors are making things worse instead of better, and the coaching is sometimes about renegotiating what helpful means.
Coach situationally. A lot has been written about open-ended questions in coaching, and the literature is good, but Eric flagged that there are days when the person being coached doesn't need another open-ended question. They need direct help. Reading the moment matters as much as practicing the technique. And reflection after the coaching conversation — asking the person whether the coaching actually helped them think — is worth doing. Most coaches don't.
Mentor upward. A system architect's coaching obligation runs in every direction, including up. Wishing your boss understood something doesn't change anything. The discipline is finding creative ways to coach the people above you into different behaviors, knowing the relationship is structurally different from coaching peers or direct reports.
Avoid lexicon traps. If a word in your organization carries historical baggage, drop it. Eric mentioned that early in his work in Flint, Michigan, he didn't use the word "Lean" at all for the first two years. He talked about making jobs better, reducing motions, improving the workplace. After two years, he could use the word "Lean." Before that, the word would have done more damage than the methodology. The same applies to "A3," "kaizen event," or any other term that carries baggage in a specific organization. It's not a battle worth fighting.
Engage HR early. This one surprised Eric himself when he ranked the list, but he kept it because of two distinct benefits. First, HR can give honest feedback after leadership engagements about what they observed in the room — feedback the system architect or the team itself often can't deliver without political risk. Second, HR is where career paths get built, and CI professionals who develop strong skills in this kind of work often have nowhere to go in their current organization. The default path is to push them into line leadership roles, which most of them don't want, so they leave and take their hard-won expertise with them. The organizations that retain those people build the paths in advance.
A question came in about how to capture historical learning in a meaningful and accessible way. Eric's answer was the most honest one in the session: he'd welcome a really solid example, because most attempts he sees aren't quite working.
The default move — building a SharePoint site or shared drive for lessons learned — fails for a reason that becomes visible in two or three years. Without an explicit process for putting data in, categorizing it consistently, and archiving older material, the repository becomes a snowstorm of accumulated documents that no one searches and no one trusts. The space exists. The knowledge doesn't.
The most effective alternative Eric pointed to is building knowledge into the work itself rather than into a separate repository. The physical version is easier: when you learn something about how a workplace should be laid out, the layout itself becomes the embodiment of the learning. Someone walking into the workspace doesn't need to read a lessons-learned document. The workspace is the document.
Knowledge work is harder to capture this way, but the principle still applies. Checklists embed learning into the activity. Software that surfaces constraints at the moment of decision embeds learning into the design process. CAD systems that prevent certain dimensions or configurations based on accumulated standards embed organizational learning into the tool. The pattern is to ask, for each piece of hard-won knowledge, whether there's a way to make it impossible to ignore the next time the work happens — rather than relying on someone to remember to read a document.
This is one of the deeper points in the session. Most organizations think about knowledge capture as a documentation problem. Eric was suggesting it's actually a design problem.
The argument running through this session is that good process development is the upstream work that prevents most of the downstream rework most improvement programs spend their time on. The system architect role is what makes that upstream work durable across multiple value streams and over time.
What infrastructure does in this context is less about generating the process design and more about making the two A3s the system architect owns visible and trackable. The development of a specific value stream — with its milestones, its experiments, its iterations across context, concepts, converge, configure, confirm, and continuously improve — is itself a structured body of work that benefits from being managed in the same place where the rest of the organization's improvement work lives. The development of the process of process development — making this approach repeatable across the organization — is even harder to keep visible without a system designed for tracking it. Both are A3s. Both need owners. Both need to be reviewable by leadership without requiring the system architect to recreate the picture every time a status update is requested.
The knowledge capture question Eric raised lands here as well. The most effective capture is built into the work, not into a separate repository. But for the cases where a repository is the right answer — pattern libraries of process designs, archived lessons from past launches, configurations that worked across multiple value streams — having a place where the artifacts live alongside the improvement work they came from is structurally different from a SharePoint site that accumulates documents until it stops being searched. The integration matters more than the storage.
Mark suggested at the end of the session that KaiNexus customers who embrace this process design methodology could configure the platform to track the process development model itself — the iterations within each lens, the lessons learned across cycles, the improvements to the process of process development. The platform isn't doing the architect's work. It's making the architect's work visible enough that the organization can actually maintain it across multiple value streams and over time.
None of this changes the underlying argument. The architect role has to exist. The two A3s have to have an owner. The leadership behaviors that enable good process design have to be coached into being. What infrastructure does is remove the structural reasons that good process design fails to spread — the lost lessons, the invisible iterations, the parallel value stream developments that should have learned from each other and didn't.
What is the development rework cycle Eric describes? A recurring pattern where launching a new process pulls resources off existing improvement work to fix the new launch. By the time the new process is functioning, the old work has degraded, so resources get pulled back to fix that. Each cycle consumes time, people, and money without compounding learning, because the next new process launches without incorporating what was learned in the last one. Eric called it a "development death spiral" in some organizations. The Six-Con model and the system architect role are the framework for breaking the spiral.
What is tozen, and how is it different from kaizen? A term from a Jim Womack article. A tozen is a kaizen that should not have been necessary — an improvement made after launch that could have been avoided if the launch itself had incorporated the relevant learning upstream. Most improvement programs unknowingly run as tozen factories. The visible work of fixing post-launch problems gets praised. The invisible cost — that the problems were preventable — doesn't show up in the metrics.
What are the six lenses of the Six-Con model? Context (what does good look like, and for whom). Concepts (multiple process ideas to fulfill the value equation). Converge (experiments and tests that narrow many concepts to one direction). Configure (tightening the chosen direction into specific design, including how steps connect). Confirm (testing the actual installed configuration against original metrics). Continuously improve (refining the launched process from a higher starting point than it would have had without the previous five lenses). The lenses iterate both within themselves and across each other. The model is not linear.
What does a system architect do that's different from a value stream manager? A value stream manager owns the flow of one specific value stream. A system architect owns the process by which all future value streams get developed. The two roles overlap — and can be paired, as the book's case study describes — but they're not identical. The system architect's second A3 is making the development approach repeatable, which is structurally different from managing the operations of one already-developed value stream. In organizations where this isn't an immediate question, the system architect may be the natural extension of an existing value stream manager role, but the broader process ownership is what makes it a distinct function.
Does the system architect need to be a senior person in the organization? Not necessarily, but they need enough credibility that people will listen. Eric didn't think it was an entry-level role, partly because the leadership coaching component requires the system architect to be taken seriously by senior leaders, and partly because the historian role requires enough context to know what's worth capturing. He was also clear that the system architect needs to be internal, not an external consultant. The role requires day-to-day presence and the kind of relationship continuity that external engagements can't provide. Consultants can pair with developing system architects to accelerate the learning, but the role itself stays inside.
Why does Eric emphasize organizational stability? Because process development takes long enough that frequent reorganization makes it impossible. Eric had been in plants where, as the CI person, he was the highest-tenure leader on the leadership team at fourteen months — not because he'd been there a long time, but because everyone else kept rotating. People will move in and out of roles, and that's fine. The system architect can bring new people up to speed. What's not workable is rotating the entire leadership structure on a cadence faster than process development can complete. The stability isn't about preventing all change. It's about giving the work time to compound.
What does "help needs to feel like help" mean operationally? A phrase Eric attributed to his colleague Jim Morgan. When a team is off-target and the leader's response is to require them to report status twice as often, that doubling of reporting isn't help — it's surveillance with extra steps. Help that feels like help removes a real obstacle, unblocks a real decision, or provides a real resource. The system architect often plays a liaison role here, helping leaders see when their helping behaviors are making things worse, and helping teams interpret what leadership actually meant when their stated help didn't feel that way.
Why does Eric say to avoid certain words like "Lean" or "A3" in some organizations? Because some words carry historical baggage that triggers resistance independent of the underlying methodology. Eric mentioned that in his early work in Flint, Michigan, he didn't use the word "Lean" for the first two years. He talked about making jobs better and reducing motions. After two years, the work had produced enough results that the word stopped triggering the baggage and could be used directly. The principle isn't that the words are bad. It's that fighting battles over terminology is a waste of energy that should go into the work. If the word is a problem, use a different word.
What's the right way to capture lessons learned across process development cycles? The default move — a SharePoint site or shared drive for lessons learned — usually fails within two or three years because there's no process for how content goes in, how it's categorized, or how older material gets archived. The repository accumulates documents until no one searches it. The more effective approach is to build the lessons into the work itself rather than into a separate repository. Physical examples are easier: a workplace layout embodies the learning that produced it. Knowledge work is harder, but checklists, software cues, and CAD constraints that surface accumulated standards at the moment of decision can serve the same function. The principle is to make the learning impossible to ignore the next time the work happens, rather than relying on someone to remember to read about it.
How do you balance ambitious operational pronouncements with the need to actually launch something workable? By treating the pronouncement as a hypothesis tested through the Six-Con model's iterations rather than a fixed constraint. A vice president declaring "no storage for parts other than at the line side" sets a direction the team has to work to make real. The iterations through converge and configure are where the team learns whether the pronouncement holds, where it needs modification, and what trade-offs are required. The model doesn't reject ambition. It tests ambition against learning, so the launched process is grounded in what's actually workable rather than what was originally imagined.
Does computer-based simulation have a role in process development? Yes, with caution. Eric's early industrial engineering background was in simulation, and he was direct about the risk: a simulation can quickly become so abstract that it disengages the workforce that has to operate the eventual process. The middle ground is involving operators in validating the models, so that what the simulation predicts matches what they've experienced doing the work. When that validation happens, the simulation becomes meaningful. Without it, the simulation is a tool the design team uses to convince itself, not the organization.
How does the system architect role end? Or does it? Eric was honest that he'd like to be able to imagine a future where the role isn't needed — where process development is just how everyone in the organization works. But he doesn't see that future arriving quickly. Even in mature Lean organizations, there's usually still a function that shepherds standards and maintains the discipline. Toyota still has an internal group that maintains and teaches TPS standards. The role may evolve over time, but the need for someone to own the development of process development tends to persist long after people expect it to.
.svg)
Copyright © 2026
Privacy Policy