[CharlieDigital]

    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.

[disattention]

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

[CharlieDigital]

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.

[michaelrpeskin]

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.

[CharlieDigital]

    I probably only commit 100 lines of new code a year 

You're a manager, not an IC.

[pc86]

No?

Firstly, they say right before the line you cherry-picked that they're not an individual contributor. But your statement makes the implicit assumption that you are one or the other. If you're not a manager, you much be an IC, if you're not an IC, you must be a manager.

The best organizations I've ever worked for have had their front-line managers still responsible for significant IC-type work. If you work somewhere where the lowest management level has a dozen direct reports and spends all day every day doing "management things," run away as fast as you can because they have no idea what they're doing. The lowest management level at my current role can expect at most 2 reports if they're managing a different team than what they came from, and at most 3 if they're getting moved from IC to management on the same team. The other ~60% of their time is spent writing code and doing these "Staff+" tasks. There can absolutely be a gray area and in the best organizations there definitely is. The top 2-3 IC levels and the bottom 1-2 management levels will be nearly indistinguishable from each other with the exception of whether or not you have direct reports.

[richardwhiuk]

It is - it's just that a really productive IC is a Senior Software Engineer. That's usually considered a fine place for a persons career to plateau.

[pc86]

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."

[surgical_fire]

I am "stuck" at the senior engineer level by choice, Having been asked by multiple managers to apply for promotion.

I declined every time. I see no benefit in going further, and I see plenty of potential downsides.

[linuxftw]

Nah, you're supposed to play PM and manager so those people can do less than nothing.

[CharlieDigital]

A couple more all-hands Teams meetings ought to fix that!

[digging]

Developing these skills will always be useful, but I agree it's not always ideal to focus on them.

[pc86]

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.

[tyleo]

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”.

[jayd16]

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.

[convolvatron]

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.

[CharlieDigital]

Sure, but the premise of the article:

    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".

[convolvatron]

I don't care about promotion. what gets lost here is how we drive the product. we vest all the authority to a manager, and the manger rightfully sees their role as mataining the culture and the group. how do actual engineering decision get made. how to we decide how to evolve the product? thats not in the wheelhouse of the manager. increasingly ICs are encouraged to see their work in isolation - they get a task, they get to decide how to do it, and retire it in two weeks or less. How do we set direction as a group? How do we actually make a cohesive design rather than just dig a pile of feature requests. mostly it seems we just don't.

as an engineer I don't want to deal with scheduling people's vacations. I do think there is a real need for a manager to build and shape a group. To treat people like people instead of just contributors. but broadly as an industry we are totally failing to make decent strategic technical decisions and follow through.

[efficax]

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.

[Spartan-S63]

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.