I worked for a company a few years back, for a short time, who bought engineers crappy Lenovo consumer laptops with a halfassed installation of Linux Mint and a resolution of 1368x768. They would not invest in appropriate processes/tools to run an agile development shop, but wanted to brag to investors and clients about all the usual buzzwords. Engineers spent forever shelling through machines to find logs in staging, production APM was half-implemented. Everything was a poorly-implemented open source project with no contributions upstream. The teams other than my greenfield team were mostly self-taught, previous college interns.<p>I say all of that to say this. Allow your engineers to save you money. The bean-counters frequently in finance/accounting working the balance sheet don’t know the first thing about saving money where it actually matters. Everything that company did was mired in technical debt and took easily 3x the time it should have taken with proper tools, processes, and staffing. It frequently cost them productivity towards reasonable deadlines all the time.
Make it a part of their bonus structure. Why should I spend time to save the business money if I get paid the same? My incentive is to hit my KPIs to get my bonus and keep my team happy - pinching pennies rarely aligns with either.
You have to tell them it's a priority. However, there's also the cost of an engineer's time that you have to weigh. Is it cost effective to ask a dev who is paid $100,000 / year to spend a week to save $1,000 / year on your AWS bill? Probably not. That week of their time costs $2,000 and could be spent making progress on features or products that will make you more money instead.<p>Having said that, I've personally spent a week of time that saved my employer six figures per year in hosting costs, which is definitely worth it.
By putting enough time and money aside to find what should be saved, and to fix it.<p>Here is my example, I have recently finished a project where while under development we were running instances at around 1.5x then we needed. We knew they were oversized, but not by how much because we were more focused on getting features done then making it efficient. When we were "done" we took a sprint to figure out what the "right" size needed to be, by measuring it. This means over the 6 months we "wasted" $2-3k, but you know what would have cost 25-30k? If we were running underpowered machines, that uncovered an intermittent bug that added a month to our development schedule.<p>Remember the goal is to be frugal not stupid. So before you try and do <i>ANY</i> cost cutting activity you need to go figure out what the impact of it might be, make sure you have some way to measure that impact, and then only do it if the cost of implementing is less then the savings.
Work it in the compensation structure.<p>Show engineers how much costs influence the profitability and value of their stocks and directly reward initiatives that can lower costs through bonus or promotions.
You tell them that it's a priority. You make it clear that they're continued work on projects includes these priorities. you tell people to include this stuff in code reviews.<p>Frankly it doesn't matter what the company's finances are. It matters the code is written well. This is a metric for which you can write code well.<p>You also don't push unrealistic deadlines. You include sufficient time for any ticket to also have a refactoring step.you allow people to refactor code without having to open a ticket
Be transparent about overall company finances, and clear about how the small decisions they make roll up into the big issues that affect the company’s success or failure.<p>IMHO, this is a company culture issue more than an incentive issue.
You allocate time and money to making it a priority. You need to have multi-day tickets with fluffy names like "review resource usage on login system" and give people time to work through them.<p>If you are talking about saving money while the entire backlog is all about features and bugs then you are showing you are not really serious.
To some extent developer time is more valuable. Having faster PC, faster CI/CD and faster instances is better for my productivity than a few hundred dollars saved monthly. Until you are google size, throwing more hardware on the problem is often the optimal solution.
They see you being parcimonious and they pick it up. We share business and financial information and our team can see how much things cost. Didn't need to say much about this for them to make reasonable decisions.
Focus on runtime performance (however you want to measure it), saving $ will be an automatic side effect. For example, how did Google incentivize to do cluster compute on commodity hardware.
By making part and parcel of your everyday work to have those discussions.<p>But don't penny-pinch. Engineer productivity is king. Instead of asking them to save money, ask them not to waste it.