DevOps has taken the world by storm in recent years. The job boards, forums, Facebook groups, etc. are all exploding with DevOps positions, DevOps tools and DevOps events. This post is about best practices in facilitating a DevOps culture in your organization. It’s easier to do your job as a DevOps expert when everyone are on board.
DevOps Best Practices for facilitating a DevOps culture in your organization
Best practice #1 – get the management team on board
You certainly know your craft well: you can deploy CI/CI Jenkins pipelines with your eyes closed and scale a Kubernetes cluster with a hand tied behind your back. However, your work will be much easier, more rewarding and fulfilling if you can get the upper management (C-level executives – primarily the CTO, CIO and CEO) in your organization to be on the same page with you. Many managers and executives have started their careers way before the term “DevOps” even existed. Let alone was popular or dominant in the IT marketplace. Thus they lack the “DevOps mindset”: They do not always understand what is the role of a DevOps professional (Helpdesk/Infrastructure team with a different name?), why do you need more resources (“Did you see our last AWS bill?”) and why do they still hear complaints from customers.
As stated above, this may cause them to not be as willing as you might hope to allocate resources (cloud budget, commercial tools), acknowledge your contribution during the annual (or bi-annual) performance review and hire additional staff to help you with your day to day tasks . Regarding the last point – In many organizations the DevOps expert does general infrastructure work for the organization as well (think of setting up office365, making sure the Wi-Fi network works) and even Helpdesk tasks (“Why the Zoom meeting has no sound?”, “Can you replace me the keyboard to something more comfortable?”). Getting help will allow you to focus solely on DevOps.
What should you tell them?
So it’s part of your job to advocate to upper management the things that you know and why they should pay heed. It’s up to you to explain to them, for instance:
- The benefits of CI/CD pipelines compared to manual deployments. Better reliability, lower downtime, deploying more features to production and overall increased productivity
- The benefits of containers over legacy VM deployment. A lightweight solution, enables you make sure that the code works on the developer’s machine and on production as well without changes and/or breaking things and etc.
- Get them to understand the “DevOps Mindset”. Explain to them that the role of DevOps is to optimize the way the organization works. You are the DevOps expert and sure – on the technical side of things you are the authority on everything DevOps. But in order to succeeded in your job, you need the organization as a whole to adopt the DevOps mindset. The organization as a whole should allocate time and money to facilitate this culture of rapid change and optimization. Which brings me to my second best practice:
Best practice #2 – get the developers on board
Developers are the core stake holders you’ll work with most of your day (except for other DevOps Engineers of course). Bringing them on board can make a lot of impact on your success. Bringing the management on board is only half of the story because you still may run into trouble if you don’t get the developers’ cooperation. The developers by their job’s nature are more hands-on and more tech oriented so they usually have a better understanding of what DevOps is and is not. But the developers should understand the DevOps mindset as well and the way you can help each other.
If the developers’ don’t understand how a proper DevOps culture can help them, they will be less appreciative of your work and you (and your manager) will get less positive feedback. For instance, if developers don’t understand that you can shorten their build time – they might not even approach you with this problem and you might stay unaware of it. Or as another example – if developers don’t know that you minify JS files as part of the build pipeline they can feel frustrated and waste time on figuring out what has happened to their files.
What should you tell them?
It’s up to you to explain to them the ways in which you can help and hear them out on their problems. In addition, it is important to decide what tasks falls on the developers’ part and what is under your jurisdiction. Should developers create their own docker files or is it something DevOps Engineers provide? If there is a production bug – are the developers on call too or just the DevOps guys? Is it up to you to come up with suggestions for improvements for the way you build and deploy your code? Or is it something that should come from the programmers? and etc. A good collaboration between the DevOps Engineers and the developers will make the life of both sides easier and will contribute to productivity.
Best Practice #3 – communicating results
They say that good job shows, but this is not always the case. At least it doesn’t always show immediately. If you clearly communicate your results and successes to the different stakeholders in your organization you’ll promote better understanding of the benefits of DevOps. Once people see the fruits of your labor, they are more likely to approach you with additional challenges. They are more likely to appreciate your work and give you positive feedback. This form of internal marketing also reinforces the things stated above in Best Practices #1 and #2. The more clearly you communicate your results with developers and upper management – the better. Examples for things that can be achieved and showcased:
- Shortening build times by X percent
- Improving production availability by Y minutes a month and Z percent
- Saving T time on solving production issues via implementing a centralized logging system
- Shortening the development to production cycle by T’ man hours a month by implementing containers on the developers’ machines
- and etc.
Try to set up a weekly or bi-weekly meeting with the R&D managers and another monthly meeting with upper management. Create a great looking presentation highlighting bullet points like the ones described above. Try to quantify your results as much as possible. “Streamlining the deployment process” is nice, but stating that “The company has saved 50 man hours a month” is much better.
Conclusion
In this post I’ve have discussed the best practices for facilitating a DevOps Culture in your organization. I’ve discussed the importance of getting upper management on board with you. Why this is important and what can you do about it. I’ve stated the importance of getting the developers on board as well and why this is considered a best practice. In addition, I’ve outlined that good work doesn’t always show (at least not immediately) and why it’s important to do a bit of internal marketing. In conclusion – your success in your current job and your career advancement doesn’t depended solely on your tech skills. Facilitating a DevOps culture can make your job more rewarding, fulfilling and enjoyable. Likewise, it can improve and ease the work of other stake holders in the organization (as discussed: primarily developers) and last (but not least of course) improve the company’s bottom line. After all, that’s what DevOps culture and DevOps mindset are all about.