Ask HN: How do you incentivize engineers to save money?

Author: rexfuzzle

Score: 8

Comments: 27

Date: 2020-11-06 17:01:17

________________________________________________________________________________

aejnsn wrote at 2020-11-06 18:55:50:

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.

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.

MadVikingGod wrote at 2020-11-06 20:14:35:

By putting enough time and money aside to find what should be saved, and to fix it.

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.

Remember the goal is to be frugal not stupid. So before you try and do _ANY_ 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.

qppo wrote at 2020-11-06 21:50:37:

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.

kingnothing wrote at 2020-11-06 20:35:38:

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.

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.

probinso wrote at 2020-11-06 17:35:25:

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.

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.

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

908B64B197 wrote at 2020-11-06 19:15:33:

Work it in the compensation structure.

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.

gumby wrote at 2020-11-06 20:19:25:

I agree, but the hard part is that not everybody has agency over the cost structure (this is why I've always wondered if "profit sharing" provides any incentive at all).

toomuchtodo wrote at 2020-11-06 19:26:00:

Absolutely. It’s about aligning incentives. If you don’t both empower and incentivize practitioners to make cost efficient decisions, rarely will it happen out of the goodness of someone’s heart. Top tier talent will, because they’re top tier, but they’re also getting compensated at the requisite rate for their skills and experience.

908B64B197 wrote at 2020-11-06 19:27:59:

There's always that manager that wants to get away with no equity in the compensation.

"But it's not the norm in our -regional- market"

I was expecting the downvotes.

maest wrote at 2020-11-06 19:39:44:

What if the engineers, like most other employees, don't receive stock comp?

gumby wrote at 2020-11-06 20:18:25:

Who wants to work at a place like that? At the first company I sold even the receptionist made enough to pay off her mortgage and all other debt. It doesn't always work that way of course but when things go well, it should.

maest wrote at 2020-11-06 22:30:51:

> Who wants to work at a place like that?

Most people, it seems, seeing as, outside of a small part of the world, equity comp is uncommon.

908B64B197 wrote at 2020-11-07 00:08:21:

There's wanting and there's being able to.

There are a lot more folks who want to be NFL players than there are actual NFL players!

908B64B197 wrote at 2020-11-06 19:48:35:

You are doing it wrong then.

maest wrote at 2020-11-06 20:17:47:

Can you expand on that?

Are you saying everyone should receive stock options?

Or are you saying engineers are somehow special and should receive different treatment from other emloyees?

908B64B197 wrote at 2020-11-06 21:33:49:

That really depends on the type of talent your business needs.

If you are ok with not having top talent, then sure, don't waste money with stock options.

maest wrote at 2020-11-06 22:28:47:

By definition, most companies can't afford the top talent.

Your advice boils down to "pay people more", which, I mean, might seem like it works in the individual case, but it's clear why most won't be able to follow it.

908B64B197 wrote at 2020-11-07 00:07:17:

Most companies can't afford to be market leaders either.

No stock comp sends a strong signal to top talent. And about the company in general.

viig99 wrote at 2020-11-06 19:27:46:

Exactly, dont think its that complicated.

Chyzwar wrote at 2020-11-06 22:40:04:

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.

hmahncke wrote at 2020-11-06 17:05:43:

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.

IMHO, this is a company culture issue more than an incentive issue.

verdverm wrote at 2020-11-06 17:45:08:

I've seen this from several different cultures and completely agree.

slyall wrote at 2020-11-06 20:38:40:

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.

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.

Jugurtha wrote at 2020-11-06 17:58:45:

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.

edmundsauto wrote at 2020-11-06 20:48:00:

First, evaluate whether it should be a priority. Waste is easy to spot; missed opportunity is not.

kleer001 wrote at 2020-11-06 18:07:27:

Having defaults that steer people towards that? Not nag-ware, just make it easy to comply.

speedgoose wrote at 2020-11-06 20:57:22:

Put that in the requirements.