When Can I see?

One of the issues Mike Rother says he has had with the coaching questions in Toyota Kata is question #5 “When can we go see what you have learned?”

In the west, inevitably it seems, once the word “When” is uttered, everyone in the conversation leaps to hear “When will you be done?” no matter how the question is actually framed.

As I am understanding it right now, the actual intent is for the coach to establish two things:

  1. The PDCA cycle needs to be turned rapidly. “When…”? is meant to establish a time fame that might be measured in hours, or even minutes, rather than days or weeks. The more quickly the PDCA cycle is turned, the more thoroughly the problem is understood and the more robust the countermeasure.
  2. “What we have learned…” means “What surprises did you encounter?” “What went differently than you expected?” “What didn’t work the way you thought it would?” this part of the question is intended to drive home the point that it is these things, not the success, that drive deeper understanding plus give clues about the next problem that must be addressed.

Based on Rother’s experience with this question, I am tinkering with how to re-frame it so I can use it more effectively. Ultimately the behavior I want is an invitation to jointly observe how the proposed countermeasure has changed the process. We want to understand the actual effect vs the intended effect.

That, of course, requires that the intended effect is understood and explicitly stated before trying. That does NOT mean that every little step is documented on paper such as an A3. That is far too cumbersome at this level of granularity. We want this process to cycle faster than the time required to write this stuff down. It does mean that I would have evidence that it has been thought through rather than just blindly trying something.

What you can, Where you can

In my review of Toyota Kata by Mike Rother, I suggested that the staff-level practitioners who are embedded in almost every company that is “implementing lean” could put those practices to work immediately, even if it was not an ideal “top down” teaching process.

This week I gave that a try.

I was coaching a workshop leader who was, in turn, leading the team I mentioned earlier. He was simultaneously reading the book, I referred him to “the coaching questions” on page 247 and we worked together to keep asking them as the team was doing its work.

Since the team was working to solve problems that were blocking the problem solving process, it got a little complicated to keep them focused on the right “immediate problem.” However what I observed, for sure, was that my workshop leader’s skills improved significantly as the week went on, as did the team’s understanding of the issues and countermeasures.

My working theory was that just asking the questions puts someone into “teaching mode” and, as I have said earlier, the best way to learn is to try to teach.

Was this the ideal approach advocated by Mike Rother? Nope. I will have to loop back and catch some of the foundational elements. But as I have experienced in the past, these practices are so powerful that even trying and awkward application gets significantly better results than following no structure at all.

Start asking the questions, and see what you can learn as you try to teach.

Using the Questions

This week I am coaching a kaizen team in the first phases of implementing a process to respond to problems on the shop floor.

They clearly understand the objective, and are working hard.

The key is to keep them focused on working out the problem response process vs. getting distracted by the production problems they are responding to.

For my part, in an effort to accelerate the cycles of learning, I am trying to consciously apply “the five questions" of the coaching cycle as outlined on page 247 of Toyota Kata by Mike Rother.

They are:

  1. What is the target condition? (the challenge – what do we expect to be happening)?
  2. What is the actual condition now?
  3. What problems or obstacles are now preventing you from reaching the target condition? Which one are you addressing now?
  4. What is your next step?
  5. When can we go and see what we have learned?

This will not be my only opportunity – I have other challenges lining up in other parts of the company that I support.

I’ll tell you, though, it isn’t as easy as just asking the questions.

The first challenge is context. My actual condition is that this kind of rigor is new to even experienced kaizen practitioners out there. As Rother, and others, point out, most “kaizen events” simply aren’t structured this way.

There is a strong bias toward generalization and sweeping statements of "problems” and “what we need to do is…” I have to keep working to bring the focus back to what is directly in front of us as we try to work through this specific iteration. Yes, that other thing might be an issue, but it isn’t coming up NOW, so let’s keep working on what is actually stopping us.

This is important because it gives the problem solvers great power. If they can learn to stick to what is stopping them right now, they have an easier time not getting discouraged by all of the other issues that are out there.

One-by-one. Step-by-step.

Of course this iteration is complicated by the fact that we are working on a process designed to clear problems in another process, so it is easy to get sucked in to the production issues.

To their credit – we have a Home Depot technology andon light, and the team members who are the subjects of this experiment seem to be appreciating (for now) the fact that this group of people is swarming every issue they run into.

Toyota Kata: Avoid Pareto Paralysis

