How do you convince coworkers/stakeholders to try new technologies? [closed]

Question

I've got a coworker/manager/stakeholder who is very conservative when it comes to adopting new technologies. I completely understand why: we have a lot of internal expertise with Java, MySQL/Postgres, and so on, they're well-established, and there's lots of good support for them.

But technology evolves, and sometimes newer technologies are better suited to today's tasks. It makes sense, for example, to do heavy numeric processing in something like Python+Numpy. Some kinds of simple web sites are faster and easier to implement in Ruby/Rails. Processing hundreds of gigabytes of logs a day is well suited to a Hadoop M-R architecture.

But I often encounter a lot of resistance to bringing new technologies into the mix, even when I think there's a strong case for it. The resistance even goes down to minor details, like using a heavy JavaScript front-end and web services rather than server-side heavy JSP for a recent project. The most common objection is that because we don't have significant expertise in the technology, it won't be maintainable if I'm not available to do it myself.

How do you work with people like this to overcome these kinds of objections?

Answer 1

The proof is, as they say, in the pudding. Sometimes you just have to do a sample implementation and make your case based off of that. You have to demonstrate that:

• The problem is better solved using something new
• The solution is easier to maintain
• The learning curve is minimal
• Money will be saved through time being saved
• The new technology has a small, but stable and helpful community
• New possibilities exist that did not before

If you take some time to show hard data, you'll at least see the adoption of something new or edgy declined based on technical merit more than preconception, and you might just get a compromise out of it. Perhaps you won't use Hadoop for this project, but getting it in front of people in a way that they can play and touch might make it a candidate for a future project.

As you said, these things take time, and the criteria of maturity and support availability are extremely important considerations. Still, the more preconceptions you can dismiss with hard data, the better your chances will become.

Update

As an aside, this approach is how I recently got my company to start using Redis instead of a combination of Memcache and temporary tables. I wrote a simple messaging system and demonstrated it within a matter of minutes, which replaced something much larger, slower and expensive in terms of resource use and maintenance.

This showed higher ups the benefit I wanted to expressed, and also got our other developers curious enough to want to try it. Note, Redis isn't actually new or bleeding edge, but it is new to a lot of people.

Answer 2

First look at things from their perspective.

1. Realize that there is indeed a risk to using a variety of technologies.
2. Realize there are additional costs (possibly training, software, the cost of having employees that can were multiple hats, not being able to re-use code as easily)

Then make sure you can objectively demonstrate that the risks and costs of using a specific technology are outweighed by the advantages and savings that the technology will bring your product. One of the best ways is with small pilot changes/programs. If there is a new feature, make the case for a Ruby pilot or Javascript pilot. Compare the results to the same piece written in your traditional means. Ideally, the results would speak for themselves one way or the other.

Answer 3

And what is the half-life for these new technologies?

Part of the experience senior developer have is seeing that technologies come and go, and only a few live long.

Just consider the statement "It is extremely easy to create an application with a simple GUI in the new Visual Basic 6" for about 10-15 years ago.

Software tend to live longer than you think.

Answer 4

The sad truth is you often can't convince them. If they are dead set in their old ways, they will be hard pressed to try anything new, even if the benefits would outweigh the learning curve. I don't know if it's just being lazy or being afraid of trying something new but I can count the number of times I've worked in places that would embrace new technologies on one hand, while it would take many more hands to count the places that never did anything new even when the current stuff they were using (or the specific way of doing things) was long obsolete and replaced with better and more effective ways.

People always talk about demonstrating "business value" but what they neglect to mention is that often the business is too short-sighted to see any of that value, and the developers are too ingrained in their current habits to bother learning a new way when the old way is familiar and comfortable to them.

It's not always the case, but more often than not trying to do this is a losing battle and pursuing it will only make you want to quit the job. I've been there many times in my career (and probably will continue to experience it).

Answer 5

