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

161–170 of 201 posts

Re: The other kind of staff software engineer

#161

Post by Aeolun »

dvtrn wrote: post #157
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…

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.

Re: The other kind of staff software engineer

#162

Post by [deleted] »

rendall wrote: post #151
Goronmon wrote: post #138

Earlier quoted context omitted.

In that case, just don't sweat it. It's all billable. The budget for these projects won't support that. Billing an hour of lunch everyday just for myself would exceed the retainer allotted for some of these projects. And it wouldn't work anyways. Hours are billed to specific tasks, individual to the person down to 15 minute increments.

Ok. So. You are expected to bill 8 hours, and not lunch, so you are tacitly required to work more than 8 hours per day. What company is this? Are you in the US?

[deleted]

Re: The other kind of staff software engineer

#163

Post by jonny_eh »

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…

> However, small research projects are an incredibly cheap way to learn things and invent new technologies

And recessions are the time when this research is at its cheapest.

Re: The other kind of staff software engineer

#164

Post by tobyjsullivan »

noduerme wrote: post #38
adamgordonbell wrote: post #3

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…

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.

Re: The other kind of staff software engineer

#165

Post by OJFord »

phkahler wrote: post #53
adamgordonbell wrote: post #3

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…

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…

> I always hated the cost center vs profit center distinction. These are accounting terms.

But that's how it's meant when people use it like that. They mean they want to do the work somewhere where it's (considered by the accounting department) a profit centre; not cost. That doesn't mean it could be another way for that company or that nobody should work there, much the same way as OP isn't saying nobody staff vs. line is right vs. wrong nor vice versa.

Re: The other kind of staff software engineer

#166

Post by RHSeeger »

wreath wrote: post #66
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…

> My perception is that I'm considered too good on the "line"; I'd be a loss to the org to move up a notch. At a previous company, they moved a lot of their top performer “line” engineers to staff level and they all felt unproductive and eventually quit.

This is a fairly well known issue Peter Principle (https://en.wikipedia.org/wiki/Peter_principle)

> The Peter principle is a concept in management developed by Laurence J. Peter, which observes that people in a hierarchy tend to rise to "a level of respective incompetence": employees are promoted based on their success in previous jobs until they reach a level at which they are no longer competent, as skills in one job do not necessarily translate to another.[

Re: The other kind of staff software engineer

#167

Post by ZephyrBlu »

cushychicken wrote: post #89
kleinsch wrote: post #47

Earlier quoted context omitted.

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 wh…

Will and this article use "staff" in a completely different sense. The author of the post even acknowledges this difference in his HN comment at the top of this post.

Will uses "Staff Software Engineer" as the rank of Staff (I.e. one above Senior).

This article uses "staff engineer" not as the rank, but as the type of engineer (Line vs staff).

Re: The other kind of staff software engineer

#168

Post by joebob42 »

zdragnar wrote: post #72
tgv wrote: 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?

If the revenue is 101, cost is a dollar and the profit is a hundred, saving 99% on cost is remarkable but hardly a 10k improvement of profit.

It may not even be that remarkable. A decent fraction of things I can accomplish for $1 I could also do for free.

Re: The other kind of staff software engineer

#169

Post by ncmncm »

tobyjsullivan wrote: post #164
noduerme wrote: post #38

Earlier quoted context omitted.

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…

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.

Re: The other kind of staff software engineer

#170

Post by ncmncm »

cushychicken wrote: post #35
adamgordonbell wrote: post #3

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…

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 return on investment in a "cost center" is gated by the success of "profit centers".

But, woe betide if you find yourself in a cost center at a company run by MBAs. Get yourself to a profit center, or to a better-run, less MBA-saddled company.

Post reply on HN