Being an All Black

hakaSo a few people have sent me the link to the recent Steve Hansen interview* (20 mins. long) – thanks for that, it’s very good and worth writing this post about.

* For those of you who live on a different planet – Hansen is the current coach of the All Blacks (that’s a rugby team!) and is currently at the 2015 World Cup in England.

Listening to the interview shows how truly special the All Blacks environment is. I pick out below what I think are key things said that are applicable to any/ every organisation that wants to continually strive towards its true purpose:

(Quotes are in blue text with my thoughts following in black)


Interviewer’s Question: “…What defines Steve Hansen’s All Blacks?”

Steve Hansen’s Response: “It’s not Steve Hansen’s team…it’s about a collective group who are trying to do something [purposeful]….we have to set ourselves some lofty goals, and some people may say that’s arrogant, but I think if you want to achieve something in life, you’ve got to set big goals…”

This links to the setting of a clear challenge* such that everyone involved understands and wants to drive towards it, not for the leader but for themselves.

As such, this challenge has to be:

  • Meaningful: about making the world a better place in some way;
  • Tangible: easily relevant to everyone who is to be involved, not distant and abstract; and
  • Real: not a fake side-act for something else (see POSIWID).

*The challenge is not about a solution – you should know where you want to go but not impose how you believe you are going to get there (See How to have a successful journey).


Interviewer’s Question: “Is that one of the defining factors – the fact that it is a collective?”

SH Response: “…for this team to really play well, we need to be as one and the team has to be greater than the individual…”

This fits perfectly with the idea of systems thinking. The All blacks are a system made up of component parts – 15 individuals on the pitch, 7 on the bench, more in reserve, coaches and back room staff.

They want, and need, to optimise the system, not its component parts.

Every player will want to be picked in the 1st 15…but will work together even if they are not. If Dan Carter isn’t picked for a game, you’d still expect him to use all his 100+ caps of experience to help his replacement…and he most certainly will – and if you doubt it, look for the water boy!


Interviewer’s Question: “You’ve talked about humility and..devolving leadership…as the coach…you have to give up some control. Is that right?”

SH Response: “Well, it might seem like you have to give up control, but, really, it’s not about control. It’s about everybody going in the same direction, trying to achieve the same thing, so you’re not having to control anyone to do that. They want to be alongside you. And in some cases, you want them to be in front of you because they’re the people that are out there playing, and they’ve got to make the big decisions in the moment in the contest. And all we [the coaches] are is here to facilitate an environment…that is conducive to them being able to play.

This echoes everything posted on this blog about the important thing being the environment. We need to move away from a ‘command and control’ logic (and all its management instruments of torture) and replace it with a realisation that Purpose + Environment = the starting point!

Then, and only then, will the whole team truly work together for the good of all.

Purpose is necessary. Environment is necessary. Neither, on its own, is sufficient.

The other point is that it is about the people ‘at the Gemba’ making decisions. The coach’s job is just to provide the direction and support to enable this.


Interviewer’s Question: “How do you, Steve Hansen, see…get the feel for what a player needs?”

SH Response: “Well, once we’ve talked about the team coming first, the team’s made up of a whole lot of individuals, so you try and do your best to get to understand the individuals and what makes him or her tick…You’re really looking at them, ‘how am I going to get the best out of that person?’ along with the other guys that are helping you do that. It’s about watching them every day…you just know after a while when you’re rubbing shoulders with them all the time what individuals need and what they don’t, and I guess that’s the art of coaching.”

This echoes what was written in People are people so why should it be. We are all different, we have different strengths and weaknesses – the task is to develop each and every one of us, not judge and compare us!


Interviewer’s Question: “…you spend a lot of the time motivating the team…”

SH Response: “Interestingly enough I don’t think my job is to motivate the team. My job is to create an environment where motivated athletes can perform…”

I think Hansen might have read a bit of McGregor and Herzberg

He understands that I can’t motive you…but I can strive to provide an environment that has the best chance of you getting the best out of yourself for the good of you and your team.

I very much doubt that Hansen uses the management tools of cascaded personal objectives, individual targets, judgement and extrinsic rewards. Can you imagine him taking, say, SBW (that’s one of the players) to one side and saying “Right Sonny, your target this game is 6 offloads, 4 crunching tackles and 2 tries and if you do it, I’ll give you a sports car”. This would destroy the collaboration that he wants from his collective. It would make it about the individual rather than the team. It would make it about hitting the target and then doing no more.

Who’s had a son or daughter playing sport and seen what happens when a parent tries to motivate their child with, say, money for scoring a try (or goal or…). It is a coach’s worst nightmare! How on earth can they persuade this individual to get that ‘dangling carrot’ out of their mind to pass that ball?!


Interviewer’s Question: “Everyone wants to get better. I mean, how do you actually do it?”

SH Response: “I think it’s about living it every day. You create an environment where you’re living every day trying to get better and you’re not accepting that what you’re doing today’s good enough. And I think if you keep pushing that and everyone’s bought in to it first and foremost and then you keep pushing it and driving it, it’s achievable. But the minute you decide that ‘Okay, we’ve arrived’ someone’s just going to draw [go] straight past you…”

He understands that it is a never-ending journey and the moment you think ‘aren’t we just great!’ then you are in trouble.

It’s also about looking at yourselves and what you are doing rather than trying to be like somebody else (see Benchmarking – worse than cheating)


…and finally:

Whether they achieve their lofty goal (retaining the world cup) or not, I think you’d agree that they appear to be going about it in a fantastic way.

When I look back at Steve Hansen’s interview I think ‘he really gets it’. I also believe him – I don’t think he is just saying it…and, as such, I would follow him (I just need to get good at rugby now!!!).

If you didn’t know differently, you could easily think that Hansen was a student of Deming and Ohno …and who knows, he might be!

