Steve Spear on Creative Experimentation

On Monday MIT hosted a webinar with Steven Spear on the topic of “Creative Experimentation.”

A key theme woven throughout Spear’s work is the world today is orders of magnitude more complex than it was even 10 or 15 years ago. Where, in the past, it was feasible for a single person or small group to oversee every aspect of a system, today that simply isn’t possible except in trivial cases. Where, in 1965 it was possible for one person to understand every detail of how an automobile worked, today it is not.

My interpretation goes something like this:

Systems are composed of nodes, each acting on inputs and triggering outputs. In the past, most systems were largely linear. The output of upstream nodes was the input of those immediately downstream. You can see this in the Ford Mustang example that Spear discusses in the webinar.

Today nodes are far more interconnected. Cause and effect is not clear. There are feed-back and feed-forward connections and loop-backs. Interactions between processes impact the results as much as the processes themselves.

Traditional management still tries to manage what is inside the nodes. Performance, and problems, come from the interconnections between nodes more than from within them.

The other key point is that traditional management seeks to first define, then develop a system with the goal of eventually reaching a steady state. Today, though, the steady state simply does not exist.

Product development cycles are quickening. Before one product is stable, the next one is launched. There is no plateau anymore in most industries.

From my notes – “The right answer is not the answer for very long. It changes continuously.”

Therefore, it is vital that organizations be able to handle rapid shifts quickly.

With that, here is the recorded webinar.

(Edit: The original flies have been deleted from the MIT server.)

A couple of things struck me as I participated in this.

Acknowledging that Spear has a bias here (as do I), the fact that Toyota’s inherent structure and management system is set up to deal with the world this way is probably one of the greatest advantages ever created by happenstance.

I say that because I don’t believe Toyota ever set out to design a system to manage complexity. It just emerged from necessity.

We have an advantage of being able to study it and try to grasp how it works, but we won’t be able to replicate it by decomposing its pieces and putting it back together.

Like all complex systems, this one works because of the connections, and those connections are ever changing and adapting. You can’t take a snapshot and say “this is it” any more than you can create a static neural net and say you have a brain.

Local Capability

One thing that emerges as critical is developing a local capability for this creative experimentation.

I think, what Spear calls “creative experimentation” is not that different from what Rother calls the “improvement kata.” Rother brings more structure to the process, but they are describing essentially the same thing.

Why is local capability critical? Processes today are too complex to have a single point of influence. One small team cannot see the entire picture. Neither can that small team go from node to node and fix everything. (This is the model that is used in operations that have dedicated staff improvement specialists, and this is why improvements plateau.)

The only way to respond as quickly as change is happening is to have the response system embedded throughout the network.

How do you develop local capability? That is the crux of the problem in most organizations. I was in an online coaching session on Tuesday discussing a similar problem. But, in reality, you develop the capability the way you develop any skill: practice. And this brings us back to the key point in Kata.

Practice goes no good unless you are striving against an ideal standard. It is, therefore, crucial to have a standardized problem solving approach that people are trying to master.

To be clear, after they have mastered it, they earn a license to push the boundaries a bit. But I am referring to true mastery here, not simple proficiency. My advice is  to focus on establishing the standard. That is difficult enough.

An Example: Decoding Mary – Find the Bright Spots

Spear’s story of “Decoding Mary” where the re-admission rate of patients to a hospital directly correlated with the particular nurse handled their transfer reminded me of Heath & Heath’s stories from Switch. One of the nine levers for change that they cite is “find the bright spots.”

In this case the creative experimentation was the process of trying to figure out exactly what Mary did differently so it could be codified and replicated for a more consistent result independent of who did it.

The key, in both of these cases, is to find success and study it, trying to capture what is different – and capture it in a way that can be easily replicated. That is exactly what happened here.

A lot of organizations do this backwards. They study what (or who) is not performing to determine what is wrong.

Sometimes it is far easier to try to extract the essence what works. Where are your bright spots for superb quality? Does one shift, or one crew, perform better than the others? Do you even know? It took some real digging to reveal that “Mary” was even the correlating factor here.

Continuous Improvement Means Continuous Change

