Hacker News new | ask | show | jobs
by disattention 683 days ago
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

2 comments

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.