I had a miserable experience with a new hire, a self professed object oriented guru. I wasn't involved in bringing this fellow in. An odd situation but I approached it with an open mind. A fresh pair of eyes can be a good thing. It didn't need to be a miserable experience.
It made me think about how one should go about evangelizing change. I've been on the other side of this fence but I've never seen how much the approach can dictate the outcome.
The first problem was that management gave this person carte blanche. Not a good idea if you want to avoid conflict. However, the guy should have known better than to abuse this privilege so that doesn't change the lesson of this post.
First rule. Be sensitive and diplomatic. Don't be shocked or indignant by anything you see. Small companies have many skeletons in the closet. That isn't necessarily a reflection on the people, the very people that did the very work you are critiquing. If you put people off they won''t want to help you.
Listen. People know a lot more about the technical and cultural challenges than you do. Especially listen for consensus and push back. Focus initially on issues that have consensus. Build rapport by building on consensus. Defer sensitive issues until you have built trust and can explore the reasons for the push back.
Don't talk down. Some of the things you advise may already be well understood. Constraints may have dictated the course of events, not knowledge. Also, people may want to learn new practices but that will dry up fast if you talk down to them.
Be pragmatic. This blog is about software development in small companies. There is not much room for idealism in a small company. Demonstrating pragmatism will earn you respect. Revealing idealism or dogmatism is a sure way to turn people off.
Contribute. Do a feature. Fix a bug. There's no better way to learn about the organization and earn other programmer's respect.
Compartmentalize. Practical examples will be necessary but be selective when demonstrating or applying your recommendations. Don't start out by refactoring everything you touch. Instead, focus your demonstrations on your own contributions or pick a specific area in the system. Look for some level of acceptance before expanding your scope.
Be frank. Don't be afraid to admit that there will be some pain. No pain, no gain. Change always has a cost.
Be firm. Don't sit on the fence. If you decide to go a certain direction, go.
Pick good demonstrations. Make sure there is a tangible benefit. Remember, you are dealing with pragmatic people. If practical demonstrations are not easy to understand and compelling you may not get buy in.
Respect current practices. For example, if there are code reviews, offer your code for review. Don't set yourself above the status quo.
Pace yourself. Oversaturating people will turn them off. Think evolutionary rather than revolutionary - revolutions can be bloody and we're trying to avoid that. At the same time, avoid going too slow or people won't pay attention.
Know when to stop. Keep the costs and benefits in mind. Even if you've been successful so far, don't forget that you can still lose people if you forget to be pragmatic.
The approach might be different if you are a consultant.Then you might have a much shorter time frame. However, the playing field is the same. If you want your recommendations to be followed through you still need to demonstrate value and earn respect.
No comments:
Post a Comment