So you keep hearing this DevOps word, and you think you have an idea of what it is, but you don’t know where to start? I hope my post today will help you start the journey, this is planned to be a 3-part series on pitfalls I have witnessed and solutions my colleagues and I have been working on for years. They are not guarantees, but they may help you avoid failure and present some solutions to help navigate the incredibly tough journey called “DevOps Transformation”. This post is geared toward anyone wanting to balance a transformation and get your teams to the next level.
What is DevOps?
If you’ve been following DevOps over the last decade, you’ve heard it be defined then redefined over and over. Everyone has an opinion about what it means to them. Similar to “everywhere uses Agile, but what flavor?”
The best definitions are simple:
“DevOps is the culmination of behaviors, community, culture and technical talent coming together to improve the SDLC through tools, technologies, psychological safety, trust and people.”
Why is it still so hard?
Change is hard — it always will be. It is even tougher when it involves people from different disciplines, across different domains, different time zones, etc. Through the abstractness of the SDLC process and how each team works, DevOps transformations usually involve a lot of process change. Combined with environments of fear, corporate politics, and “red-tape”, it provides a very complex challenge for any organization. There is typically no time to stop new product development, so this shift has to happen while feature development continues, but the opportunity cost is well worth it.
In order to get the transformation underway, you have to change almost every way you are doing work today. In many cases, this weight falls solely on the shoulders of the Development team, and in some cases the Ops side is clumsily integrated with the dev team. Worse, many companies feel like this can simply be done with a tool or offshoring a DevOps team. I have experienced many companies buying the new shiny tool then calling themselves a DevOps shop. Reality is, this is not even close.
Most companies that say they are “doing DevOps” aren’t
Unless the company changes their culture around delivery, then the transformation will fail. Chances are if you get all the teams in agreement, then you will still need to hire a few new DevOps people, which leads to our next dilemma.
There are no such things as Junior DevOps
One of the hardest parts is simply hiring someone qualified. This leads to the temptation to hire a more junior individual. While this might seem ok, you will find they know only a subset of the skills required, and if there is not a model at your company to mentor, this person will not stick around long. On the other hand, if you have a Sr. DevOps Engineer on staff and building a team, a more junior role can work as long as proper mentoring is facilitated. So, you may ask, why it takes at least one senior?
Here is a subset of knowledge needed for a typical DevOps transformation in 2019:
- Impeccable SysAdmin Skills
- Virtualization experience
- Multiple OS background
- Scripting background
- Development background
- Provisioning, configuration management experience
- Git, version control experience
- Automated data pipeline experience
- CI/CD orchestration experience
- Container Experience
- Cloud experience
- Cyber Security Experience
- Infrastructure as code experience
There is more experience needed depending on the transformation, and much of this list takes years to become proficient in. This helps paint a picture of why this can lead to team cognitive overload. When a team that only focused on programming is now being asked to build Emotional Intelligence (EQ), and then learn about server management, security, pipelines, and deployment infrastructure, it can be a heavy burden. Even worse, it can lead to mediocrity in implementation if the team is not properly trained. Which can lead to vulnerabilities in security.
Be Careful of Cognitive Overload
So, maybe up to this point you have heard some of this. One of the main areas that I feel is not talked about enough in IT is mental well-being. Many places treat IT like a machine, including the people. Or worse, just a money pit. If you hired well, you have some of the most knowledgeable people in this organization that if leveraged the right way can exponentially cover their cost. It all comes down to initiatives and planning, but no one has time. What’s the most common response I get when I ask almost anyone how work is going? BUSY. Everyone is always walking the line of mentally stable/unstable. It’s no surprise that many want DevOps but have no priority or time to implement the change. A common solution is to work more overtime or try sneaking in changes each sprint. This is a recipe for burnout.
The first step to any DevOps transformation is for management to assess the team’s well-being and capability in bringing on such a massive undertaking.
The business side must be onboard with the changes and expected challenges, meaning time needs to be allocated from the “top” to allow for the shift. Otherwise, consider this dead in the water.
If your assessment looks good, and time can be given in each sprint, then you are good to go. I highly recommend doing check-ins with your teams every sprint to make sure teams are mentally doing well.
The Fine Line of Team Morale & Burnout
Extending beyond an individual’s mental health is the collective morale of the team. This type of transformation is stress-inducing and can take years to complete. The last thing you want to have happen is increased team attrition, negativity, etc. I cannot stress enough that it is imperative to plan out the steps and start by figuring out very small wins within the development team that initially help speed development delivery. Make it fun again to develop, build and deploy.
Unfortunately, this seems to often play out as “We’ve renamed the group, so we’re going to be letting most of the team go, because we’re “DevOpsing” all the things now and being lean and mean. Also, the developers are still a separate group and they’ll be throwing more stuff over the wall to you.”
So you end up with a few overworked, traditional Ops folks trying to keep the wheels on the bus with zero changes to the way work is managed or how the IT group functions day-to-day. Their manager is shouting down the hall about automation while the poor Ops team is trying to pivot a SAN-installing, server-racking skill set into something that looks like a cave-man version of coding.
In my next part, I will dive deeper into more specifics around the development workflow and of my roadmap. This culture shift leads to smaller but iterative change and “feeds” from itself to continuously show value to leadership. Thank you for reading, and I hope you are able to get a starting picture of how to implement this into your daily work.
Who am I?
I am a passionate technology leader and open source developer with 15 years experience working as a QA, Full Stack Developer, Technical Lead, Director of Engineering, and CTO. I have worked in corporate and startup settings, and consulted for many smaller companies on how to create and maintain best practices for IT.
Currently I am a DevOps Enterprise Architect, consulting with the Air Force on implementing a DevOps transformation.
Check us out @ https://centil.io
Like this? Feel free to reach out to me at https://www.linkedin.com/in/dwetteroth/