Since “continuous improvement” really means “continuously improving the capability of your people,” now perhaps we have “to do what.” I have said (and still say) that the “what” is problem solving.

What you get for that, though, is a deep capability to deal with accelerating change at an accelerating rate without losing your orientation or balance.

It is the means to allow the pieces of the organization to continue to operate in harmony while everything is changing. That brings us back to another dilemma: What is the ROI on learning to become very, very good? You don’t know what the future is going to throw at you, only that you need the capability to deal with it at an ever quicker pace.

But none of this works unless you make a concerted effort to get good at it.

Here is the original link to the MIT page with the video, and a download link for PDFs of the slides:

Mike Rother: Time to Retire the Wedge

Note – this post was written pretty much simultaneously with a post on the forum.

Mike Rother has put up a compelling presentation that highlights a long-standing misunderstanding about the purpose of “standards.”

Some time ago, a (well-meaning) author or consultant constructed a graphic that shows the PDCA wheel rolling up the incline of improvement. There is a wedge labeled “Standards” shoved as a chock block under the wheel to keep it from rolling back. That graphic has been copied many times over the years, and shows up in nearly every presentation about PDCA or standard work.

The implication – at least as interpreted by most – is that a process is changed for the better, a new standard is created, and people are expected to follow the standard to “hold the gains” while they work on rolling the PDCA wheel up to the next level on the ramp.

Slide 6 (taken from the book Toyota Kata) shows the underlying assumptions that are implied by this approach, especially when it doesn’t work.

There are some interesting assumptions embedded in the “wedge thinking.”

The first one is that “the standard can be ‘held’ by the people doing the work.

That, in turn, means that if when things start to deteriorate, the workers and first line leaders are somehow responsible for the “slippage” or “not supporting the changes.”

With this attitude, we hear things like “Our workers aren’t disciplined enough” or “How do I make them follow the standard?” The logical countermeasures are those associated with compliance – audits focused on compliance, and sometimes even escalating punitive actions.

Back in my early days, I had a shop floor team member call us on it quite well: “How can you expect us to hold some kind of standard work if the parts don’t fit?” (or aren’t here, or the tools don’t work, or jigs are misaligned, or the machine isn’t running right, or someone is absent, or we are being told to hurry and just get stuff out the door?)

This is the approach of control. The standard is fixed until we decide to change it.

Taiichi Ohno didn’t teach it this way.

Neither did Deming or Juran. Neither did Goldratt. Nor does Six Sigma, TQM, TPM.

Indeed, if we want creativity to be focused on improvements, we have to look up the incline, not back.

We are putting “standards” on the wrong side of the wheel. Rother’s presentation gets it right – the “standards” are the target – what we are striving to achieve.

The purpose of standards is to compare what we actually do against what we wanted to do so we know when they are different and so we have some idea what stopped us from getting there.

Then we have to swarm the problem, and remove the barrier. Try it again, and learn what stops us the next time.

The old model shows “standards” as a countermeasure to prevent backsliding, when in reality, standards are a test to see if our true countermeasures are working.

I believe this model of “standards” as something for compliance is a cancer that is holding us back in our quest to establish a new level of understanding around what “continuous improvement” really means.

It is time to actively refute the model.

If you own your corporate training materials, find that slide (it is in there somewhere) and change it.

If you see this model in a presentation, challenge it. Ask what should happen if something gets in the way of meeting this “standard.”

“What, exactly do you expect the team member to do?”  That sparks an interesting conversation which reveals quite a bit.

How Do You Deal With Marshmallows?

Yesterday, Kris left great comment with a compelling link to a TED presentation by Tom Wujec, a fellow at Autodesk.


Back in June, I commented on Steve Spear’s article “Why C-Level Executives Don’t Engage in Lean Initiatives.” In that commentary, Spear contends that business leaders are simply not taught the skills and mindset that drives continuous improvement in an organization. They are taught to decide rather than how to experiment and learn. Indeed, they are taught to analyze and minimize risk to arrive at the one best solution.

Tom Wujec observes exactly the same thing. As various groups are trying to build the tallest structure to support their marshmallow, they consistently get different results:

So there are a number of people who have a lot more “uh-oh” moments than others, and among the worst are recent graduates of business school.


