Hacker News Reader

Comment by csmpltn | Hacker News Reader

Something about these articles reads so self congratulatory and aggrandizing...

A lot of talk about how the author lives on the cross section of business, management, technical leadership and architecture - but literally zero mention of any measurable numbers or quantifiable impact. Little to no mention of honest disadvantages and limitations of this role.

I also find it a bit strange how literally every single article on https://amyunger.com/ reminds us that the author is a staff engineer, cares deeply about staff positions, very knowledgeable about the staff engineering role, and that it's oh-so-difficult to achieve this prestigious title...

View on HN

Once you have a team, it's pretty rare to have a "quantifiable" impact in the way that satisfies your engineer side. By design, your time is pulled to the problems that can't be solved quickly/definitively/numerically, or they'd have been solved by the other members of your team before you. And to the extent that solid metrics can be cited, you want them to be your team's accomplishments. The lead who takes credit for everything is a jerk.

I'm not saying your take is wrong here (some people seem to love this kind of management porn stuff a bit too much and roll around in it), but it is true that as you get more senior, you're expected to do things that don't have that kind of quick payoff.

Lead Engineer and primary designer or implementor of a service that handles 1M queries per second with 100ms 99%ile latency, globally distributed for 100M users.

The linked “StaffEng” stuff is fairly ridiculous:

“In literature, recurring character patterns are called archetypes, such as the "hero" or the "trickster," and the archetype term is helpful for labeling these frequent variants of Staff-plus engineers.”

How does anyone take this seriously?

They've read Joseph Campbell and appreciate the analogy.

Jung, surely?

Not sure. Having been a staff and principal engineer at a few places, my view is a staff engineer is primarily a reviewer and documenter: code reviews, writing and reviewing design documents, architectural and coding standards enforcer, etc. Mostly you are shepherding things along that are too technical to be dealt with by the engineering "people" management. Maybe a couple days a week you get to do some interesting coding.

That sounds like a job for someone who is washing out technically but has some wisdom and institutional knowledge to share.

It depends on the org.

> Something about these articles reads so self congratulatory and aggrandizing...

That's a requirement for staff engineering. This is how you graduate to staff. If you don't understand, there's a couple of books you can buy and educate yourself. Also there's a staff engineering podcast where staff engineers are invited to talk staff engineering and how to staff engineer effectively.

See my previous comment about this:

https://news.ycombinator.com/item?id=30049319

This guy Staffs

This is the language required to get that staff title and salary. It’s all part of the game. It’s all just a game, after all.

Quantifying impact in many of these roles is something that's incredibly difficult, and if you actually do it, most people will say "wow, that's an incredibly arbitrary and abstract way of quantifying impact that feels suspect."

The only thing you can reliably point to is "During my tenure, the company saw X metric go up or down in this area." But anyone in management who claims "I made metric X go up/down" is probably selling snake oil. Are you sure that it was you? Maybe it was a parallel change made by someone else. Maybe it was someone you hired, while you did literally nothing else but hire them. Even if you are sure, how in the world is anyone else supposed to verify that?

If someone can point to actually reliable ways to quantify impact of leaders/managers, please I would love to be shown to be misinformed.

> most people will say "wow, that's an incredibly arbitrary and abstract way of quantifying impact that feels suspect."

As someone who's said that, you've given me reason to ruminate on whether I was being too cynical and not empathetic enough.

Quantifying individual engineer output - lines of code, etc - has many well-known problems.

Quantifying impact of mentorship, technical leadership, management inherits all those problems and then adds new confounding factors in on top of it!

Quantifying business metrics changing is usually going to be misleading at best short of for, say, a CTO, and even then it's gonna also depend on product, sales, marketing, etc.

I like where you went with this.

1. The corporation itself is built on business metrics though. Everyone quantifies this way, it’s table stakes to portray oneself as responsible for a positive change in business metrics. You still must pretend they matter even if you know better.

2. What do you think about quantifying by the free market? Eg. the annual revenue contribution of a new SaaS SKU that you spearheaded.

Listen, jack. Delivering mind numbing corporate software is important.

Now you listen here, Mac. We're delivering valuable designs and solutions at cloud scale over here, so you take your FUD and envy elsewhere.

I've only read this one, but did in a spirit of "happy to be there." I did get a bit of a whiff of "drank deeply of the cool-aid" vibe, however. For a blog meant primarily to be read by your team/pr-vehicle it might make sense.

Even better, she just declared herself Staff because she wanted too.

> I was incredibly lucky to spend 5 amazing years at Heroku. By the end of my time, I was operating in a Staff capacity, although I’m honestly completely unclear which titles at Salesforce actually map to Staff.

> I live-snarked much of the process on Twitter

oh, that explains it. An "influencer" and "thought leader".

Reply on news.ycombinator.com