Live data from Hacker News

The other kind of staff software engineer

earthly.dev

181–190 of 201 posts

Re: The other kind of staff software engineer

#181

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 look for folks with this background to join my team at my Day Job. I need folks with a solid hands-on technical background who want to stop building things and start telling me which people SHOULD build and which people ARE building those things so I can give those people money.

It’s tricky because I need hands on experience but the desire to switch to a more strategic, executive-style role. Plus folks need to have the core communication and people skills to manage a complex set of stakeholders.

Hard to find good people, but the people I find tend to be very very good.

Re: The other kind of staff software engineer

#182
post #147

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…

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…

Since you mention videogames. I used to work at EA and one thing I found was that the company culture was not as developer oriented as you might expect. Obviously, they invested a lot in developers, artists, and other content producers.

But the overal company culture and the upper echelons of leadership very strongly reflected EA's history as a software publishing company founded by business folks, and not a group of game makers who set out to build their own company. It was very much about producers, money, marketing, etc.

I used to joke that EA was in the business of selling disks and that the games on them were merely an annoying chore that they were obliged to do in order to get people to buy them. It often felt like they considered the entire dev team to be a cost center.

Re: The other kind of staff software engineer

#183
post #176
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.

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

Not sure if you’re being sarcastic? Or haven’t read much about the military and are assuming?

Combat vs combat support vs combat service support (logistics) is a very common and very significant distinction to make and usually matters a lot for a great many things.

Has a logistics branch officer ever led a major Army? We had an artillery officer in the UK and even that was a talking point at the time.

Re: The other kind of staff software engineer

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

[deleted]

Re: The other kind of staff software engineer

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

This view is slightly wrong when it comes to software. Software is a force multiplier, not a cost reducer.

Sometimes they're the same. Sometimes they aren't. A well placed, smart team of "staff" engineers can increase revenue as much or more than a team of line employees.

Re: The other kind of staff software engineer

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

Since you mention videogames. I used to work at EA and one thing I found was that the company culture was not as developer oriented as you might expect. Obviously, they invested a lot in developers, artists, and other content producers. But the overal company culture and the upper echelons of leadership very strongly reflected EA's history as a software publishing company founded by business folks, and not a group of…

Ex-gamedev and this totally rings true.

We had one title I worked on where the "interviews with the dev team" was all just interviews with the external producers(aka PM who came in from the publisher to keep everything "on track").

Never happened to us but the best one I heard was that the publisher puts a clause in your contract that they get the source+IP if you go bankrupt(protect their investments, their taking huge risk, etc....). However about 2/3 through development when the studio is at peak HC burn they would start denying milestones for trivial things. One, two milestones go by and the studio burns through all cash, folds and publisher gets source+IP. Publisher then hires the dev team, who just lost their jobs, at a reduced rate(most gamedev a don't have great savings...) to finish out the game, avoids paying any royalties and picks up the IP.

Happy to be out of that industry, some really interesting technical challenges and driven people but the whole thing is similar to the recording industry in the way they exploit people and passions for their own gain.

Re: The other kind of staff software engineer

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

In our company the prefix Staff was adopted when the CTO team got tired of creating (mostly fake) managerial positions for good software developers who have reached the maximum salary allowed by the CFO team for a “Senior” software engineer.

Most NYC finance firms did this. You will find lot of AVPs (Assistant Vice President) who are mere software developers getting paid more than $125k base (during early 2000s). It was fun to suddenly have “Vice President” in your title.

Re: The other kind of staff software engineer

#188
post #131

Earlier quoted context omitted.

Probably because it's ambiguous and opens them up to legal headaches when there's disagreement over how much was made or saved.

No. I always made it very clear. Example: Show me your current budget for your main data center. Let me show a proposal for a Cloud move that will keep equivalent or better quality of service, including training and while defining KPI's for success.

Would you have agreed to a deal that called for you paying _them_ if those KPIs were missed?

Re: The other kind of staff software engineer

#189

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 am a Staff software engineer in a consumer goods company. I got quickly promoted to it manger , head of it and then CIO. The tech is shallow but it exposes me to production, supply chain , sales , finance and pretty much every aspect of the operations. I report directly to CEO. We typically buy erp but small softwares , I choose to write myself so that I got some practice on coding. I go to home before 6 and enjoy…

That's nice, I think the question on everyone's mind is: is your pay comparable to FAANG?

Re: The other kind of staff software engineer

#190
post #178
post #169

Earlier quoted context omitted.

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?

Because a significant number of managers seem to fall into the same trap, and it only takes one such manager in the chain above you for it to be painful.
Post reply on HN