Hacker News Reader

Comment by birdyrooster | Hacker News Reader

I know someone that worked at some skeezy company in Menlo Park that got passed up for a raise after spending months navigating the bureaucracy to save the company millions on their operating costs because they didn't write enough code. This was in the last four years.

Edit: And they quit right afterwards.

View on HN

That skeezy company [1] at least has a fairly clear review process; it's clear what they will reward. It's not clear how what they reward is related to things that are useful to ~users~ people, advertisers, or the business, or even not breaking everything by rushing to push at the end of the review period. If you care about those things, you either have to not care about your reviews, or enough review positive stuff that you have a little time to do real work.

[1] Unless there are multiple skeezy companies in Menlo Park.

Menlo Park has Facebook and Robinhood connected by Willow Road.

For readers who, like me, don't keep track of SF Bay area municipal borders: I looked it up on Wikipedia and that skeezy company is likely Facebook.

It’s better to find ways to make more money than to save it. There’s a floor but no ceiling in much of what we do.

The ceiling is the size of the addressable market.

I wouldn't say it is better, just different. Both have value. If you find a way to save millions, that might be quite worthwhile, because that might be easier than building something new that makes millions of dollars. It's all about ROI.

People shouldn’t downvote him. He’s right. i’ve done lots of small things to save time and money in the past. Management really doesn’t value it as much as making money or working on more visible projects.

Telling someone that it only took me an hour to eliminate an hour of someone’s work every week doesn’t go far.

That's just bad management, not an axiom.

Someone was building an empire by having employees do manual data entry instead of parsing json files. All the way up the mgmt tree there are fewer direct reports. Nobody ever gets a job title promotion by having fewer direct reports.

Even worse, someone else now has to explain "why they did it wrong to begin with" regardless if the replacement technology existed or not at the time of original process creation.

A lot of this just visibility and internal salesmanship. Having an engineer standup at an all-hands and be lauded for saving $X million right after the sale-gal is lauded for closing the deal with $BIG_CO is something I've seen done, and it does it get recognized.

Making a million or saving a million are equally important in the end assuming one of them doesn't require particularly unreasonable ways. Sometimes it happens that the floor is really close to the ceiling and lowering the floor is the easier thing to do. Go for the low hanging fruit first. If you have too much useless clutter it makes sense to remove it rather than break down walls to expand.

Certainly many companies prefer this approach because so many goals are tied to increasing revenue, and certainly personal bonuses are too. Very few people get rewarded for decreasing costs. In my last (big!) company it was never even talked about. Increase revenue was the only goal.

Also making more money is better, because it means growing the company with more employees and more job safety for everyone.

Thanks. This comment blew my mind. This perspective is so far on the other side of things that I never considered it.

It feels like saving money might also be more environmentally friendly than growth.

If your revenue can grow exponentially, that's probably the right priority.

Most companies aren't like that though. Know your company!

Also consider if you can run out of money before growth kicks in...

Companies that only ever learn to spend money to make money tend to flame out when their market matures. They never learned how to sustain.

Also know your reporting metrics. Increasing revenue is growth, which capitalism jerks off over. Profits, not so much.

Yessir, Mr. Belson!

This heavily depends on the industry you're in. In software, yes this may be true, but in low margin industries it's absolutely not.

The maths is simple. If my margin is 1%, and you make me an extra $100, I keep a buck. If you save me $100, I keep that whole $100. If I'm smart, I can use that to drive my prices down, and take more market share without reducing my margin.

Obviously it becomes less clear if your margin is >20% or so.

If it's a high margin market, you should absolutely focus on capturing more revenue, it gives you more available capital to work with. Once that slows down or you get competition, you can focus on improving your efficiency.

The defense I've seen is that it works reasonably well as a measure of productivity _if_ you're working in a similar team and in a stable codebase.

From what I understand a lot of product teams at FB have nearly frictionless development tooling for their use cases so the pressure is to produce volume.

Was the team that caused the outage of half the apps on iOS one of them?

Didn’t the same team do it twice?

I call bullshit. Even if you have high-powered tools you still have to spend time thinking about how to use them, and you still continually improve them to reduce line count.

Perhaps, but it’s designed to be a consistent process. At least that’s the defense I’ve heard.

Reply on news.ycombinator.com