Summary
In Jerry Weinberg's classic "The Secrets of Consulting" (Dorset House, 1985) he says something to the effect of "You probably won't be able to make any changes."

I find the maxims in this book to be like design patterns. You can see the pattern on its surface, perhaps even feel like you know it, but until you experience the fundamental insight about that pattern, it remains obscure.

Weinberg's maxims usually appear to mean something obvious on the surface. Sometimes they are even "on the nose," but I usually find that to be an illusion. In this case, "You probably won't be able to make any changes" seems on its face to be a reason for just giving up. Many years ago I re-read this book right before going into a particularly difficult and intimidating consulting project, and the "no changes" part allowed me to make a difference.

(An aside: some of the rules in Weinberg's book, as well as some of my own rules, would tell me to avoid working with clients that exhibit difficult behavior. Sometimes the experiences are simply painful, but on more than one occasion I've become thankful for some of these clients because I've learned so much from them. This makes it difficult to know which ones to accept. As in many things in my life, I've come to simply trust and rely upon my intuition).

As painful as they sometimes are to achieve, I really love the "deeper insight" experiences. They may last from moments to months, but something about that feeling of change, to me, is one of the things that makes life worth living. I may be a counterexample to Jerry's "people hate change" proclaimation, but I seek it. Perhaps the real truth is that "change is painful," and so most people respond by avoiding it. For that matter, it's only through experience that I've come to recognize the pain of change, and even if I don't embrace it, I know that it's worth moving through.

Some of the best insight experiences are those that take what I know and turn it upside down. For me, it's very life-affirming to be reminded of how surprising the world really is. Discovering Open Space events has been like this. Unlike traditional conferences where the goal is to control everything and nail down every detail, with Open Spaces, the more you let go, the better it gets. In fact, I've seen attempts at Open-Spaces-style events where people were not quite able to trust the process and the organizers didn't let go enough. These events limped along, but didn't achieve the pinnacle of ease and energy possible with Open Spaces. (See my calendar for upcoming Open-Spaces-style events).

Another example is the writing process. For as long as I can remember, I have never understood writers who say "I write for X hours a day, every day." I have always waited for inspiration, or at least allowed time for the inspiration to arrive. Recently, I have started feeling overwhelmed with administrative management duties, and I've started wondering whether those writers weren't really saying: "I'm unavailable for these hours every morning." It's in the same vein as those who say "don't look at email in the morning." By establishing these parameters, you set boundaries, not so much for yourself as for other people ("The mysterious process of writing happens during these hours. Disturb it and you may scare away the muse."). Of course, it probably helps to tell yourself that these are writing hours, but I wonder if the bigger issue isn't actually boundary setting.

No Changes vs. Appreciative Inquiry

Before going to the aforementioned difficult consulting project, reading the "no changes" passage allowed me to let go of the idea that I was going to make any changes. And this ironically allowed me to see what was going on, and so I may have produced some small effect in the end. It may have simply been a change in perspective from "I'm the high-paid consultant who has been brought in to fix everything" to "I'm probably not going to be able to do anything here, so I'm open to anything where I might be able to make a difference." I'd like to think that the insight to Weinberg's maxim was the humbling effect that forced me to be open to anything.

Whether or not that's what he meant, I think being open to anything that a client might actually need is one of the most essential aspects of consulting. The "high paid" and "consultant" parts too often tempt a consultant to think that the experience is about the consultant, when it's always about the client. One of the great failings of the agile movement has been this hubris, which has time and again prevented any effective change from happening. A consultant arrives, tells the customer that they are doing it all wrong, and that they should drop everything and do it this other way. This actually makes life very easy for the consultant, because they just say the same thing to every company they visit (you might as well just make a set of DVDs if you're going to repeat yourself). But every company has its own personality, and the art of consulting is in discovering what change that company is able to make. This change is usually something small, and it's also usually a direction where everyone wants to go already. The most effective consulting removes a small roadblock or makes a small shift that allows the company or group to get where they already want to go.

This insight -- that it isn't about "fixing" the client, but rather enabling them -- is at the heart of what's called Appreciative Inquiry. It doesn't explicitly call itself a consulting technique, but rather a technique for change (that is, you don't necessarily need a consultant to do it).

The name sounds touchy-feely, but Appreciative Inquiry began in academia, and produce the usual academic research and papers, relatively inaccessible to the business world. I learned about it through The Thin Book of Appreciative Inquiry, by Sue Annis Hammond (2^nd Edition, 1996 Thin Book Publishing Co.) which went to the trouble of culling through these papers and creating a nice, accessible summary.

I can summarize it even further: "What have you done that's worked out really well for you? Let's do more of that!" Much of the book is about how to discover things that have been successful -- because we tend to bury those when we succumb to the inevitable, constant pressure to grow and expand, or we interpret the outcome based on someone else's standards of success rather than our own.

In Apprieciative Inquiry, an important part of the measure of success is how it makes you feel. This is a legitimate metric because, if we have positive feelings associated with a particular action, we already want to do it again. So, as a consultant, your barrier to change becomes very low. You don't have to convince anyone: they've already successfully done it before, and it felt good. Naturally, it seems like a pretty good idea to do more of it. Instead of an uphill battle to introduce contrary new ideas, consulting becomes a process of exploration, discovery, and reminding people of how good they felt last time they did something that was a success for them. Instead of discovering what the client is "doing wrong" and telling them how to do it right, your process becomes to discover what the client is doing right (what their particular talents are), reminding them that those things are enjoyable, and suggesting that they do more of that.

If you're ambitious, this may not seem like much. But if you have learned that "you probably won't be able to make any changes," then a process like this takes you from being ineffective (especially if you've been battling people's resistance to change) to making a small, but very positive difference.

As an example, consider Test-Driven Development (TDD) from the perspective of appreciative inquiry (using a little bit of mental gymnastics). Programmers like to feel that they're in control of a situation and that they do a good job. Various management forces and the programmers themselves may cause them to bolt forward and rush to a perceived finish line -- thinking, perhaps, that this time everything will fall into place easily (I know it happened once to a cousin of a friend of my brother's). When it doesn't and things start to go wrong, programmers feel frustrated and helpless. Although TDD is usually a new experience for people, it reminds you of how nice it is when the compiler or development environment finds bugs for you. Although I find that it requires leadership to guide people through the experience the first time, the eventual "aha!" moment when the test framework finds the problems reminds people of what it feels like to be in control of the development process.

Talk Back!

Have an opinion? Readers have already posted 2 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Bruce Eckel adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Bruce Eckel (www.BruceEckel.com) provides development assistance in Python with user interfaces in Flex. He is the author of Thinking in Java (Prentice-Hall, 1998, 2nd Edition, 2000, 3rd Edition, 2003, 4th Edition, 2005), the Hands-On Java Seminar CD ROM (available on the Web site), Thinking in C++ (PH 1995; 2nd edition 2000, Volume 2 with Chuck Allison, 2003), C++ Inside & Out (Osborne/McGraw-Hill 1993), among others. He's given hundreds of presentations throughout the world, published over 150 articles in numerous magazines, was a founding member of the ANSI/ISO C++ committee and speaks regularly at conferences.