Dangerous Change Efforts LO15196

Michael Gort (gort@mail.com)
Thu, 2 Oct 1997 10:48:16 -0400

Replying to LO15168 -- was: "A Process is a Process - NOT!"
[Subject line changed by your host...]

Lon Badgett wrote, in response to a post from Benjamin Compton:

"Ben, I don't think you have enough faith in the longevity of great
discussions or their ability to lead somewhere. For instance, thanks to
you, the discussion about Novell just reached all of us - and I think we
are all richer for it."

Ben's comments had reflected his frustration (my word) concerning a
discussion at a dinner about the lack of common understanding among
co-workers about company values. He also said "That started quite a
discussion. Unfortunately I was not in a position to do anything about it.
It was a great discussion that lead absolutely nowhere."

Lon,

I think I hear and understand your point. I hear you saying that Ben may
have been frustrated that the conversation did not go anywhere because it
did not cause apparent immediate change in his company, but hat it did
mean something, perhaps on several levels. First, it seems to have led to
some reflective learning on Ben's part, thus contributing to his personal
mastery. Secondly, it has led to some reflective learning on some
reader's of the LO list, thereby further enhancing personal mastery and
perhaps building some shared learning and understanding among this
extraordinary learning community. Most subtly, it may even have led to
something inside of Novell. One thing about starting strategic
conversations is that they have a way of continuing and growing, sometimes
deeply "undercover", and may ultimately lead to significant changes in the
system at Novell. A problem, however, is the length of the delays between
the initiation of these conversations and the very strong balancing loops
that kick in to inhibit lasting change in the organization.

Ben and I have been caring on a private discussion about what has happened
to each of us as we worked in transformational roles in our respective
companies. Ben's post therefore spoke very eloquently to me to the risks
inherent in leading transformational efforts at companies where the
corporate culture is not like HP or Harley Davidson. In my company, the
culture was brutal on change efforts, the system had hundreds of feedback
loops designed very carefully, even if tacitly, to quickly isolate change
efforts, send out the corporate white blood cells and quickly eradicate
the source of the change "infection". Over a six month period, we
initiated some simple but powerful project management and group dynamic
efforts that were in fact transforming the way our engineers, service
professionals and internal customers interacted. Unfortunately, there was
at least one balancing loop that had a threshold so that while we seemed
to be making progress at an increasing rate, we discovered that one of the
balancing loops had a threshold. Once we went over the threshold, the
balancing loop was like hitting a wall. Ninety days later, virtually the
entire quality and process improvement team has been terminated, has left
or has been reassigned and in another 30 to 60 days will all traces of the
effort will be gone. Was our effort perfect? Hell no, we made lots of
mistakes, and learned from all of them. Was our effort beneficial? Well,
our Division Manager felt it was, our CEO thought it was and the senior
managers of our largest internal customers all supported the activity. So
why the sudden demise? My theory: we created a tremendous amount of
transparency into the development process, and into the costs of
developing software internally and maintaining and supporting it after
delivery. Many senior managers in development seemed to be very
threatened by the transparency, but were willing to put up with it because
they too were worried about spiraling costs. In the end, we got a new
CIO, who is very close to the development managers most opposed to
documenting process and measuring process effectiveness. And he
immediately crippled everything related to quality improvement, focusing
only on testing and inspection. Now it looks like testing an inspection
will go away.

In the long run, I agree with Lon. We have started a series of
discussions that will eventually lead to a new way of managing the
divisions' activities. But not now or the near term. Instead, the system
has moved back to stasis, at very significant human cost, including the
loss of virtually all knowledge learned during the process. When budget
pressures once again dominate, hiring new developers will be halted. Then
the constant increase in maintenance and support activities from low
quality, high maintenance systems will require converting ever more
development headcount to support roles. Soon thereafter, all new
development will grind to a halt as all developers will be trying to keep
existing systems operating. And then someone will once again intervene
and try to move the system to a higher level of quality and serviceability
in delivered systems. My learning from all of this is to warn the next
"change agent" to be very aware of the power of the balancing loops that
will kick and try to return this system to its prior levels. In
particular, remember that it gets better before it gets worse, so watch
out for the system archetype of Fixes that Fail.

Thanks.

Mike.....

Michael A. Gort
Gort@mail.com
(203) 316-9454

-- 

Michael Gort <gort@mail.com>

Learning-org -- An Internet Dialog on Learning Organizations For info: <rkarash@karash.com> -or- <http://world.std.com/~lo/>