By looking at continuous improvement, leader standard work and standards, editorial board member Jacob Austad warns against the most common pitfalls we encounter when we apply lean tools and explains why many companies don’t know the purpose behind them when they first reach for their tool kit.

There are organisations focused on delivering customer needs and there are organisations that believe success means to follow a methodology step by step.

The former allow for flexibility in their approach and undertake experiments governed by curiosity and a strong belief in a more systemic way of thinking. The latter are tick-a-box organisations believing that simply applying tools and techniques will do the trick.

The question is why some companies use tools without really knowing why and what problems the tools are designed to solve.

Why and how are tools used in companies across industries? Let’s look at continuous improvement, leader standard work and standards in general.


More and more, the lean community discusses how leader standard work can support the implementation of a continuous improvement programme. But what about reflecting on the reasons why people – particularly in service and administrative environments – resist standards? What about asking whether in reality it is the standards they resist or some embedded elements like assessments and audits, which often blame and praise people for (non-) compliance with the standards?

There is hardly any company or organisation that works with lean without about the aim of implementing a culture of continuous improvement; much good advice and many research papers tend to show how to do it. But do we know the purpose of this?

What problem are we trying to solve? Why does this process exist? Who are we doing this for? Questions like these often seem to be missing. There are therefore numerous examples of suggestions for improvements without any common direction other than they all count as continuous improvement suggestions. People need direction and, first of all, an understanding of the reasons why we are doing what we are doing.

In order to build a lean culture (and continuous improvement is most certainly a part of a lean culture), there is a need to consider several areas. First of all, we need to understand the system and it is the people working on the system and the leaders who need this understanding.

In the early days of lean, when (some) organisations believed they could just copy the use of tools from Toyota and get the same brilliant results it had, only few succeeded. Most companies lacked the understanding of the big picture and of why Toyota developed the tools and techniques.

Unfortunately, few studied the causes before abandoning “the programme” and they did not realise that continuous improvement cannot be a goal in itself or it will result in a non-sustainable culture.

In fact, many improvements only focus on short-term activities, which do not improve the system but merely reach one target, thereby driving costs up.

One of the problems with any kind of standards is that they are often designed and implemented for the wrong reasons.

Technocrats and tool-heads believe that, if a standard is put in place and we ensure that people (operators and managers) follow it, everything will be good: assessment and audits will be passed and everybody will collect their bonus. In other words, we’ll tick all the boxes.

In a service environment compliance to standards should be avoided (or at least handled with care) and the thinking should be reversed. It should start with understanding what problem we are trying to solve. Then measure the improvement in systems performance and adjust following the PDSA cycle (Shewhart and Deming’s scientific method).

As a result, people will see a series of improvements (as well as many ideas/theories that had to be abandoned because they did not improve the system).

Now, these could be labelled as continuous improvement, but they are there as a result, not an aim. The real aim is to improve systems performance and not to put standards in place.

In healthcare (which is often labelled as a service system), there are good reasons for having standards to ensure the right treatment of patients. However, these are designed at the right level and ensure that doctors and nurses’ competences are never left out. Standards need to be handled with care and it is important to ensure the right level that always includes an understanding of the purpose (the why).


Organisations across sectors talk about standard work – not only at operator level, but increasingly in leadership. This is often labelled leader standard work.

Examples of LSW include planning and executing staff meetings, follow-up on employee performance, developing competence, delivering monthly reports, ensuring targets are met, etc.

From an organisational standpoint, predictability is often good as it helps to avoid fire fighting: without problems that suddenly occur there is less need to change our focus here and there. Consequently, there will be no vicious cycle of a constantly changing focus and thereby no extra time will be required to take a systemic and long-term view.

Talking about LSW could potentially lead to the wrong behaviour. A tool-head manager will see standard work as a checklist of what to do and measure if this is done on time and to standard. Success (in this case compliance) would be measured as “yes-no” or “done-not done” with only little focus on actual customer and business benefits.

Success should not come from checklists but from the honest desire to work with people to improve the system to better deliver customer needs.

A daily, weekly or monthly briefing focusing on operations and overall systems performance could be called a routine and the aim is not to have the briefing/meeting, but to look 360 degrees at the system performance in the past period and, based on the lessons learned, to take concrete actions going forward. This includes prediction of what will happen when completing those actions.