And of course there are teams that have a lot more “ta-da” structures, and, among the best, are recent graduates of kindergarten.[…] And it’s pretty amazing.

[…] not only do they produce the tallest structures,but they’re the most interesting structures of them all.

What is really interesting (to me) are the skills and mindsets that are behind each of these groups’ performance.

First, the architects and engineers. Of course they build the tallest structures. That is their profession. They know how to do this, they have done it many thousands of times in their careers. They have practiced. Their success is not because they are discovering anything, rather, they are applying what they already know.

In your kaizen efforts, if you already know the solution, then just implement it! You are an architect or engineer.

BUT in more cases than we care to admit, we actually do not know the solution. We only know our opinion about what the solution should be. So, eliminating the architects and engineers – the people who already know the solution – we are left with populations of people who do not know the solution to the problem already. This means they can’t just decide and execute, they have to figure out the solution.

But decide and execute is what they are trained to do. So the CEOs and business school graduates take a single iteration. They make a plan, execute it, and fully expect it to work. They actually test the design as the last step, just as the deadline runs out.

The little kids, though, don’t do that.

First, they keep their eye on the target objective from the very beginning.

Think about the difference between these two problem statements:

  • Build the tallest tower you can, and put a marshmallow on top.


  • Support the marshmallow as far off the table as you can.

In the first statement, you start with the tower – as the adults do. They are focused on the solution, the countermeasure.

But the kids start with the marshmallow. The objective is to hold the marshmallow off the table. So get it off the table as quick as you can, and try to hold it up there. See the difference?

More importantly, though, is that the kids know they do not know what the answer is. So they try something fast. And fail. And try something else. And fail. Or maybe they don’t fail… then they try something better, moving from a working solution and trying to improve it. And step by step they learn how to design a tower that will solve the problem.

Why? Simply because, at that age, we adults have not yet taught the kids that they are supposed to know, and that they should be ashamed if they do not. Kids learn that later.

Where the adults are focused on finding the right answer, the kids are focused on holding up a marshmallow.

Where the adults are trying to show how smart they are, the kids are working hard to learn something they do not know.

Third – look what happened when Wujac raised the stakes and attached a “big bonus” to winning?

The success rate went to zero. Why? He introduced intramural competition and people were now trying to build the best tower in one try rather than one which simply solved the problem.

Now – in the end, who has advanced their learning the most?

The teams that make one big attempt that either works, or doesn’t work?

Or the team that makes a dozen attempts that work, or don’t work?

When we set up kaizen events, how do we organize them?

One big attempt, or dozens of small ones?

Which one is more conducive to learning? Answer: Which one has more opportunities for failure?

Keep your eye on the marshmallow  – your target objective.

Last thought… If you think you know, you likely don’t. Learning comes from consciously applied ignorance.

Edited 2 August 2016 to fix dead link. Thanks Craig.

“Opportunities” vs “Problems”

Over the decades, I have observed that it is quite common for organizational leaders to try to use the word “opportunity” when talking about a problem.

I can understand the desire to do this – we typically think of “problems” as something to do with people.

But I find the emphamistic language… problematic.



Mr. Opportunity


There is a Honda marketing campaign in the USA that features a cartoon character named “Mr. Opportunity.” His tag-line is “I’m Mr. Opportunity, and I’m knocking.” The opportunity is an invitation to take advantage of discounted prices for Honda cars.

Words mean things.

An opportunity is something that I may, or may not, decide to pursue.

But in lean thinking, no problem can go unaddressed.

Rather than a friendly cartoon character knocking on your door, a problem has kicked your door in and is standing in your living room. It must be dealt with, and dealt with quickly.

It has to be contained, pushed back, and finally resolved to keep it from getting back in.

IF the process for doing these things is carried out correctly, there are opportunities for the organization to learn along the way. But in the vast majority of cases, the only way those opportunites get exploited is if the leaders insist on hearing what was learned. So even those “opportunities” shift to imperatives.

Friendly euphemism that soften the urgency do not help us. If we are to have a true problem solving culture, we have to be willing to call things what they actually are.

Knowing vs. Knowing How To Learn

