Hacker News Reader

Comment by msoad | Hacker News Reader

I'm a Staff Engineer, but I hardly do anything that this book describes. Maybe it's my company, but we have so many Staff Engineers that if we all were to do this stuff, nobody would have time to do the actual work and there would be too many people trying to lead.

Perhaps the levels are diluted and my title doesn't match my actual role at my company, but it feels like this is an industry-wide phenomenon.

View on HN

Titles are very much diluted.

I've seen companies hire college sophomores who have never heard of the concept of a database and make them Sr Engineers on a analytics teams. I've seen Sr Engineers hired with one year of relevant experience.

At this point, "Sr Engineer" is just the new "Jr Engineer". There's nothing wrong with this, but indeed, Staff Engineer tends to mean 8+ years of experience.

It's because we still have no standards as a profession. Whatever bullshit trends in silicon valley, suddenly everyone follows it, petrified that they might get left behind or are missing some important new thing.

I remember when Systems Administrator was a noble and important profession full of smart, talented people. But a lot of people misunderstood it and made fun of it, so it became an unattractive title, and instead of changing the role, they just made up new titles. Now they're cool and in-demand, and still nobody understands what they do.

This is the way.

("Sr. Prompt Engineer", "Visual Strategist", "Director of Front of House") People want to have some leverage to get things they want done, done. Sys Admin -> DevOps (Cloud) Engineer. Things change. Adapt or die.

If you read IBM's coding standards from 1980 and compared them to Google's from 2000s and then to Today's AI journey, you would have complaints about each. Processes form from people. Change comes from people.

Title inflation isn't specific to tech. Look at the banking industry, pretty much everyone is a VP or SVP of something.

Or sales. The startup I used to work at, absolutely everyone in sales had some kind of Director or higher title regardless of seniority or role. I guess the theory being you're more likely to take a call from the Senior Executive Director of Business Development (never mind that said Senior Executive Director is 23 years old and has zero decision making authority). I always wondered if people actually fell for this crap.

It's prolific because banking clients want to work with someone in a position of authority.

Funnily enough, the author of this book started out as a systems admin.

Thats because nobody can get hired as an entry level or junior engineer

If you arent internalizing the senior title immediately then you will get nowhere

If you’re not forming an LLC and putting yourself as an junior employee of that shell company with some verifiable information or project, then I dont know how to help you

Staff engineer is the new senior engineer.

I disagree but only because I thought this way and it hurt my performance.

Unpopular opinion: With quickly growing organizations and therefore more inexperienced people managers, promoting someone to staff engineer is an easy way out of responsibility.

How often have I heard "you’re at a point in your career now where a people manager will only hinder you" to justify not being capable of supporting me.

Curious your thoughts on who a Staff should report to. I've been at a handful of places where there were Staff Engineers (some of them even deserved it!) and it always seemed like the promotion from Senior to Staff came with a change in reporting structure, where now instead of reporting to a Manager you're reporting to a Director or a VP, even the CTO in smaller orgs.

I think this is a good indication of increased authority/responsibility, but also an easy way to shirk management responsibilities as you said. How much 1:1 management is a VP or CTO going to be doing with a Staff Engineer? Do you really want a VP with all the political nonsense that comes with that type of position to have their own pet engineer they can bother about things?

As a staff in practice, but not in title, here's how it works for me: My manager and I are at the same level. We work as peers. They handle the people stuff of the team, I handle the technical stuff of the team. They help with routing people/HR/management questions, I help with routing technical questions.

If you think "Gosh, that person (on another team) sure was rude", that's a question for my manager.

If you think "Gosh, I sure have no idea why that API (from another team) sucks", that's a question for me.

In terms of reporting to my manager it feels more like having a corner-man in the boxing ring than a boss. I fight the fight, they say "Hey you're dropping that right hand on your left hook, stop that or you'll get rekt. Here's some ice". And they spend more time thinking about and navigating politics-like issues in the org than I do, which means I can lean on their expertise when "org stuff" is needed.

I probably have similar or more years of experience than my current EM. The person we both report to, happens to be a true greybeard.

This tracks with what I've read in your newsletter :)

You're describing being a Senior Engineer. Staff (according to this book) goes beyond that.

I'd argue that if you're a staff engineer, you need to be adept at navigating the "political nonsense." A director/VP should be able to think of you as at least as senior and capable of handling ambiguity and being self-directed as any manager.

Staff engineers that report to directors or whatever the equivalent 2nd or third mgmt level is are most effective in my experience.

An important part of the job is to “borrow” your boss’s authority and for that to work they need to have some. I’ve seen staff engineers be ineffective because of their boss’s position many times.

Reporting to someone higher than director you start getting too disconnected from on the ground stuff (architecture astronaut syndrome) and lower the ground is all you can see.

