I have observed that a Staff engineer has mastered these three skills: Communication, Adaptability, Challenging Situation Management
Normalize being just a really productive IC. Not everyone wants to spend their energy on these facets of a job; some folks just want to build awesome stuff -- and that should be fine.
I think it's unwise to dismiss soft skills as getting in the way of that goal. As responsibility increases, and the complexity of your work increases, you'll have to lead people at some point. You can absolutely remain an überproductive IC forever, but you will cap out on what you can achieve -- and most importantly, what you can control -- by virtue of almost all great accomplishments being realized by more than one person.
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
I fundamentally disagree with the author's perspective on a "Staff+ Engineer". This is why organizations have management tracks like "Director of Engineering", "Engineering Manager", "VP of Engineering", "Head of Engineering", "System Architect".
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.
I think it's even MORE important to have good "soft" skills to graduate above a senior engineer. If you go to a management track, you kind of have the prestige of "being the boss" that means you can be pretty bad at soft skills and still have people listen to you.
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 don't know when people started conflating "being a really productive IC" with "getting to the top of the IC ladder but not having to do anything I don't want to do."
People want to be "a really productive IC" and just churn out tickets and never have any meetings and be short with their peers. That's fine if you accept that there is a ceiling to your career if you behave that way, and that ceiling is far below Staff level both in terms of respect and also impact and compensation, and rightly so. But expecting to continue to get promotions and buckets of money for churning out JIRA tickets is not something that should be "normalized."
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.
I concur with the comments that soft skills are necessary to excel even as an individual contributor. An anecdote comes to mind:
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”.
Ok, so you don't want to be a mechanic but learning how to change oil and a tire comes in handy. Sure you'll usually pay someone else to do it but the skills are useful and can get you out of a pinch.
these aren't exclusive. ultimately our ability to function as engineers has to be in the broader context of the organization. to build thing that are designed to solve customer or organizational problems. to do so in a way that slots in with existing systems and cultures. the function sympathetically as part of broader team.
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
Is basically "here's why you can't get promoted".
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".
it is fine. there's nothing wrong with being a senior eng for the rest of your career. but everything above senior is a sort of management position even if you're an ic. you have to work with stakeholders to make strategic decisions and to do that you need people skills, even if you're not managing direct reports.
Yeah, to me, not focusing on those skills is what makes someone a Senior II. I think it needs to be okay for not everyone to make it to staff+ title levels. Those ICs fulfill a different role in the org than a senior engineer. Having multiple senior levels or a wide enough salary band should ensure a suitable terminal path for those who don't want to step into the staff+ space.
Personally I'm going to be the devil's advocate and say that soft skills are vastly overrated. Usually it's the "soft skills" people getting in the way of engineers, and as someone who's been on the other side of the fence purchasing a $1M/yr SaaS product, I want the sales people to get the hell out of the way and connect me with a real engineer.
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.
Speaking as a highly introverted guy, I realised long ago that I would be limiting myself hugely if I didn't learn to get along, communicate effectively, and yes, influence other people.
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.
I have observed that while having some can be beneficial, usually banging the "soft skills" drum are those that do not have the capability to learn much else anyway, as soft skills are the lowest hanging fruit.
Nothing wrong with the senior engineer level. I’ve had the experience of managing 75 developers and I enjoy the fact that right now I’m “just” a Senior Software Engineer.
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 difference is often that “Member of technical staff” and “Staff” are two different things. Lots of companies have “member of staff” ~= swe 1 and 2 but then simultaneously also have staff above senior.
I'll throw another possible explanation into the mix: the gap between "senior" and "staff" can be quite large in some places depending on the threshold for being titled "senior". I've seen places where promotions to senior is not uncommon for someone 3-4 years out of college but with no staff engineers under the age of 30, and only a few under 35. Without any other granularity of IC roles, the only options for a young engineer are to be "stuck" for a decade at a role with a title so coarse that it doesn't really convey seniority (which tends to mean that the actual "seniority" of an engineer is implicit institutional knowledge), swap to a manager role, or go somewhere else with a more explicit career path for ICs.
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.
these are nice and useful, but kind of basic social skills that you'll find are neither sufficient or necessary (otherwise almost everyone who managed would have them, and having them would yield manager roles). they will make you more likable, and less annoying to deal with for sure. however, the people you ultimately work for have typically learned some variation of this: https://jeffreypfeffer.com/teaching/
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.
Another part of considering your audience that I often see overlooked, is understanding how your role and your work fit into a larger picture of the organization's goals. The goal of software engineering isn't ultimately to produce software, it is to accomplish some other real-world task. One of the biggest mistakes I see senior software engineers make, is trying to solve every problem by writing software. A wise software engineer knows when they shouldn't be writing software, but instead solving problems by addressing human processes or engaging with other disciplines.
It's not just being able to communicate, you need to adopt a persona.
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.
Readit News
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.
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.
Deleted Comment
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.