Advertisements

Turkeys don’t vote for Christmas!

turkeySo your leaders want to ‘improve’ your organisation! (or is that reduce its cost base – “aren’t these the same thing?!”).

Put yourself in the shoes of those leaders:

You have two choices:

a) You think you know ‘the answers’ and so can quickly move to ‘obvious solutions’: a dollop of specialisation here, a heap of centralisation there, perhaps with the ‘synergies’ word thrown in for good measure…and then, hey presto, let’s standardise and ‘automate it‘ whilst also doing that ‘customer-centric’ thing in parallel!; or

b) You understand that you don’t perform the daily processes at the front line and so you are necessarily reliant on the value-creating workers (with their middle and lower management) to:

  • Identify and work through where improvements might actually lie; and then
  • partner with you in successfully (and continually) changing the current system.

You can see (from the hyperlinks) that I have written a number posts that relate to option a) and I hope you agree that one of THE foundations of real and sustainable improvement is to meaningfully involve the process performers….so let’s take a look at option b).

Involving the workers

Okay, sounds great. Nice idea…so let’s start by asking the workers what they’d change.

Mmm, they don’t seem to be coming up with much, and what they are contributing seems rather insignificant and poorly thought through, dare we say feeble. They aren’t very competent are they! Perhaps our problem is with our workers – do we need to get rid of them and get a better bunch? After all, isn’t it one big ‘war for talent’ out there!

But, whoa, stop, back up the horse: What if your process performers aren’t (meaningfully) engaging in your much hyped ‘improvement programme’? …and why might that be? What might they be thinking about? How about the following:

“Do I have the time (and motivation) to properly engage in improvement thinking for fear of this counting against me elsewhere? (such as my business-as-usual workload, targets and incentives)

“Do I trust them to properly listen to what I am saying, in full and not jump to overly simplistic and seemingly easy ‘quick wins’?”

“What would any changes mean to me and my environment?”

“Will I be better or worse off?”

“Will they look after me (or those colleagues that my ideas would affect)?”

In short, turkeys don’t vote for Christmas. (Nice Roast dinner picture though eh – looks very tasty)

If leaders haven’t established (and don’t continue to nurture) an environment of trust then they should expect very little in return.

Trust

A critical part of achieving (what is often termed) ‘Operational Excellence’ is trust. (The opposite of fear)

“To drive the kind of no-holds-barred commitment to operational excellence that is required, everyone in [the organisation] has to believe in the process and that she won’t be ‘rewarded’ for driving progress towards [improvement] by having her job cut!

Without trust, [improvement] projects quickly devolve from finding and fixing critical problems to battles to shift blame and accountability to others….” (Liker)

Put simply, we need to treat people as assets, not as costs to be slashed. Deming went further:

“I used to say that people are assets, not commodities. But they are not just assets: they are jewels.”

Now, leaders might respond with “we don’t do that here!”…and, yes, maybe not blatantly…but what about how it looks; how a leader’s words are translated and what actually eventuates?

  • do you require business cases with ROI’s and financial benefits to be calculated and ‘realised’? Are these benefits often about head-count (perhaps masked with that 3 letter ‘FTE’ acronym)?
  • do you have structures in place* that make it very hard for someone in the system to suggest horizontal changes from their vertical silo’d world? (*such as cascaded personal objectives linked by judgement and rewards)
  • do you hold competitions between teams that should be collaborating? Do you often talk/write in such competing language?
  • do you preach empowerment of the people but then provide little time and support for their ideas?
  • do you continually re-organise such that people are continually finding their feet (and voice) within yet another management structure?
  • do you employ lots of change managers and external resources, distorting and hindering natural team dynamics?

To establish trust, improvement must not get confused with head-count reduction.

Management need to provide an environment whereby people are comfortable ‘changing their jobs’ because they know that they will go on to even more interesting work (preferably inside, but also outside, the organisation).

And here’s the wonderful chain reaction:

  • If you gain people’s trust (which will be hard at first and will take real leadership)
  • …by providing a safe, secure and stimulating environment for your people
  • …then they will develop themselves (some will amaze you!)
  • …and look for opportunities to continue on this journey
  • …which will mean that your organisation becomes self-sufficient in the ‘brains department’
  • …with a very healthy side effect that you can save an awful lot of money (and often pain) by avoiding the ‘bring in the outside consultants’ option
  • …meaning that you will align organisational purpose with those of your people
  • ….causing exceptional, and sustainable, results
  • …allowing the organisation to organically grow (rather than by constant acquisition)
  • …which enables you to invest in your people and we are off, full circle, around the chain reaction 🙂
  • BUT this chain is unstable and can be ever so easily broken by the words and deeds of leaders.

“Trust takes time to build, seconds to lose and twice as long to regain as it did to build in the first place.” (Unknown)

Deja Vu

How often does your function experience people coming in to ‘map processes’? And when this happens, how often are they referred to a similar exercise, usually performed for a specific project, carried out a year or so ago?

When your function digs out (what they can find of) these earlier process mapping ‘artefacts’ (as they are, in my view, unhelpfully labelled) for the new mappers to look at, how often do they say “excellent, we’ll use these as a starting point” and then adopt a slightly different mapping approach/ method/ tool and do it all over again.

….and the people ‘mapping’ and those ‘being mapped’ experience a certain déjà vu.

deja-vu

Even worse, do the ‘mappers’ take process performers away from the process to do the mapping in workshops?! Do you think this enables them to map reality or a set of opinions? Do you think they end up with a highly crafted and nice looking ‘logical diagram’ or the complex and messy truth?

If processes have been mapped before and this is being done (yet) again, then some hard questions need to be asked.

  • why did they get mapped last time?
  • who (if anyone) agreed/ agrees with what they produced?
  • who used/ uses them to perform the work?
  • what happened to them? (are they likely to be complete, current and meaningful?)
  • …and therefore, why does it need doing all over again?

