.png)
Throughout my professional career, I faced situations and challenges that were crucial to my growth. What has always intrigued me about the world of DevOps is how each company interprets this practice and applies different approaches.
"DevOps" Means Different Things to Different Organizations
As a mentor used to tell me: "Every company is a universe," and I couldn't agree more. This becomes evident when asking a simple question during an interview: What does a typical workday look like? The different answers never cease to amaze me.
When I imagine how a DevOps team should be, I envision a group that collaborates closely with developers and quality assurance teams to simplify their daily routines. This way, professionals can focus on what they do best: creating solutions. Aspects such as where the application is hosted, what type of server is used or how the environment is configured should be the responsibility of the DevOps team, with guidance provided by the architect.
Why should a company care about how the DevOps team functions or collaborates with other areas? The answer is simple: the DevOps team is like the quarterback in American football. Our job is to take the ball, run the play, call the next play and execute the gameplan to achieve victory.
As DevOps engineers, we are enablers, existing to support the development team and make their work smoother. We want the dev team to focus on creating solutions, while we take care of the infrastructure and its proper deployment.
The Issues At Some Organizations
Unfortunately, in my experience, this isn't always the case. Many companies have adopted the term "DevOps" by simply renaming their operations or support teams. These operational teams often do not apply DevOps practices.
Their success is measured by how many tickets they resolve per month, and they have minimal interactions with development teams. They rarely question the "why" of things. Why does this team need a new Kubernetes cluster if we provided one last month? Why does their application need to scale twice as much? The question "why?" rarely arises in these cases.
Many companies have adopted the term "DevOps" by simply renaming their operations or support teams. These operational teams often do not apply DevOps practices.
The Four Pillars of DevOps
So, what does a DevOps team represent to me? A DevOps team should be a business enabler. Questioning and understanding the reason behind development requests is fundamental and our first pillar. How can we help if we don't fully understand the requirements?
This leads us to the second pillar: planning. As enablers, we must be proactive and work together from the start of projects. We must understand the business priorities and, based on that, develop an action plan that allows developers to work effectively.
Automation and quality are the third pillar. As a DevOps team, we must automate any process that repeats more than once. Some time ago, while analyzing a client's situation, the operations team told me about a task they performed manually. It was a one-time task for each client when they had a new release, which happened monthly.
What do you think was the operational cost of this task described as "simple"? In the analysis, we understood that this task was performed manually 64 times (once per client) every month, costing the team four hours of work per client. By automating it, we reduced the operational cost by more than 50%, allowing them to reclaim 30 days of work in a year to focus on more productive tasks.
Finally, this brings us to our fourth and final pillar: metrics. How do we measure the success of our DevOps work and teams? There is much discussion about this, and I believe Nicole Forsgren details it very well in the book "Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations."
We cannot measure our DevOps teams by resolved tickets or story points. We must take business units that truly matter in the area:
- What is the deployment frequency?
- What is our lead time?
- How long does it take us to recover from an incident?
- What is our success rate?
The key here is not to overthink. Understand that measuring under this methodology is a long-term investment.
Next Steps With Your DevOps Team
The first step is to understand where we stand today. The second step is to start planning how we can be better for the next quarter, focusing on just one of these metrics. Why only one? Because starting to measure our teams in this way will bring about such a cultural change within the organization that the last thing we want is to stress our team.
So, take one metric and plan how to improve it together with your team. You'll see that little by little, everything starts to improve. The speed and productivity of your team will increase, they will feel more confident, and other teams will trust you more, too.
In summary, a DevOps team should work in collaboration with development teams, not just work for them by resolving tickets.
Stay tuned for my next article, where I will explore the four types of DevOps teams that exist, how to identify which one you're in, and how to transform your team into an Enabler.