On the way to the airport a few days ago a couple of thoughts occurred to me that I wanted to toss out there and see how you all responded. This is one of them.

What separates an expert from a master? Actually I need to ask in more prejudicial terms. Some people who are truly experts are also “stuck” in that they try to fit new things they encounter in to an analogy within their (vast) experience. When they find it, they apply the analogy and often come up with a pretty good solution. But they can have problems relating when the encounter something that doesn’t compare with anything they have seen before.

As an example, the classic elements of standard work are described as

  • a repeating work sequence
  • balanced to a takt time
  • standard in-process stock

And, indeed, these things are the elements of standard work when there is a repeating work sequence and when there is a takt time.

Some experts at applying standard work, however, have a hard time seeing application outside of this scope. They know work needs to be standardized, but they continue to try to shoe horn what they see into this model.

Another, more general, lean manufacturing model is the notion that this is about manufacturing, or that it “doesn’t apply” to true job-shops or non-repetitive environments. But this, too, is just a limitation of an “analogy” model. It is the analogy that breaks down, not the concept.

In the analogy model, we try to educate by providing more analogies, more examples of different applications in order to expand the base for comparison.

And, to be honest, this works to a degree. Some people get it, others simply don’t want to expand their analogy base. They are the ones who say “This (model) does not apply to (whatever is their current paradigm)     .

Indeed, people who are tightly holding the view that kaizen events led by trained specialists are the only way to drive improvement can easily be blind to the possibility that an organization that is successfully running daily kaizen is operating at a fundamentally different level. I have seen that as well. And I have seen the same excuses made to explain away the difference in performance. “It isn’t different;”  “it doesn’t scale;”  “it isn’t repeatable.” All of this is defending a mental model – a paradigm – an analogy.

On the other hand, I want to contend here that a true master is not one who has mastered a process, but rather one who has mastered the process of learning about a process.

At an organizational level, true continuous improvement starts to engage when “process” and “standard” become baselines to gain higher understanding. Rather than trying to audit and enforce compliance, they are genuinely curious about the reason why a process is not being carried out as it should. This thinking requires far more work because it is empowering – it simply does not allow playing victim to “they won’t.” It puts the spotlight right back on what can (or should) be learned from the experience.

Put another way, the “expert” knows.

The “master” knows that there is much to learn.

Grassroots Innovation: The 3rd Way

Grassroots Innovation: The 3rd Way.

Greg captures a concept in 183 words that entire books have utterly failed to explain.

When we are trying to solve a problem, there are always people involved. And people have positions, feelings, and are always emotionally tied to this-or-that outcome.

It is critically important to find “The 3rd Way” when working on a solution.

There is a great example of what Greg describes as “flight” starting in page 73 of John Shook’s book “Managing to Learn.”

Shook summarizes “The 3rd Way”:

. . . making good decisions required everyone’s complete commitment to dealing with harsh reality.

This produced yet another counter-intuitive aspect of A3 management: respect through conflict.

Organizations that confuse “nice-nice” with teamwork end up paralyzed and frozen in place the moment there is disagreement. No further intellectual growth appears, and they had better hope they are far enough ahead that their competitors won’t catch on.

I have already used more words talking about Greg’s post than he spent making it.

Is This a Problem – Part 2

Last week I posted a story of a failed freezer, ruined food, and a customer support experience that could be summed up as “That’s how we do it.” I invited comments and asked:

“Is this a problem?”

And when I say “problem” I mean, is this a “problem” from the standpoint of the company’s internal process?

There are some interesting comments, some about the internal culture of the company, others about the support process itself.

But I promised to offer my thoughts, so here they are.

The key question is “What did they intend to happen?” While we can speculate, unless we have the process documentation or are otherwise privy to that internal information, we really don’t know what they intended in this case.

Let’s assume, for the sake of argument, that Frank’s experience was exactly as the company intended it to be. Then, from the point of view of their internal process, there is no problem.

“Wait a minute!” I can hear, “Nobody wants  a customer to never buy the product again.”