Projects vs. Processes:

If the purpose of mapping is ‘for a project’ then there is already a problem.

A process exists all the time, no matter what projects are being done on (or, more likely, to) it.

A process should have a purpose and a clear customer. It will have demands that are placed upon it (both value and failure) and a capability for handling that demand (which includes variation). It will have a desired flow (how it should be performed), a current flow (how it is performed) and a set of system conditions (constraints) that make this so.

Whilst a project might affect a process, you shouldn’t need a project to understand a process and you don’t always need a project to improve a process. If you do, then you aren’t properly managing your processes!

Conversely, if you’ve got a project that is going to have a major impact on your processes….you had better be managing your processes well for this project impact to go smoothly. Otherwise you can expect the proverbial car crash.

Purpose

Let’s get to the real point: Every process performer wants to do a good job and, to do this they desperately* want:

  • really good process knowledge that they can easily use to do their job to the current standard;
  • this process knowledge to be able to cope with (absorb) the variety that they experience in customer demands, not force them into an unhelpful straight jacket;
  • to be able to use their actual experiences (as opposed to what is supposed to happen) and make sure that these learnings are captured, understood and properly used so that the process knowledge is continuously improved for them and for the benefit of their colleagues;
  • to know when the standard has changed, why and to what such that they can easily and consistently adopt it…and this means there is NO confusion as to what the new standard is and from when it is to be adopted.

What you will notice from the above is that it is the process performers who most want and need excellent and current process knowledge and, standing back, this is actually rather obvious!

* I use the word ‘desperately’ because this is what I always hear when I talk to the process performers at the Gemba (the place where the work is done). They cry out for the above!

But is this what our usual process ‘mapping’ focus is? I would say not.

Reality:

So what actually happens?

Projects come along, pull process performers into workshops, ask them what they do, document what they say, (sometimes) ask the process performers to ‘sign off’ on these ‘artefacts’ (grrr) who, in turn, typically think “it doesn’t tell the whole picture but, yeah, that’s about right” or “it’s not how I would have explained it, but I can see what you’ve done there”…and then the project goes away allowing the process performers to get back to their reality….until, wham, the project change is sprung on them.

In parallel to this, process performers are getting on with their day jobs and, desperate to make it easy for themselves to know what to do, they create (or augment) the necessary process knowledge to perform the work. They do this in whatever medium they have available to them, in what little spare time they have and then store it wherever is convenient for them. All of which is totally understandable.

Over the top of all this, those who determine the policies to be adhered to when carrying out a process (let’s call them the process owners) issue ‘memos’ (in increasingly modern formats) informing all of what is changing and how it should be done from now on. Similarly, these process owners also issue ‘rebukes’ as to what people are doing wrong (along the lines of “didn’t you read my memo dated xyz!”) and warning them to “do it right from now on!“.

dogs dinnerThe above usually creates what I would refer to as a ‘dog’s dinner’

Here are some thoughts on what’s needed for our processes to continually deliver customer value:

  • Clarity as to what the organisation’s set of value streams (and processes within) are and who is responsible for what;
  • A horizontal focus on these value streams, rather than a vertical silo focus…so that:
    • a process is seen from the customer’s point of view
    • there is meaningful collaboration by process performers across the flow
  • The process performers and process owners jointly owning their own process knowledge….they need to:
    • determine what they need to know and how it is best provided/ presented for their ongoing consumption;
    • like using this process knowledge; and, even better
    • like improving it (meaning this has got to be easy and obvious to do)
  • A focus on the wider subject of process knowledge, not (just) process maps:
    • i.e. any/ all knowledge necessary to perform the work
    • this includes the business rules (policies) to be applied when performing a process, and any necessary supporting materials
  • A true understanding of Service organisations such that the process knowledge helps the performers to absorb the variety within customer demand, not frustrate it
    • we shouldn’t attempt to create a ‘process encyclopaedia’ that clinically answers everything since no such thing can truly be created. Instead, it needs to allow the absorption of variety
  • An experimentation mentality (trial and error) from which to continually improve how process knowledge is created, provided and improved
  • Expert help on what tools are available to enable the above BUT this help is not to ‘do it’ to them or for them….but to advise and support them

Some good tests for process knowledge are:

  1. how comfortable (or conversely, anxious) a new starter is when beginning their work; and
  2. if/ how well a seasoned operator picks up a change in process without reverting to the old way.

And finally….it’s not about tools!

It doesn’t matter how good the ‘process management’ tool is that you have found if you don’t understand and properly live the above. Your investment in such a tool (and the resources to populate it) is likely to become one huge costly, dare I say ‘dog turd’ of a, mistake. You can create amazing (looking) process knowledge in an awesome tool but if no one uses it to perform (and continually improve) their processes then, wow, what a waste!

“A fool with a tool is still a fool” (Grady Booch).

Conversely, we seem to have the idea that there is only one tool ‘out there’ that will work for us. Rubbish. Many tools will help you, though no doubt some will help more than others. The process performers can successfully start with using, say, MS Word if they want…and then continuously improve through their experimentation and learning…where this may take them in many directions as opposed to finding ‘the one tool to rule them all’.

There is no ‘right answer’ when it comes to tools, only a never ending journey to continually improve the efficiency and effectiveness of how process performers know how to carry out their work in the best way currently known for the good of the customer.

Are you currently involved in ‘process mapping’? Is this Déjà vu for you?

Rolling, rolling, rolling…

cheese-rolling1So let’s suppose that we (‘Management’) have come up with (what we think) is a great idea to improve a process. We’ve tried it out in one place (such as a branch/ outlet or a team/ shift or a channel/ brand) and we now want everyone else to change to our new brilliant way.

i.e. let’s do a roll out!

Excellent, so let’s ‘grease those wheels’ by bringing in a ‘change manager’1 who can work out sensible things to make this roll out happen:

  • Let’s ‘big it up’: We’ll prepare fancy presentations (and perhaps some posters for around the office) that explain the change in an up-beat and positive way that makes it sound just great!
  • Let’s deal with the worries: We’ll have a period of consultation, prepare a set of FAQ’s in response, and make small changes to show that we have taken these worries on board;
  • Let’s ‘motivate them’ to want it: We’ll adjust everyone’s balanced scorecard and related objectives, targets and incentives so as to make it ‘front and centre of stage’;
  • Let’s create a launch: We’ll design a competition2 where ‘demonstrated compliance’ with the new way wins prizes for an initial period of time.

…does any (all!) of the above look familiar?

Now to reverse this logic:

Imagine that every team:

  • Understands its capability (against a system’s purpose) and works in an environment that wants to continually improve;
  • …so wants to experiment (for themselves) with new ways of working;
  • …so, as well as coming up with their own ideas (which their environment encourages), is really interested in going to see what other teams are doing;
  • …so brings back new ideas to adjust, try, consider and conclude upon (using the Plan-Do-Study-Act cycle);
  • …so is intrinsically motivated to rolling in new ways of working that they believe in.

John Seddon came up with the label ‘Roll in’ to explain this point. Here are his definitions:

Roll-out: Method that involves developing an improved process, standardising it and applying it to other areas*. This tends to create two problems:

  1. The solution is not optimised for each specific context so it is not a good fit;
  2. The staff in the other units have not been through the same learning and therefore feel little sense of ownership. They may also feel a loss of control and resist change.

(*I note that the much used ‘achieving buy-in’ phrase is synonymous with the ‘rolling out’ phrase i.e. it is actually about someone trying to sell something)

Roll-in: A method to scale up a change to the whole organisation that was successful in one unit. Change is not imposed. Instead each area needs to learn how to do the analysis of waste for themselves and devise their own solutions. This approach engages the workforce and produces better, more sustainable solutions.”

…meanwhile back at Toyota:

You might have heard that a big part of the hugely successful Toyota Production System (TPS) is standardisation3. and you might then make the mental leap to assume that every shift in every comparative production line in every Toyota plant across the world conform to the one ‘standard’ (i.e. the exact same methods). Yet such an assumption would be incorrect.

Liker’s decades of Toyota research makes clear that change is most definitely NOT imposed on the people and their processes. Instead, each unit (at all levels) is set a clear challenge (a target condition ) that aligns with purpose and is then coached through experiments to achieve it. And, once achieved, the cycle starts again.

So a given team on a given line in a given plant will want a standard way of working so that they are very clear on how to (currently) perform a task but this standard may be quite different to another team/ line/ plant.

Key points in this Toyota way of thinking:

  • The challenge that is set isn’t about rolling out some pre-defined solution. The solution is not known. It is up to each team to work out how to get there for themselves (see ‘how to have a successful journey’);
  • Each challenge is specific to each team, taking account of their current condition;
    • A mature plant in Japan would have very different challenges set to a much newer plant in, say, America, even though they might be making the same car model;
  • It is perfectly acceptable for one plant (say) to arrive at a different method of working to another. This is in fact considered a good thing because it keeps people thinking, broadens ideas and sets off yet deeper studying and understanding…fuelling yet more improvements;
  • It creates a desire for collaboration between plants: they are very interested in what others are doing (going to each others ‘Gemba’* ). This is the total opposite to the competitive (and myopic) mentality of ‘Our team’s way is the best way…it must be – we won a prize!‘;
    • In fact, a mature Japanese plant wants to go and see what a newer American plant has come up with because they understand that the ‘newbies’ may have come up with completely different (and potentially step-change) ways of thinking.
  • If a team from plant B do a Gemba walk at sister plant A and sees something of interest, they don’t just go home and implement it! They can’t – because that would just be the ‘plant visit’ team dictating to their colleagues back home. No, instead, they will explain what they saw, experiment, decide whether it is of use to them and, if so, adapt so that it fits for their needs;
    • The original plant A is highly likely to do a ‘reverse’ Gemba walk to see what plant B has done with their ideas…and then rush back home to experiment again….and, hey presto, what a healthy innovation cycle we have!

(* Reminder: Gemba roughly translates as ‘the place where the work happens’)

In short: Seddon didn’t invent the ‘roll in’ idea (Toyota, as an excellent example, have worked this way for decades) but he is very good at putting it into words, giving it a name and passionately championing it.

Looking back, it seems pretty obvious that if people find out about and learn things for themselves then this will be fulfilling and lead to real and sustained successes….which will create a virtuous circle. No such worthy circle exists from ‘stuff being done to you’.

But what about that Iceberg?

Many of you will have been introduced to, and likely read, John Kotter’s well written business story book called ‘My Iceberg is melting’. If you haven’t then it’s about a colony of penguins having to deal with a change being imposed upon them (the clue to that change is in the name of the book!).

Now, if you are having a change imposed upon you, then Kotter’s logic might be very useful to you….but, wow, wouldn’t it be sooo much better if you decided on your own changes!

I think one quote sums much of this post up nicely:

“People don’t resist change, they resist being changed.” (Scholtes)

Be realistic!

“Oh come on Steve, sometimes change is imposed and you’ve just got to deal with this!”

Yes, this is most definitely so. But here’s some counters to this critique:

  • Such a change should be coming externally (such as a legislative, societal or environmental change)…not from within the organisation;
  • Even if such change occurs, it is still better for the organisation to deal with it by setting its people suitable challenges (rather than dictated solutions) and leading them through rolling in changes for themselves;
  • If your people are used to the ‘roll in’ change paradigm then you will have a whole bunch of people who are skilled, creative and motivated problem solvers …just imagine how fantastic that capability would be for an organisation every time the challenge of an external change has to be handled!