A great key point comes out on page 124 of Toyota Kata by Mike Rother.

…a Toyota person once told me to focus on the biggest problem. However, when I tried to do this I noticed a negative effect: We got lost in hunting for and discussing what was the biggest problem. When we tried gathering data and making Pareto charts, it took a lot of time and the biggest problem in the Pareto chart was usually “other” which put us back into debating options. By the time we decided what the biggest problem was, the situation at the process had changed. This effect is called Pareto paralysis, and I encourage you to avoid it. Pareto paralysis delays your progress as people try to determine the “right” first step to take.

[…] it matters more that you take the first step than what the first step is.

I have seen this many times with my own eyes. It is a common problem when “problem solving” is taught as “application of the seven tools” and “correct” use of the tools becomes more important than understanding the problem or making actual progress.

Hirano, I believe, has been quoted as saying:

Waste often comes disguised as useful work.

That is what is happening here. The team thinks they are working to solve the problem when, in reality, they are still trying to decide what problem to work on. The gridlock may be driven by fear of working on the wrong problem. But in reality, there is no wrong problem, there is only the one that is in your way.

Here is something else I commonly see. When they discover “problem solving” many organizations want to immediately undertake large projects that involve “stretch goals” and breaking down complex issues. They look at operational metrics that are actually aggregated – total inventory, total lead time, productivity of the entire factory, total defect rates, total lead time through the system. While those metrics are nice to gage progress, they do not give you any actionable information.

Even worse is using averages. Averages aggregate even more, and “bad” tends to be countered by “good” in many average calculations. What is important is to look at each instance vs. an external, discrete, and objective standard or specification. Average defect rates tell you nothing at all about what to work on. But this unit had this defect, or this part dimension was this amount out of specification DOES.

Put another way, there are very few big problems. Big “problems” are the aggregated symptoms of many small problems.

This is good news and bad news.

The good news is that small problems can usually be understood, cleared and sometimes solved fairly quickly. The bad news is that it takes work to do this. The other bad news is that there isn’t any other way that actually works.

Doing a good job working on large complex issues requires engaging across the organization, time, and a high level of skill at understanding the situation, framing the problem, getting to causes, working on solutions, testing understanding, etc. Doing it well requires a mentor who is intimately familiar with the thinking behind problem solving.

This skill can not be gained in a “problem solving” or “A3” class, at least not one that simply walks the team members through the process once or twice. Skill comes from practice, and effective practice comes from starting simple, working in an environment where it is safe to experiment and to be wrong. This means working on shop floor issues that can be isolated from one another, the effect of a test or simulation can be seen immediately. The factory and production organization that Steven Spear describes in his research about Toyota is actually designed deliberately to facilitate this kind of work.

Another common mistake is setting up performance targets too early. If the processes are inherently unstable – if there is no sense of takt time, you are having problems with consistent quality or delivery, the first goal is simply to get to the point where you actually know how things are performing against an indicator of stability. Again, this is usually much simpler than setting a high level target and then trying to break down and stratify all of the issues out there. Set that stability target, study the process, and take on the disruptions as you see them. If there is a debate about which one to start with, then start with the simplest one so you can improve your capabilities.

In the end, it is about taking on problems as they come up, where they come up. That thinking is facilitated by the way you structure the flow, the work, and the organization itself. Get to the shop floor, stand in the chalk circle, and ask “What is stopping this team member from being successful right now.”

Customer Service Opportunities

Today was traveling on behest of a large corporation, so the travel arrangements were made through them. It all went about as routinely as could be expected on the last weekend before Christmas… for me.

Unfortunately the guy I am supposed to meet here had flights going through D.C. that were on a collision trajectory with a snow storm on the east coast today. Flight cancelled.

OK, I need to continue on, then shift my departure out 24 hours – hang around here another day.

Fortunately at the bottom of the itinerary emailed by the corporate travel company is the handy “In case of problems” etc. phone number:

CONTACT xxx TRAVEL 1-800-3xx-xxxx

So I call the number.

A couple of layers of voice menu prompts (including a reminder that airlines are implementing luggage policies, please check your airline’s web site – totally useless information that only delays the response I am trying to get), I end up with the “hold music” being reminded periodically that “Your call is important to us…” etc.

A human comes on the line and I am cheerfully informed that this is not the 800 number I should call. I am reminded that MY reservation was made through the online system (which it was not, I talked to a human being when I made it), and that I need to call “them.” And, kindly, I am forwarded to “them.”

