Live data from Hacker News

The other kind of staff software engineer

earthly.dev

91–100 of 201 posts

Re: The other kind of staff software engineer

#91

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…

For me the more useful distinction has been: how close are you to the customer? If you never interact with them, not even indirectly through a team manager directly interacting with them, you're probably working more in a "staff" role under this categorization regardless of who is actually using the thing you're building. Admittedly this has problems -- you have to figure out who the customer is, for one, but it's legitimate for them to be either internal or external, paying or not. And for many companies (perhaps especially "tech companies" and tech startups) it often ends up being both via dogfeeding. I think the presence/absence of the customer in short feedback loops alongside those actually making and maintaining things dominates the distinction of whether it's staff or line. Focusing this way does help avoid the sometimes difficult distinctions of what makes a company tech or non-tech and how reasonable people can disagree over some particular example, whether what you're doing is really important to the company's overall success, or whether something is a profit center or cost center (I find it more useful to think first about whether an individual employee is an Asset/Profit or Cost, and note that being a cost isn't necessarily bad but also types can change over time).

Still, even customer proximity is not always a useful distinction, and certainly doesn't have to be a static one. I wonder if this industry resists distinctions among people or groups like these due to something at the root of the hacker culture that created it, like a realization/commitment to the idea that the only really worthwhile distinction is the bit.

I'm not sure I buy the dark matter idea. In the US there are only on the order of a few million software developers, you don't have to go very far down a list of FAANG/FAANG-like high paying tech companies to reach on the order of a few hundred thousand US-employed programmers at those firms (~10% of the market, already exceeding ordinary matter's 5% of the universe). Decide on a consistent definition of tech company in general and add in all of the programmers from them and it wouldn't surprise me at all if tech company employees actually exceeded non-tech, though I can see it being the other way too, just not being "vast majority".

As for stories from roles at non-tech places, most are probably told orally (especially to fellow employees at larger companies as cautionary tales of the crazy messes out there that make their own current insanity look pretty sane) but also remember that at any given time like half of the professional market has been in it for less than 5 years (how many of them got into tech-company vs non-tech-company roles?). And remember you may have read stories from them but not realized it because the actual work regardless of line/staff or tech/non-tech company distinction itself for programmers can be so similar, so it's not always clear whether some story on e.g. The Daily WTF is from which (though sometimes it is or you can guess).

Re: The other kind of staff software engineer

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

That owner was absolutely correct. If you can make the company money and you can prove how, the sky's the limit. You're much more likely to get a cut of profits over a cut of savings.

Re: The other kind of staff software engineer

#93

I guarantee you at Duke Energy the contractors are second-class citizens, are laid off first and each and every one of them will take FTE at Duke the first chance they get.

> I guarantee you at Duke Energy the contractors are second-class citizens

In fairness, I’d bet the full time devs are too.

Re: The other kind of staff software engineer

#94

>> If you are a dev team within a bigger, non-tech company, you are basically an in-house agency with one client. Imma argue with this, as a developer for a bigger non-tech company (and a few small ones) I've worked for in-house agencies and the pattern is completely different. In-house, every dictat in the software comes from the top down as a fully-formed thought. Whereas being an independent contractor gives you w…

> If you are a dev team within a bigger, non-tech company, you are basically an in-house agency with one client.

I only wish I had that level of autonomy when working for the most horrifically bureaucratic corps I’ve seen.

Re: The other kind of staff software engineer

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

It's been common in academics forever. A 'staff researcher' is someone who is typically affiliated with an 'organized research unit' which is basically a facility that a lot of 'principal investigators' utilize, and which are likely funded by overhead on the PIs individual grants, or via bulk grants. Benefits are not having to sit around writing grant proposals all day, but they're basically never first or last autho…

the incentive structure is reversed in academia. staff are closer to adjuncts than full-time faculty positions in compensation and benefits

Re: The other kind of staff software engineer

#96
post #17

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 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 were also expected to hit it in 3-5 years.

Now it seems to be Jr / n/a / Senior / sort of equal footing for Staff/Principal depending on whether you're a generalist or specialist? And Staff might also be Lead but also not? I've read Larson's stuff and I'm still not sure the moniker is useful in a way "Senior" wasn't, except to the degree other titles have inflated. (I've seen three resumes in the past week for "senior" applicants with 2y experience or less restricted to a single stack.)

Re: The other kind of staff software engineer

#97
post #80

This articles sort of right, sort of wrong. Staff in the modern military means you're a careerist. It's the last rank that you can't be forced out without advancing, and might not be expected to advance at all. Staff has different kinds of connotations depend on officer and enlisted. Staff officers would never lead from the front. That's O1-O3s job, those people are actually trained by enlisted careerists before they…

[deleted]

Re: The other kind of staff software engineer

#98
post #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.

I don't disagree with the article. Within a tech company, it's obvious why they value engineers. In a "staff" you might also be highly valued or you might not be. As an example, I've recently noticed that home depot has a superb website. Looking at the quality of it, they've obviously put a lot of thought and resources into it. It's something they value. The people working on it might be in the "staff" bucket, but I'd bet the C-Suite is well aware of the impact they are having. On the other hand, I've seen companies where the "staff" engineers are completely disregarded.

Re: The other kind of staff software engineer

#99
post #41

I've been both staff and line at various companies. The biggest downside to staff IME is that you are almost constantly reminded that you are a cost and at danger of being cut. OTOH, the biggest upside is the domain knowledge, and in particular, how companies (ie customers of the line engineers) really deploy and run their systems, which IME is often very different from how the line engineers think they run them. Lin…

> The biggest downside to staff IME is that you are almost constantly reminded that you are a cost and at danger of being cut.

It seems like this shouldn't be an absolute that applies to all staff roles, just a sign of a company with an immature viewpoint on costs. Or even just an inconsistent one. Consider the electricity used to keep the office running, it's a cost, but no one would feel the urge to remind the utility company that it's a cost and therefore at danger of being cut. That "and therefore" isn't even true in general anyway. Pre-pandemic most would consider the risk of cutting the office electricity to be no higher than the risk of the company ceasing to exist for whatever reason, i.e. if the company goes the office also goes, and there aren't many other causes for the office to go for most companies so it's mostly vice-versa too. Similarly there are businesses basically entirely supported by staff teams/individuals doing maintenance of some old software, if they go, the business goes, and vice versa. Anyone trying to pull a "don't forget you're a cost and might get cut!" reminder on them would be an asshole. Meanwhile companies like Google have no problem killing off entire products and their teams (though I think they tend to re-purpose the programmers rather than officially lay them off) even though it's making on the order of ("only") $200m/yr in profit.

Sure, if people can get something for cheaper than they used to, or get rid of something they realize they don't need/want, there's incentive to do that and "cut costs" by that amount if they can, but this incentive applies regardless of the staff/line division. Maybe the cure is to remind line roles at such places that they too are in some vague danger.

Re: The other kind of staff software engineer

#100

Earlier quoted context omitted.

The article is titled The “Other Kind” of Staff SWE. Presumably the “first kind” is the definition to which you are referring

Sure, I just wished the author/article would have spelled out/confirm the standard definition of 'staff swe' as step/level in the ladder before going into the 'other' meaning of 'staff swe' as being part of non-core product.

Like this, from article footnotes:

    When talking about “staff” in this article, I do not mean the Staff software engineer role that is found at tech companies after senior. That is a different usage of the term
Post reply on HN