I’ve seen the opposite problem far more often. Less experienced managers who are perfectly fine at managing junior engineers attempting to manage senior engineers in the same way.

It’s refreshing when a company realizes that staff engineers with 15+ years of experience don’t need daily management.

Yes, but if you stay where you are and don’t push the managers you work with to take execution responsibility you will damage your career.

That's been my suspicion for a while now.

The last 3 companies I've worked for had no juniors and mid-levels, but only seniors and a handful or staff engineers. What staff engineers did on a day-to-day basis was hardly different from what the senior engineers do, besides having more responsibilities and maybe more say over things like architecture. Depending on the company, a staff engineer could be managing or not managing at all. In general, I don't think these title really mean a whole lot, that is unless one is intent on managing specifically.

Can confirm. Didn’t want to be staff and don’t think I’m at that level, but it was the only way they could give me the raise I was demanding within the rules of the silly HR system they’d built.

I've always viewed the levels sort of like this, obviously very dependent on company:

Juniors need hand-holding at every step. They may be new grads who don't even know how to behave in a professional environment or very inexperienced folks 1-2 years out of school taking a role in a completely different language they're unfamiliar with. You're talking to them anywhere from 5+ times a day to every other day as they transition up. They may have lots of meetings, especially during onboarding, but they're mostly listening. Their day-to-day is almost entirely "how" with very little "why."

Mids need hand-holding for the bigger picture stuff. You still need to give a general shape to their work but you can expect them to look up the docs for your validation library if they don't know how to do something, and you can expect to format and structure their code and PRs the right way every time (the junior will likely ping you on Slack asking how to write a custom validation function at least once). But it's unlikely you're going to need to talk to them daily. Hopefully they have large blocks of uninterrupted time to work as these are the folks churning out lots of tickets. They can also start thinking more about "why" than "how."

Seniors shouldn't really need hand holding for much of anything. Give them a feature or an entire product and they should be able to figure out approximately how to do it and what resources it will take. More meetings than mids but still need uninterrupted time. IME my productivity starts to really dip if I don't have at least two half-day blocks in a week. I'm in a new-ish job (first year still but 14 years in industry) so have been lucky so far but have been starting to block off chunks if I see my schedule filling. Seniors are probably running several of the meetings they're in, and maybe directing work for juniors and mids. I've been in companies where the line between Senior and Engineering Manager is very blurry as well with new EMs still spending 1/4-1/2 their time writing and reviewing code. And in most companies this is the "terminal" or "professional" level where you're not expected to move beyond here. Lots of folks will hit senior and be there for 15, 20, 25 years until they retire.

Staff is where the amount of code you write starts to drop off, meetings start to ramp up (you're no longer able to block off half your day), and in my opinion the biggest difference, you don't get assigned anything to work on. You're expected to have intimate knowledge of your business domain, your technical domain, and the challenges in both, and formulate plans to use technology to ease problems in both. I also feel like this is the first level where most companies don't need them, including a lot that have them. We have about 85 software engineers where I am, and two of them are Staff, which seems like about the right amount percentage-wise. There's only so much big work to go around and while there might be a lot of people capable of doing it, you don't want 10% of your engineers to be Staff and fight over the 0.5-1% of Staff work that's available. This is also the level I see it much more important what you're doing outside of work. Not as far as side projects, but going to conferences, speaking, user groups, having content available that works as advertising for your and your company, etc.

And then of course Principal where 99% of companies don't have or need them, where you're basically a VP or Director but on the Individual Contributor track rather than management. These are going to be so company-specific it's not even worth talking about them except in the context of a particular company. You're probably at Google or Microsoft or similar at this point.

I think there's another past staff/senior where you get to tell all of the other groups to leave you alone, and you're back to being dirty and building cool things. This is where you're most valuable and where they want you. But, you need the confidence that you've got it handled and you're trusted to communicate as needed.

Yes this is the Guido/Rasmus level we should all aspire to!

I don’t know what kind of jobs you do, but there is no way on Earth that a senior architecht VP whatever will even start to grasp an “organically” grown monstrosity most places have mustered into being. Like, no matter how experienced someone is, the concept behind the whole thing is ill-specified, overly complex and not actionable upfront. It’s 1-2 months minimum that they can do useful work in my experience, and it has nothing to do with technological knowledge, simply the business knowledge is so vast.

What’s your ratio of staff engineers to all engineers?

I always think of staff as engineers working across multiple teams, so there should be ratio of 1:15 to maybe 1:30 (or in another terms, staff engineers should represent 3-7% of all engineers). If the ratio is smaller, like 1:5 or 1:8 then staff engineers are really just senior engineers

It might depend on the organization of course but I hear what you mean here. It does seem somewhat of a phenomenon..

Reply on news.ycombinator.com