10 Ways to work WITH Developers to take action with FinOps/Cost Optimization

When FinOps Practitioners share recommendations for cost optimization, they can often be met with a “No”, a “I can’t right now”, or “It’s not my priority” from a Developers (Devs). According to the FinOps Foundation’s “State of FinOps 2023” report, the number one pain point was getting engineers to take action. But, I am here to say, “It’s not the Devs fault!” We spoke with customers who have overcome this roadblock and want to share the lessons learned with you! This blog will walk through 10 ways you can work with your engineers to establish a FinOps culture at your organization.

Don’t blame them

Recently we heard “Devs should just know how to optimize”. While there is some truth here, Devs may not know you expect them to do this or what the best practices are at your company. So, when working with Devs, give them the tools and information, so they can prioritize actions in their daily work. Three things to do:

1. Educate them when they onboard. Showing what is expected from them when they start will not only educate them, but also allow you to refer back to optimization basics and role expectations in future conversations.
2. Give them the tools to succeed: Every time you provide a recommendation to make a change to optimize, give them a link to how. Telling them to go do something but making them to find out how to do this by themselves adds work to their plate and is a frustrating experience.
3. Estimate how much effort the task will be: Adding a simple bit of information (e.g. 3 mins completion time) will show that this is not as big of a time investment as they think.

Give them a chance to shine

Don’t you love being told you did a good job? Well, your Devs feel the same way. When there is an optimization success story, shout it from the rooftops! Showcase it in a monthly cadence call, highlight it during a standup, or create a recognition process. Highlight the success will do three things for you:

1. Provide positive reinforcement for Devs, so they know that the work they do in cost optimization is important.
2. Inspire other teams to do the same. When someone else has done the hard work of testing the optimization, the other Devs are more likely to follow.
3. Gain optimization alignment. We have seen great success with the FinOps Champions concept. This is where Devs become advocates for FinOps. This takes the pressure of the FinOps team and connects you with more technical teammates.

Build trust

As a FinOps Practitioner, working with Devs to ensure they take your recommendations seriously and follow them can take time. Devs need to know that the optimization recommendations you are giving them have been verified, because if it goes wrong, they may get the blame. For example, deleting a resource that seemed idle but was an important backup. It is your job to be rigorous with your data. One bad recommendation will delay others from acting on your suggestions. In simple terms, validate your recommendations.

Don’t try to boil the ocean

Optimizing one service across an entire organization can seem like a simple way to start, but when you look closely, it can be too much to handle at scale. So, start small. Narrow down your scope of optimizations. You could focus on a single optimization activity, such as gp2 to gp3 for EBS, which can save 20% (read this blog). Establishing a single focus across your business at a time will increase adoption. To do this, set up a recurring campaign, monthly/quarterly, will keep momentum going. For example, optimize all gp2 to gp3 volumes that can be changed. You can use unit cost (read this blog) to track how the work impacts your applications.

Keep yourself accountable

If you have infrastructure you are using in your FinOps team, practice what you preach. Run an optimization review of your spend and see how you can improve. This will give you the opportunity to learn more about what effort is actually required to optimize a workload. You can empathize with Devs, as you have been through it too.

Integrate with how they work

The way we share a lot of optimization opportunities is through downloading excel sheets, but this is not how Devs work. They work in sprints and tickets that have been pre-decided for their workload. If you send them an email with an excel with a bunch more work to do, how do you think that will go? Work with the project owners to get tickets put in with the right information, in the appropriate format, and with the correct priority, and it’ll get done. Using a ticket will help you to log and track optimization efforts over time. (Also, don’t forget to link to that documentation you shared in these tickets).

Give them access to their own data

This point may sound obvious, but Dev’s don’t want to click lots of drop downs to see their spend or jump across multiple AWS accounts to get the full picture. When providing data, cost or recommendation, giving them access to just their data and give it to them through one pane of glass. Two benefits to this are:

1. Lowering the number of clicks on a dashboard or tool to filter to see their application costs will increase their engagement with the tool by making it more user friendly.
2. Showing them their impact will make optimization data more powerful. For example, if they see that the company could save $1k on gp2 to gp3 migrations, but their project only accounts for $3 of that, then they may think “why would they bother doing this for $3, it’s not important?” However, if you showed them their numbers allows them to see it in comparison to their own spend, and not compare to others. “I could save $3 of my $20 account spend, I should fix that”. This will establish ownership and ensure they do the task.

For more information, you can read this blog on Row Level Security with the Cloud Intelligence Dashboards.

Hold them accountable

It is a Dev’s job to know that the work they’re doing is optimized. The same way as they should know what security precautions they have put in place. Putting ownership on them to plan effectively starts them off with designing with cost in mind. You can use both AWS Pricing Calculator and check out infracost, which enables cost estimates at creation of pull request. Try adding a cost and utilization review, once a project is built. Having this cost data in front of Devs and showing that they are measured on efficiency and cost will encourage them to take ownership and improve development.

Set defaults in code

Take steps to set Dev teams up for success through governance, best practices, and guardrails. Make it easy for them to make the right choice. By using defaults in Infrastructure as Code, you move away from reactive to preventative cost optimization. Some examples of defaults you can set are Graviton for managed services, gp3 for EBS and Amazon S3 lifecycles polices for unnecessary objects like delete markers. Now, you won’t need to chase down Devs to make a change, since it’s there from the start!

Encourage them with new technologies

Who doesn’t love a new toy? Devs enjoy working with new AWS technologies, and luckily for us these new offerings are often more cost optimized. Give people time to try new things, such as moving to serverless, trying Spot for containers, or migrating to Graviton. The time aspect is important as this work may feel outside of their normal job. Set up workshops or trainings with you AWS team to educate them on these tools.

Final thoughts

With all these tips the most important part is building the relationships with your Dev teams. After all, you are all working towards the same goal of making your business successful.

To learn more, checkout this video. “How to empower software engineers to take action” from the AWS Twitch show, The Keys to AWS Optimization. If you have any follow up questions or want to share your best practices email costoptimization@amazon.com.