The routine could be labelled LSW, but in reality it is an organisational routine aimed at delivering according to customer needs. The difference is, that the common purpose(s) needs to be articulated first and this should always be to deliver according to customer needs. This will ensure a link to the system performance and not some arbitrary internally-focused targets related to “what” and “how.”  There is also a framework for improvement, which brings the focus back to the overall purpose involving everybody and not only managers.

The difference in focusing on the system’s performance instead of the standards is clearly seen in the measures and the questions asked. Here is an example:

Of course people should be “allowed” autonomy with regards to identifying opportunities for improving, but that will only happen if people know why. Give people a target of x number of improvements per year and they will fulfil it. The question is: by doing what? The same is true for standards and LSW and the constant fight between quantity and quality.

Continuous improvements need to happen for the right reasons and therefore it is extremely important that we are careful implementing standards and measuring compliance to them.

Continuous improvements are also (from time to time) labelled kaizens and no one can argue that Ohno didn’t know what he was talking about. Hence it might be worth remembering one of his statements:

“If you’re going to do kaizen continuously, you’ve got to assume that things are a mess.“

Let’s clean up the mess and focus on systems performance, then.

The prediction is that starting by understanding purpose before implementing standards will decrease the need for standards and eliminates the endless discussion on which standard or template to use. And the focus will shift to constantly measuring if the system delivers according to customer needs and not if the people in the organisation comply with the standards.

Ask people why lean practitioners want one piece flow and many will answer: “Because we learned it is faster and the company saves money.” The answer isn’t entirely wrong, but it’s not entirely correct either. What about understanding that one piece flow also allows one problem flow and by handling one problem at a time (for example, quality) people learn and improve the system and thereby align it to delivery according to customer needs?

The result is, yes, continuous improvement.


Standards are put in place because there is a belief that compliance to them will ensure delivery. That might be right in a world where customer needs and demand never change and in a one-size-fits-all world.

The way to ensure compliance to standards is for instance to check whether the fixed (and repeated) agenda of the meeting was followed in terms of sequence and time, while evaluating whether the purpose of the meeting was achieved.

The danger of introducing a standard is that failure demand is codified instead of eliminated – it is the difference between doing things right (which will actually make it worse) or doing the right things.

Imagine what could happen at a retailer if failure demand was codified instead of eliminated:

Customers asking the store manager where a product is or if there is one more of a certain item is in fact failure demand, but if this is not understood the store manager will (at one point) properly suggest having more employees helping customers, changing the responsibilities, setting up more signs with customer information etc.

If he listened to what the customers were saying and studied the causes for customers asking, instead, he would be able to eliminate the causes of the problem, understand the change in demand, reorganise the layout and ensure products are available on shelves (and not in the storage room) and thereby prevent the customers from asking (as there would be no need).

This would free up the store manager’s capacity to provide better service by, perhaps, helping out at the cashier when the queue at the till is too long.

A standard should only be put in place with a purpose and in this store example it would maybe be a good idea to create a one-page lesson (OPL) to educate the store manager and teach them to handle the till – he could probably use some coaching to see his role changing from manager to leader).

Here’s the pitfall: when management demands standards (so they can measure compliance and adherence) and fails to understand that the only acceptable form of standard is that asked for by employees.

Leaders will know that the important part is to focus on process and system deliverables and ensure they are aligned to customer needs. Any measure of compliance to standards creates disempowerment and lack of engagement. Standards are often misunderstood, especially when there is a significant difference between the need for them in manufacturing and in services.

Manufacturing often needs standards, while standards in service are often not designed to respond to customer needs. Specifications of this kind will create failure demand. They will eventually drive costs up and in trying to bring them down management will put in even more standards and compliance measures. It will take a leader to make things right.


The literature is full of examples of why lean (or other improvement methods) fails and the causes are often listed as a number of things to avoid. An approach like this might be good (but it often isn’t) if people knew how to read these lists and understood the underlying truth.

This is that there is no right answer except for “It depends…” There is only a need for an understanding of what applies to a specific situation, which by definition needs to start by an understanding of the situation first. Deming said:

“Any theorem is true in its own world. But which world are we in? Which of several worlds makes contact with ours? That is the question.”

There is a lot to learn from this quote, especially in relation to understanding the current environment from a systems perspective and not only in functional silos.

Leaders will be able to understand and explain the problem, the systems conditions affecting the problem and therefore also why a change is needed.

Managers will not be able to do so if they start with tools.

Failing to figure out the system end-to-end leads some organisations to concentrate on tools implementation rather than on finding the right solution that will help to fulfil the business strategy.