This is one of many entries in the Change Diary: a true story of success and failure, written as it happened.

Week Nine: Wednesday

27 Feb, 2002

Code freeze today. Nothing interesting happening. This sort of feast/famine cycle has been common. We go into production in a few days, and we'll all be standing by, prepared to support that effort.

Week Ten: Wednesday

6 Mar, 2002

Code finally went live. Yep, it took a week. I spent most of the time fighting fires, but I did have time to write an essay about improving communication by collocating programmers, QA, and project manager. I was careful to propose a very small change: just collocating people. I didn't mention unit testing, pair programming, or iterations. I see collocation as a necessary first step, so that's what I focused on. And, if I could only choose one thing, collocation would be it. Communication is a big problem here.

The other XP guy here thinks I'm being too cautious. We'll see. Previous attempts at top-down change have resulted in disinterested responses and comments about changes being too big. The XP guy thinks my timing was just off... now that we're finishing a product cycle, now is the time to change the process. Also, the fires have been so bad, they're impossible to ignore. He called a meeting yesterday (that I couldn't go to, darn it) and process issues were discussed for an hour and a half.

No one else has given me any feedback on the essay yet, but that's because there hasn't been time.

Week Ten: Thursday

7 Mar, 2002

Reaction to the essay has been universally positive, but only mildly. Everybody has said they liked it, but I've had no real feedback. It must have made an impression on someone, though, because I saw one of the managers that I didn't give a copy to carrying it.

Years Later...

14 Apr, 2006

Top-down change, bottom-up change... I've been throwing these terms around, but I don't think I've defined them.

"Bottom-up change" is what this diary is all about. It's changing an organization when you're an "in the trenches" worker with no official power.

"Top-down change" is what I normally do. It's changing an organization when you have authority over people's paychecks. No, I don't ever have that kind of authority, but the people who hire me do, and they listen to my recommendations.

Ironically, now that I have access to that kind of heavy-hitting authority, I never, ever use it. I can't.

You see, I've come to realize that both bottom-up change and top-down change are essentially the same thing. Both are extremely difficult. Both require that people want to change.

When I was trying to change my organization back in 2002, I thought to myself, "If only I had the authority, I could make big changes around here." Well, I've had that authority... and I've tried to make big changes... and now I realize that even "authority" doesn't translate into "ability to make big changes."

There are people out there who know a lot more about organizational change than I do. Diana Larsen, Johanna Rothman, and Esther Derby come to mind as a few of the folks in the agile space who work on "people stuff." I've never studied organizational development in the way that I imagine these folks have. But I've studied my own successes and failures, and from that, I've come to realize that, for me, effectively introducing new ideas comes down to one thing:

I am able to introduce new ideas when people trust me.

That's it! It's as simple as that. When people trust me, I've been successful. It hasn't even been hard. And when people don't trust me, no amount of cajoling, persuading, beating with sticks, etc., will make a difference.

To help earn trust, I have a short list of things that I keep in mind when I work with an organization. I don't do these things perfectly, and some people just won't trust a consultant no matter what, but that's okay. This is the best way I know.

There Is No Change

It took me several years to realize this, but now I believe that the Way to Change is No-Change. No, this isn't some sort of pseudo-Zen mysticism. (Okay, I admit to dressing the phrase up in a zen outfit, just for fun.)

Seriously, though... I no longer approach my work from the standpoint of "I'm here to Change Things." Instead, I'm interested in showing people ideas, seeing what they think, talking about alternatives, listening to experiences, etc.

If it turns out that people don't think the ideas will work for them, that's fine. I'll be disappointed, yes. If I feel that people haven't given the ideas a fair chance, I'll push them to be more open-minded. If I've been hired to introduce the ideas, I'll talk with the folks that hired me about our alternatives. But I'm not going to try to force people to do something they don't agree with.

That attitude shows through in the way I approach my work, and I think it makes it easier for people to trust me.

Be Respectful

At all times, I strive to be respectful of both the people and the organization. I don't always succeed on the organizational side. I have a pretty low tolerance for bullshit and it seems that organizations always accumulate some amount of bullshit. My intolerence makes me seem unfriendly and critical, which makes it harder for people to trust me. (Hmm. I should probably work on that.)

On the positive side, though, I am absolutely respectful of people. "Being respectful," by the way, doesn't mean "being friendly." Sure, I'm friendly... to the best of my ability... but more importantly, I'm don't think of others as incompetent. I look at problems and think, "There must be a reason things are the way they are." I find out what people are good at and think, "Everybody here is responding to the situation to the best of their ability."

This attitude, which I think some people call "Assume Positive Intent," has served me very well. I'm particularly fond of using it when I'm being attacked by questions: rather than respond defensively, I assume that the questioner wants information, and I respond straightforwardly, without malice.

Earn Respect

I know my stuff. I don't talk in vague generalities; I talk in terms of experience, and I can practice everything I preach. I think technical folks are particularly inclined to respect people with lots of competence, so I've seen a lot of benefits from this.

By the way, if there's a difference between "top-down change" and "bottom-up change," it's in this arena. If I've been hired as a fancy-schmancy consultant, then there's a certain level of implied respect that the organization has given me. It may mean that I have to do less to prove myself.

But I often encounter folks who think consultants are just modern-day con artists who only know how to suck money out of the bosses' pockets, so I don't know if the "top-down" thing really helps me all that much. Similarly, the "pointy-haired boss" might have farther to travel in terms of gaining trust than the well-respected guy who fixed the build system last week.

Ask Permission

Asking permission has become one of my most commonly-used tools. When I first started leading teams, I asked permission all of the time. Then I started feeling like I "knew the answer" and had "authority" to explain it... and I stopped asking permission. My effectiveness dropped like a rock. Now I ask permission again. It could be that this one simple thing is the most effective tool in my kit.

By "asking permission," I mean just that. I don't assume that people want me to tell them my ideas. I don't assume that they want me to show them how to do something.

If I see people struggling with something, or simply discussing ideas, I'll ask if I can share my thoughts. Sometimes I'll ask if I can lead--for example, I recently worked with a team that was doing a retrospective. I hadn't been hired to help them with retrospectives, but I could see they were struggling with it a bit. I told the team that I had an idea for the retrospective and asked if they'd like me to lead them through it. They agreed, so I did.

By the way, this isn't a "fake" sort of permission in which I'm assume the answer will be "yes." It's funny--I can't remember the last time somebody said "no" when I asked permission like this. But maybe that's because "no" is a non-event. I'm not asking permission as a disguise for saying "Let me show you how it's done." I'm just offering to help out. If somebody says no, I'm okay with that, too.

I have a new sense of calm about what I can do, and I think it ties back to point #1: the Way to Change is No-Change. I've seen how hard organizational change can be, and so I no longer attempt it. I just share ideas, lead by example, and have fun doing it. If things change, great! It's a much easier approach to life... and you know what? I think it's made me more effective as a consultant, and as a change agent, too.

My wife, after reading this, said, "It's all about respect, isn't it?" Yes, it is. That's the best way I know to earn trust.

Next: Week Eleven: Monday