.svg)
Three Ways to Better Appreciate your SREs and DevOps Engineers
DevOps engineers and Site Reliability Engineers are vitally important to the continued health of your product and business. We all know it’s true, and yet people in these roles often feel underappreciated and undervalued. This sort of work runs into the issue of “when process and infrastructure break, it gets shoved in the spotlight; but when everything works perfectly, no one notices.”
Work in this category is often described as “glue work” – it holds everything together, but can become invisible if you aren’t highlighting it. Employees that feel underappreciated have no incentive to go above and beyond, and are more likely to move to other opportunities. Moreover, they likely are being underappreciated, missing out on opportunities to advance in their careers and make a bigger impact because their work is undervalued.
We’d like to try to shift the tide on this all-too-common sentiment with these three suggestions.
The foundation of appreciation
Before we get into our specific suggestions for the world of DevOps and SRE, we’d like to reinforce some necessary aspects of showing any employee that you appreciate them.
- Competitive compensation – if your employees aren’t being compensated, with salary and/or equity, at a competitive market rate, they’ll want to explore other options no matter what
- Comprehensive accommodation – giving employees flexibility around remote working, ample paid time off, health plan coverage, and accommodating other needs is necessary to get good performances from employees and retain them
- Psychologically healthy work environment – employees need a space where they feel safe and supported to experiment, make mistakes, and speak their minds. Otherwise, they’ll never reach their full potential
We hope that this goes without saying, that it represents the baseline for appreciation. However, we’d argue that these things are necessary but not sufficient for SREs, DevOps engineers, or other infrastructure engineers to feel truly appreciated.
Celebrate their achievements (and let them have the mic)
Major feature releases from developers are often highlighted and celebrated, in everything from spotlights in all-hands meetings to full-on launch parties. The same culture should be built up around process upgrades, resolutions for big incidents, and other infrastructural milestones. Here are some examples of projects you should track and highlight in the SRE/DevOps space:
- A new process was built and implemented
- A major incident was resolved
- Systemic changes were made to prevent a recurring incident from persisting
- Updates were deployed faster or with less issues than before
- A milestone was reached for fully written and reviewed retrospectives
When you highlight these achievements, encourage the people responsible to speak. Their proximity and passion will make their explanation more compelling, leading to further recognition and appreciation among their peers. Plus, giving them these opportunities will improve their self-advocacy and presentation skills, furthering their careers and impact.
Practice boundaries around job descriptions
One of the most common sources of feeling undervalued is duty dilution. People performing “glue work”, such as DevOps engineers and SREs, often find themselves asked to handle random, ad-hoc tasks. These tasks could include:
- Organizing and running meetings to explain new process
- Making ad-hoc testing scripts for debugging
- Working with developers in the codebase
- Keeping stakeholders informed on incidents
- Documenting anything and everything
These engineers likely are responsible for these tasks in some circumstances, or similar tasks. Because of that, managers are inclined to slowly inch their duties wider and wider. Because these expanded duties aren’t part of any job description, they’re very unlikely to be formally (or even informally) recognized and appreciated.
Each individual ask may not be big, or may be promised as a one-time thing. However, as these accumulate and become expected, they add up to a significant time sink and source of stress. Often these tasks are extra toilsome because of their ad-hoc nature, but investing time into the process around these tasks can seem pointless.
Maintain boundaries around what you ask of people. Don’t just assume someone can handle it because “they normally do”. Have proactive conversations about how big a lift the task could become if they become expected to maintain or reproduce it. Most importantly, ask yourself: “do I really need this done?”
Invest in tooling to reduce toil
The most impactful way to show engineers appreciation is to materially improve their job experience. Cut out toilsome or tedious tasks, and empower their work on meaningful, impactful, and interesting projects. The best and easiest way to accomplish this is investing in tools.
To be clear, there’s nothing more tedious than being forced to adopt a tool that you don’t need. You can’t just grab random products off the shelf and hope that they’ll help. Instead, work with your teams to figure out what processes are most toilsome, then research solutions together. Surveying has found that tool sprawl (the sheer number of tools in a stack) isn’t a common or significant problem for most organizations. So there’s room for more tools – provided that they’re useful.
Fortunately, tooling keeps getting better and better. It used to be that building a solution in-house would afford you more flexibility and integration. Nowadays, off-the-shelf tooling can provide everything you’d need at the fraction of the time. Most importantly, it shows appreciation for your engineers and their priorities. Rather than encroach on their boundaries with the new task of building a tool, invest a relatively small amount of money to save them hours and hours of time.
Show your appreciation with Blameless
When we talk about great tools that reduce toil and empower meaningful work, right out of the box, Blameless is at the top of our list. We take the headaches out of incident management, allowing your engineers to focus on solving the problem. When the incident is resolved, we empower engineers to make meaningful improvements, with automatic retrospectives for each incident and pattern tracking across incidents.
.svg){kind=icon}
