There are a lot of not-sexy but highly impacting skills in systems programming.

For example, the most productive person I've ever met, is a master of shell script, all the various shell tools (with obscure flags and usage modes), has deep knowledge in the use and application of makefiles, is a perl wizard and knows lots of tricks for virtualizing/replicating things in non-obvious ways.

When this person wants to automate a task, he can do it immediately, without having to think about 'how do I xxx'. It just flows from his fingertips because he knows all of these 'basic' things. Since so many things in SW are automatable, this gives him a non-linear advantage against nearly all his peers. He can dedicate 50% of his time building tools that act like a multiplier for the 50% of his production work and gets 500% done.

Ship code that works, do it quickly, and do a lot of it.

A common mistake is to focus too much on the technical aspects and not enough on shipping. It’s easy to get lost in over-engineering the hypothetical perfect system that doesn’t ever shift to customers. You don’t want to be that person.

Instead, focus on simplifying implementations and shipping simple, trustworthy code as quickly as possible. A reputation for getting things done will go a long way.

Beyond that, focus on area under the curve. The more code you ship and the more tickets you work through, the more experience you’ll acquire. Cut through the time wasters and get coding as much as possible. Over a decade you can accumulate multiple times more experience than someone who moves slowly and puts in the bare minimum. This doesn’t mean kill yourself by working 50+ hour weeks, but it does mean you need to learn how to cut through the slack in a workday and eliminate procrastination and distraction. Learn how to get down to work and focus efficiency. It’s a learnable skill.

When you are trying to become a good junior engineer, or a good senior engineer, it feels more like "checking off the boxes on the checklist". There are many skills that are expected of you, and you should gain them.

But you are kind of past that point. There are a lot of different "archetypes" for being a really good staff engineer. You can become very skilled at a particular technology, or very knowledgeable about a particular product, or very politically effective within a particular organization. For different people, the best strategy here is different. It depends what you're good at, and what you really want to be good at.

For your question - if you joined a new team, what skills would you really need? The answer is, it depends on what the team needs.

I think you might be focusing on the wrong details. The first step in taking your career further is to find a team that is a good fit for you. That means two things.

1. The team's mission is big enough that it needs a staff engineer (or another staff engineer)

2. The skills needed for the role of staff engineer on this team are skills that you have or can acquire

On some teams it will just be impossible for you to become a staff engineer, because there just isn't enough opportunity or importance, as perceived by the management. On some teams it will be impossible for you to become a staff engineer, because it will require a skill that just isn't you. So go find the right team, and then it will be far more obvious what you need to do to become a ridiculously good backend staff engineer.

Feel free to email me if you'd like to chat more, I have been the engineering manager for a number of people who have gone through the senior -> staff period in their careers....

Get to be better than average at picking projects and tasks that have identifiable, meaningful deliverables. A history of highly evident impact is a huge part of a personal brand of success. Learn to avoid projects where the best outcome is "fail less hard." Avoid being brought in as life support. Don't be left holding the bag.

Obviously, green-field projects hold the promise of easy prominence. But you can learn to spot other opportunities that aren't as obviously sexy, yet get you name recognition.

Take time to reflect. A lot of folks focus so much on doing that they don't take the time to take a step back and see what's working and what isn't. You might be shipping a lot of good stuff, but maybe you're making assumptions too often, or making the same mistakes over and again, or simply not taking the time to just _think_.

Take time to share and listen. Teaching, mentoring, coaching, etc. others, especially those with less experience, is good, but is often done as a one-way transfer of information. Instead, find people who ask good questions (those with the least experience often ask the best ones) and be open to exploring those questions together. It's hard, because you will base your answers on your experience, which is by definition limited (it is for everyone), but it may not be the right answer in all situations.

> A bit of a click-baity title, apologies.

On the contrary, your attitude of "I want to become ridiculously good at this" will carry you 50% of the way there. Good luck!

I haven't been around the block a lot nor do I consider myself as "ridiculously good" but from my experience shipping is king, every time.

It's very easy for us to focus on the tech and think that more knowledge, more performance or whatnot is the next level. While we have some superheros (John Carmack, Dennis Ritchie, Dan Abramov) that are famous for incredibly focus and deep technical skills, for the rest of us, we are evaluated on getting stuff done, reliably and consistently.

There are, of course, situations in which "shipping" has to do with performance (I once had to rewrite and algo from python to rust to gain about 100x performance), but in those cases it's often explicitly defined as a business requirement, i.e. more revenue or lower expenses.

Another tool in my toolbox has been understanding better the "business" of coding, that is, how does software engineering work fits in the "supply chain" of a company, from idea to the sales guy making cold-calls. Two books come to mind, "The Unicorn Project" and "The Phoenix Project".

At any rate, the desire to keep improving yourself, growing and learning it laudable!

If you pay deliberate attention, you will find that some problems affect projects dramatically more often or more severely than others. If those problems were easy to solve, they might not exist. If you learn to solve them, you will be a lot more valuable.

However, since this isn’t about listing trendy techs on your resume or l33tcoding, I don’t know if it will make you more in demand or not

Don't make simple things complicated. Simplify complex things. backend developers generally like to build complex crap.

In addition to the good advice already posted, some links here that could perhaps be useful for you: https://news.ycombinator.com/item?id=28007862 (mainly the first two links in the list)

Internalize DDIA and go deep on some topic (databases, event sourcing, kubernetes, etc) that interests you.

1. automation. Write code that removes humans effort.

2. do hard things. Solve problems other people are incapable or unwilling to solve.

3. practice. Rinse and repeat until you get it right. Be insanely persistent.

4. humility. There is no secret sauce. There is no magic toolset, framework, or assistant to do your job for you or cheer for you. Toil in silence and repeatedly fail until you get it correct. That pinnacle of success is the expectation not an achievement.

read this https://staffeng.com/book and decide which type of staff path you want to follow.

the author Will Larson https://lethain.com/ goes into detail about all types of staff engineers

also follow him on twitter

The non-tech stuff seems to be most important at this level. One thing I notice some senior SWEs lacking is instinctive understanding of how prioritize and which tradeoffs to make to maximize their value. Beyond that it seems to be almost entirely political / luck of the draw. Figure out how to play the game.

Learn databases.