And here is my point. We don’t know. This company may be perfectly willing to accept that consequence, i.e. “fire the customer” to preserve their warranty cost structure. They certainly would not be the first. Whether that is good business or not is a totally separate issue. The question is “Did they produce this result on purpose, as a logical, foreseeable outcome of the process as they designed it?.” If the answer is “Yes, they did” (and only they can know), then there is no problem. It might be bad business, but the process is working just fine. (I acknowledge that “bad business practices” can result in unintended results – like bankruptcy. But my point is the results are the outcome of a process, and the process is the result of a decision, even if that decision was to “not care.”)

The key point here is that only after there is clarity of what should happen, can the process itself even be addressed. Until the intended result is clear, then there is no way to see if the process works or not.

Was there a problem here? I don’t know. But this is what I would like people to take away from this little story.

Whenever something in your company seems “not right” ask this really powerful clarifying question:

“Did (or would) we do this on purpose?
If the answer is anything other than an unqualified yes then it is likely you have a problem.

Here is a tougher position: If something was unpleasant for your customer, and you don’t intend to fix it, then embrace the truth that you did do it on purpose. Take responsibility for your decisions, look in the mirror, and say “We meant to do it exactly that way, and will do it the same way next time.” If you can’t stomach that, then go back the the first question.

Here is an extra credit question for this little case study in customer support.
What, exactly, did the customer want here? Gets It

Not many people know that is one of the “places to see” if you are looking for companies practicing the TPS. The fact that their sales and profits are hitting records as most others are scratching and clawing to stay in business is telling.

This recent post by Kevin Kelleher on Gigacom really sums the whole thing up with one sentence quoted from Jeff Bezos’ letter to shareholders:

At a fulfillment center recently, one of our Kaizen experts asked me, “I’m in favor of a clean fulfillment center, but why are you cleaning? Why don’t you eliminate the source of dirt?” I felt like the Karate Kid.

If you have to keep cleaning up a mess, find out where the dirt is coming from.

But the philosophy goes deeper.

If an assembly Team Member is continuously spending time cleaning up threaded holes, go find out how the debris is getting in there (or find a way to keep it out). Go and see.

If you keep losing market share, find out why customers prefer your competitors products. (And don’t sit around a mahogany table talking about it, GO AND SEE.)

Other posts on the same site relate to eBay’s troubles trying to compete with Amazon. The difference, I think, is summed up in a quote from an Amazon executive related to me by someone who was a fly on the wall in one of their meetings:

“At an eBay sellers meeting last quarter, my counterpart was booed off the stage. That is not going to happen here.”

Kaizen is less about the tools than it is an obsessive curiousity about what the next problem is between you and perfection.

How Do You Look At Problems?

A couple of posts ago, I tried to emphasize “hypothesis testing” as the key, core thinking behind the TPS. For that matter, I think that anyone who truly understands any of the various improvement approaches out there will find the same thinking at the core. Certainly Six Sigma; Theory of Constraints; and TQM are all about surfacing and solving problems. They may use different language, might insert the initial lever between different bricks, but in the end, the approaches all embrace the same basic thinking.

I’d like to put out there an idea that it is the way problems are regarded and approached that separates “gets it” from “business as usual.”

What Constitutes “a problem?”

In “traditional thinking” a problem is something which disrupts output. It is something serious enough that it cannot be ignored.

In a true continuous improvement mindset, anything that causes variation from the plan, in any way, is “a problem.” Any barrier between the current condition and the idealized world is “a problem.”

What triggers a response?

In “traditional thinking” if output isn’t disrupted, spend time elsewhere. There is a caveat to this, however. The parable of the “boiling frog” (whether true for actual frogs or not) can drive an ever higher level of numbness as “normalized deviance”   sets in.

Since continuous improvement is a process of discovering the ideal process, variation from the plan is new information. It must be investigated and understood. If everything is running smoothly, then the problem solving shifts to the next barrier to higher performance.

What triggers alarm in the organization?

This one may be the most controversial. While “stopped production” is certainly cause for alarm and immediate response, in the traditional thinking world, it is the only thing that really gets people’s attention.

In a thinking and learning organization, I would add to the above “No problems are apparent.” If there are no andons, there are no defects, there are no line stops, there are no shortages, there are no disruptions, then there is a BIG problem. I say that because these conditions are impossible and it is only because your system is totally numb that you would not see them.