First you need to improve your skills at making a case to do something. Learn how to do cost benefit and decision analysis. Take a debate class. Get public speaking skills. Read How to Win Friends and Influence People. Take a technical writing class. People don't change unless you convince them that the change will improve things. You need to start looking at things from their point of view not yours. (That's why the suggestion for a debate class where you don't know until the debate which of the two sides you argue and have to prepare the arguments for both. Most useful class I ever took.)

Next be aware that expereience developers understand that using new shiny technology is risky and can cause failure of the whole project. If they have been thorugh one or more of those failures, they will be much more resistant to change. They also know that technologies come and go so fast sometimes that they would rather wait and see if something will last for awhile rather than switch to the new toy of the month. They also are aware of how much work it is to take a working product and change it to something new. You introduce new bugs (Which, let me tell you, clients hate) and often you have to do it on non-billable time as the client doesn't want you to redo a working solution. I tell you these things not so much to discourage you, but to make you aware of the points you need to have counterarguments for in order to get a suggestion accepted.

Answer 6

Your best bet may be to use new technologies to address specific problems. Don't propose a new project using something new, fix a pain point using something new. If you've got a response time problem because you're using pure JSP instead of AJAX, then add the AJAX call to fix it. Get it adopted as a small case, let everyone poke at it and see how it works, then eventually it'll become a standard technique!

Answer 7

Recognize that, from management's point of view, they've got a solution that works for $X. No technology you want to introduce can save more than $X, and the possible loss if it doesn't work is almost certainly greater than $X. Changing to the new technology is itself going to cost money, and things will get done slower for a time. (New technology is rarely instantly productive.) This means that management will be strongly inclined to be conservative, and you will have to provide strong and convincing reasons to change. There are several arguments you can use, based on the above, not all of which will be convincing by themselves (or necessarily applicable). You will need to base all of your arguments on solid evidence.

The likelihood of the new technology failing is sufficiently low to be ignored, or you can provide a fallback plan that doesn't lose too much money, or the new tech can be introduced slowly and incrementally into non-critical areas at first. This means you're providing a bound on the worst case. Managers hate writing blank checks.

The technology will save $Y over time, either by allowing reductions in staff or equipment or by allowing more to be done, and that's worth the cost. (If $Y is spread over several years, find out how the company calculates the present value of future money, and use it.)

The cost of what is being done now will go up significantly without this technology (like introducing VB.NET to replace VB6, or if legal or regulatory requirements are changing and it will be hard to adapt the existing system).

The new technology will allow us to do something else, which will bring in $Z. (This is by nature speculative, although it may be easier to make if the company already uses software for strategic advantage.)

Be as specific as you can be, and be honest. If you accidentally leave out something unfavorable to your case, and somebody spots it, that's a problem. If you're caught deliberately falsifying or concealing things, you should probably just give up, because nobody's going to trust you or take you seriously. Favor arguments that are understandable to non-technical management.

Answer 8

In my experience when I want to introduce a new technology I create a trade study to show the benefits of the new technology over the old technology in a simple summary.

Then I usually have a working proof of concept and try to find a feature that is small and there is no schedule risk to try and introduce using the new tech.

Once the new tech has proved itself in that scenario it becomes much easier to incorporate it into larger aspects of the project.

All that being said you really do need to weigh the costs of training team members on the new technology. Most software teams have varying degrees of capability in their team members and for some of those members introducing new and unfamiliar technology can be a challenge.

There's also something to be said for focusing on a single language for a project/team. You can focus on specializing on the tools for that language and know all the idiosyncrasies that particular language may have (i.e. multi-threading issues, memory management, etc).

Answer 9

I tend to pick smallish projects and just use something new. Facts on the ground are hard to argue with.

Answer 10

You have to be extremely lucky to get a company to adopt new things or ideas. It's a fight I have tried to make in several companies on several projects. Especially when it comes to UX the maturity of the company matters and if they are not at a mdecent maturity level they will not see experimentation and innovation appealing, instead they see it as a change they do not want to make. After all everything is working and money is being made, so why fix something that isn't broken?