Since you are reading this post, I am sure that you can relate to the classic plight of the IT, sysadmin, or Operations team: They are invisible until things go wrong.
For practitioners of DevOps and Site Reliability Engineering, that can also be true, especially for teams where the low-hanging fruit has already been addressed.
When the big outage happens, it’s all too common for management to have the kneejerk reaction to ask questions like “Why didn’t $TEAM prevent this from happening?”, and “What have they been doing instead?”. Even worse, management can start to wonder why they invested in DevOps/SRE/Platform Engineering/etc in the first place.
This article describes how to clearly show your value delivered to a tech company as someone who focuses on non-functional requirements such as operability, performance, or reliability. This is important, especially for organizations that haven’t yet undergone the cultural transformation to where investment in these aspects is naturally valued and rewarded.
Focus on Impact
One of the biggest takeaways from my experience working at Meta was the following mantra:
Focus on Impact
It was everywhere: posters in the office, hiring marketing materials, employee onboarding materials, and in the mouths of engineers. Needless to say, it was deliberately introduced as a core value.
“Focus on Impact” simply means that there must be a return on investment for the time and effort towards the work you decide to do. You need to be able to demonstrate that your activities benefit the business in a meaningful way, especially when compared to the standard of software engineers delivering feature work.
So what work is ‘impactful’ in our context, you ask?
The Goal of Every Business
Since your work is ultimately evaluated and rewarded by management, we need to think like a manager to answer that question.
From the book “The Goal” by Eli Goldratt, the goal of every business is to make money by increasing throughput while simultaneously reducing inventory and operational expense.
Let’s rewrite that sentence in terms of a SaaS company, since ‘inventory’ is a concept unique to manufacturing:
The goal of every SaaS is to make money by increasing sales/subscription revenue while simultaneously reducing the amount of unreleased code and the expense of operating and supporting the product.
Next, let’s unpack these ideas:
- Sales/subscription revenue: this is enabled by the delivery of features that customers want. Generating revenue itself is outside of our control (sales, marketing, product management, market research), however, activities that reduce friction in this process are valuable.
- Unreleased code: consider code in the development/test/deploy pipeline has yet to produce business value. In addition to that, it comes at the cost of time spent by engineers writing it. This is traditionally a problem focused on by DevOps practitioners via the use of CI/CD.
- Operations/support cost: this consists of the costs involved in running infrastructure, time spent by the team operating the product and being on-call, supporting services such as observability platforms, time and money spent on infosec and compliance, as well as customer success teams providing support for the product. This is typically the problem space SREs work in.
Common to all of these concepts is that they all can be expressed in terms of time and money.
Our Goal as Tech Professionals
Therefore, our goal is:
Demonstrate that our work saves/makes money at a proportion significantly larger than what we are being paid.
The following may seem cold and cynical, however: a business expects a return on investment when hiring you. The burden of proof is heavier on activities that don’t directly tie to sales numbers, especially for teams considered a ‘cost center’ like traditional IT and Ops.
Let’s discuss some ways we can better show our value to the business.
Everyone Is In Sales
Tom Erickson (my old CEO when I worked at Acquia) often said:
“Everyone is in sales.”
Originally, I hated that quote, as I felt that more people in the company needed to understand how the product was operated and supported, not just sold.
However, my career in SRE showed me how right he was. We have to sell the importance of the work we do to incentivize our peers to want to collaborate with us, especially if we are the one person embedded in a team as is typical with SRE engagements.
This means placing continuous effort toward communicating our plans and accomplishments. Here are some examples:
- Add a value proposition for every OKR, project, or task you create, prioritize, and work on. Remember to express the potential time or money saved, and don’t be afraid to be ambitious!
- Measure the impact of your work using your observability platform and display the results on a dashboard.
- Track all significant wins and their supporting metrics. With them:
- Communicate these wins to your team, department, and even customers when appropriate.
- Discuss them with your manager to support favorable performance ratings/promotion cases.
- Add them to your resume/LinkedIn profile
As you establish a track record of identifying and delivering impactful work, the organization’s perception of you and your team will of course improve. However, this also opens up additional opportunities, such as growing the team, expanding your scope and influence, promotions/raises, and possibly more lucrative job offers at other companies!
Conclusion
Demonstrating your value as a DevOps practitioner/SRE at a tech company requires a strong understanding of what work will make the greatest impact towards revenue and operational cost, consistently delivering on that work, and effectively communicating it across the organization. This is especially important for companies that value delivering new features at the expense of everything else.
Are you struggling with moving the needle on how your company sees your team’s significance and efforts? Schedule a call with me and let’s get to work!
(Image produced by OpenAI DALL·E 2 with prompt “computer monitor displaying graphs and dollar signs, digital art”.)