Target Condition

Given the above, then I think it is safe to offer that silence is equated with “stability” in the traditionally reacting organization. Of course it isn’t stable at all, it is just that there is so much systemic anesthesia that nobody feels anything.

In the continuous improvement mindset, things are running as they should if there is a continuous flow of problem being surfaced and solved. That is the only way to be 100% certain that things are getting better every day.

“Management Commitment”

The term “management commitment” is tossed around as a prime reason for failure of improvement initiatives. There are lots of good reasons for this, but until we really define exactly what leaders need to do every day, stop using euphemisms, and start getting real about leadership’s actual role in this process, we are crutching the problem. This is partly “our fault” because we teach the basics very badly. We put top leaders into “kaizen events” but never explicitly link kaizen to daily problem solving. In doing so, we convince them that if only they support enough kaizen events, the organization will be transformed. The logical result is a monthly report on how many kaizen events have been run. Argh.

If we used kaizen events to explicitly teach the core questions, the rules of good process design, and the concept of applying PDCA to everything, we might get more traction. That can be difficult, but maybe if everyone in the industry starts thinking in terms of a few core mantras we might get a chorus going.

The TPS In Four Words

ptolematic_universeIn the world of science, great discoveries simplify our understanding. When Copernicus hypothesized that everything in the universe does not revolve around the Earth, explaining the motions of things in the sky got a lot easier.

In general, I have found that if something requires a great deal of detail to explain the fundamentals, there is probably another layer of simplification possible.

Even today, a lot of authors explain “lean manufacturing” with terms like “a set of tools to reduce waste.” Then they set out trying to describe all of these tools and how they are used. This invariably results in a subset of what the Toyota Production System is all about.

Sometimes this serves authors or consultants who are trying to show how their process “fills in the gaps” – how their product or service covers something that Toyota has left out. If you think about that for a millisecond, it is ridiculous. Toyota is a huge, successful global company. They don’t “leave anything out.” They do everything necessary to run their business. Toyota’s management system, by default, includes everything they do. If we perceive there are “gaps” that must be filled, those gaps are in our understanding, not in the system.

So let me throw this out there for thought. The core of what makes Toyota successful can be expressed in four words:

Management By Hypothesis Testing

I am going to leave rigorous proof to the professional academics, and offer up anecdotal evidence to support my claim.

First, there is nothing new here. Let’s start with W. Edwards Deming.

Management is prediction.

What does Deming mean by that?

I think he means that the process of management is to say “If we do these things, in this way, we expect this result.” What follows is the understanding “If we get a result we didn’t expect, we need to dig in and understand what is happening.”

Control ChartAt its most basic level, the process of statistical process control does exactly that. The chart continuously asks and answers the question “Is this sample what we would expect from this process?” If the answer to that question is “No” then the “special cause” must be investigated and understood.

If the process itself is not “in control” then more must be learned about the process so that it can be made predictable. If there is no attempt to predict the outcome, most of the opportunity to manage and to learn is lost. The organization is just blindly reacting to events.

Here is another quote, attributed to Taiichi Ohno:

Without standards, there can be no kaizen.

Is he saying the same thing as Deming? I think so. To paraphrase, “Until you have established what you expect to do and what you expect to happen when you do it, you cannot improve.” The quote is usually brought up in the context of standard work, but that is a small piece of the concept.

So far all of these things relate to the shop floor, the details. What about the larger concepts?

What is a good business strategy? Is it not a defined method to achieve a desired result? “If we do these things, in this way, at these times, we should see this change in our business results.” The deployment of policy (hoshin planning) is, in turn, multiple layers of similar statements. And each of the hoshins, and the activities associated with them, are hypothesized to sum up to the whole.

The process of reflection (which most companies skip over) compares what was planned with what was actually done and achieved. It is intended to produce a deeper level of learning and understanding. In other words, reflection is the process of examining the experimental results and incorporating what was learned into the working theory of operation, which is then carried forward.

Sales and Operations Planning, when done well, carries the same structure. Given a sales and marketing strategy, given execution of that strategy, given the predicted market conditions, given our counters to competitor’s, we should sell these things at this time. This process carries the unfortunate term “forecasting” as though we are looking at the weather rather than influencing it, but when done well, it is proactive, and there is a deliberate and methodical effort to understand each departure from the original plan and assumptions.

