Hacker News Reader

Comment by throawayyyy | Hacker News Reader

So here's a curious question that is perhaps incredibly naive and seemingly impolite, hence the throwaway, but I really don't know, which is why I'm asking.

Why must one be a senior engineer in tech before they can become a staff engineer? To me, this seems much more like a communication role. Moreover, the tech that is needed to know is at a high level. Is it really needed to know the technical finer details of systems when high level software architecture and communication seem to be 90% of the whole role?

Or put in a more blunt, albeit unrefined, way: why can't someone who specializes in communication become a staff engineer? I mean people like consultants. They get so much experience with communication and high level tech (some of them at least) that this seems to be what they'd be good at.

View on HN

There is a role like you're describing at some companies, often called a technical program/project manager. They're responsible for managing schedules, communication, etc.

The difference with a staff engineer is that TPMs are not expected to be technical experts, while a staff/principal engineer is. So they're not just routing information between stakeholders, they're also synthesizing and evaluating, partly responsible for the project going well and empowered to make changes they think necessary.

All of that takes a lot of experience in the trenches, having seen many projects succeed and fail. It also requires a lot of trust and respect, which takes experience to cultivate.

It takes a lot of experience to build the intuition to make the right technical tradeoffs, choose the right architecture, escalate staffing gaps, forecast timelines, rope in the right folks, etc. It’s not something you can learn in school, and there aren’t any shortcuts.

I think a pretty good example of why this isn't work is visible in the LinkedIn inbox of nearly every software engineer (and probably other specialized people). People with an HR degree become tech recruiters and they often really suck at it on two fronts: spotting the right candidates and explaining the job. All they do is target as many people as possible and hope someone bites.

A really had thing for someone without actual work experience in the field is spotting the difference between: someone with the exact right experience, someone with the wrong experience but a valuable set of skills and personality to learn, someone bullshitting their resume and talking like they understand the tech stack and someone who seems to have the right experience but is actually a bad fit.

For a staff engineer it's critical to be able to spot knowledge gaps in teams, explain complex technical issues to business people, spot opportunities for the implementation of new tech and estimate the complexity of implementing it, etc. No matter how good you are at communicating, you will be unable to do this without actual understanding of the tech stack. Just explaining why last week it was ok to hire a react dev to fulfill an angular vacancy, but this week you really need a dev with super specific knowledge to fill an urgent need is hard to do without understanding those technologies.

I think you're too harsh on recruiters. They're paid less than developers and recruiting is a numbers game.

They can't afford to spend time to get super deep technically, since it's not worth it. And I imagine that those that do dive deep just get a technical job for less pressure and more money.

> They can't afford to spend time to get _super deep_ technically

Maybe you're just extremely lucky.

I'm already happy if I get a recruiter mail where the buzzwords aren't even used in a nonsensical way, e.g. just from two sentences I know the person hasn't ever written a single line of code or worked in a project using any of the 10 buzzword technologies.

Made up examples "using exciting database technology like mysql and mqtt", using "programming languages like SQL and XML"

> They're paid less than developers

Are we sure about that? I thought one of the most common compensation structures is they got a commission of approximately 10% of the first year's salary for each hired candidate, payable after the candidate has completed 3 months at the new job.

I hope the average recruiter places more than 10 developers per year.

The smart ones develop relationships with frequent job-hoppers. It turns almost into an agent-talent relationship.

They're usually employees. They only see a chunk of that.

That's about what the company gets. Most recruiters don't own their own companies.

Interesting question. As someone else pointed out, TPM is a role more like what you’re describing.

For Staff+ engineers, communication and high level architecture are just the tip of the iceberg. You have to understand the problem domain and the solution domain, be able to come up with good technical solutions (which is generally a collaborative process), and sell others on these ideas. Then you have to follow through with implementing them yourself and leading others working with you on them. If you don’t have the technical depth to understand the details, you’re not going to succeed at that. If you haven’t already internalized a lot of the details through your past work, you’re not going to have enough time to both learn the technical details and do all the communication, implementation and other parts of your job.

Another thing to keep in mind is title inflation.

The role that most companies these days call “Senior Software Engineer” is actually an intermediate-level role (e.g., 5 years of experience). Staff is arguably where the actual senior-level roles start. This corresponds with the transition from being told what to do to being told to figure out what needs to be done and make it happen.

If you are a Senior anything and being told what to do, you're not really a Senior.

Maybe that works for you, if you're in the right place getting paid the right amount, but we do ourselves a disservice when we allow this to occur.

My personal understanding was: junior: lots of tactical guidance

medium: less tactical, lots of strategic guidance

senior: no tactical, very vague strategic (normally coming from business partners).

Maybe that's just me, though.

>senior: no tactical, very vague strategic (normally coming from business partners).

>Maybe that's just me, though.

That's just you. I agree that's probably closer to how the terminology should work, but it doesn't. I'm unaware of any large company where senior engineers are getting direction directly from business partners.

You're lucky if "senior" engineers have 3 years of experience.

I see it the same way. I've had to have the "why did you hire me if you're going to tell me how to do everything?" conversation with a recent manager.

This is my experience, too. For example, if I look at the title breakdown across the three SRE teams at my employer it's

Senior: 53%

Staff: 35%

Senior Staff: 12%

Your job isn‘t just to coordinate people, but help them reach consensus. If there‘s a tie, that decision is yours to make.

So:

1. You have to keep writing code to remain an effective tiebreaker 2. You still need to be a badass engineer in order to hire and keep exceptional talent who‘s looking up to you for mentorship. Respect and excellence are non-negotiable ingredients in a working meritocracy.

Sure you can also work outside of a meritocracy, but results and engineering happiness/productivity is usually subpar.

So that‘s exactl why the hunt is on for those unicorn engineers who can also socialize: It‘s proven to work.

Reply on news.ycombinator.com