After 20 minutes of hold music, my plane is boarding, so I have to drop the call.

Try again from the seat.

Different initial operator who makes a little more effort to make me wrong for calling the ONLY number that they print on the itinerary they send, otherwise same result. They are closing the cabin door, I have to drop the call.

There actually is a lesson here.

What defines how well a process or system works is not so much the individual components, but the interfaces between them. In this case the “interface,” if you can call it that, is the hapless (and irritated) customer. I am the one who has to integrate various otherwise separate components of this fractured process.

The other story is the reason they were likely so busy today. After all, a major snow storm socked the east coast and caused havoc in the flight schedules that went through there. I am sure there were plenty of people who were impacted, and calling them for assistance re-booking flights, etc. And after all, there really is no way to predict when that will happen so they could be prepared, right? The really cool thing about 21st century communications technology is that you can can not only monitor live weather conditions and radar in real time, if you need to react, “extra people” don’t even need to leave home to be available… they don’t even need to be in the same state or even country. It is possible to plan and prepare for extraordinary mind-boggling never-forget-it customer service, if it is important to you.

In the end, it is about making a conscious decision about the experience you really want your customer to have, and then structuring your processes, deliberately, to deliver that experience – and be sensitive and alert you when they do not. It is not that big a shift from “serving customers” to “customer service,” nor does it cost more in the long haul. “Quality is free” – if you understand how to do it.

I.E. and Kaizen

There is an interesting thread developing on the NWLEAN discussion group. Kris Hallan, a regular reader here, asked a great question about the contributions of the industrial engineering pioneers to what, today, we regard as “lean production.”

This, in turn, sparked some debate about whether Taylor, the Glibreths, and others were actually following lean methods; about whether traditional industrial engineering is bogged down in over analysis, and a host of other issues.

Because not all you are following NWLEAN, I wanted to share my thoughts here as well.

The pioneers all did very good work advancing the field of knowledge.

The Gilbreths, for example, are credited with the realization that “time is the shadow of motion.”

Ohno and Toyoda were both adamant that everything they applied to build cars was simply an extension of what they saw at the Rouge plant.

The neat thing about knowledge and technology is that each generation has an opportunity to build on the last. Sometimes this is incremental, sometimes it is a profound shift. But in either case, it is the previous work that establishes the foundation – either something to extend, or a refutable hypothesis to test and reject.

If I really look at the shift that separates traditional I.E. from the more modern approach, it is in who holds the knowledge of the process AND how to improve it.

Taylor separated thinking about the process from determining the best way to perform it. He (and the Gilbreths) learned to observe with a keen eye, and optimize the motions he saw. Great stuff. Nobody did that before. Everything we do today is built on that foundation.

Today I see two levels of lean practice.

The first, and far more common, is the “outside expert” – the kaizen workshop leader, for example. In this model, this expert comes from outside the actual process. He acknowledges that the people doing the work probably know the best way to do it. But the work of exactly HOW to improve things – the magic of kaizen if you were, belongs to the expert. He is the one who facilitates improvements. While “process improvement” is the domain of the people doing the work, the “process of improvement” is owned by the outside expert.

So the skill of “improvement” is separate from the skill of “doing the work.”

I see this all of the time. Its dark side is manifested in “How do I make them follow standard work?” as if that is even possible through coercion or some punishment/reward system.

This is really an extension of the Taylor model of separating “thinking” and “doing.” In this case, however, it is “thinking about how improvement should be done” and “doing the improvements” vs. the work itself.

But something slightly different is happening in the organizations I see pulling ahead.

In those, the “skill of how to improve” is also manifested in the people doing the work. “Improvement” is part of that work itself, not something separate. There is time and resource specifically allocated to it, just as there is for production. EVERYBODY is focused on not only making improvements, but also improving how they do improvements themselves.

To the outside observer, the difference in the teaching and implementation processes are very subtle. But the difference in the culture and results that emerge can be profound.

The key difference is in letting go, finally, of the Taylor model and working to incorporate the knowledge and skill of process improvement into the entire organization – everybody – rather than keeping it in a small cadre.

I think this is one of the distinctions between a practitioner and a true sensei.

Are You Ready for the Upturn?

Many pundits out there think the economy has hit bottom. If the last couple of cycles are any indication, when things start picking up again, it is going to happen fast. As people scramble to retain or gain market share they are going to want more and want it now.