Over Deming’s objections, “performance management” and reviews are a fact of life in today’s corporate environment. If done well, then this activity is not focused on “goals and objectives” but rather plans and outcomes, execution and adjustment. In other words, leadership by PDCA. By contrast, a poor “performance management system” is used to set (and sometimes even “cascade”) goals, but either blurs the distinction between “plans” (which are activities / time) and “goals” which are the intended results… or worse, doesn’t address plans at all. It gets even worse when there are substantial sums of money tied to “hitting the goals” as the organization slips into “management by measurement.” For some reason, when the goals are then achieved by methods which later turn out to be unacceptable, there is a big push on “ethics” but no one ever asks for the plan on “How do you plan to do that?” in advance. In short, when done well, the organization manages its plans and objectives using hypothesis testing. But most, sadly, do not.

Let’s look at another process in “people management” – finding and acquiring skills and talent, in other words, hiring.

In average companies, someone needing to hire someone puts in a “requisition” to Human Resources. HR, in turn, puts that req out into the market by various means. They get back applicants, screen them, and turn a few of them over to the hiring manager to assess. One of them gets hired.

What happens next?

The new guy is often dropped into the job, perhaps with minimal orientation on the administrative policies, etc. of the company, and there is a general expectation that this person is actually not capable of doing the work until some unspecified time has elapsed. Maybe there is a “probation period” but even that, while it may be well defined in terms of time, is rarely defined in terms of criteria beyond “Don’t screw anything up too badly.”

Contrast this with a world-class operation.

The desired outcome is a Team Member who is fully qualified to learn the detailed aspects of the specific job. He has the skills to build upon and need only learn the sequence of application. He has the requisite mental and physical condition to succeed in the work environment and the culture. In any company, any hiring manager would tell you, for sure, this is what they want. So why doesn’t HR deliver it? Because there is no hypothesis testing applied to the hiring process. Thus, the process can never learn except in the case of egregious error.

If we can agree that the above criteria define the “defect free outcome” of hiring, then the hiring process is not complete until this person is delivered to the hiring manager.

Think about the implications of this. It means that HR owns the process of development for the skills, and the mental and physical conditioning required of a successful Team Member. It means that when the Team Member reports to work in Operations, there is an evaluation, not of the person, but of the process of finding, hiring, and training the right person with the right skills and conditioning.

HR’s responsibility is to deliver a fully qualified candidate, not “do the best they can.” And if they can’t hire this person right off the street, then they must have a process to turn the “raw material” into fully qualified candidates. There is no blame, but there are no excuses.

Way back in 1944, the TWI programs applied this same thinking. The last question asked on the Job Relations Card is “Did you accomplish your objective?” The Job Instruction card ends with the famous statement “If the worker hasn’t learned, the teacher hasn’t taught.” In other words, the job breakdown, key points and instruction are a hypothesis: If we break down the job and emphasize these things in this way, the worker will learn it over the application of this method. If it didn’t work, take a look at your teaching process. What didn’t you understand about the work that was required for success?

I could go on, but I have yet to find any process found in any business that could not benefit from this basic premise. Where we fail is where we have:

  • Failed to be explicit about what we were trying to accomplish.
  • Failed to check if we actually accomplished it.
  • Failed to be explicit about what must be done to get there.
  • Did something, but are not sure if it is what we planned.
  • Accepted “problems” and deviation as “normal” rather than an inconsistency with our original thinking (often because there was no original thinking… no attempt to predict).

As countermeasures, when you look at any action or activity, contentiously ask a few questions.

  • What are we trying to get done?
  • How will we know we have done it?
  • What actions will lead to that result?
  • How will we know we have done them as we planned?


  • What did we actually do?
  • Why is there a difference between what we planned and what we did?
  • What did we actually accomplish?
  • Why is there a difference between what we expected and what we got?

The short version:

  • What did we expect to do and accomplish?
  • What did we do and get?
  • Why is there a difference?
  • What are we doing about it?
  • What have we learned?