On paper, being an SRE may look nothing like being in sales. But in reality, and especially if you work for a startup, there’s more overlap than you might think. We’d bet that every SRE can remember a time when they had to pull out all the stops to convince the team to adopt new tools and processes. In fact, the best SREs are constantly cultivating their influence in different ways.
Why is influence so important for SREs? Well, if you ask the typical engineer what they care about, “reliability” probably isn’t at the top of that list. Every single team would agree that reliability is essential, but —… and there’s always a “but” — there’s an endless number of bugs in the product to fix, there are P0 customer features to work on, and the site seems to be up and running. Left to their own devices, engineers will always find excuses to worry about reliability “another day” and so it never gets prioritized.
Nobody likes to be the bad cop. OK, maybe some people do, but they’re not usually the kind of people you’d want on your team. These tips will help you improve your influence as an SRE so you can do less nagging, add more value, and accomplish your goals with confidence.
Why does your organization have SREs in the first place? You might have even asked yourself this question in a moment of frustration when you couldn’t get anyone to listen to your recommendations. And actually, it’s the exact question you should be asking.
Your organization has SREs because reliability is essential. Arguably more than most work that happens at the company, reliability impacts the business bottom line. (As an oversimplified example, when the site is up, you’re making revenue — and when the site is down, you’re not.) The more that you can show that business value, the more you will improve your influence.
To highlight the value you bring to the organization, make sure that your SLOs are tied to business processes and requirements. If you can attach a dollar amount to each SLO, you’re more likely to have an impact. Even something as seemingly abstract as developer morale can be measured. Think about how often your engineers are paged about issues. Does a 1% difference in uptime mean that you’re paying for an extra 10 hours of engineering time per month to keep the site alive?
Building a relationship with engineering is essential to being influential. When you join an organization that hasn’t traditionally had an established SRE team, if you start trying to kick off a top-down process, you’re probably going to meet a lot of resistance. You don’t want to spend all your time chasing people down and telling them what they have to fix.
Whether you just joined the organization or are simply looking to have more impact, it’s a great idea to schedule time with each team to sit down and actively listen to what their pain points are. Are they having reliability issues? What do they want to improve, and how can you support them in that process? Approach engineers as a partner and show you care about solving their problems and making their lives easier.
Finally, be careful about how you implement gates. For example, imagine you want to start enforcing some requirements for each build. It might be tempting to add a check to your pipeline that looks at the Dockerfile and blocks the build if these requirements aren’t met. But that’s just going to create resentment and create an “us vs. them” mentality with engineering. Instead, make an announcement saying that in two months, you’re going to add this gate. And over-communicate why the decision was made, explaining how the gate will help the engineering team build better software and have fewer on-call emergencies.
If you’re joining a newly established SRE team at a startup, the engineering organization is most likely growing fast, and the number of services is skyrocketing. Before you know it, you might have 50 different services playing by their own rules — and you could even be trying to report across multiple APM tools and deployment systems.
As an SRE, you should seize the opportunity to influence decisions on best practices and tooling while the organization’s systems are still immature. Drive conversations with engineering about what tools the team should use, what on-call rotation best practices should be implemented, and what you want to incorporate into your production readiness checklist.
Try to reduce friction at every stage of your process with standards and automation. For example, instead of everyone having their documentation in GitHub or markdown files, you might pull this information into a wiki. And if you want all your services to be reporting on certain SLIs, work with your DevOps team to set up dashboards. This will show how much you value the engineering team’s time, improving your relationships and helping your influence grow.
As an SRE, instead of yelling “don’t shoot the messenger,” it can be a real life-saver to remove yourself from the messenger role altogether. Instead of having to tell people that their services aren’t meeting requirements, you can become more influential if you give them (or their managers/leadership) the tools to see exactly how they’re doing.
We built Cortex’s Scorecards to address this need. At a glance, Scorecards automatically grade against reliability initiatives you define. Everyone can quickly see whether requirements are being met and know where improvements need to be made. Scorecards enforce very objective requirements, which helps you save time on evaluating services and get buy-in from the team.
Cortex also has a new feature, called Initiatives, to help your team make tactical progress towards your objectives. With Initiatives, you can set a reliability objective and a deadline, and everyone can see precisely what needs to be done for each service and how each scorecard is tracking towards the finish line. Scorecards and Initiatives have been very empowering for engineering teams.
We hope you can put some of these influence-enhancing tips into practice with your team. And if you’re looking for a solution to help you implement these best practices, manage your microservices, and more, you can sign up for a free demo of Cortex here.