Personal tools
You are here: Home Weblog Talk To The Hand
Document Actions

Talk To The Hand

Most of us have learned that we should be very careful in how we respond to ideas brought to us by others. As might be expected the presence of a conflict is responsible for the need for care in handling such situations. In this article I present the conflict -- as I understand it -- that Eli recognized so long ago. My hope is that by learning how to respond much better to ideas from others we can avoid wasting the many opportunities that surround us -- if only we will do the work necessary to seize them.

Talk To The HandMany years ago my oldest daughter once told me to "Talk to the hand, 'cause the face ain't listening."  It caught me by surprise, but pretty quickly, everyone in the house was having fun with it.

The saying is terribly out of style now, but knowing how to respond appropriately to other people's ideas is -- in my view -- a critically important skill.

Further, I have been writing about Opportunity Wasting Behaviors recently.  I am continuing that thread today. In my view one of the ways in which organizations -- and individuals -- waste opportunities available to them is by being horribly ineffective in responding to ideas from others.

Many of you will have seen the Goldratt Satellite Program tapes.  On tape #7, Eli describes how a conflict -- a dilemma -- often causes us to respond poorly to ideas brought to us by others for consideration.

On the GSP tape, Eli presents a CCRT that describes how we often react poorly when people bring ideas to us for evaluation and, frequently, seeking permission to implement them.

Responding To An IdeaFigure 1, below, is an Evaporating Cloud diagram of the conflict.  I have used my own words here, so if there is an error, it is mine rather than Eli's.

In text, this cloud could be read as follows: "When someone brings me an idea, I want to respond in the best way.

To respond in the best way, one of the things I must ensure is that my relationship with the inventor is protected.  And in order to protect this relationship, I have to be avoid raising the issue of negatives that I perceive as following from the implementation of the idea.

On the other hand, in order to respond in the best way, I must also protect the system in which the idea will be implemented.  To protect the system in this manner, I must raise negatives that I believe will follow if the idea is implemented as is.

And so, I'm in a dilemma.  I have to both raise and not raise the negatives that I perceive as following from the implementation of the idea.  And clearly, I can't do both."

On the video, Eli appears to challenge an assumption on the conflict arrow (the D-D' connection).  That is assumption is "We can't do both."

In fact, we can. 

Breaking this conflict begins with giving the inventor (the person bringing the idea) what they are seeking -- praise.  But understand this very carefully.  There is a world of difference between "plastic politeness" and genuine praise.

Then, once the inventor knows that he has been heard he is emotionally able to listen to a proper response to the idea.

The response to the idea has to be carefully crafted and based on cause-effect logic.  So, shooting from the hip is out for most of us (certainly for me.)  Much better to develop the negative branches that you see in the privacy of your own office.

Once the negative branch(es) have been built, it's time to schedule a meeting with the inventor to communicate them.  But again, it's not just a matter of dumping a bunch of logic twigs on the inventor and then bailing out.  The goal is to really prepare the inventor to understand your concerns.

In this article I can't give you the full logic that Eli develops on the GSP tape.  There are many subtle aspects to this subject matter and to "get it" you should view the tape (probably several times) and/or work with someone that really understands it.

Let me now get to my larger point, however.

Once you understand this aspect of TOC, you look at situations in an entirely new light.  It's another of the many paradigm shifts that we must make in order to fully exploit the many opportunities that surround us.

For example, consider in the software world the humble code review.  In many companies, developers cannot commit code to a shared development branch or view without first having another developer inspect or review the code.

Have you considered that a code review is, essentially, one developer saying to another developer "I have an idea.  Let's change our code to work like this."

In code reviews, design reviews and other meetings where one engineer is sharing a set of ideas with other engineers, the dynamics Eli describes on tape #7 are fully in play (in my view.)

Is it any wonder that when we attend these kinds of meetings we often find ourselves both wanting and not wanting to comment on some aspect of the proposal?  If so, we are experiencing the conflict that Eli has identified.

There are many other ways in which people suggest ideas to others.  For example, when someone sends their resume to someone else, it's a way of saying "I have an idea.  Let's explore whether we might be able to do business."

Finally, I want to tie all of this back to the idea of Opportunity Wasting Behaviors.

Not knowing how to properly respond to ideas from other folks is a guaranteed way to waste opportunities.

As Eli shows, responding to someone's idea in the common manner often leads to hard feelings on the part of both parties.  And when that happens "Kiss goodbye real collaboration."

So let me close with this recommendation.  Take the time to learn how to respond to the ideas of others the TOC way.  It's more work than what you're doing today, but it's far more effective in the long run.

And it's all about the long run.

_____
tags:
Sunday, March 18, 2007 in managementproblem-solvingtheory-of-constraintsworklife  | Permalink |  Comments (0)

del.icio.us   Digg   Yahoo   Google   Spurl

Powered by Plone CMS, the Open Source Content Management System

This site conforms to the following standards: