Bender's Blog

As a consultant, I work with a lot of clients of varying backgrounds, skill levels and willingness to explore new techniques and tools. In addition to my development/architecture duties, nowadays I’m often brought into a team to provide mentoring and perform assessments. This takes a variety of forms but there is almost always some effort needed to “evangelize” new ideas and approaches to clients.

Some clients are very open to this. They recognize that I’m there for a reason and that my advice can help them get from where they are to where they need to be. Sometimes the ideas I provide and the steps needed to implement them are difficult and scary, but in the end they will be better off.

Then, there are clients who are a little more resistant. This is almost always based on fear. Mostly fear of the unknown. They’ve been doing things they way they do them for years.  They feel pain but it’s the pain they know. They’ve noticed all the changes in development in the past several years, but haven’t been able to keep up on all of them. Usually they’re in a situation were an tool/technology/technique needs to be vetted before it is used. In the meantime they need to continue supporting their business users with what’s available to them. They find themselves behind the technology wave and getting back on top seems like an impossible task.

Additionally, they know how to be “successful” with the tools and techniques they have now. It’s what they know. Introducing new tools and techniques increases the chance of failure. People tend to put too much emphasis on the negative side of failure without acknowledging the learning experience it provides.

So, how do you win these people over?

The Wrong Approach

As a passionate technologist, sometimes my first inclination is to come in and try to get them to change everything. Right now. This takes fear and turns it into outright panic. From their point of view you’re asking them to throw out everything they know and start over. This isn’t like asking someone to move from Java to .NET or from Visual Basic to C#. The jumps we’re asking people to make are much more difficult. Introducing new developers to concepts and practices like TDD or Inversion of Control require them to make a significant leap in abstract thought. Making a change from Web Forms to MVC, or from Remoting to REST based services takes a major change in the way we think about designing and building applications.

But that’s just what’s on the surface. When you walk into a situation were a team has already been working diligently on an application, which is usually the case, you’re in an indirect way leveling criticism against their development skills. And the more you insist the it must be thrown out and re-done your way and dig your heels in, the more biting that criticism is. No one likes to be told their baby is ugly.

What I’ve Learned

When I was in the third grade I remember reading a book called “Stone Soup.” It was the story about three soldiers who were on their was somewhere and stopped in a small town. The soldiers were hungry, and proceeded to knock on every door in the town asking for food. The townspeople knowing that the soldiers would be very hungry and not wanting to share their food decided to tell the soldiers that they don’t even have enough food for themselves, let alone anyone else. The soldiers are able to see through the ruse however and come up with a plan. The tell the townspeople that they can teach them how to make soup using nothing but stones. The set a large cauldron of boiling water, containing one stone, in the center of town. The townspeople begin to gather, curious about how they are going to make soup out of a stone.

The soldiers make a big show of tasting the soup and claiming it to be, almost, the best soup they’ve ever had, remarking that the only thing is needs to make it perfect is a few carrots.Still curious, a farmer runs to his root seller and returns with some carrots which the soldiers add to the soup. The soldiers go through the same “tasting ritual” this time claiming that if they only had a few potatoes, then the soup would be perfect. Next celery. After that cream. Then meat. You get the idea.

I have found that this approach works well with developers too. We’ve all heard the phrase “Don’t boil the ocean” this is a great technique on how to avoid getting into that trap. Instead of asking a client to take on a dozen new tools, frameworks and techniques, introduce them one at a time. Let the client see the value and point out that by taking another step (when the clients team is ready) will yield even better results. Don’t get hung up on going back and re-doing their existing application. If it’s working now, it’s probably good enough. The benefits you gain by introducing these techniques for new development are not necessarily going to provide an equivalent when used to refactor an existing code base. If there is a benefit to be had, and you’ve used this technique correctly, the clients developers will be the ones who start to champion that cause.

This technique is not an overnight solution, but it is a lasting one. Take your time. Convey your excitement, but also remember to be patient. Keep your changes small and manageable. And enjoy your soup.