Standard Work Is Like Food – Taste before Seasoning

During a recent trip to the great state of Texas, I heard some down-home wisdom, “Before you season your food, why don’t you taste it first?”

The person who uttered that question was NOT talking about food. Rather, he was challenging someone who was a little too hell-bent on changing something without truly understanding it.

Sound familiar?

Heck, even etiquette folks will tell you it’s rude to season before tasting.

“If you season your food without tasting it, you will convey to the cook that you are already assuming the food will be bland and tasteless. It is more polite to taste food first and then add seasoning if you think it's necessary.” (How to Season Food With Table Manners)


But, the point of this post isn’t about important as they are.

It’s about standard work.

People are relatively quick to pick up on the notion of kaizen – making things easier, better, faster, and cheaper. Self-induced kaizen is fun, even freeing.

It’s better and more fun to give than to receive.

Of course, improvement without standardization is stillborn to say the least.

No doubt, we have heard the Taichii Ohno quote, “Where there is no standard, there can be no kaizen.” Standard work implies that there must be adherence. Without it, it’s more like a standard wish…as fickle as the wind. We can’t sustain improvements and we have little foundation for the next.

However, adherence, especially when “virgin” standard work (you know, that first step from the wild no standard work west days) is introduced, requires folks to often significantly change the way that they do work - new steps, sequences, cycle times, standard WIP, etc.

It can be hard learning a new way. It can be frustrating. It can feel limiting. But, it ensures that people are working to the current one best way…until it is improved again.

So, here’s the rub (pun intended).

How long does one need to go before they start adding seasoning?! How long before the standard work should be subject to improvement?

We know the likelihood of any given standard work being perfect is essentially ZERO. It’s one reason why we apply SDCA (standardize-do-check-act) – to assess not only adherence, but the sufficiency of standard work.

Improvement should follow.

But, try this scenario on for size. Standard work has been developed during a pilot, regularly subjected to improvement over a period of many weeks. It’s been battled tested and has facilitated significant, measurable improvements in productivity and quality. Then, it is introduced to another line or location, with an appropriate application of change management. (Hopefully, this includes the rigor of a net change activity to understand and compensate for any true differences in the adopter’s value stream versus the pilot’s…)

The next line or location quickly goes from no standard work to adopting the new standard work. It’s painful. Within minutes the new adopters think, "I don’t like this." It’s not “sufficient.” It plain old su*ks.

Not long thereafter, the new adopter folks start thinking about seasoning, about “improving” the new standard work. Hey, I tried it for a day, time to exercise my Ohno-given right to kaizen. Almost, an "it's my ball, and I'm going home...with it," type of mentality.

So, here’s a question for you – how long should someone taste the new standard work before they are genuinely ready to consider seasoning it?

I’ve got my thoughts. What are yours?

Related posts: Standard Work Is a Verb, Leader Standard Work Should Be…Work!, Lean Decay Rate

There are 10 Comments

markrhamel's picture

Hi Mike,

Thanks for the very thoughtful comment!

I wouldn't be so bold as to select an arbitrary time frame either. But, I think a relatively brief and temporary "lock down" on standard work - perhaps a week or more makes sense. One very key point you make is that the teams need to "understand" the standard work. Understanding can only come to fruition through practice. Of course, practice will help identify waste and other opportunities. You are spot on regarding how an extensive lock down will frustrate stakeholders and their engagement around kaizen.

It's a delicate balance!

Best regards,

Mike Krebs's picture

This is a very timely post for me considering our company is deploying standard beyond the pilot site. You can only catch so much during the net change event - as you state the chances of it being perfect are nada.

Concurrent with deployment - as more minds review and follow the SW - it becomes clear that it can be improved almost out of the gate. If we wait too long to integrate the improvements, teams lose the "buy-in" if they have to suffer through something wasteful but unchangeable. So, allowing for some "early" improvements can aid in the adoption.

To pick a time frame like 30 or 90 days, or number of cycles seems arbitrary. Improvements should begin to be made once the teams understand the SW and begin to see the waste.

Eager to here your thoughts.

markrhamel's picture

Hi Andrew,

Thanks for the comments.

Now there's something to add to the interview selection criteria! Thanks for sharing.

Best regards,

markrhamel's picture

Hi Wesley,

Thanks for the comment. Some excellent points.

What I was referring to was standard work that had been developed, often started within a kaizen event, but then continually PDCA'd for a number of weeks within the pilot line/cell/team. The pilot process is important from a technical prove-out perspective and to shake out any initial human resource issues. Here, the presumption is that there are similar, if not identical lines, within the same or other locations.

