Convincing a company to add new technologies and techniques to their body of standards?

Question

I work in an organization that relies heavily on technology standards. For the most past this is great and helps provide direction to developers and helps them move across teams really easily.

However in the past year I have discovered more effective ways of doing things using new technologies and I am struggling to get these strategies added to the technology road map.

Has anyone had this experience and if so what have they done to bring about change in the organization?

Answer 1

With permission, offer to do a small project using the new technologies. Demonstrate its value and that it works.

Answer 2

I work in a small agency and I'm lucky enough to have direct access to my boss. When I find better ways to do my job I just make sure to let him know that there are options early in the job cycle. Over time we've built a level of trust and every time I suggest a new approach there is less and less resistance.

I also make sure to document exactly how much time/money was saved using the new technology. This is easily the most compelling way to evolve your company's process. Bean counters love metrics!

Answer 3

If what you make ends up being supported by a group of people other than yourself you need to live with Standards. Can you imagine open source being developed without standards?

Answer 4

I'm in what I think is quite a backward and archaic shop. We're still using CVS (!), Perl was only upgraded from 5.6 to 5.8 this week, and we came on board PHP 5 from 4 only this year. If you get any success, let me know :) but based on experience, I can tell you that sometimes a big factor that impedes adoption of new technologies is not so much that the benefits and superiority of the technology is not known or acknowledged, but rather that there are more pressing priorities that management wants to get to.

If the team, department or company is getting by with currently used technologies, or even doing relatively well with them, then changing to or even test driving new stuff may not have sufficient justification yet.

Something I'm doing which you might consider is keeping a log of actual, tangible problems encountered with the technologies you consider inferior. For example, in my case, I am keeping a log of the times when CVS gives any member of the team problems or frustration, especially when my preferred solution (git) would have saved the team time, or made possible a quick solution that CVS doesn't allow. At some point, the amassed evidence might weigh heavily enough to support a decision to change to the new technology.