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.
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.
> 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?"
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.
The actual technical merit or cost effectiveness usually has utterly no correlation at all to how the business decision is made.
I thought you didn't want to be burdened with selling ideas, but just wanted authority to implement them without convincing people.
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?
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.
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.
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.