…and finally:

Here’s an Ackoff ‘f-Law’ that might resonate with you as a true-ism:

“The only thing more difficult than starting something new in an organization is stopping something old.”

I think we all recognise that the ‘roll out’ problem doesn’t stop with merely getting someone to do something new…

Consider that, in contrast, by using ‘roll in’ the people are choosing for themselves to stop doing the old (whatever that is for them).

______________________________________________________________________

Addendum: I always ask someone (relevant to the subject) to act as editor before I publish. My editors always add great value Here are a few improvements:

  • Whilst Toyota may not enforce the same standard way of working across everywhere, it could be argued that they do have a cross-organisational standard way of thinking and acting (i.e. their management system, which has been termed ‘The Toyota Way’)…but, just like rolling in, this wasn’t copied from elsewhere and dictated to them – it came about through years of humility and experimentation;
  • If you want everyone rolling in the same direction then you still need a very clear (and meaningful) purpose, and systems thinking, such that all challenges being set lead to the same point on the horizon;
  • The ‘corporate form’ (e.g. a public body, private enterprise, large publicly quoted company,…) will likely have a huge impact on where you are now, and where you can get to;
  • You might like the idea of rolling in (as compared to rolling out) and say “yeah, great…how do we get there from here?” This is a BIG question, and just happens to relate to a future post which the ink is drying on….so, with that segue, please tune in again then.

Notes:

  1. Change management within command and control organisations is usually about senior leaders getting people to do what they want them to. Their employment of a skilled ‘change manager’ (of which there are many) may substantially improve the roll out outcomes…but it is still a roll out, with all its associated limitations.
  2. Competitions: Please don’t run ‘change’ competitions like this…or, if you do, know the harm that they cause. Research* shows that: Providing a reward for doing something seriously devalues that thing; and people think even worse of that thing once the reward period has finished, thus likely slipping back to how it was before and then making it that much harder to ‘get them to change’ (* see Alfie Kohn’s book ‘Punished by Rewards’).
  3. Standardisation: Don’t make the assumption that this standardisation principle is exactly the same for service organisations – it isn’t. I use it in this post merely to explain and demonstrate the roll-in principle.

Pulling Power

Beer pumpThere are two very different productivity ideas:

  1. Make as much as you can! …meaning that:
  • you are always busy (it is a ‘corporate crime’ to be idle!);
  • it is irrelevant whether the next activity down the track is already snowed-under with work or even if it is available….you just keep pumping it out! They aren’t your problem;
  • the ‘performance police’ are likely measuring the cost of the activity being performed, and judging you accordingly.

…this reflects a Push system, which fits with an ‘economies of scale’ efficiency mindset (“how many did you make!”).

  1. Make only what is needed when it is needed…meaning that:
  • each person is highly connected to the next activity down the track (because they need visibility of how the next step is going);
  • it becomes immediately obvious if there is a blockage and where it is;
  • the process performers can:
    • collaborate on making improvements at the (now visible) bottlenecks; and
    • see and measure the overall flow, from customer demand through to its satisfaction.

…this reflects a Pull system, which fits with a ‘flow’ effectiveness mindset (“how did we all do together for the customer?”)

Now, you might think that push will cost a lot less than pull because everyone is always working flat out, not waiting to do something….but you’d probably be wrong, and by a profound margin.

What’s so good about pull?

Here’s a simple ‘push’ diagram from the Lean Enterprise Institute to assist:

overproduction-e1351860597383

Stick man ‘A’ is happily making stuff, much to the despair of ‘B’ and, given that a real life process will have far more steps than A and B, you can imagine what this looks and feels like on a bigger scale – organised(?) chaos:

  • work will pile up throughout the process, meaning that there will be loads of ‘work in process’;
  • process steps might be working flat out, but it takes a really long (and usually increasing) time for a unit of work to get from start to (proper) completion. It spends a massive amount of its overall cycle time simply waiting;
  • defects are hidden within this mess, so it takes a long time for them to surface….with the time and cost to rectify the defect rising alarmingly as more work is performed on the defective unit of work;
  • changes in specifications or customer needs whilst units are (a long time) in process mean a huge amount of rework, and even scrapping of work done to date (Customer: “In the time you’ve taken, things have changed….I don’t want that anymore!”);
  • the long cycle times will create a huge amount of failure demand (blue marbles) from customers asking where their unit of value demand has got to and how long it will be.

Is this relevant to Service?

Absolutely! But, like most things, it can be a bit different to manufacturing.

THE big difference in service is that the trigger to start work is pull by default i.e. you can’t make a service in advance ‘and put it into stock’…you need to wait for demand to trigger the work. But, just because we have a customer pulling the demand lever doesn’t mean we should then be pushing their unit along a value stream before the downstream activities are ready for them.

For a really obvious example, let’s take a natural catastrophe (flood, earthquake, etc.), which results in an insurer getting a huge spike of claims demand. The insurer wants to help everyone as soon as they can but they a) are still getting the necessary processes defined ‘on the ground’ and b) have limited resources to do the work.

Now, this is a challenge: Insurers want to be seen to be pro-active and ‘getting on with it’ for their customers. But beware of creating a seemingly good short-term impression at the expense of a huge longer-term mess.

If you push claims through a process that isn’t yet defined and resourced then you can expect to:

  • only partially perform the necessary work, but not realise this;
  • set expectations that turn out to be incorrect (e.g. what you thought looked clearly a house rebuild turns out later to only be a repair…and vice versa);
  • go back and perform a great deal of re-work (ending up in multiple site visits, ‘reconciliations’ with previous findings, defensive explanations and compensatory actions);
  • throw away old work and virtually start again to cope with changing customer circumstances (“I was okay with you doing that 6 months ago…but not anymore”); and
  • lose the trust of the customer (your unintended mistakes are seen by them as malice and trickery)…which creates much failure demand, to be cautiously tip-toed through.

