<p><pre><code> I have observed that a Staff engineer has mastered these three skills: Communication, Adaptability, Challenging Situation Management
</code></pre>
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.
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.<p>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.
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.
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.<p>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: <a href="https://jeffreypfeffer.com/teaching/" rel="nofollow">https://jeffreypfeffer.com/teaching/</a><p>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.<p>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."<p>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.<p>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.<p>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.<p><a href="https://github.com/joelparkerhenderson/architecture-decision-record">https://github.com/joelparkerhenderson/architecture-decision...</a>
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 <i>shouldn't</i> 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.<p>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.<p>I can communicate the same idea effectively using both personas but being detached, calm and cool just seems to garner respect more easily.
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.<p>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.
From the article: <i>"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."</i><p>Tips like these are becoming increasingly less applicable in the advent of remote only jobs.
Who is this guy and why are we listening to his advice?<p>Edit to add:<p>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.<p>Otherwise, find a staff level position elsewhere, and apply for that.<p>Soft skills aren't what holds engineers back from advancing.
Why should it be necessary or thought of as important to do that?<p>A great and experienced programmer is gold and what we need more of.
Brownnosing ladder climbers are a dime a dozen.<p>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.<p>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.<p>Up or out is just dumb.
I’ve also stopped calling these soft skills.<p>It’s a comparison to “hard skills”, usually meaning technical skills.<p>And these interpersonal and communication skills are extremely hard. Calling them soft devalues anyone who has cultivated them.