I have observed that a Staff engineer has mastered these three skills: Communication, Adaptability, Challenging Situation Management
Wanting to remain as technical as possible and be paid for your ability is valid, but soft skills will multiply your knowledge (and therefore value) across a team. In fact, I would argue soft skills are necessary to actualize your own potential as an IC within a team
For a Staff+ Engineer, aside from being an excellent IC, I'd make the case that there's only one primary skill (from which several others follow) at which they must excel: they must be able to write, write well, and write prodigiously because this is the most important form of communication within an engineering team.
My company does it great, we have a full engineering-not-managing track.
I'm a principal engineer, and because I have "engineer" in my title, I'm responsible for engineering. Though, that doesn't mean I'm an IC. I probably only commit 100 lines of new code a year - just the stuff that's clearly my expertise (and we use that as a learning experience by having the juniors responsible for reviewing that code).
I do need to lead the engineering effort of the team. I'm not their manager, they don't need to do what I said just because I said so. So, I need to be able to communicate well which means both being technically correct and persuasive so that the engineers who actually do write the code, right the correct code.
It's almost all soft skills needed to shape the direction.
I declined every time. I see no benefit in going further, and I see plenty of potential downsides.
At some point you have to be nice to work with, be able to communicate to a group why you want to make the changes you want to make, be able to adapt those changes to fit in with changing demands from leadership, and/or be able to convince your boss's boss why it's worth pushing back on those changing demands. That's all still IC work. "Doing tickets" is great but is a small part of a bigger picture.
A student publishing their first paper was remiss that their name was only one among many. Their mentor said, “That only matters if this is the only paper you ever write. Publish a lot of papers, and you won’t care for the placement of your name among any single one.”
The point is to do a lot of teamwork. You can scale yourself and others that way. I like to think that the job of an IC is more “make software happen” than “write all the software on your own”.
but _that_ should be enough. more than enough, and in any organization larger than 50 people its just not.
Welcome to the very first post on Path to Staff Engineering! Subscribe, and I will teach you the skills to level up to Staff faster
This is the classic "Maker vs Manager" dilemma that we've created with regards to technical career path ascension. A staff ENGINEER is still an engineer; reserve that role for your strongest ICs. Make them an engineering MANAGER or DIRECTOR or VP if their role is to manage people, situations, and communications.
I postulate that one of the many reasons organizations eventually fail to innovate is that they bias towards manager instead of maker. Once that happens, you've taken some of your strongest ICs and given them only one option to "level up": "Go manage people".
Soft skills are a commodity. I can go to a small town used car dealer and find more soft skills than the entire C-Suite at most tech companies. If you're a good engineer, embrace the unique value you actually bring to the table.
Soft skills are completely worth acquiring, especially if they don't come naturally to you. You don't have to make them your career focus, but rejecting them will definitely limit how awesomely you can apply your unique value.
But staff engineer wasn’t really used, and title inflation started giving out senior level titles for 3 years experience, so I guess Staff got rebranded as more senior than senior.
The number-based systems at the super large tech companies can be hard to understand from the outside, and they might introduce potential confusion when trying to calibrate between different companies with incompatible systems, but they at least allow for a more clear trajectory for an individual contributor (although whether this actually determines how promotions happen in practice is a crapshoot; internal company politics can't be fixed by nomenclature). I don't think that software engineering is somehow different enough from other professions that levels can't be classified with descriptive names rather than numbers, but clearly _something_ needs to change when we can't even all agree on what "senior" and "staff" mean.
Stanford has Pfeffer's Paths to Power, Harvard had the Negotiation Project, and I'm sure the other ivy and oxbridge colleges have something similar. you are up against pros who train on this.
Learn this stuff. we need more people with domain competence in _something_ in positions of power because I think there is an essential moral quality to competence that mitigates its excesses. the basic problem with specialist professional management is the goal of all professions is to sustain themselves first, whereas domain-competent people who manage can offset the crap from ones who just like power over others for its own end.
It turns out that an important soft skill is knowing how to make these kinds of drafts work in your favor, especially with internal stakeholders, by doing drafts that are annotated with where you want help and input.
As one example, "We want to work on the foobar because [get exact wording from team] to improve throughput [%]. We will request [#] team members for the next [n] months. We're working on decision records for our top 3 options which are [1, 2, 3]." Share these one-on-one with each stakeholder, gather feedback, and hone the draft.
For technical work as described in the post as "write a technical spec for engineers in & outside of my team", I recommend trying an architecture decision record, and sharing drafts early/often with stakeholders.
https://github.com/joelparkerhenderson/architecture-decision...
Your example still shows that you've put some thought into the draft, you know what you need to say, and where you need help filling in the details.
As a more experienced engineer that is actually extremely passionate about my work, the difference in the way I'm treated when I adopt a calm, cool persona speaking with a calm voice vs being excited, passionate, and appearing happy is significant.
I can communicate the same idea effectively using both personas but being detached, calm and cool just seems to garner respect more easily.
Stuck? Hardly. I protect my mental well being by working on mid size companies where where science and politics are important and yet, separate and equal concerns.
Make certain the planning people have no idea what the project actually looks like. Recipe for success, no doubt.
Sarcasm asside, I do understand not assigning coding tasks to someone who doesn't have the bandwidth but to be chastised for pitching in seems non-ideal.
On the contrary, I find that the first or second line of managers above ICs is almost always insufficiently compensated to offset the extra hours/stress/bullshit.
Fully agree on the incremental amount of excess bullshit, though. :)
Tips like these are becoming increasingly less applicable in the advent of remote only jobs.
Edit to add:
None of this advice really holds. At the end of the day, your technical ability is what matters. If you're gunning for a promotion, figure out what your manager needs to achieve their annual performance bonus, and make sure you are instrumental in helping them achieve that.
Otherwise, find a staff level position elsewhere, and apply for that.
Soft skills aren't what holds engineers back from advancing.
A great and experienced programmer is gold and what we need more of. Brownnosing ladder climbers are a dime a dozen.
What companies need to do is to ensure that a person who is who is great at their job and loves the role are compensated for the great job they do. and the value they bring to the company.
If necessary, create senior programmer (1,2,3,4,5,6,7,8,9,10,11,12) if the company feels it essential to change title to get more money.
Up or out is just dumb.
It’s a comparison to “hard skills”, usually meaning technical skills.
And these interpersonal and communication skills are extremely hard. Calling them soft devalues anyone who has cultivated them.