Yes – the title isn’t a typo. This goes back to KataCon 4 in Atlanta. Though I had attended all of them, this was the first time I actually spoke at one. My task was to follow Rich Sheridan and share why I thought his message was a powerful one for an audience of Kata Geeks even if he wasn’t specifically talking about Toyota Kata in his company.
As an experiment, I took the sound recording from my talk and synchronized it with the slide deck. (That is harder that it sounds, by the way.) As another experiment I am sharing it via hosting on WordPress (the back-end of this site) rather than YouTube or a similar host. It is a little over 13 minutes long, and there is another experiment below it.
How Remote Teams Can Connect Meaningfully – Simon Sinek – March 20, 2020
We are all being pushed into the zone beyond our knowledge base right now – having to rapidly adapt and adjust to different ways of working together.
This morning Craig Stritar forwarded a cool little video to me from Simon Sinek’s YouTube channel. In it Steve Shedletzky, a member of Simon’s team, introduces their weekly huddle – a way that this team, which has been working remotely for years, maintains their connection to one another.
One of the keys here is that this meeting is not a conversation about the business at hand. There are other meetings for that. This one is intended to strengthen the social bonds of the group.
They dedicate 75 minutes a week to this task. The video is a condensed version to give us a taste of their structure.
And it is structure that makes it work. It is structure that makes sure no individual dominates the conversation, and structure that keeps it from becoming the kind of wide-ranging conversation that happens over beer and pizza.
It is structure that gives them the freedom to hear and be heard.
I just got the book, and am reading it now. I think there is going to be a lot of good material to discuss here.
But this post is about a marketing email with an excerpt really resonated with me, and I want to discuss that. I wrote to Dan Heath, and got his permission to use pieces of the excerpt here. (Thank you, Dan)
Management By Measurement = “Ghost Victories”
I have talked about what I call “management by measurement” in the past. In that post I told a true story of a company that placed very heavy emphasis on reducing inventory levels without digging into how that performance was achieved. The net result was a an embarrassed CEO during a quarterly analyst’s call. Not good.
Dan Heath talks about the same thing in Upstream. He calls it “ghost victories.”
[when] there is a separation between (a) the way we’re measuring success and (b) the actual results we want to see in the world, we run the risk of a “ghost victory”: a superficial success that cloaks failure.
The most destructive form of ghost victory is when your measures become the mission. Because, in those situations, it’s possible to ace your measures while undermining your mission.
He goes on to describe a case in the U.K. where the Department of Health established penalties for wait times longer than four hours in the Emergency Departments. And it worked. Wait times were reduced – at least on paper. Then the facts began to emerge:
In some hospitals, patients had been left in ambulances parked outside the hospital—up until the point when the staffers believed they could be seen within the prescribed four-hour window. Then they wheeled the patients inside.
If making the numbers (or the sky) look good is all that matters, the numbers will look good. As my friend Skip puts it so well, this can be done in one of three ways:
Distort the numbers.
Distort the process.
Change the process (to deliver better results).
The third option is a lot harder than the other two. But it is the only one that works in the long haul.
All of this ties very well to Billy Taylor’s keynote at KataCon6 where he talked about the difference between “Key Activities” and “Key Indicators.” It is only when we can get down to the observable actions and understand the cause-and-effect relationship between those actions and the needle we are trying to move that we will have any effect.
To avoid the “Ghost Victory” trap, Dan recommends “pre-gaming” your metrics and thinking of all of the ways it would be possible to hit the numbers while simultaneously damaging the organization. In other words, get ahead of the problem and solve it before it happens.
He proposes three tests which force us to apply different assumptions to our thinking.
The lazy bureaucrat test
Imagine the easiest possible way to hit the numbers – with the least amount of change to the status quo. The story I cited above about inventory levels is a great example.
I can make my defect rates improve by altering the definition of “defect.”
There are lots of accounting games that can be played.
This is one to borrow from Skip’s list – How can the underlying numbers be distorted to make this one look good when it really isn’t?
The “rising tides” test
What external factors would have a significant impact on this metric? For example, I was working at a large company where a significant part of their product cost was a commodity raw material. As the market price went down, “costs” went down, and bonuses all around. But when the market price went up, “costs” went up and careers were threatened and bad reviews issued.
Those shifts in commodity prices had nothing to do with how those managers were doing their jobs, the tide rose and fell, and their fortunes with it.
The question in my mind is “What things would make this number look good, or bad, without any effort or change in the process we are trying to measure?”
The defiling-the-mission test
Hmmm. This is a tough one. (not really)
And it is a really common problem in our world of quarterly and annual expectations. In what ways could meeting these numbers in the short term ultimately hurt our reputation, our business, in the long term?
For example, I can think of an ongoing story of a product development project that hit its cost and schedule milestones (what was being measured). But they did so at the cost of destroying their reputation with customers, their Federal regulators and the public (and, to a large extent, their employees). They now have a new CEO, but the deeper problem has origins in the late 1990s.
How long will it take them to recover? That story is still playing out.
In another case I was in a meeting with a team that was discussing a customer complaint. The ultimate cause was a decision to substitute a cheaper material to reduce production costs. But this is a premium brand. There was a great question asked there: “Which of our values did we violate here?” – so the introspection was awesome.
Next step? Ask that question before the decision is made: “Is this decision consistent with our values?” If that makes you uncomfortable, then time to look in the mirror.
Then there is this little incident from 2010:
BP Deepwater Horizon fire – Photo by USCG
The metric was cost and schedule. Which makes sense. But the behavior that was driven was cutting corners on safety.
Getting Ahead of Problems
The book’s subtitle says it is about getting ahead of problems. I am looking forward to reading it and writing something more comprehensive.
Continuing my breakdown of Billy Taylor’s opening keynote at KataCon…
Key Bullet Points
People follow what you do before they follow what you say.
If you (as a leader) think you are above the process…
Deliberate practice on your practice of leadership. Focus on one thing.
Break down your leadership style [into elements]. Practice deliberately on one thing you want to reinforce or improve.
That second bullet is a real challenge for those of us who are in leadership positions (or even positions of influence). “If you think you are above the process…” – do you follow the standards and expectations you ask of others?
I think a good test would be “If a production worker corrected you, how would you respond?” If your internal emotional response (that initial feeling you have, not how you show yourself) is anything other than “Thank you for reminding me” then you are exempting yourself from the rules.
The other take-away:
Throughout his presentation, Billy was tying together the idea of “deliberate practice” and “developing leadership skills.” Leadership is a process, and processes can be broken down into their constituent elements and practiced.
This ties back perfectly to a broad spectrum of leadership development models. In the end, what we can control are:
What we say.
How we say it.
Who we say it to.
The structure of the environment that either inhibits or encourages the behaviors we want.
All of these things can be developed through experimentation, and then practiced. This is what Toyota Kata is about.
One of the artifacts of Extreme Programming as practiced by Menlo Innovations is the Story Card. In the purest sense, a story card represents one unit of work that must be done by the developers to advance the work on the software project.
But the content and structure of the story card make it much more powerful than a simple task assignment. The story card is written in a way that engages the programming pair doing the work.
Before a story card is created the team works very hard to identify the primary persona that represents the human being who most benefits from their work. That persona gets a name, a face, a biography. She has wants, needs and aspirations.
(c) Menlo Innovations. The primary persona is shown in the center of the target. There are two shown in the second ring, and three in the third ring.
Why? A couple of reasons.
First, it establishes priority of effort. In software development compromises must be made between optimizing the interface and workflows for various users. By identifying the primary persona, the team says “This person’s use of the software will be optimized.” Other users will certainly be accommodated, but any compromise will break in favor of the primary persona.
Menlo, for one, works very hard in the up-front design process to smoothly integrate the workflow created by their software into the larger context and workflow that their end-user is trying to carry out.
The other effect is more subtle. It humanizes the “user” as the developers are talking about what their code does, or does not, do.
Rather than simply set out a feature in an abstract way, the story card focuses on granting an ability to the main persona. The process of creating the personas, and developing the persona map humanizes the group of people that would traditionally be thought of as “the users.”*
Thus, the feature would be described something like this:
“Sara is able to select her choice of color from a pull-down menu of options.”
Then the developers write code that enables Sara to do this, quickly and easily.
This is a simplification, but it suffices to set up my main point.
Who Are You Optimizing Your Improvements For?
Let’s translate this thinking into our world of continuous improvement.
Who is your key persona? Who are you enabling with your process improvement? What will this person be able to do that, today, he cannot?
Rather than saying “The lowest repeatable time does not exceed 38 seconds” as a target condition, what if I said “John is able to routinely perform the work in 38 seconds when it is problem-free.”
I don’t know about you, but I feel a lot more emotionally engaged with the second phrasing. This is doubly true if John is an actual person actually doing the work.
What about scaling to other shifts, other operators?
Yup. I agree that at some point your target condition is going to shift to “Any trained team member” but what I tell people today when they are trying to go there first is this:
“If you can’t get it stable with one person, you are never going to get there with multiple people.”
You have to get it to work once first. Then introduce the next layer of complexity. Start simple. One step at a time. Control your variables.
I have been experimenting with this linguistic shift in my Toyota Kata classes and consulting.
If you are in R&D this is an even more direct application back to Menlo’s model.
Training = Giving People Ability
I also ran an experiment with a client HR team that was charged with developing a comprehensive on-boarding training process.
Rather than do the traditional thing, which is take the laundry list of topics they are supposed to try to cover, and trying to figure out how to stuff everything into the time they have been given (40 hours, which is really more like 35 hours), I asked them to experiment with the following:
For each skill they have been asked to train, write it on a separate 5×7 card in the form of “[The learner] is able to _________.” In other words, describe the skill as an ability that someone is able to demonstrate.
Then determine how they will test that skill. Do that before they even think about how they are going to teach it.
Then develop training experiences and exercises that they believe will allow the learner to pass the test.
Software developers will recognize this as “test driven development” – start with the unit test, then write the code.
Testing Your Target Condition
As in the example above, a target condition should also be testable. By stating what we will observe or measure when the target condition is met, we are constructing a “unit test” of sorts.
By stating what we will observe or measure first, we can separate “solved” from “the solution” and open up the possibilities of what solution(s) we will experiment with.
—————–
In the culture of many more traditional software development and I.T. organizations, “users” can be almost a derogatory term, with an implied, usually (but not always) silent “dumb” appended to the front. We write Books for Dummies so they can understand our brilliant systems.
I have been telling everyone who will listen to read Rich Sheridan’s book Joy, Inc. ever since I came across and read it in the fall of 2015.
Fast forward to earlier this year when Lean Frontiers sent out their request for suggested keynote speakers for KataCon. I wrote to Mike Rother and asked him “Do you think we could get Rich Sheridan?”
Skip ahead a bit more, and I spent four days last week at Menlo Innovations in Ann Arbor – two days “in the chalk circle” paying close attention to the actual day-to-day work there, and two days working (pairing) with Rich Sheridan to work out the key beats for his KataCon keynote.
The “So What?” Test
Menlo is well known as a benchmark for a great working culture. But the question you may be asking (and, honestly I hope you ARE asking it) is “What does Menlo Innovations and agile software development have to do with Toyota Kata?”
If you visit Menlo (and I really hope you do!) here is what you won’t see:
Learner storyboards.
“5 Questions” coaching cycles.
Obstacle parking lots.
Experiment Records (PDCA Records)
In other words, you won’t see the explicit artifacts that characterize an organization using Toyota Kata to learn how to think about improvement scientifically. In that sense, Menlo isn’t a “Toyota Kata” benchmark.
OK… and?
You don’t see those things at Toyota either. You don’t go to Toyota to see “Toyota Kata.”
The Underlying Thinking Pattern
What you will see (and hear… if you pay attention) at Menlo Innovations is an underlying pattern of scientific thinking and safe problem solving in everything they do.
Let’s review what Toyota Kata is really all about.
Rather than re-writing something elegant here, I am going to quote from my part of an email exchange between Mike Rother, Rich Sheridan and me:
Going back to Mike’s original research premise, we knew that Toyota has this pretty awesome culture thing, but didn’t really understand the “secret sauce” of the exact structure of their interactions. Put another way, we saw and understood all of the artifacts, but copying the artifacts doesn’t copy the culture.
Mike’s research was really the first that dug deeper into the interactions that the artifacts support.
Once he extracted that “secret sauce” he then boiled off all of the other stuff, and what remained at the bottom of the pot was the Improvement Kata steps and the Coaching Kata steps.
In practice at Toyota, those things are deeply embedded in the artifacts. Sometimes they aren’t even spoken.
My informal hypothesis was that if I spent time paying attention to, not just the artifacts, but the way those artifacts guided interactions at Menlo, and then boiled off the other stuff, what would remain at the bottom of the Menlo pot would also be the Improvement Kata and Coaching Kata steps. And, though I didn’t do this formally, and yes, I had confirmation bias working here, I believe I can safely say “I have no evidence to contradict this hypothesis.”
For example:
In our conversation on Friday, Mike pushed back a bit on “just run the experiment,” [context clarification: Experiments to randomly try stuff, without a clear target condition rarely get you anywhere] but the reality I observed and heard was that “purpose” (challenge and direction) and “current condition” are deeply embedded in the day-to-day interactions, and “just run the experiment” is, indeed, working on a specific obstacle in the way of a target condition of some kind.
[…]
“What problem are you trying to solve?” is Menlo jargon that I overheard many times just listening to people talk.
Within Menlo, that term is contextual. Sometimes it is about the higher-level direction and challenge.
Sometimes it is about an intermediate target condition.
Sometimes it is about an immediate problem or obstacle.
As we say in Kata world, it is fractal. It is truly fractal at Menlo as well, to the point where the words don’t change at various levels.
The words DO change at various levels in Toyota Kata’s jargon, but we can’t get hung up on the terms, we have to look at the structure of problem solving.
Menlo’s co-founders already had this thinking pattern, and deliberately sought to embed it into the culture of the company they were starting. There wasn’t really any need to explicitly teach it because they weren’t trying to change the default behavior of an organization. New Menlonians learn the culture through the interviewing and on-boarding process and adopt very quickly because the very structure of the work environment drives the culture there.
In fact, spend any time there even just hanging out, and it is very difficult NOT to get pulled into The Menlo Way. Like everyone else, Rich and I were in the daily stand-up as pair-partners, reporting our work progress on his keynote.
What About Toyota Kata?
Menlo has had hundreds (thousands, actually) of visitors, and those who are “lean savvy” all ask if Menlo is “using lean” as their guideline. The answer is “no, we are just trying to solve problems.” While they have certainly incorporated most of the artifacts of “agile software production,” the purists push back that they aren’t “really doing it” because they didn’t copy those artifacts exactly. Nope. They used them as a baseline to solve Menlo’s problems.
When we see an awesome problem-solving culture, it is tempting to try to reverse engineer it by copying the physical mechanics, such as heijunka boxes (work authorization boards), kanban, “standard work” and the like.
But we have to dig down and look at the routines, the behavior that those artifacts and rituals support. When we do, we see the same patterns that Toyota Kata is intended to teach.
You need to begin with the thinking pattern. Use Toyota Kata to learn that.
As you do, take a look at your artifacts – the procedures, the policies, the control mechanics of your work. Reinforce the ones that are working to create the kind of culture you want. Challenge the ones that are getting in your way. Do both of those things as deliberate experiments toward a clear vision of the culture you want to create.
That is the benefit of studying companies like Menlo.
I hope to see you all at KataCon, hear what Rich has to say to our community, and establish a link between these two communities that have, up to now, been separate.
An organization’s culture and mindset evolve over time. When confronted with a problem or challenge, the organization (or more accurately, the people in the organization) view it through a filter of their experiences. Ideas that they believe have worked for them under past similar conditions are more likely to be applied again. Ideas that have seemed less successful, or more difficult, in the past are less likely to be applied again.
Over time, this collective experience determines how they respond to the day to day rough spots as well as more serious challenges. Those unconscious biases drive the responses, and in turn, shape how their processes are structured.
Different Cultures = Different Ecosystems
The process mechanics in a company like Toyota evolved over decades in a very specific organizational culture ecosystem, with specific values and beliefs shaped by their historic experiences.
When we are looking at the current processes in a different company, we are seeing the process mechanics that evolved in their management culture. Those process mechanics are optimized by the pressures that are exerted by the way THAT company is managed. Since Toyota is managed differently, its processes are optimized by different pressures, so will look different.
If we take Toyota’s process mechanics and shift them into a different ecosystem, they will have the different pressures exerted upon them. Different default decisions will be made. These alien process mechanics will likely begin to resemble the legacy processes rather quickly, if they survive at all.
This is why the promise of a rapid and dramatic change in operational results is frequently unfulfilled. The process mechanics are imported from a tropical rain forest, and installed in an alpine meadow. As beautiful as it looks in one environment, it won’t stand for long in the other.
Adjusting the Culture vs. Adjusting the Process Mechanics
If we want this transplant to work, we have to pay careful attention to those evolutionary pressures. In practical terms, this means we try the new mechanics, we must watch carefully to learn what problems they reveal. We also need to observe the decisions that are made when these problems come up.
What adjustments need to be made in the way people interact, and to the immediate response to problems or surprises if this new process is to thrive?
Having a formal structure for this deliberate self-reflection is critical.
The Improvement Kata is engineered to specifically drive this kind of reflection by making changes as experiments, then deliberately reflecting with the question “What have we learned?”
For this to work, of course, we must be honest with ourselves and not just issue a flip answer like “It doesn’t work.”
Because we are asking people to adjust their responses, we are asking them to do things which are unfamiliar and may well run opposite from what they have experienced as successful for them in the past. If we try to move too fast, we are asking them to trust an alien process which is, in their experience, unproven in their environment. We might be asking them to reveal their own limits of knowledge – which is very scary for most of us.
That, in turn, asks for reflection on why “I don’t know…” is so scary to admit in the organization’s culture.
We have sold “lean” as a deceptively simple set of common-sense process mechanics with the idea that if we just implement them, we’ll get incredibly great results. As true as that is, “just implement them” is a lot harder than most of the “rapid improvement” models imply.
There is a lot going on behind what appears to be well understood and simple on the surface.
Take a look at this cool video from Space-X that highlights all of the failures that preceded their successful (and now more or less routine) landing of a recoverable orbital booster rocket. Then let’s discuss it a bit.
When we see failure, or even failure after failure, it is easy to forget that learning is rarely linear.
A Culture of Learning
Organizations like Space-X (and their counterparts such as Blue Origin) are in the business of learning. They are pushing the edges of what is known and moving into new territory. For organizations that understand that setbacks, mistakes, failures and the like are an inevitable part of learning, these things – while costly and unpleasant – are regarded as part of the process.
We have seen the same mechanisms in play – a process of experimentation toward progressive target conditions toward a visionary challenge – behind pretty much every breakthrough achievement throughout history.
No Mistakes = No Learning
At the opposite end of the spectrum are organizations with no tolerance for mistakes. They expect everything (and every one) to get everything right every time. They dismiss as incompetent any notion of failure, and attack as weakness any admission of “I don’t know” or “I don’t know how.”
A few years ago, as I was teaching Toyota Kata coaching with a client, a middle manager approached me during a break and said – point blank – that it was not his responsibility to develop his people. “Our policy is to hire competent people, and we expect them to be able to do the job.” He wasn’t the only one to say that, so I built the impression that this belief was, indeed, part of their culture. Needless to say they struggle a bit with getting innovation to happen because they try to mechanize the process.
Mistakes = Tuition
Here’s how I look at it. When a mistake happens – especially one that is expensive – you have paid considerable tuition. Your choice now is to either extract as much learning as you can from the event, or to try to ignore it and move on. The later choice is like paying your tuition up-front, then skipping all of your classes and wonder why you aren’t getting it.
Learning = Adapting to Change
Organizations that manage in ways that regard learning as part of their everyday experience are much more adaptive to changes and surprises than those who just execute their routines every day. The paradox here is that organizations who value learning are generally the most disciplined at following their routines. This discipline makes execution a hypothesis test, and they can quickly see when their process isn’t appropriate and adapt and learn quickly as an organization. They strengthen their routines, and through those routines, embed what they have learned in the organization’s DNA for future generations.
Organizations that figure it out as they go, on the other hand, tend to rely on individuals to adapt, but there is no mechanism to capture that learning beyond the individual or small group. Sometimes there is a “lessons learned” document, but that’s it. Those reports rarely result in the changes in organizational behavior that reflect learning. I suppose the most egregious case would be the loss of the space shuttle Columbia upon re-entry for exactly the same organizational failures that resulted in the loss of Challenger.
Technical vs. Cultural Learning
Space-X is solving a technical problem with science and engineering. I hope (and expect) that as they become more successful they will always be striving for something really hard that will drive them to the next level. Based on what I see publicly, I think that is embedded into their culture by Elon Musk. (But I don’t really know. If anyone from Space-X is reading this, how about getting in touch? I’d love to learn more.)
I expect this works for Space-X because they have a culture of learning.
What doesn’t work, though, is to try to apply technical solutions to transition a rote-execution culture into a learning culture. Changing the culture – the default behaviors and responses of people as they interact – isn’t about improving the mechanics of the work process. You certainly can work on the work processes, but the starting condition is what evolved in the context of the organization’s culture. The mechanics of the “improved” process that we try to duplicate evolved in the context of a learning culture. The ecosystems are different. It is difficult for a lean process to survive in a culture that expects everything to run perfectly and doesn’t have robust mechanisms to turn problems into improvements.
Occasionally I get an email from someone who asks a question like “How can I improve cycle time in the [fill in the blank here] industry?” Generally my reply is along the lines of “I don’t know, but I can help you figure it out.” I’ll give them some homework, often pointing them at Mike Rother’s Toyota Kata Practice Guide online, and asking them to do the Process Analysis step and get back to me with what they have seen and learned.
Who was that masked man?
This is usually followed by silence (cue the crickets here). Perhaps they think there is an easy answer and a single email can just tell them what to do to get that 20% performance improvement.
Unfortunately it doesn’t work like that. Process improvement involves work. There aren’t easy fixes (that last). There isn’t any solution anyone can give you that can just be implemented, nor can anyone learn it for you.
The real work is adjusting your culture
Digging a little deeper, if you want that productivity improvement to reach even a fraction of your full potential or sustain for any length of time, you have to go beyond technical solutions. When I said process improvement involves work, the technical mechanics are the easy part. The real work is understanding what social and cultural norms in your organization are holding you back and dealing with those.
Fortunately we have learned a lot more about the influence of the organization’s culture and how to influence the culture. But influencing the culture doesn’t happen by accident. And you can’t outsource your own thinking, reflection and learning.
If an organization wants to encourage learning, they have to get comfortable with not having all of the answers. Learning only happens when we discover something we don’t know, and then actively pursue understanding it. Many organizations, though, equate “having the answers” or “already knowing” with “competence.” Thus, if I say “I don’t know” then I am setting myself up for being regarded as incompetent.
What I see in these organizations is people will take great pains to hide problems. They will try very hard to figure things out, but do so in the background always reporting that everything is going fine. They live in the hope that someone else’s problem will emerge as the show-stopper before theirs does, and give them the extra time to sort out their issue.
Meanwhile, the bosses are frustrated because people aren’t being truthful with them. But what should they expect if “truth” attracts accusations of being incompetent?
But… there is hope.
I was talking to a friend last week who works in a huge company that seems to be making an earnest effort to shift their culture. There is nearly unanimous agreement that the existing culture isn’t working for them. On the other hand, actually changing culture is really, really hard because it involves changing people’s immediate, habitual responses to things.
Nevertheless, I was encouraged when my friend recounted a recent meeting where someone admitted two things:
There was an unexpected problem that came out in a recent test.
They, right now, don’t know how to fix it.
Just to be clear, these two things coming out in this meeting is a big deal. This has been a culture where unexpected problems have not been warmly received. Bringing them up without a confident assessment about a prospective solution was inviting the kind of intervention that is rarely helpful.
This time, though, was a little different.
The leaders started going down the expected responses such as “What do you mean we don’t know what to do?” then… stopped short. They paused, and realized this was not in line with their newly stated values of creating trust and accepting failure as an inherent part of learning.
And they changed their tone. They shifted the conversation from trying to assign responsibility blame for the test failure toward asking what we, the organization, needed to learn to better understand what happened.
My thoughts are:
Kudos to the person who was brave enough to test the waters and admit “I don’t know.”
