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

Thursday

25 Apr, 2002

Q: How many psychologists does it take to change a light bulb?
A: Just one, but the light bulb has to want to change.

Today I was having a conversation with my champion. You know, the guy who has the same basic viewpoint as me but has more pull with management. He was talking about one of our clients.

"They want us to reduce development cycles and respond more quickly to changes," he said.

I smiled, knowing what was coming next. That's a textbook reason for instituting an agile process.

He continued. "That's why it's important that we get the framework right."

I was floored. I've been talking about agile software development for three or four months now. Along comes a classic customer request—the exact request agile development was invented for—and this is the conclusion?

I've clearly screwed up. My approach has been fundamentally flawed. Since he got here (which was before me), my "champion" has been advocating a framework as the solution to the company's problems. The framework's been developed. (It's not solving the problems.) I come along and advocate agile development and people-centric processes.

Of course I'm not getting anywhere. I'm not saying anything that can be heard.

Years Later...

8 Jun, 2006

Mindsets.

I don't remember exactly what I was thinking when I started my change effort, but I think it was something like this: "This organization has problems, but they can be solved. I just need to let people know about the solutions, and get them to trust that I can help, and we can solve these problems!"

Ha! Ah, the naïvité of me. I forgot that other people had their own take on the situation.

Some people didn't realize there was a problem. Yes, there was minimal teamwork; yes, there were a lot of bugs; yes, the software was perpetually late and released only with heroic effort. "That's just the way software is, right?" My efforts were primarily directed towards these people. I talked about how things could be better and what steps to take to make it better. Unfortunately, I think these folks were in the minority.

Other people blamed the workers. It's partially true: the organization expanded rapidly during the .com boom and hired a surplus of mediocre workers. But they had who they had and it wasn't the workers' fault. Besides, individual heroism is a lousy way to run a business. (You get in the habit of jumping off buildings while yelling, "Save me, Superman!" Then one day Superman's off getting a latte in Rome and you're jam on the pavement. "Splat," says your project.)

On this particular Thursday in 2002, I ran across another mindset: the "technical solution" mindset. I see it all the time--it really shouldn't surprise me anymore. Yet it does.

The "technical solution" mindset basically takes the approach that problems are best solved by the introduction of some new technology. "We need a framework" is a common one I see in companies that do multiple projects. (This is particularly common. I haven't seen it work yet.) "We need a project management tool" is a common refrain among people adopting a new process.

There's nothing wrong with tools as tools. They're good at making established processes more efficient. The problem is that the technical solution mindset focuses on making symptoms very efficient rather than solving underlying root causes, which are almost always people-oriented.

Okay, back to the situation at hand. My champion and I saw the same problem: projects were taking longer than they should, consistently over budget, and were chock full o' defects.

My champion looked at this situation and thought, "People are spending too much time writing the same software over and over again. We need a framework to abstract out the common elements of the software."

Management looked at this situation and thought... well, I don't really know, but I'll guess... "The people we have aren't getting their work done. We need to hire better people and push the ones we have to work harder."

I thought, "People aren't sharing knowledge or using adequate technical practices. We need to introduce better work habits, starting with cross-functional teams and feedback-based scheduling."

Who was right? We all were, to a degree. Okay, I have to admit: even now, with the benefit of hindsight, I think introducing better work habits was the best solution. I just underestimated how difficult organizational change could be, and how much the organization's revenue structure contributed to its problems.

My point, though, isn't about who was right. It's that these folks weren't blind. They recognized the problem and they had a strategy to solve it. I was blindsided by this. I thought I was introducing a solution into a vaccuum... that people were either blind to the problems or standing around wondering what to do. That wasn't the case and it's not likely to be the case at your organization either.

What do you do about this? I don't know. If we could read people's minds, it would be easy, wouldn't it? Unfortunately, people don't go around telling you their organizational philosophies.

These days, it's easier for me. I'm hired to help people make changes. So I just ask. "What do you hope to accomplish?" "Why is that important?" "How will you know when you're successful?" These three questions, repeated in several different configurations, are a great tool for sussing out underlying points of view.

As a peon, I don't know that I could have asked those questions. I wasn't hired to make organizational changes and I didn't want to put on airs. However, I do think I could have been more direct. What would have happened if I had met with the director and said, "I see problem X, Y, and Z. Do you see that problem too? What do you think about it?"

I don't know what would have happened; I didn't do that. At that stage in my development I was more interested in providing solutions than in listening to others. If I had listened more, I might not have been blindsided as I was on that Thursday in 2002.

Or not. My approach had some notable successes, such as the bullpens that continue to this day. Either way, you can see my frustration continue to mount. Two weeks to go.

Next: Week Eighteen