And, if the last couple of times are any indication, many businesses are going to be caught totally flat footed and struggling to increase their output. I would also imagine that the “never again” vows that they made as things were going down will, once again, go out the window.

So, short of building up a lot of inventory and/or investing in excess capacity, what can you do to be more prepared?

Continue to work toward the ideal of one-piece-flow.

This does a few things for you. If you do it right, you will progressively collapse the throughput time of your process. This will make you more responsive to changes and make you less vulnerable to forecast errors.

More importantly, though, is the understanding you gain as you do this work. You want to know the cycle time constraint of each and every process in the value chain. With that information, you can predict what will constrain you from reaching any given level of production, and start to work on those constraints. That does not mean you increase production, nor does it mean that you add capital equipment. It means you know exactly what you are capable of doing, and exactly what you must do to get to the next level. In other words, you have a plan that you can put into motion at any time.

Work to standardize and stabilize your processes.

This effort helps make your work more ready for people. Many operations today are running well below their capacity, and they have lost their performance edge. Problems are going unnoticed and unaddressed because they aren’t really affecting production right now. That will change, and change fast, in a ramp-up situation.

Worse, unstable and poorly understood processes translate to long, error-prone learning cycles for new people, or current people in doing different work.

Re-energize your daily kaizen and problem solving and start seeking out the things that are disrupting the work. That investment will not only develop your ability to respond quickly and robustly to growth, it will develop people’s skills as well.

Develop your people and organization.

This will help your people become more ready for the work.

Things may be slow today, but do you know who you would put into your next leadership positions as they open up? Have you developed those potential leaders? Have you thought through how you will organize and support the work as business expands?

The more preparation you can make now, the easier it will be when you get into a fast-moving dynamic growth period. You will already have a baseline plan, so you will only need to assess the situation, modify as appropriate, and carry it out. The more of this planning you can do now, the more thinking you will be able to put into execution.

Even people who are already in leadership positions can probably use skills development. There are a few easy things you can do that will pay great dividends in a fast-flux environment.

Look into the TWI programs. These address crucial skills that line leaders need to succeed. Ideally, people would demonstrate those skills before being put into leadership positions.

The side benefit is that these programs give people skills they can use today to make the workplace safer, more consistent, and more stable. In a growth situation, Job Instruction gives you a standard method to bring new people on board, or to flex people quickly into different work and get them up to speed.

Free up as much capacity as possible.

The bottom line results of kaizen are seen primarily in the form of additional capacity – you are able to produce more with the same resources. You might not need that additional capacity right now, but if you are living within your means today, you can put that additional capacity in your hip pocket. Then, the first round of sales growth can be met without any additional resources. The better you are at kaizen, the longer you can hold your resource levels the same while growing output. The only way to get better is to practice, and just like learning to play the piano, this means practice every day.

Understand your supply base.

How well do you know your suppliers? How quickly can they respond if your needs change dramatically? Do you know which supplier controls how quickly you can increase output? Do you know at what point that bottleneck shifts to a different supplier?

The other thing to consider here is the length of that supply chain. If you are bringing in things from overseas, there is one fundamental that many people try to wish away:

No matter how hard you try, you can’t change what is on the boat.

That might seem obvious in saying it, but it is amazing how many times that four or five week transportation time ends up negating any “cost savings” in lower prices.

I am not saying this is good or bad. I am saying to look beyond invoice and transportation prices and understand your enterprise value chain as a dynamic, moving thing with a response time to change. That response time becomes critical when things are changing. Know what that response time is, and manage to it. If you don’t like the answers, you have to alter the system somehow.

Bottom line: The time to get good is now.

When you are scrambling to meet demand, “there won’t be time” for kaizen, and there will be even less time to learn how to do it. The time to get good at it is now. Your alternative is growing your cost structure at least as fast as sales are growing. Experience has shown that your cost structure likely grows faster than sales, and additional earnings come only with non-linear growth – relying on volume to make up for ever thinner margins. That might look OK in the short-term, but it is a strategy of becoming ever less efficient.

The better prepared you are for the upside, the stronger you will be the the inevitable next cycle.

Continuous Erosion

“Sustaining the gains” is a frequent topic of discussion in the continuous improvement world. Often the discussion degenerates into a rant about “management commitment.”

But in the real world, people generally don’t sabotage improvements on purpose. (Though I have seen it happen, but only once.) The mechanism is far more subtle.

