Live data from Hacker News

The other kind of staff software engineer

earthly.dev

81–90 of 201 posts

Re: The other kind of staff software engineer

#81
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…

Your comment reminds me that I've only seen this distinction in terms of profit center VS cost center. Profit centers do business and get perks, cost centers support business and get the early layoffs.

The article's staff vs line distinction cuts it a little differently, and definitely gives a rosier picture of working in a staff role.

Re: The other kind of staff software engineer

#82

Author here. Working at a tech company as a developer vs working at a non-tech company are very different. These two types of roles were called line vs staff when I took a business school class and I think the differences between these two types of roles have a big impact on what the job is like, even if doing the same type of work. It's a bit confusing because it overlaps with 'staff software engineer' term. I recal…

I work at a non-tech company. I mostly write/maintain unexciting components for a website's CMS, and any tertiary work around that. Easygoing, remote, great work/life balance, good pay. Often go fishing or work on projects like an ebike for a lot of the day, sporadically checking the work chat and tuning into meetings from my phone. On the rare occasion something really important comes up I'm always ready to jump in and give 100%. Established a good reputation and get great performance reviews for what I do. I'd probably never trade this for a job at Google et al with higher expectations and stress.

Re: The other kind of staff software engineer

#83

Calling a software engineer (swe) 'Staff' because "working on non-core product" is indeed different from the standard corpororate 'Staff' prefix as a step/level of the ladder (within an org working on either core or non-core product) "swe, senior swe, staff swe, senior staff swe, principal swe, distinguished swe, fellow swe, senior fellow swe" I would have like to see mentions of both kinds of 'Staff swe' in the arti…

I think that's why the title reads "the other kind"

[deleted]

Re: The other kind of staff software engineer

#84
post #77
post #68

Earlier quoted context omitted.

If you can save 99% on cost, but sell at the same price, you've got a 10,000% profit, isn't it?

That's called COGS, or Cost Of Goods and Services. It's separate the kind of costs he's talking about. If you're working on COGS you're working in a profit center generating revenue, not in a cost center performing necessary but expensive functions. Tech doesn't usually measure COGS, because the cost of another user on a website is near zero.

I've seen the distinction drawn, usefully I think, between "Cost of Revenue" as more or less fixed operating costs eg AWS spend, and "Customer Acquisition Cost" as specifically the average spend to gain "another user on a website", usually in a way that can be either considered in the aggregate or broken out per channel such as for specific ad vendors or similar.

I think "COGS" as discussed here would probably be a rollup of both? Not sure; while I've been in orgs where the cost center/profit center distinction was made, I haven't run into a situation where COGS was a metric I saw used.

Re: The other kind of staff software engineer

#85

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…

"destined" may be a better word than "doomed" in this case :) I have a similar feeling, I like doing low level work but I also mentoring junior engineers, hopefully that mentoring will multiply my overall output over time!

Hah, yeah, mental note to reframe as "destined".

I also really like the mentorship angle. It's really cool to watch someone grow, and how fast they do when given stuff that's just outside their current capability level.

Re: The other kind of staff software engineer

#86
post #77
post #68

Earlier quoted context omitted.

If you can save 99% on cost, but sell at the same price, you've got a 10,000% profit, isn't it?

That's called COGS, or Cost Of Goods and Services. It's separate the kind of costs he's talking about. If you're working on COGS you're working in a profit center generating revenue, not in a cost center performing necessary but expensive functions. Tech doesn't usually measure COGS, because the cost of another user on a website is near zero.

I'm not sure if you're talking about at the executive level or at the engineer level, but here's some anecdata:

At the big tech (household name) I work we definitely spend a lot of energy talking about COGS a engineers. We have a LOT of data, and we spend a lot of money on cloud services to keep our product running - you want to add a new piece of data to this database to support some new feature? Go calculate how much it'll cost in storage and compute and if it's above some threshold, request special approval. You want to improve performance by caching our indexing? Let's talk about how much that'll be in COGS. This stuff ain't free, all those users add up.

The interesting bit is that all this COGS isn't actually money that transfers hands, the cloud we use is our own. But it isn't free and internal accounting is taken seriously.

Re: The other kind of staff software engineer

#87
I couldnt agree with this more. I think its more common to call this a generalist vs a specialist. A lot of engineers are true generalists. At larger companies it's a lot more common to be a specialist or to have ones work touch a very small portion of the companies products.

Re: The other kind of staff software engineer

#88
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.

Re: The other kind of staff software engineer

#89

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…

I don’t think I’d try to mix those things together. Same word, completely different things. In this article, a new grad who works on basic HR IT tasks for a factory is doing staff work. That’s not staff level scope in the Will Larson sense. There are plenty of “staff software engineers” in the Will Larson sense who create strategy for new product lines and launch them - “line” level work. Also plenty who work on DevX…

I think we'll have to agree to disagree. My takeaway from much of Larson's writing is that staff engineers can do the line work required to launch new product lines, but generally don't, because the impacts of their strategic work is much higher than that of line style coding.

They direct and advise on technical strategy, but delegate execution to others, because having the 10k foot view is typically more valuable when deployed on strategic opportunities.

Re: The other kind of staff software engineer

#90

Author here. Working at a tech company as a developer vs working at a non-tech company are very different. These two types of roles were called line vs staff when I took a business school class and I think the differences between these two types of roles have a big impact on what the job is like, even if doing the same type of work. It's a bit confusing because it overlaps with 'staff software engineer' term. I recal…

I think it's an interesting distinction, line vs staff, but I don't think it encapsulates the role of a dev at non-tech companies like myself. Certainly what I do is mission-critical on a 24/7/365 basis, and yet, I'm not working for "Thoughtworks" or a company that sells my expertise as a product. But nor am I "support staff" in the sense that a minor malfunction could go under the radar; in fact it could destroy a r…

> in fact it could destroy a revenue stream if I slept on a bug.

There are plenty of staff positions where incompetence could be very damaging or deadly to the business. E.g. in-house lawyers or accountants, even HR in some circumstances (failing to act in the presence of a hostile work environment). That doesn't mean it's not a staff position.

Post reply on HN