Once that post-pilot "checkpoint" has been cleared, we often proceed to another line, where we can see the technical scalability dynamics as well the impact on HR stuff (may have gone from the handpicked folks in the pilot to a team that may be more representative of the general population). Certainly, when the move proceeds to other sites, we can start experiencing the impact of different cultures as well, etc.

The point that I was attempting to get at is when moving from the pilot to one or more "initial deployment" lines, the recipients should just use the new standard work for a period of time before introducing changes. This is especially important, if the new standard work is moving to an area that is very immature from a lean perspective - often never having any real standard work. If we don't lock down the standard work for a period, the immediate reaction from the next line is something along, "this stinks, let's change it."

Now, it does make sense before the deployment to the next line to conduct what I call a "net change" review within which we review the value stream to see if there are any heretofore unidentified differences between the pilot and the next line (systems, equipment, staffing ratios, etc.). If there are substantial differences, then the standard work should often be adjusted before introducing it to the new line.

There's more to say, but I hope this makes sense.

BTW, go Bantams! Nice to hear from a Trinity grad.

Best regards,
Trinity '85
BS Math (not a good one)
Varsity Baseball, captain

Wesley Connell's picture

I might be outside the normal line of thinking, but I don't see any problem with allowing the new line to "season" the standard work very early, almost immediately, in the process.

During a implementation workshop, the standard work from the pilot line is distributed and run through with the affected workers. The data from the pilot line on cycle times are made available. Before the conclusion of the workshop, we allow for any improvements to be made to the standard work, but they need to be agreed upon by all members of the new cell and documented.

This starts the PDCA cycle. The rule is that the new standard work will be evaluated against the pilot. Best standard work wins. This has done well for us to engage employees and make the improvement process their own.

Its not that they are seasoning the food that they are being served, its more akin to a chef making the recipe their own by adding their own unique seasoning.

markrhamel's picture

Hi John,

Thanks for the comment. You make a number of excellent points!

My purpose for referencing a time-frame is primarily within the context of deploying standard work across a number of (near) identical lines and/or sites that have little or no prior experience with standard work. In such instance the standard work is typically developed at the pilot site/line. The inexperienced recipients of the new standard work very often have an immediate reaction that the standard work needs to be "improved." This is induced largely by the change and the feeling that their freedom to do their work as they desire (non-standard) is being infringed. The point is that they need to live with the new standard work for a bit to adequately understand it and "check" or "study" it before making changes.


John Huner's picture

I don't see any need for a timeframe, myself. The key is to make sure any improvement is documented.

Any actual change should really be PDSA (so tested and proven). I don't mind using judgement to make a change to the standard and then test it when that makes sense - it does in some cases.

As long as you update the standards and validate they work that is the key to me. Not the time-frame. If an organization found it was inefficient to have too many changes then it can make sense to impose restrictions. That is a system specific constraint though, I believe. To a significant extent those early in lean will have constraints that make fast changes seem impossible (similar to ideas of fast turnover, more many years ago - now many people realize how possible such things are).

markrhamel's picture

Hi David,

Thanks for the comment. Excellent point(s)!

Yes, cycles of new standard work rather than time frame, itself may make a heck of a lot more sense. Depending upon the value stream and the specific processes, cycle times could be seconds, minutes, hours, or even days. The team(s) that have adopted the "new," previously developed standard work from the pilot line, need to experience, unless there are some glaring deficiencies, some cycles before "seasoning" the standard work.

Best regards,

David Kinne's picture

Is it about 'timeframe'? Is it about 'cycle rate' (number of uses of the standard or product/service related to the standard work0? Is it about a 'measure' of the standard? Something rings true to a measure more than a timeframe. Just as standard work is a means to structure activity to a agreed standard the ability to change the standard work should probably have a standard applied as well. I'd vote for some measure of performance (if able to) over a flat timeframe. Or even cycles of use or cycles of product/service provided? If the standard work is truly developed within the context of the team then, wouldn't the team be the final review to determine if a change were needed? Guess I have more questions than answers.......
Thanks for the challenging thoughts.

Andrew Bishop's picture

Stories about Thomas Edison abound in my former home, Fort Myers, FL, where the great inventor is something of a patron saint (he had his "Winter Laboratory" there - shared grounds with Henry Ford & Firestone!). In one story, he famously declined to hire an interviewing engineer who salted before tasting at mealtime. I guess he figured, like you, that it was a general rule and, if broken at the table, might be broken at work as well!