Introducing new technologies – How to battle resistance

Previously I had posted about the sad drudgery developers often have to deal with in large companies. I’ve decided to follow up that post due to two epic milestones the past week: taking RabbitMQ live within the company and getting github blessed by legal and infrastructure for internal use.

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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

Related Articles :

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

Leave a Reply


five + = 7



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close