If you hear management say “right, let’s get all the claims through ‘assessment’ by [date x] and then we’ll focus on the next stage”, you know you’ve got push and all its associated problems.

This doesn’t mean that you don’t do all you can to make sure your customer is okay whilst you work things out (e.g. temporary repairs, emergency accommodation) and explain to them what is happening (including what you haven’t got in place yet)…but it is saying pull work through your flow when, and only when, you (& they) are ready for it.

This means that you focus your attention on defining and refining the flow, rather than wasting it firefighting each and every ‘undoing what’s already been done’ disaster.

A specific example for the catastrophe claims scenario: If a builder has a number of house builds on the go, don’t push any more on them (they may very well tell you they can take them!). Instead, allow them to pull the next one only as and when each build is satisfactorily complete. This will mean that the builder is focused on making their build processes effective, rather than trying to stockpile work for the next few years.

Moving on to ‘workflow management’:

Okay, so thankfully catastrophe management doesn’t happen all the time…so what about ‘day to day’ pull in service?

Who works in an area that has a ‘workflow management’ role (or even team) that sorts out work as it comes in the door by briefly looking at what it is, categorising it and then assigning it to people as fairly as they can? This is pushing.

What does this cause?

  • Incorrect classification: As explained in ‘The Spice of Life’, there is huge variation in service demand. It is impossible to properly appreciate the necessary work content until you do the work; which means that…
  • Feelings of unfairness: …it is impossible to fairly divide up the work. This wouldn’t be such a problem if judgement and rewards weren’t hanging on it…but they usually are! This creates a constant tension between the work assigner and the workers; leading to…
  • Dysfunctional behaviour: …people will do what they can to protect themselves. You can read ‘The trouble with targets’ to see the general techniques that people understandably use to survive;
  • Re-working the workflow: So the work has been carefully assigned for the week ahead but Jack’s work is turning out to be slower than expected (Bob’s is easier than expected but he isn’t going to tell you!), and Jill is off sick…this only comes to light mid-way through the week so customers in Jack and Jill’s trays have been waiting in vain. Push requires a constant need to review and re-sort allocations between queues as circumstances (always) change…which is pure waste.

What’s wrong with people pulling work from a central and highly visible ‘pile’?

‘Command & Control’ Manager: “Well, people can’t be trusted to do this can they!”

Counsel: “Eh? Why ever not?!”

Manager: “Well, they will slow down and look for the easy ones.”

Counsel: “and why would they do that?

Manager: “Erm, because of their personal metrics…needed because their performance is being judged…which will affect their linked rewards/awards.”

I hope you can see that this is a classic case of looking past a logical tool/technique (in this case ‘pulling work’) and seeing the root causes within the ‘command and control’ management thinking.

If the team:

  • had a capability measure as to how they are all doing (so that they could see the system, rather than being blinded by personal targets);
  • were being coached, not judged (so that they wanted to improve, not protect, themselves;) and
  • were sharing in their success (so that they wanted to collaborate, not compete)

…then a) designing an initial* pull system could deliver great results and b) the workers would likely look for, and make, continual improvements to it…so that it worked better and better and better.

* don’t try to implement the perfect pull system: let the workers move towards pull through experimentation….but management must remove the constraints that are in their way.

Examples of service moving from push to pull:

In fact we have all felt moves from push to pull. One obvious area has been customers (that’s us) being able to book appointments (pull) rather than being assigned a slot (push). This has happened from medical appointments, through school parent evenings, to home deliveries.

Note that ‘pull’ is actually an ideal, not a tool. You need to think widely (and differently) about achieving it. It isn’t an easy journey…but it’s well worth the effort.

How about this one from John Seddon: When a contact centre agent gets a customer demand that they are unfamiliar with, they should ‘pull’ in the necessary expertise to handle it, instead of ‘pushing it’ to the expert to perform. In this way, the agent is developing on the job and the customer feels that one person is caring for/ owning their need…developing great trust: a win/win.

Pulling is linked with continuous improvement, like an umbilical cord.

Notes:

  • Pull is a key part of the Toyota Production System (TPS), and is the 4th of the 5 ‘Lean Thinking’ principles;  
  • Kanban is a Japanese word and refers to a visual signal (often a card) used to trigger an action. The downstream process provides the kanban (signal) to the upstream process (i.e. it pulls the work along the value stream).
  • You can substitute the catastrophe example used above with any service process where a) the process isn’t yet properly defined and/ or b) a spike in demand has to be handled (i.e. exceeds capacity)

Capability what?

tape_measureReaders of this blog will have likely come across a phrase that I often use but which you might not be too clear on what is meant – this phrase is Capability Measure.

(Note: I first came across the use of this specific phrase from reading the mind opening work of John Seddon).

I thought it worthwhile to devote a post to expand upon these two words and, hopefully, make them very clear.

Now, there are loads of words bandied around when it comes to the use of numbers: measures, metrics, KPIs, targets. Are they all the same or are they in fact different?

Let’s use the good old Oxford dictionary to gain some insights that might assist:

Measure:     “An indication of the degree, extent, or quality of something”

Metric:     “A system or standard of measurement”

KPI (Key performance indicator): “A quantifiable measure used to evaluate the success of an organization, employee, etc. in meeting objectives for performance.

Target:     “An objective or result towards which efforts are directed

So putting these together:

A measure quantifies something…but this of itself doesn’t make it useful. It depends on what you are measuring! In fact, there is a huge risk that something that is easily measureable unduly influences us:

