Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The other kind of staff software engineer

earthly.dev

Post reply on HN
Print view View original

171–180 of 201 posts

Re: The other kind of staff software engineer

#171

Post by ncmncm »

pgodzin wrote: post #122
chadash wrote: post #65

Related to this article: The owner of a company (non-startup, but growing and profitable) I used to work for gave me great career advice. He said to always focus on things that produce revenue. If you aren't doing things that produce revenue, try to move into those areas if possible. His view was that revenue can soar 100%, 200%, 1,000%, 10,000% or however high. Cost savings, on the other hand, can only go down to a…

> Obviously, a rational CEO would see $1m cost savings the same as a $1m gain in profits This is generally incorrect, especially at SaaS companies where revenue is recurring. It's very likely that you'll see much of that $1m gain again in future years, possibly even growing, while cost savings are hard to repeat consistently without impacting future growth.

Cost savings we count are usually recurring in the same way.

Re: The other kind of staff software engineer

#172

Post by phkahler »

kqr wrote: post #144
phkahler wrote: post #53

Earlier quoted context omitted.

Two thing. One, I always hated the cost center vs profit center distinction. These are accounting terms. It's super common in places that have embedded software (auto industry is close to me) where any manufacturing plant is considered a profit center, and engineering is often a cost center. When things are tight they tend want to reduce "costs" not realizing that engineering can also be seen as an investment in the…

> engineering can also be seen as an investment in the companies future. In fact, when things are tight is the very moment you should go all in for R&D. Let's clear up something simple people forget: when things are tight for you, they are normally also tight for your customers. In fact, that's generally how they become tight for you. So you can forget investing in production and sales when things are tight. Things a…

Saw this in interview at an RV company. Their market tanked in 2008 and the invested in engineering projects. Bought competitors after the recovery by selling newer better product.

Re: The other kind of staff software engineer

#173

Post by OJFord »

the_only_law wrote: post #88
chadash wrote: post #65

Related to this article: The owner of a company (non-startup, but growing and profitable) I used to work for gave me great career advice. He said to always focus on things that produce revenue. If you aren't doing things that produce revenue, try to move into those areas if possible. His view was that revenue can soar 100%, 200%, 1,000%, 10,000% or however high. Cost savings, on the other hand, can only go down to a…

What’s sad is I’m pretty sure the team I work I’m collectively paid more money than we bring in yearly.

That's not necessarily (and probably isn't) sad, I can think of two general reasons for that to happen and it not be a problem:

- Growth, e.g. trivially everyone at a company that's yet to turn a profit

- Critical but not revenue-generating function

I mean basically that's 'line' and 'staff' from OP (but for line the subset of companies/teams that isn't profitable yet). The latter being a 'cost centre'.

If you don't like it ('what's sad is') then the article might be a useful approach/line of thought when looking for your next role - i.e. a 'line' job (at a profitable company on a team working on the profitable thing).

Re: The other kind of staff software engineer

#174

Post by rockemsockem »

frellus wrote: post #158

Although these divisions may exist, I'm not sure why we have to call them out and normalize them. Essentially what you've described is a two-class system of engineers. Staff engineers can save the company money. Without them the "line" engineers cannot be as efficient in their mission. Why create any sort of hierarchy? This type of thinking is antithetical to the startup mentality, but seems very amenable to the way…

I don't think discussing something that exists is "calling it out" or "normalizing" it. It's just discussing it and personally I think it is an interesting take that I hadn't seen phrased in this way before. Now I can think about how it impacts me personally in a new light. Definitely a net win.

Re: The other kind of staff software engineer

#175

Post by dvtrn »

Aeolun wrote: post #161
dvtrn wrote: post #157

Earlier quoted context omitted.

A stock trading company, IT stuff are support for the real employees, the traders. You have a trader, you have a trading company. The programmers are just support for them. Not the norm, but I suspect it probably happens more than it should...but this is the sensation I'm feeling about "Devops engineers" in the last few years. Which, yeah, we could sit here and talk all day about whether or not "Devops engineers" sho…

Feels like the opposite to me. A lot of ops teams got turned into ‘devops’ teams overnight without any change in mode of operations, leading to skewed expectations from developers that actually know what the ‘dev’ part is about. At least, I was fairly surprised by how our devops team looked at what I was trying to push onto them until I learned their origin story.

Chesterton's fence is a real bitch, ain't it?

Re: The other kind of staff software engineer

#176

Post by dvtrn »

ncmncm wrote: post #170
cushychicken wrote: post #35

Earlier quoted context omitted.

The 'line' vs 'staff' distinction makes a ton of sense to me. I've been reading Will Larson's blog about staff engineers and trying to articulate what sets staff engineers apart, and I think you've nailed it. "Staff" more or less equals "support", but on an executive or strategic level. A problem I deal with personally is growing into "Staff" style work. I'd love to have bigger, wider impacts on a more strategic leve…

