An evocative learning about innovative disruptive technology is that you might find out that not everybody is going to be excited about tools which can give you more productivity.

To make this question less generic, what are do's and dont's - so as they also say, lessons learned - of evangelizing Docker in your organization based on real experiences with different roles?

  • I find out that the best reaction to low acceptance environment is leaving. When good people keep leaving, it becomes very convincing very quickly. Dec 15, 2017 at 22:09
  • @JiriKlouda How long will you give it a try? Imagine that someone joined a company last week and sees that there is a low acceptance environment, should one leave in one week?
    – 030
    Dec 15, 2017 at 22:33
  • On any job you need 30 days to learn the environment and 30 days to try to make your first mark and larger contribution. If you were not able to make a contribution by then, you won't have the reputation to bring larger change. If you did, you can try to push on the acceptance issue, if after another 30 days you still meet with sharp resistance, start escalating up the chain one step a week all the way to CEO. If the CEO does not care about transformation, nothing will change. Start lining up the interviews. Dec 15, 2017 at 22:49

3 Answers 3


This is not docker-specific, but this general rule for evangelism applies: different audiences require different evidence. In general, software developers (and managers from a development background) want to see it in action, so POC's with measurable outcomes are preferred. Other disciplines and executive stakeholders may be OK with case studies and presentations before giving the greenlight; your goal is to identify which audience you're talking to, and begin to build a comprehensive argument.

Start small; find one key stakeholder, and present your case using the evidence that best suits them. Be patient; change in mature organizations is usually slow, so getting a small project up and running is a major accomplishment.


A couple of months ago I gave a presentation about the pros and cons about docker. My expectation was that the developers would start to use tool immediately after the presentation, but it took a couple of months. It turned out that a (huge) problem was required in order to get it accepted by the team members:

There a six services at the moment that all run in vagrant. My system is unable to handle it anymore. Shall we use docker? You addressed in your presentation that it omits an OS, that it is more lightweight compared to a VM so the machine will consume less resources and I will be able to run the services locally right?

When it turned out that the services were now able to run, more and more developers started to use docker.


You could put the names of colleagues in a sheet and decide per individual if one is easy or hard to change, has a lot of influence and is willing to share knowledge. Start sharing the information with the one that has the highest score and try to convince him or her to convince the next one that is most likely to change.



You want people who are able to work horizontally across the organization and who have good communication and networking skills.


Identify your committed digital champions early – individuals who network well and can create horizontal influence to help implement behavior change across silos.


Ensure that the supervisors or other employees whom the rest of the staff looks to for advice and leadership will show enthusiasm.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.