Weak Soft Skills: Why you are stuck at the Senior engineer level | Hacker News Reader

Weak Soft Skills: Why you are stuck at the Senior engineer level

pathtostaff.substack.com

36 pointssidwyn51 comments

    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.

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.

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

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.

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.

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

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.

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

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 probably only commit 100 lines of new code a year

You're a manager, not an IC.

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.

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

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

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.

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.

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.

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.

You don't need to manage 75 developers to be a higher-level engineer on the title/pay ladder.

Back in my day, Staff was below Senior.

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.

Same. "Staff" was entry level. The word "Junior" was not used in job titles, and I still think it sounds belittling.

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.

> "Do not share a half-assed draft."

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

Interesting technique. Thx for sharing

Well there's a differnece between half-assed and incomplete.

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.

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.

Can you elaborate?

I get much better results when trying to convince people of something when I speak in the generic podcaster voice.

A world filled with MS Power Point presentations with lots of bullet points and sprint velocity charts and 2 hour technical meetings is a sad world.

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.

I’m constantly torn by the natural inclination to climb the ladder and enjoy the financial rewards, but I have little interest in the day-to-day tasks of my staff engineer coworkers (mostly sitting in meetings and writing emails, very rarely writing code because that’s considered beneath their pay grade and they’d likely be chastised for it at my company). If I had a family to provide for, I think it would be a much easier decision to take the money.

> If I had a family to provide for, I think it would be a much easier decision to take the money.

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.

On the other hand, early in my career as an IC, I was already working as many hours as I possibly could (out of interest/passion and driven by myself rather than a boss or PM). As I transitioned into management, there weren't any more hours possible (though I was already well over 40/week).

Fully agree on the incremental amount of excess bullshit, though. :)

> writing code because that’s considered beneath their pay grade and they’d likely be chastised for it at my company)

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.

This assumes that working 40.0 hours a week of $x/yr is going to be worse for your family than working 60.0 hours a week for 15% or 20% more. If you're already making $175k/yr in Omaha it's very unlikely that making $205k/yr but missing dinners and school functions and not being able to chaperone class trips is going to give you such a huge quality of life increase that it's worth it.

This assumes the staff engineers work more hours (not my experience)

From the article: "Watch how your audience reacts. You have the benefit of being able to see how people in the audience react. See if they're engaged or falling asleep, and tailor your delivery."

Tips like these are becoming increasingly less applicable in the advent of remote only jobs.

Unless everyone has webcam off and are muted and stop participating - I still can see people rolling their eyes when someone is saying something silly, I still can see someone is unhappy with decision we just made. I still can get some stuff from tone of voice when person disagrees even if they have webcam off.

Who is this guy and why are we listening to his advice?

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.

Why should it be necessary or thought of as important to do that?

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.

I’ve also stopped calling these soft skills.

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.

You can stop calling them soft skills if you want but all that's going to do is make it so nobody knows what you're talking about when you call them something else.

they're typically called "durable skills" outside tech. it reinforces the idea that they are portable between domains and are themselves things to be developed and practiced.

Reply on news.ycombinator.com