My team is finishing a 15 month project aimed to convert over 500 Enterprise applications to a standard development methodology and CI/CD pipeline. This included a company-wide re-org, defining new Scrum processes and attending bootcamps, and undergoing a complete tooling overhaul.

After roughly 12 months of the project was completed and 300 applications had been migrated, we realized only 8 applications were deploying to Production with the new tooling. This realization shocked our whole team – we had taken all of these applications from long weekends of manual deployments and tech bridges to automated builds and deploys with push-button functionality - why weren’t more people using it? The answer came to me at a company Mardi Gras party.

A good friend of mine was telling a story about the previous weekend’s deployment, which took 16 hours to complete. The team took pride in working this long, grueling day, celebrating in hard work paying off and rewarded with extra days off. It seems that, while hard work should be applauded in any organization, employees were hesitant to use automation because it could result in less work for them. The fear is automation could make them less important to the organization, and possibly end in the loss of their job. A DevOps change is not complete until the way the organization values work changes.

If DevOps goals are to complete tasks faster with as much automation as possible, praise and rewards should focus on these elements and work to discourage laborious efforts that could be automated.