"Line vs staff" is a fundamentally bankrupt concept, as much so as "combat vs logistics". Wars are won or lost on logistics, as Russia recently discovered. Money wasted in a "profit center" has exactly the effect on bottom line as the same waste in a "cost center", and failure of a "cost center" can have just as large an effect on your business as in a "profit center". The only meaningful distinction is that the retu…

as much so as "combat vs logistics".

First time I've ever heard these two things talked about as a matter of "this versus that" and not "combat and logistics".

I'd hate to be a CO or NCO under a General who looked at the two as somehow adversarial or mutually exclusive in terms of planning and resourcing.

Yours is quite an interesting analogy, here.

Re: The other kind of staff software engineer

#177

Post by bcj7393nsk »

filoleg wrote: post #150
gernb wrote: post #147

Earlier quoted context omitted.

It's crossed my mind in the past that there are companies where often devs run things and companies where devs are just support for the real business. I don't think I ever want to work at a company where devs do not run things only because my spoiled experience has entirely been at companies where they do and I selfishly don't want to just be support staff for the real business. You might disagree with these examples…

Fully agreed with your overall position, but I got a small correction in regards to what you said about fintech. While you are correct in that at a lot of finance companies, devs just act as "support for the real business" (e.g., Goldman Sachs). But there are others where devs and quants pretty much harmoniously run the show. Look at something like Jane Street and their tech blog[0]. Their annual "what our interns ha…

> but I got a small correction in regards to what you said about fintech.

Market makers like Jane Street are not fintech. They are trading companies.

Jane Street in particular is still very much gut-feeling point-and-click trading, compared to Jump and Citadel Securities.

Fintech companies are more related to payments: Stripe, Gusto, Plaid, etc.

Another difference is pay/TC: trading companies pay significantly more than fintech and MAANG, even for SWEs.

Re: The other kind of staff software engineer

#178

Post by waych »

ncmncm wrote: post #169
tobyjsullivan wrote: post #164

Earlier quoted context omitted.

It sounds like you are conflating “support staff” with “inconsequential” or low-value work. That is definitely not what the author says. By the definitions of the article, the head of engineering at a tech company, or even the CEO, are considered support staff. Their success and failures will 100% map to the success and failures of the company.

The author isn't saying it, but business schools are. The business school mantra is invest in profit centers, nickel-and-dime cost centers . If you are so unfortunate as to be at a company run by an MBA and are in a cost center, woe to you.

The author called out that profit centers and cost centers are similar, but different, to the staff vs line distinction being made.

Why equate them as the same here?

Re: The other kind of staff software engineer

#179

Post by justinhj »

morelisp wrote: post #96
sytelus wrote: post #17

Earlier quoted context omitted.

I had not heard the "Staff" designation before Google popularized it. I believe in early 2000s, the popular job prefixes were "Senior" and "Principal". The "Staff" prefix always confused me and gave me a feeling that if layoff ever came "Staff" will be protected while everyone else was expendable. I don't think Google adopted this prefix in the sense it was popular in militery.

More confusingly, at my first (tech industry) jobs the progression was Jr -> no modifier -> Staff -> Senior -> Principal, "Staff" being the first level you could start coasting at, "Senior" being the end for most people who kept developing their skills, and "Principal" for extremely autonomous / R&D roles / "Leads" with no actual teams. In this case, "layoff protection" was exactly what the staff level was for; you w…

In my experience I think of Senior as an autonomous builder of a thing that they are told to build. Staff is the same but may work across multiple teams and help define the thing that needs building. They will usually have considerably broad experience. They get thrown at random problems nobody is sure how to fix. Principals extend that concept but may be industry leaders in a field or at least deeply specialised.

Re: The other kind of staff software engineer

#180

Post by Spooky23 »

dvtrn wrote: post #176
ncmncm wrote: post #170

Earlier quoted context omitted.

"Line vs staff" is a fundamentally bankrupt concept, as much so as "combat vs logistics". Wars are won or lost on logistics, as Russia recently discovered. Money wasted in a "profit center" has exactly the effect on bottom line as the same waste in a "cost center", and failure of a "cost center" can have just as large an effect on your business as in a "profit center". The only meaningful distinction is that the retu…

as much so as "combat vs logistics". First time I've ever heard these two things talked about as a matter of "this versus that" and not "combat and logistics". I'd hate to be a CO or NCO under a General who looked at the two as somehow adversarial or mutually exclusive in terms of planning and resourcing. Yours is quite an interesting analogy, here.

You’re used to reading about western militaries.

Look at the Ukraine War… Russia clearly completely ignored logistics and failed in their attempt at a “modern” war and quickly degraded to a WW1 style artillery duel.

And yes, being a NCO or field officer in the Russian army is miserable.

Post reply on HN