Utility

This week, I had two of the critical conversations in the kata deployment. These were go and see experiments because my conversations were only elicitations of the impressions of my interlocutors. I wasn’t trying to see what would happen if I introduced a conversation into the process of management. I wasn’t trying to change their minds, but see how the current state of their minds reacted.

I showed the simple block diagram. It looks something like this:

Inputs Process Outputs
Difficult decisions Choose the decisions that will take the longest to answer (leave the easier ones for later).  Improved questions
Ideas of plans Draft a clear attempt at an answer, preferably a diagram with explanatory notes. Answers
Preliminary drawings Distribute it to the team members. Ask them to scrutinize it and ask questions. Plans
Impressions of obstacles Answer all of the questions that you can.  
Impressions of questions

For the questions that you can’t answer clearly, do research, or experiments, and find the answers.

Do coaching cycles on these research cycles.

 
Known hindrances Update the document with those revised answers.  
Known questions

Repeat these steps until the document can bear the scrutiny of a core set of team members. It’s not that everyone has to agree. It’s that the answers to questions must be defensible. The kata coach should be in these conversations, and look for indications that the interlocutors are making arguments and claims outside of their knowledge threshold. She should document these arguments and claims as obstacles and discuss them with the learner after the meeting. 

They should do more experiments (PDCAs) on these arguments and claims.

 
  Don’t even try having difficult technical conversations without a drawing or technical document in front of the members.  

Of course this process isn’t guaranteed to produce consensus, but lack of consensus isn’t what been plaguing us. It’s a maelstrom of vagueness. Of arguing past one another. Of groundhog day debates. Klinkenborg’s diagnosis comes to mind: people want so badly do be done, that they don’t focus properly on doing. They want the decision made. They “don’t want to argue.” They commit to an idea for a day, then the next throw their hands up, claiming indifference. 

I predicted tepid assent; instead, the idea received enthusiastic support. Why? What did I learn?

In a coaching cycle with my boss, he asked me, and we came to a different conclusion together than I had before the cycle. My conclusion had been something like bafflement. Sometimes people are excited by the same ideas that I am, sometimes they aren’t. Who knows why. His impression was clearer and probably more accurate.  

The question I’m trying to answer is not how to apply Lean principles to the work we’re doing (a question that’s interested me for years). The question I’m asking is, how can we overcome the most daunting obstacle before us? Also, at present, the team members’ descriptions of the obstacle are remarkably convergent.

My thinking, and consequently my presentation, emphasized how our problem could be addressed, instead of how my preferred technique could address our problems.

Is this learning, precisely? It seems more like the application of some general principles. Maybe it’s more like practice. I didn’t learn the principle. But maybe I’ve developed some experience in applying it. 

I think what I’m seeing is that  we (meaning, people in general) want to see precisely how a technique can help us solve our most pressing problem, not hear how, in principle, a methodology can justifiably be applied to a family of problems. Because the core team has been experiencing real grief, sitting in the same long meetings, and I have been trying specifically to reducing this suffering, the resulting ideas were more interesting to my teammates. As Rother would say, I’m focusing on the  one obstacle that we need to solve now. Not picking out the problems that I think I know how to solve. 

Rules

The Epictetus quote that I have recited the past several mornings is,

“Whatever rules you have adopted, abide by them as laws, and as if you would be impious to transgress them; and do not regard what anyone says of you, for this, after all, is none of your concern.”

What does it mean? First, it implies that you should adopt rules for yourself, and that you should do so very carefully. You wouldn’t pass laws that you didn’t think that you could follow. You wouldn’t enter into a religion the gods of which set impossible standards. So think your rules through.

It implies, also, that you should have a process for adopting rules. Use a process of experimentation on any  rule before adopting it. You should also have a process for eliminating a rule that, because of changing circumstances, is no longer serving its intended purpose. Only remove a rule from your list when you are calm, and not at the precise time that you are supposed to be following it. You never want to set yourself up for failure by having the option of abolishing the rule on the spot.

What does it imply that you should do when you transgress a rule? Should you flagellate yourself, or put yourself behind bars? No, but you should think hard and make serious plans to ensure that you don’t transgress it again. Ask yourself what you should do. Transgression should be a prompt for reflection. What was your intention when you adopted the rule? What outcome does it assist you in achieving or avoiding? Why did you transgress it? What, mentally, was going on at the time? What externally? What, done differently leading up to the event, would have prevented it? What about precisely when it occurred? Were there negative practical repercussions? What did you do about those? What should you have done? 

I use the mental technique of going back and visualizing myself not transgressing the rule. I play the scene leading up to it just as I remember it, but when it comes to the critical moment, I make the right decision. If I transgressed any rules that led to this one, then I correct those in the memory, too.

If there are behaviors that I engaged in that made me more likely to transgress the rule, I run another visualization in which I engage in safer behaviors. 

How do I know when a rule applies? As always, practice. When I lie down at night, and when I hear the alarm in the morning, I perform a simple exercise. I have a rule for going to bed and for getting up, and its primary purpose is to remind me to identify situations in which a standard applies, and to apply it:

  1. I put my thumb to my first finger, and ask questions like: what’s the standard (rule) for this behavior? (Or, when I’m trying to achieve such and result, what’s the process? Or, when such and such occurs, how do I respond? What’s the output standard? Are there input standards?)
  2. thumb to second: do it.
  3. thumb to third: what was the result? Did my performance (process) match the standard? Did my product (output) match the standard? Did the inputs meet their standards? If they didn’t, what did I do about it?
  4. thumb to fourth: do the standards need updated, or are they still correct?

This takes less than 10 seconds. By practicing it before going to bed, and right when I wake up, I ingrain it.

When I’m performing an action for which I can’t think of a standard, but suspect that I should develop one, I perform the hand mnemonic in reverse:

  1. thumb to fourth (finger): what am I trying to achieve? What don’t I understand? What question is most relevant? What experiment can I perform? What is my mental model of this situation? Can I make a prediction based on it? What do I predict will happen if I perform such and such?
  2. thumb to third: do it.
  3. thumb to second: what did I see? What is the data? What did I predict would happen? What actually happened. (Obviously, this is an adaptation of Mike Rother’s language.)
  4. thumb to the first: what can I extrapolate from this? Can I create a standard (a rule) from what I learned? Do I need to do additional experiments? What else do I need to learn? 

These are the SDCA and the PDCA.

As an aside, in his new book Mike Rother observes that PDCA remains jargon, and we’re probably better off using common terms like prediction→ test → data → evaluation. Think about it. Shewhart developed the PDCA as a specific industrial application of the scientific approach. Over the years, we’ve expanded its use to include all kinds of empirical modalities. So why not just go back to the plain language of science and empiricism? 

Also, when I break a rule, my primary technique for addressing it is asking myself questions about the situation. I’m not particularly hard on myself, because I know that if I make the process too unpleasant, I could lapse. Sustainability is the priority. I favor honest assessment over strict adherence. I seem to answer honestly when I ask questions about my adherence to my rules. And assertions are more impactful when they are framed by a question. 42.