Have you ever come into a company and looked around and wanted to change everything so it’s new, modern, and follows best practices? Or have you gone to a conference and taken a ton of notes on how you could fix processes in your organization when you return? If you have, you probably found out the hard way that change isn’t easy. Organizations are not always receptive to change, especially if just one person is advocating for it. What you can do is help people in your organization see the value of that change.

Before you can convince anyone to undergo any kind of change, let alone transition to a DevOps model, you have to be sure you understand why the existing process is or isn’t working for them. I mean, would you like it if someone came along and told you that the way you read email is all wrong and you have to change it to this new way? (I’m looking at you, Google Inbox). Probably not, unless there was an obvious value to you changing. And in Google Inbox’s case, it does a pretty good job of sorting mail into categories, which means you context switch less between emails (okay, we’ll give it a try).

So, if you want to introduce DevOps best practices to your organization, you have to prove that the new way of doing things will be an improvement.

Before we dive in, let’s level set on what we mean by DevOps. It’s important to note is that DevOps is more than just automation. Just as important, if not more important, is fostering a cultural shift in the software delivery process. Along with automation, it’s critical to focus on improving communication, collaboration, sharing, and measurement that facilitate iterative improvement. In this article, we’ll focus on easy wins as they relate to automating tasks, measuring success, and sharing learnings to help boost efficiency across any team.

Find the Pain Points

Start by finding the pain points in your organization by looking for the situations where people are doing repetitive or manual tasks. That is the low-hanging fruit of the DevOps world. Focus on automating things so that you have more time for interesting problems instead of routine things like tests and releases. Look out for processes like routing requests, provisioning systems, or approving changes — which can also be major pain points for teams.

One way to find these pain points is to go to parts of the organization that do customer-related work and ask them what they spend the most time on. It’s very often some routine task that could be easily automated if only they had the resources to do so. IT and support teams are very clear about what they could get off their plates with a little scripting, or at least very clear on what they do over and over again. Every time you automate a task, find out both how long it took before and after you automated it, and present that saved time as an opportunity to do more similar, interesting things. Don’t forget to share your learnings with other teams.

Be Like Kale in a Smoothie

Because people don’t like change, sometimes it’s more effective to disguise efforts around change until people are used to them (you know, like the kale in your delicious smoothie that you didn’t know was there?). You don’t have to say anything about culture change just yet — just start small with things like:

• Taking action items that occur multiple times in meetings and find a way to automate them.
• Working with the people who manage on-boarding to script as much of the on-boarding process as possible to make new hires productive more quickly.
• Holding hack days to work on particular parts of your product or culture that could use some focused attention.

For example, you can set aside one day for a documentation hack day where everyone sits together in a conference room and works on deleting outdated information in the wiki or replaces confusing instructions with better ones. Give prizes for the person who makes the most documentation pull requests or finds the most typos. And by including people from multiple teams, you get the opportunity talk to each other about whether the documents are working for your needs.

A positive effect of gradually introducing automation and facilitating inclusion, in a DevOps fashion, is that you’ll already have projects you can point to that have made a difference. “We did these four things and reduced on-boarding time by a week. We could do the same type of thing for server imaging!” As your team gets more efficient, you can also offer to teach other teams about your magic tricks, and help more people get back time that can be spent on higher-value tasks.

See Something? Say Something.

As a person motivated to improve process and tooling, you’re valuable to the company. What organization doesn’t want to discover new ways to save time and money, and increase productivity?

Be an agent for change and act on your ideas around automation, observability, and useful metrics that can help your team collectively improve. Do as much as you can in your organization to make the value of a DevOps mindset clear. You may not be able to go “full DevOps,” but a few little things here and there can add up to a lot of time saved and maybe even convince your teammates that there might be something to this “DevOps” thing after all. And if it doesn’t work, document everything you did to try to make it work and use it as a point in your next adventures.

Get started on the road to change by checking out these six DevOps case studies. These companies have already made great headway into modern software delivery and contain a treasure trove of tips and tricks, as well as tried-and-true implementation strategies for rugged DevOps that can help any team. Be sure to also check out our webinar, ROI is the True Measurement of DevOps Success to learn the impact of embracing DevOps on ROI and to members of the organization, why enterprises shouldn’t be afraid of DevOps, and much more!