In response to my recent post, Building Blocks, Rob Levin commented in part:

He and I were both lamenting how hard it is to get team leadership to support the notion of small methods and classes …. One can argue rationally and still be “vetoed” by the teams “elders”. It then becomes increasingly easy to throw your hands up in the air in apathy. … I’d love to see some articles here address this problem with solutions that persuade. Thanks!

I addressed the first (more technical) part of the comment in Small Methods and Classes. In this post, I’ll address the second part of the comment, the people part.

How do you convince others to try new approaches? Especially, how do you do this when the others have more authority or a higher position than you?

The most important thing is to watch your tone when trying to sell someone on your ideas. If you talk down to your audience, or treat them like they’re stupid or incompetent, you’ve already lost.

The next most important thing is to understand your reasons for wanting a change. If you just want things to be your way, that’s not good enough. But if you’ve got some compelling reasons for your proposed changes, then share those. Focus more on the “Why?” than the “What?”. If you can highlight some pain points that everyone is feeling, and talk about how your solution addresses those pain points, you’re more likely to find a receptive audience.

That said, here are few ideas of things you can try. I realize that you may not be in a position where it is safe to do any of these things. I sincerely hope that is not the case, but please don’t risk losing a job you can’t afford to lose.

You can lead by example. Even if you have no power on your team, you can use your ideas and approaches in your own work. If they are truly better than what others are doing, that will start to show.

You can also share your ideas when you’re pair programming. If your pair partner likes what you’re doing and adopts it, you’ve found an ally. As you pair with more and more people, you can start to build a critical mass of supporters.

You can find small, safe spaces where you can try your new approach. A failure on something mission-critical would be a disaster, but if there’s a safe space off to the side where you can experiment, that’s ideal.

You can propose a time-limited experiment. This is often how agile principles and practices (such as pair-programming) were sold early on. The first episode of the Bike Shed podcast had a great example of this. A team decided to adopt Sandi Metz’ rules for Rails code on their project to see what would happen. This can be a great way to introduce a change in a non-threatening way. By time-limiting the experiment, everyone knows that there will be a time when they can “re-decide” about the approach.

You can work to educate your teammates and leaders. Share books, articles, and videos. Have brown bag discussions. Give tech talks. Whatever it takes to share the information.

Remember that resistance isn’t a bad thing. Resistance is just a response, and that response gives you more information to work with. Dale Emery discusses this brilliantly in Resistance as a Resource. I highly recommend reading that article.

I also remember a talk that Norm Kerth gave at Agile 2005 called, The Secrets of Leading From a Position of No Power. I can’t find a video or slides online, but Bill Wake has a brief summary of the talk. See Part 5 of the post near the bottom.

If none of these ideas work, there’s always Martin Fowler’s famous advice: “If you can’t change your organization, you might have to change your organization.” If you can’t effect change where you are, and it’s that important to you, you might have to start looking for a new position that’s more aligned with your ideas and values.

I hesitate to give this advice because, as Sarah Mei tweeted recently:

If you feel that your only option is to find a new job, I hope that you can work yourself into the position where you have that ability.