Before we get into what happens after improvements are made, let’s look at a common improvement process itself.

In many companies, the primary method for making improvements is through special events or projects. These are usually planned, organized and led by a staff specialist.

Although the exact methods and words vary, the general process usually looks something like this:

  • Identify an opportunity, select an area for improvement.
  • Analyze the current state.
  • Select an improvement team.
  • Teach the team members how to apply the improvement tools.
  • Facilitate the development of improvement ideas.
  • Work with the team members to implement them.
  • Wrap up with a report or presentation, including remaining action items for management.

A variation on this is where the team is chartered, and it is up to them to identify an opportunity. This approach was more common in the late 1980’s than it is today.

This process actually works. It is capable of making pretty dramatic changes over a short period of time, often only a few days.

So why do the results erode? Or put another way, what is the problem?

Take a look at the routine decisions that are made during normal work, especially the ones that result in some change to the process. Those decisions must be made, because people have to get something done. The question comes down to whether those decisions result in improving the new process, or eroding it somehow.

Once things are in operation, some kind of unforeseen event always happens. Guaranteed. It can be something that the improvement team didn’t think of. It can be a piece of malfunctioning equipment. Maybe there is a material shortage or a defective part is delivered. The same things happen in administrative processes, only the words are different. Incomplete information arrives.

It could even be a deliberate decision. A production rate change. A software upgrade. Making room for some other activity.

All of these things, no matter how small or inconsequential, force decisions to be made. “How do we deal with this this and get production going again?”

The person making that decision is either:

  1. Fully capable of applying kaizen principles, and applies them in a solution to the problem.
  2. Is not fully fully capable of applying kaizen principles, but knows that, and seeks assistance in finding a solution to the problem.
  3. Is not fully capable, may or may not know this, and does the best he can to get production back on track.

Both (1) and (2) result in making the system better, more robust and more responsive.

(3) usually results in a little bit of erosion. Variation is accommodated, things are made a bit more complex, the layout is now less than optimal, the old process does not work as designed anymore so the team member must improvise a bit. That, in turn, introduces more variation into the process, and usually drives a cascade of these little decisions.

If there is no mechanism for problem escalation (and if there was, we would likely be in (1) or (2) in the first place), then this becomes the new way, and things are steadily creeping closer to where they were before the event happened.

Given enough time (which can be amazingly brief), the process reverts back to where it was, or morphs into something else entirely – but equally wasteful.

Meanwhile the improvement specialists have moved on to the next project. Even if the local leader did ask for assistance, they might not be available, or worse, they tell him to figure it out.

Follow this with an “audit” that dings the local leader for “not supporting the changes” and wonder why he is less than enthusiastic about this kind of help.

Here is the question I want to leave hanging out there:

What was the intent of the kaizen event? (and was that intent accomplished?)

Notes From a Kaizen Event

I was cleaning out some old stuff and came across a folded piece of paper with notes on it. They were from my parting comments to a kaizen event team that had put in a great week with spectacular results. They had started out wanting to improve the delivery of WIP to and from the warehouse.

When we went to the shop floor to see the current situation, what I saw was much more opportunity. It took a little work, especially with the area manager, but by the end of the week they had gone from needing 5 work cells with 6 people each – plus more to meet the holiday seasonal production – to 4 production cells with 5 people each, that could comfortably meet the rush. Not bad for a week’s work.

That’s the background.

When I look at old notes like this, I am always comparing what I knew then with what I know now. Now and than I turn up something that gives a hint that I knew what I was doing.

These comments were as much for the rest of the audience as they were for the team members themselves. After all, they knew what they did, and were fully aware of what they had to do next. But the other teams, and their collective bosses, needed to hear it as well.

  • Wow – great team. You caught flow fever early in the week and ran with it. You make me look like I knew what I was doing – thank you.
  • You connected the operations into a smooth flow.
  • Now you can begin the process of kaizen. Stick with it, stay on the shop floor, and work to stabilize the work. Many problems will come up. Help the work teams learn how to see them and solve them.
  • If you can save, and stabilize, a quarter of a second every day, in three months you can get another 20% of productivity. Think about that – and do the math for yourself.

What made this work?

First and foremost, we had the operational manager there, fully participating. He was skeptical at first, but once I sat down with him and went through his production requirements, step by step, he began to see things in terms of takt times and production leveling rather than just quantities to push out the door. That was a big shift.

