My previous post was a rant in response to port 22 being blocked and preventing us developers from using github so I thought I’d detail how I got past the resistance and how you too as a corporate rebel can help bring change to your company as well.
First, let me set the stage. It has been my experience that larger companies tend to err on the side of caution when it comes to introducing new technologies/ideas/practices. This can be due to being burned in the past as well as a combination of getting more process or control in place due to social scalability issues. The later just boils down to it being easier to trust the devs you work with or near you versus 200 or so developers of which sadly a percentage have probably downloaded viruses or other silly things.
There’s always a lot of resistance within these type of companies as adopting something new poses a risk that quite frankly some people might rather do without. So, given my successes in the last couple weeks I’ve decided to share some of my techniques for battling this resistance.
- Research. Do a lot of experimentation and research on what it is you are wanting to bring in. Sometimes this involves just using it on personal or side projects. I’ve also found that writing articles, blog posts, and presenting at usergroups about the topic is a GREAT way to learn more about it.
- Share Information. The best way to have a new idea gain traction is to share information about it. Brown bag lunches and internal presentations are the gold standard here, just give presentations and demos internally to those who are interested without trying to imply you’re hoping the company will adopt it. Not only will this expose people to it but it will also help you gain insight into what kind of concerns people might have. In addition to presentations, also share links from time to time on case studies, tutorials, and the like. Extra bonus: you might be a catalyst that will ignite someone else to help bring the idea forward.
- Find an ally. With my situation with RabbitMQ, I found allies in different departments and even on the business side. These “alliances” came in strong for the win in the 11th hour, especially when the dreaded “what is the business justification for…” resistance tactic came in. When that question came up, my product owner was able to pipe up and make a strong case for why he needed what I was proposing. Not only that, but he was able to help coordinate with managers in other departments to ensure we succeeded.
- Be there. Every one hates 1am production support issues. Remember that what you’re trying to bring to the company will undoubtedly lead to someone’s lost sleep sooner or later and they know it. Be ready to take the fallout from the risk that your change will bring and be ready to respond to production support calls. The first night we took RabbitMQ live I had to bust my butt and head down to the data center at two in the morning to respond to “queue depth limit exceeded” alerts because message consumers weren’t able to stay caught up with the heavy load from publishers. The moral is, be ready to be available and respond to those situations. Make sure others know that you are taking the responsibility for the risks that you are bringing. Bonus points in outlining those risks and how you will counter them.
- Never give up. If you’re convinced that something will improve your company and make a change for the better, stand behind it 100%. No matter how many times you fail keep pushing it, push until it breaks. There are a lot of times I’ve seen people talk about things like “it’d be a lot better if we used something like Hadoop instead of our homebrew framework” and not do squat about it. They might even self defeat themselves by making an excuse for why it probably won’t do well in our environment. Don’t let that happen! Throw your full weight behind it don’t give up.
Hope that helps for all of you other change agents out there!
Reference: Playing To Win from our JCG partner James at the “Rants and Musings of an Agile Developer” blog.
