Hacker News new | past | comments | ask | show | jobs | submit login

This article, along with a boatload of companies, fundamentally misunderstands the way that senior / principal / staff engineers add value.

The article mentions it briefly in the small part about “force multiplier” but then seemingly reverses course when talking about “soft” duties & especially emotional labor.

The value of staff engineers is to give them autonomy in deciding how to be a force multiplier. If they realize for themselves that this can be accomplished with some soft skill application, so be it. If they realize this will happen if they do not delegate some critical task and instead clear the calendar so they can write the code that time, that is good too. And lots in between.

But autonomy is the critical thing. These are engineers that you’ve decided to trust greatly, so you cannot get in their way with compulsory person management overhead, adding them to every product meeting, burdening them to “sell” their vision on some architecture, recruiting policy, whatever.

These are the very people who you should be getting out of the way of, letting them decide how to be a force multiplier.




> burdening them to “sell” their vision on some architecture, recruiting policy, whatever.

Fair warning, if I ever interview you for a position of senior or higher, I will be evaluating your ability to sell your ideas to other engineers. Anyone who comes in as a Staff Engineer expecting to simply dictate their ideas to lower-ranked engineers without selling those ideas, is going to fail.


In that case, I would politely thank you for the chance to interview and decline to speak further with you, because it would be clear I would not be empowered to get my job done in the face of all the time-waster politics to lobby for projects or quarterly goals, etc. I would feel, “why have they hired an expert like me if they don’t plan to trust my advice on what action to take?”


The statement

> anyone who comes in as a Staff Engineer expecting to simply dictate their ideas to lower-ranked engineers without selling those ideas, is going to fail

was almost certainly about the field in general, not this person's immediate org or even company. So it's more like, "why would we hire an expert like you if we won't actually get the value we're paying for?"


> “So it's more like, "why would we hire an expert like you if we won't actually get the value we're paying for?"”

But hiring them into a position where they are automatically subject to pre-existing political barriers guarantees you won’t get value out of them.

Giving them autonomy means you could possibly benefit from their value-add.


I don't think it's fair to use the label "pre-existing political barriers" when talking about being able to convince people that your ideas and vision are worth the cost it takes to implement.


That makes no sense at all. Pre-existing political barriers are the primary obstacle to convincing people in most business settings.

The actual technical merit or cost effectiveness usually has utterly no correlation at all to how the business decision is made.


> convincing people

I thought you didn't want to be burdened with selling ideas, but just wanted authority to implement them without convincing people.


“Selling ideas” is not related at all to demonstrating the technical merit of ideas. They are completely unrelated things.


It might be just me but I think a lot of people read "Selling ideas" as "demonstrating the technical merit of ideas".

Unless the requirements are brain-dead simple, you'll need to sell at the very least the criteria on which you're measuring technical merit: is a latency number a hard requirement, will it scale for x of years, will it be buildable in y months or years.

At least some of that is going to come to convincing someone you've done your homework even if they couldn't make a better decision right?


That's an odd distinction and almost certainly not one that was made by anyone else in this conversation.


I disagree. It is a basic and ubiquitous distinction in any corporation, because the distinction between appraising the technical merit of a proposal and assessing the political implications, who gets credit, bonuses, etc. etc. is so vast.

The connotation of “selling your vision/plan” is obviously political, getting buy-in from a political / authority sense, unrelated to any technical specifics.

This is just corporate day-to-day 101 stuff. My use of this distinction is not unique in any way, it is the obvious interpretation that would be used anywhere someone is discussing any type of business project.


Do you really think software engineers react well to being told what to do by someone who has not yet earned their respect?


That seems inapplicable. This part of the comments is just about being given the political authority to implement the course of action you determine is best.

Of course that always starts with developing trust and belief from the engineers and probably even needs to be based on what they know and their experience.

That’s a separate issue from being a political lame duck hire who, even with engineer support, is blocked from being effective.


This is pretty insightful!

To me this capture the right gist of being more valuable than senior eng.

Next for principal, it must involve business decision. Their work must noticeablely affect top or bottom line of the company.


but the eng himself isn’t going to make those calls. he needs to work closely with PMs and other business side folks as a team.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: