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

41–50 of 201 posts

Re: The other kind of staff software engineer

#41

Post by kitd »

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.

Line engineers tend to gloss over the myriad of external influences that affect how easy their systems are to deploy and integrate (eg how many FTEs doe it take to operate your systems, how long is an acceptable maintenance window for applying fixes, how long does it take to roll back if a fix fails, etc).

An experienced staff engineer introduced to a line team can be a huge asset, and will ask the right kind of questions, ie those that the customer is often most interested in.

Re: The other kind of staff software engineer

#42

Post by ubermonkey »

Goronmon wrote: post #27
xarope wrote: post #23

Earlier quoted context omitted.

That's unusual, in consulting days of yore it was about 80%* billable hours * may vary of course, but nobody expects 100%, even the big 5/4.

Yeah, it crept up over the years. Start at 6hrs a day, then 6.5, then 7 and then 8 about 4 years ago.

8 is just unrealistic, and invites fraud.

BigLaw have expectations like this, but the overt toxicity of that is so famous I'd hope tech would avoid it. In some firms, with rounding allowed, it used to be common to schedule 3 20-minute calls in an hour, because it would yield 1.5h of billable time.

Re: The other kind of staff software engineer

#44

Post by photochemsyn »

sytelus wrote: post #17
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 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 authors on papers, so it's not a route to becoming a department chair or famous academic etc. Can be more interesting as you get to work with multiple research projects, although if the PIs in the department are the petty tyrant types with inflated egos (more common than not) it can be ridiculously political (who gets time on the big machine etc.). Typically called 'supertechs' by PIs, i.e. 'not real scientists'. Training grad students in techniques is often part of the job, too.

Re: The other kind of staff software engineer

#45

Post by the_only_law »

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…

> A problem I deal with personally is growing into "Staff" style work.

My problem is that you seemingly get locked into it. The only people who want to talk to me are staff positions, the “line” roles do not want me at all. Technically my current role is at a tech company, but in a “staff-like” position and happens to be one of the least recognized teams invoice department because the work is among the least visible and a very tiny percentage of the companies income.

Re: The other kind of staff software engineer

#47

Post by kleinsch »

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…

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 - “staff” level work.

Re: The other kind of staff software engineer

#48

Post by Scubabear68 »

I have always found this to be a useful distinction, but software is blurring the lines in many cases

For example, when I worked in Wall Street as a dev/SW architect, you could call that staff. But in fact software was so vital to how Wall Street operates that we were treated as effectively line resources. We were a core to the business.

Where as, writing internal billing software as in the example clearly comes in as a staff position. Working IT in industries where IT is not highly valued was…not fun in my experience.

Re: The other kind of staff software engineer

#49

Post by kerblang »

Another thing about IT dept software dev vs. the tech company dev: Often in the IT dept you have smaller projects where you have greater responsibility and ownership. For all the talk about "t-shaped people" a lot of mature tech companies prefer a stay-in-your-lane person who doesn't dare venture beyond their assigned role or challenge the pecking order. You might expect it to be more bureaucratic in the IT dept because "tech companies are too cool to be bureaucratic" but I wouldn't assume that. Definitely true that the average expertise levels are lower, pay scale is a little more "average" and promotability is high. I'd say the less competitive atmosphere keeps the dog-eat-dog behavior to a minimum. But of course your mileage may vary...

Re: The other kind of staff software engineer

#50

Post by erwincoumans »

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 article.

Post reply on HN