“We tend to overvalue the things we can measure and undervalue the things we cannot.” (John Hayes)

A metric is the way that a measurement is performed – it’s operational definition. There’s not much point in taking two measurements of something if the method of doing so differs so much as to materially affect the results obtained.

KPIs are an attempt to get away from using lots of different measures and, instead, boil them down into a handful of (supposedly) ‘important ones’ because then that will make it sooo much easier to manage won’t it?…I hope your ‘Systems thinking’ alarm bells are ringing – if we want to understand what is really happening, we need to study the system. Any attempts at short-cutting this understanding, combined with the use of targets and extrinsic motivators is likely to lead to some highly dysfunctional behaviour, causing much damage and resulting in sub-optimal outcomes. The idea of ‘management by dashboard’ is deeply flawed.

Targets – well, where to start! The dictionary definition clearly shows that their use is an attempt at ‘managing by results’…which is a daft way to manage! We don’t need a target to measure…and we don’t need (and shouldn’t attempt) to use a target to improve! A target tells us nothing about the system; distorts our thinking; and steals our focus from where it should be.

So what are we measuring?

I hope I’ve usefully covered ‘measure’ and its related terms so let’s go back to the first word: Capability

To start, we need to be clear as to what system we are studying and what its purpose is from the customer’s point of view. Then we need to ask ourselves “so what would show us how capable we are of meeting this purpose (in customer terms)?”

Some important points:

  • Capability is always about meeting the customer’s purpose and should be separate from the method of doing so:
    • An activity measure (i.e. to do with method), such as “how many calls did I take today”, is NOT a capability measure. None of my customers care how many calls I took/made!;
    • Activity measures constrain method (tie us in to the current way of working i.e. “we make calls”) whilst capability measures liberate method and encourage experimentation (“what would happen to our capability if we…”).
  • The best people to explain what really matters to the customer are the front line process performers who help them with their needs (i.e. NOT managers who are remote from the gemba):
    • The process performers know what the customers actually want and whether they are satisfied or not
  • As a rule of thumb, the end-to-end process time from the customer’s point of view is almost always an essential capability measure BUT:
    • end-to-end is defined by the customer, not when we think we have finished;
    • Targets will distort the data that we collect and thereby lead to incorrect findings…so, if you really want to understand your system’s capability you need to remove the targets and related contingent rewards.
  • Other examples of likely capability measures of use are:
    • A system’s ‘one-stop capability’: the amount of demand that can be fully satisfied (as determined by the customer) in one-stop;
    • The accuracy and value created for the customer; and
    • The safety and well-being of your people whilst delivering to the customer

An example:

I am currently moving house. I have to switch the electricity provision from the previous occupants to me. I want this switch to happen as painlessly as possible, I only want to pay for my electricity usage (none of theirs) and I want the confidence to believe that this is the case.

So:

  • The system in question is the electricity switching process;
  • My purpose is to switch:
    • Easily (minimum effort on my part….easy to start the process, no need to chase up what is happening, and easy to know when it is complete)
    • On time (on the switching date/ time requested); and
    • Transparently (so that I trust the meter readings and their timings)
  • I don’t care how the electricity companies actually achieve this switching between themselves (the method, such as whether they use a SMART meter reading or a man comes to the house or…). I just care about the outcomes for me.

The electricity company should be deriving measures to determine how capable they are in achieving against my purpose. They are then free to experiment on method and see whether their capability improves.

I have deliberately used a generic example to make the point about the system in question, its purpose and therefore capability. You can apply this thinking to your work: what the customer actually wants/ needs and how you would know how you are doing against this.

Sense-check: Capability measures are method-agnostic. Think about putting your method inside a metaphorical ‘black box’. Your capability is about what goes into the black box as compared to what comes out and what has been achieved. You can then do ‘magic’ (I mean experiments!) as to what’s inside the black box and then objectively consider whether its capability has improved or not.

What does a capability measure look like, who should see it and why?

Okay, so let’s suppose we now have some useful capability measures. How should they be presented and to whom…and what are we hoping to achieve by this?

The first big point is that the measure should be shown over time*. We should not be making binary comparisons, and then overlaying variance analysis and ‘traffic lights’ to supposedly add meaning to this (ref: Simon Guilfoyle’s excellent blog ).

We want to see the variation that is inherent in the system (the spice of life) so that we can truly see what is happening.

* Note: A control chart is the name for the type of graph used to study how a metric changes over time. The data is plotted in time order. Lines are added for the average, upper and lower control limits – where these are worked out from the data…but don’t worry about ‘how’ – these statistics can be worked out by an appropriate computer application (e.g. Minitab) in the hands of someone ‘in the know’.

Here’s a control chart showing the time it takes me to cycle to or from work:

Cycle time control chart

The second big point is that these capability control charts should be in the hands of those who perform the work. There’s little point in them being hidden within some managerial report!

Here’s what Jeffrey Liker says about how Toyota use visual management:

Every metric that matters…is presented visually for everyone who is involved in meeting the goal [purpose] to see. A key reason…is that it clarifies expectations, determines accountability for all the parties involved and gives them the ability to track their progress and measure their self-development.

[Making these metrics highly visible] is not to control behaviour, as is common in many companies, but primarily to give employees a transparent and understandable way to measure their progress.

Put simply: if the people doing the work can see what is actually happening, they are then in a place to use their brains and think about why this is so, what they could experiment with and whether these changes improved things or not* ….and on and on.

* Looking back at my ‘cycling to work’ control chart: I made a change to my method at cycle ride number 15 and (with the caveat that I need more data to conclude) the control chart shows me whether my change in method made things better, worse or caused no improvement. I cannot tell this from a binary comparison with averages, up/down arrows and traffic lights.

