Approach to encouraging organizational adoption of new web dev tools [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 5 years ago.

Improve this question

I'm attending the O'Reilly Fluent conference, and a clear theme I've seen is the widespread adoption of tools to improve effectiveness of efficiency in web development workflows.

I readily recognize the value of these tools, but I am concerned that some of my coworkers may feel like my suggestion to adopt them would be seen as "one more chunk of overhead - one more thing adding complexity and standing between me and getting code written".

What are approaches you've successfully used in similar cultures or situations to help your organization be open to considering the possibility of adopting new tools?

Some of the tools I have in mind (as examples, though the question isn't limited to or even specifically about these) are Grunt, Travis CI, ReactJS, Hubot, Browserify, PhantomJS, ES6 (with Babel, currently), etc.

Answer 1

A lot of it is about communication skills. You should also know that being skeptical about new tools is common in software industry. More on this later.

First: Your Mindset

• You are not selling so don't feel like it. You are kindly presenting a solution to a common problem so be confident. (Actually if you were marketing a product, you would also be advised to have the latter mindset.)
• Be prepared to be rejected. You can never be sure to convince everyone every time. Furthermore, it is common in software development teams to be (wrongly) skeptical or even lazy about:
  1. Reusing code which needs learning about it.
  2. Using proper new advanced tools to solve new advanced types of problems.
  3. Writing unit tests.

Second: Your Presentation

Dale Carnegie in his classic book, "How To Win Friends And Influence People" has a lot of things to say about this subject. One of those things is that you have to point out their problems and your solutions for them rather than stating your desires and emotions. Following that lead:

- Find The Problems You Can Solve

Try to find the main common concerns in your organization that the tools can somehow solve. Start with them (e.g. Remeber the other day when we were talking about how running our tests regularly puts too much on our plates? ... and then lead to Contiuous Integration tools.)

• Find and list the problems that your team beleive they exist too. This way you won't have to convince them that a problem exists prior to presenting the solution. Winning an argument is really hard. Winning two arguments in one session is really really hard.
• The problems you mention do not have to be directly related to the solution you are providing. You just have to be able to start from the problem and lead to your solution. of course, the solutions should be practical enough or you would look like preeching. Do not preech. never.

- Answer Before They Ask

Try to answer the arguments you really guess people would start before the start it. This makes your argument more solid and convincing.

• Do not be obvious in this. Blend those answers in the context of your presentation. E.g. in the first part of this answer I pointed out 3 common skepticisms in software development. I put our subject in the second item! See what I did there?!

Finally I have to emphasize again that you should avoid at all cost preeching. always keep an open mind.

Answer 2

I've been in situations like this before. One thing to avoid is to jump right into saying "We should adopt tool X, because of reason Y." This would likely trigger the response you're woried about.

One of the approaches that have worked for me in the past is to actually identify a point of improvement. For example, you could point out something in your processes that takes a lot of time. If you can then identify a tool that helps improving on that point, and you can demonstrate, that could allow for a more open aproach.

Something that is always very important in these situations is to listen to your coworkers. They may come up with some valuable feedback. Or they might come up with a better solution. There might alsow be cases where they are just trying to block you with irrelivant arguments, in which case you should be ready to reply to them accordingly.

Another approach is to casually demonstrate a tool to a coworker. The way you could do that is to have the tool open on your computer with a demo scenario ready and when a coworker looks on your screen, show him or her what you're playing with. Lines like "I've been playing with this to see if it's any good. Look, it does this which is cool." can help.

Another thing to keep in mind is to be honest about any tools, including drawbacks. This would enhance the feeling you're trying to solve a problem, not introduce more overhead.