The other big thing was having  the team work off line for a few hours to construct a mock-up of a “typical” work cell. Then, without worrying a bit about the takt time, work to minimize the cycle time of one person going through the complete cycle. They learned for themselves that to save time you must study motion. We went through three or four cycles of granularity – every time they thought they had “the” solution, we introduced another tool to see the next level of extra motion. Through this exercise, they gained confidence that it was entirely possible to make a dramatic improvement in the “optimal layout” that they already had.

After that, it was a matter of getting to work. They watched the actual operators, and now could see the excess motions that were being driven by the way the work was arranged. They started making little adjustments – always being respectful of the workers. “We’d like to try something different here, just to see if it works better for you. May we just try something?”

That “May we try this?” attitude introduced something into the dynamic that doesn’t show up often enough – humility. Rather than these managers saying “We’ve got a better way, do it like this.” they were saying “We really don’t know if this will work or not,” and asking not only permission to try, but for input on whether it worked, or how it could work if it wasn’t quite there.

A lot of changes got implemented, but there was no arguing or friction because everything was just an experiment to see if it would work or not.

In the end, I saw something I had never seen before – the manager put in a budget request for a reduction, because he knew he could  get it done with less, or at least figuring out how was within his reach.

That scrap of paper reminded me of a pretty good week.

The Lean Manager: Part 3 – People, Purpose, Problems, Process vs. “Systems”

Click image for Amazon.com listing

This is Part 3 of a multi-part review. Part 1 is here.

Before I get into it, I will break the rules of blogging and acknowledge a time gap here. I did finish the book shortly after I wrote part 2, in fact, I didn’t want to put it down. So now I am going back through and bringing out some key points, intermixed with some other stuff that has caught my interest lately. Anyway – back to what you came for…

Steve Spear has described the TPS as a “socio-technical system.” Put in less formidable terms, it is a system that uses the structure of the work, the work environment and the support systems (the technical part) to create an organizational culture of problem solving.

Jenkinson, Andy’s boss in the book, describes it:

“You need to organize a clear flow of problem solving, explained Jenkinson one more time. “Operators need to have a complete understanding of normal conditions, so that whenever there is a gap, they know it’s a problem. Go and see is not just for the top management, It’s for everybody. This means operators as well, in particular how they learn to see parts and see the equipment they use. How can all operators recognize they have a problem? [emphasis added]

The simple statement, and following question posed by Jenkinson sums up a great deal that is left out of lean implementations. I see it everywhere, and will be commenting on it more shortly.

We talk about “go and see” (or “genchi genbutsu“) as something leaders do. I think this is because traditional leaders aren’t naturally out in the work areas, on the shop floor, in the hangars, etc. We don’t think about the workers because they are there all of the time.

Yes, they are. But what do they see? Do they see disruptions and issues as things they are expected to somehow work around and deal with? Or do they see these things as something to call out, and fully participate in solving?

And if they do see a problem, what is the process for engaging it?

Just saying “you are empowered to fix the problem” does not make it so. When are they supposed to do it? Do they have the skills they need? How do you know? Is there a time-based process to escalate to another level if they get stuck? (Or do they just have to give up?)

And indeed, as the story in the book develops, Andy turns out to be taking a brute-force approach. He is directing staff to implement the tools and to solve problems. But in spite of nearly continuous admonitions from his boss and other experts, he is not checking how they are doing it. He has put a “get-r-done” operations manager into place, and while the guy is getting “results,” in the long haul it doesn’t work very well. Yes, they end making some improvements, but at the expense of alienating the work force.

It is only late in the story (and I won’t get into the details to avoid playing the spoiler to a pretty good plot twist) that Andy finally learns the importance of having a process that is deliberately designed to engage people.

Commentary – it is amazing to me just how much we (in the “lean community”) talk about engaging people, but never really work through the deliberate processes to do it. There are explicit processes for everything involving production, administration, etc. but somehow we expect “engaging people” to happen spontaneously just because we believe it is a good thing.

The message in this book is loud and clear. This is about leadership. The tools are important, yes, but only (in my opinion) because they are proven techniques that allow people to become engaged with the process.

But the tools alone do not require people to get engaged.

Permission to make input is necessary, but not sufficient. If you want people to be engaged, you have to deliberately engage them. Otherwise you are just asking them to become nameless cogs in “the system.”