It should by now be clear that a capability measure is about the system, and NOT about the supposed ‘performance’ of individual operators within.

To summarise:

In bringing the above together, John Seddon applies 3 tests to determine whether something is a good measure. These tests are:

  1. Does it relate to purpose? (i.e. what matters to the customer);
  2. Does it help in understanding and improving performance? (i.e. does it reveal how the work works? To do this, it must be a measure over time, showing the variation inherent within the system, and it must be devoid of targets);
  3. Is it integrated with the work? (i.e. in the hands of the people who do the work so that they can develop knowledge and hence improve).

If it passes these three tests then you truly have a useful Capability Measure!

As luck would have it: One of my favourite bloggers, ‘Think Purpose’, released a similar ‘measurement’ post just after I had written the above. It includes a couple of very useful pictures that should compliment my commentary. It’s called A managers guide to good and bad measures – you could print them out and put them on your wall 🙂

A clarification: I’m happy with the use of the word ‘target’ if it is combined with the word ‘condition’. A reminder that a target condition (per the work of Mike Rother) is a description of the desired future state (how a process should operate, intended normal pattern of operation). It is NOT a numeric activity target or deadline. I explain about this in my earlier post called…but why?

So why can’t we do that?!

tesla-factoryI don’t know about you but ever since I was a kid I have loved watching short videos of manufacturing plants and staring in wonder at how the products we take for granted actually get made! It all seems so futuristic and alien.

Here’s a short (4 mins) yet amazing video showing the mind-boggling production of TESLA Model S cars over in Fremont, California.

What do you notice? Here’s what I see:

  • a large, high volume manufacturing plant;
  • an ultra clean and tidy environment;
  • ordered, smooth flow through specialised process steps;
  • consistency of operation and velocity;
  • substantial mechanisation & automation;
  • calm and assured humans working alongside the machines;
  • …with a high quality product coming out the end.

Sounds fantastic, I’ll have some of that!

…so why is it that service organisations don’t seem to get anywhere near the awesomeness that is modern day manufacturing?

Here’s the answer…..because they try to copy manufacturing!

“Hey, that doesn’t make sense…”

Surely (I hear you say) if manufacturing is sooo advanced from the times of Henry Ford and through Taiichi Ohno’s Toyota Production System, then service organisations should be studying what they have done and applying it to their world?

And, indeed, that is what many (most) service organisations have done. But, in doing so, they have spectacularly missed a crucial point: Service is different to manufacturing and therefore they have been ‘solving the wrong problem’.

Here’s a fundamental John Seddon quote with regards to service:

“Service differs from manufacturing. There is inherently more variety in customer demand….Whilst the Toyota method was developed to solve the problem of how to produce vehicles at the rate of customer demand, in service organisations the problem is how to design the system to absorb variety.”

Going back to the TESLA factory, notice how each car being made is essentially the same. Now I know that there is some variety – different colours, different engines, different trim levels – but it is basically the same (modular) product. I also know that Taiichi Ohno’s Toyota Production System brilliantly worked out methods to deliver this limited variety within the one production process (as opposed to requiring separate lines).

Much of manufacturing has adopted the mantra of ‘specialise, standardise, centralise and then automate’….but this is just about the opposite of what would be good for a customer requiring their very specific needs to be met for a service.

Let’s carry on with the car example but move on down the process to the service end – the selling, distribution and servicing of the car.

Let’s assume that TESLA’s competitor, TRAGIC, has applied the manufacturing mantra to their car service processes.

TRAGIC has created a centralised and highly automated ‘contact centre’ and separate ‘service centre’, both of which are broken up into highly specialised teams with standardised processes.

  • you will be directed to a website on which it is nigh on impossible to find out what you need to know, let alone a way of contacting a human being for a conversation;
  • …assuming you do find a contact number, you will then be punished by a multi-layered IVR that doesn’t have an option that meets your specific need;
  • you will have a standardised ‘scripted’ conversation with someone who doesn’t seem to be allowed to help you with your actual needs…but who can transfer you to [insert name of another department here];
  • you will then be passed around a number of specialised departments as they all ‘pass the parcel’;
  • you will be allocated to a ‘back office’ work queue and will have to repeat everything you have said so far to whomever is allocated your ‘ticket’…and they will likely disagree with whatever the person before them said to you along the lines of “oh no, I only do this” or “no, they don’t know what they are talking about, we can’t do that for you”;
  • you will talk with people who have a standard time slot allocated to you (or at least an ‘average handling time’ target), who will ask you standardised questions, categorise you according to limited drop-down boxes in their computer and then allocate you to defined ‘solutions’;
  • you will be confused as to who is actually dealing with you (or who even cares);
  • you will spend time and effort chasing up what is happening;
  • you will be provided with a standardised solution which either doesn’t meet (or only partially meets) your needs;
  • ….you will be forced through the whole sorry process again (and perhaps again) as you struggle to get your actual need resolved.

The Point:

In service, the customer comes in ‘customer shaped’. Our job is to design the system so that it can absorb their variety, not frustrate it.

Beware the manufacturing mantra of ‘specialise, standardise, centralise and then automate’.

Toyota and automation: I know that the TESLA factory looks like it’s been taken over by intelligent robots…but don’t get too carried away with automation in manufacturing. It’s worth noting that:

  • Studies have shown Toyota factories to be significantly more efficient than their competitors despite being less automated;
  • Toyota is wary of ‘over automation’ and has been reported to be reducing/ removing some automation in preference to human beings carrying out the work.

Their rationale? Putting to one side the enormous cost of developing, buying, installing and maintaining robotics, a robot simply does what it is programmed to do. Contrast this with a human that can think about the process they are performing and continually look for ways to improve it.

This can be the difference between static and dynamic processes…but of course this is only relevant if the human is in an environment that motivates them to continually improve what they do.