How I influence tech company politics as a staff software engineer • Hacker News Board

Re: How I influence tech company politics as a staff software engineer

#211

Post by veep33 » Mon, Oct 06, 2025, 10:42 PM UTC

Appreciate this discussion. I worked 15yrs in large tech companies as a software engineer and felt like a pawn always.

Engineers have a hard task - building and maintaining code is a high focus activity, leaving no time for scheming. Meanwhile the non technical people have all the free time and use it wrongly on scheming.

With vibe coding, perhaps this dynamic can shift.

In the early days of the software industry there weren't these many non technical people running the show.

I appreciate the authors workarounds but shouldn't the larger question be whether this is the correct way to run a company?

Re: How I influence tech company politics as a staff software engineer

#212

Post by apwell23 » Tue, Oct 07, 2025, 12:27 AM UTC

latchup wrote: post #185

roenxi wrote: post #167

Earlier quoted context omitted.

Although we should notice the other side of that - managers that don't have an explicit onboarding where they lay that algorithm out for their reports are doing a terrible job. It is literally 3 lines. Lay it out at least once. Maybe go through it in a standup once a year. They are letting people slip through the cracks to the point where we have junior and even mid software engineers that don't realise there are pri…

> One of the reasons companies get dysfunctional is low- & mid-tier managers seem to be allergic to the idea of laying out what the priorities are and provide feedback on whether people are working on them or not. Have you considered the possibility this is not a result of incompetence, but intentional? If these things are never clearly communicated and, more importantly, put in writing, management can just reframe w…

exactly. my last job the project i was working on suddenly became "my project" where manager wanted to "give me a win" by shipping. it became my project when we discovered all the way in the end that what he had come up with isn't viable at all. thing i was telling from the get go but he didn't listen and adamant that it would be fine.

we even had it in writing the i had objected to his scheme and that he overrode it but that document was completely hidden from upper managment.

Re: How I influence tech company politics as a staff software engineer

#213

Post by valeriaortiz » Tue, Oct 07, 2025, 10:47 AM UTC

[dead]

Re: How I influence tech company politics as a staff software engineer

#214

Post by awesome_dude » Wed, Oct 08, 2025, 1:52 AM UTC

creer wrote: post #183

awesome_dude wrote: post #138

Earlier quoted context omitted.

Ah, I think that I get that, thanks. Although to be clear, the estimates will "this is where we think that we will be saving money" followed by a review (in 12 months time) that will be "this is what we think is the result, but it will include improvements from other vectors, such as better communication from business"

Sure. This is rough engineering. If you identify a plausible significant cause, and you attack that, and you get useful improvement, people are not too likely to be overly concerned that there was some confounding factor in the improvement. If there is any excess, it's likely to be in the other direction: deciding that the likely improvement is not worth it. Engineers hate that kind of decision.

We're really still no better off than where we started at - it cannot be measured, it has to be estimated, the estimates are only able to be validated after some time period has elapsed (1 - 5 years) and the confounding factors cannot be discounted.

I'm not arguing that we shouldn't I'm arguing that the business cannot put a number on it that it can rely on. That's fine if the budget is available, but if there's no budget, almost always for reasons beyond the engineer's responsibility (VC money, market resizing, etc) then you're really struggling to be able to justify it.

Re: How I influence tech company politics as a staff software engineer

#215

Post by creer » Wed, Oct 08, 2025, 5:24 AM UTC

awesome_dude wrote: post #214

creer wrote: post #183

Earlier quoted context omitted.

Sure. This is rough engineering. If you identify a plausible significant cause, and you attack that, and you get useful improvement, people are not too likely to be overly concerned that there was some confounding factor in the improvement. If there is any excess, it's likely to be in the other direction: deciding that the likely improvement is not worth it. Engineers hate that kind of decision.

We're really still no better off than where we started at - it cannot be measured, it has to be estimated, the estimates are only able to be validated after some time period has elapsed (1 - 5 years) and the confounding factors cannot be discounted. I'm not arguing that we shouldn't I'm arguing that the business cannot put a number on it that it can rely on. That's fine if the budget is available, but if there's no b…

What budget ever gets justified with exact numbers? What fantasy is this?

You get a fixed-price quote, you pay a fixed price amount, sure. But only because the vendor was planning to and is absorbing the uncertainty. Except if it was not really fixed price, then they send you a nice report explaining why it will cost you more in the end.

The future is great - so many estimates you can pick from!

> almost always for reasons beyond the engineer's responsibility

Now, you are touching to a different issue: If the project owner really wants to fund it, they will pick one estimate (or one end of the estimate). And if they really don't want to fund it, they will pick the other estimate (or the other end of the estimate). Either way, the issue will NOT be that the engineer couldn't cook up exact numbers. Even then, if by some sorcery you really need an exact number, just find a vendor willing to quote you a (very high) fixed price.

Re: How I influence tech company politics as a staff software engineer

#216

Post by creer » Wed, Oct 08, 2025, 6:29 PM UTC

awesome_dude wrote: post #214

creer wrote: post #183

Earlier quoted context omitted.

Sure. This is rough engineering. If you identify a plausible significant cause, and you attack that, and you get useful improvement, people are not too likely to be overly concerned that there was some confounding factor in the improvement. If there is any excess, it's likely to be in the other direction: deciding that the likely improvement is not worth it. Engineers hate that kind of decision.

We're really still no better off than where we started at - it cannot be measured, it has to be estimated, the estimates are only able to be validated after some time period has elapsed (1 - 5 years) and the confounding factors cannot be discounted. I'm not arguing that we shouldn't I'm arguing that the business cannot put a number on it that it can rely on. That's fine if the budget is available, but if there's no b…

Separately from "accurate", I would also argue that if the improvement you are proposing is slim or difficult to distinguish from other ongoing ambient improvements - then perhaps you shouldn't try to bring it up as a stand alone project. It's not worth it. "Slim" is not enough impact. You could bring it up as part of a package of other improvements - like those generated day in, day out by a methods or build group. They should be the ones championing small ongoing improvement - and they have an umbrella "do what you can" budget for that.