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!

No tags

So the past couple of weeks at work have left me with a bad taste in my mouth. A bad taste I thought I’d reflect on. Granted it has been an awesome couple of weeks with lots of progress forward, there’s still those small nagging issues. It’s the silly idea in the corporate world that the developers you hire must be shielded from doing damage to themselves.

You know what I’m talking about… organizations that block tons of websites and introduce draconian network policies that are completely prohibitive. Want to share your delicious bookmarks with your fellow teammates on gradle? Too bad, it’s blocked. Want to download a zip file of an example application similar to what you’re working on? No way, even though our proxy will detect a virus we’re still blocking it from you. Want to push your personal development project to github? No dice… we turned port 22 off. Only for the developers though, operations can still ssh out. Oh yeah, and so can developers that aren’t at YOUR geographical location. And no this isn’t an accident, there are security reasons for why we did this, just for your development group. I guess I should be happy that we actually can download jars so we can resolve dependencies through gradle. Yeah, couple years back the place blocked jars from being downloaded and you had to come up with a “business justification” to have something like Spring downloaded.

I know, I’m venting. But there’s something to be said about such “security measures”: a lack of respect. Anyone under such restrictions will simply feel like they’re being treated like a child and feel a little disgusted about it. Especially when other employees aren’t subjected to such restrictions. When a company does that all it does is place their developers at the bottom of the food chain and you can’t help but wonder how long you’re going to keep those devs before they go on to greener pastures.

In this age a company can’t afford to prohibit their developers from being able to get their job done. Innovative companies know this and openly embrace new technologies and allow their developers to experiment and even open source useful libraries. It’s time we recognized that to truly be successful we need to hire and retain people who are technically competent enough that we know they won’t click on some random facebook link to a virus. People that we know are responsible enough to make the right decisions when evaluating adopting a new technology. And above all, companies that truly succeed recognize that trust and respect are amongst the most important attributes amongst peers.

Flame off. Hopefully tomorrow I can get this dang port 22 unblocked and start our trial of using github.

No tags