My Path to Becoming a Staff Engineer

There’s a plethora of information out there on what it means to be a staff engineer, and every article has their own points that you can learn from. This article is just talking about my personal experience of becoming a staff engineer at my current company.

TL;DR

In my personal opinion, a staff engineer is someone that is a force multiplier. This can be achieved by taking many different paths, but ultimately comes down to having passion for what you do and doing it in a confident manner.

Table of Contents

Different Paths to Staff

My company’s current job ladder goes Software Engineer (SWE), Senior SWE, Staff SWE , Senior Staff SWE, and Principal SWE. Other companies have many different levels of Staff engineer but as for right now at my current company, getting to staff engineer was quite an achievement in (IC) track. Leading up to my promotion I was constantly comparing myself to one of my peers who recently got promoted and I kept saying “I need to be like them”. But really there are different paths to becoming a staff engineer and I’ll talk about what I went through from the idea of working to promotion, to getting promoted and finally accepting the promotion.

Path 1: Large Cross Functional Projects

The peer that I kept comparing myself to got promoted to staff engineer and I thought their staff engineer defining moment was completing a large cross functional project. Completing a large cross functional project requires good planning, coordination, communication and execution across more than just your immediate team. Sounds exactly what a high level engineer does right? When my manager asked me about what I thought about my level and what I think would get me to the next level I naturally said, “completing a large cross functional project”. This was obviously a naive opinion because next thing I know… I get promoted to staff engineer which I was not expecting, so what was the work that I was doing that they thought qualified me to be a staff engineer?

Path 2: Foundational Work

The things I was working on included: completing large projects for our team, interviews, doing tech talks, mentoring, extracurriculars, and paperwork. So what I thought I was lacking was that large cross functional project, but I actually made up for in all the other areas. Completing large team projects, interviews, tech talks and mentoring are all things that all senior SWE’s should be doing. Extracurriculars like planning hackathons, participating in cross functional committees, and organizing offsites in my honest opinion… should be done at all levels. The paperwork that I was doing was the differentiator in my case. I was having a conversation with my director (in a skip level one on one) about my level and after a couple meetings it became clear that the “paperwork” I was doing was actually impactful foundational work. I was working on a bunch of process improvements like improving our Agile processes, and standardizing our project execution processes (from design documentation to planning all the way to the finish line). Both of which can definitely feel like paperwork but does provide a lot of value. I also piloted a new operating model for our team by embedding in other teams and generating the proposal for operating procedures so we could roll out more embedded engineers. Doing these things allowed me to be a force multiplier, that improved the efficiency and execution of our team.

Being a Force Multiplier

I recently came to the realization that providing value as a high performing engineer comes down to being a force multiplier. What does “being a force multiplier” mean? My best guess is that you provide business value in scalable manner. As I stated earlier two examples of this include executing large projects that are directly connected to the consumer, or doing foundational work that enables the organization to move forward harder, better, faster stronger (yes I went there). Whatever your force multiplying work is, I have some advice that I have been giving to my mentees for about a year that helped me start performing as a high level engineer. It all started with kicking my case of imposter syndrome and performing with confidence.

Kick the Imposter Syndrome

I briefly mentioned imposter syndrome in my first blog post, and you either know about it, or can easily read one of the many articles out there to learn about it. The turning point in my own career was when I was finally able to kick that darn hinderance. That turning point was I started to trust myself more. I have now been in the industry for about 10 years and I have a lot of knowledge and experience that I can trust. My own personal mantra is “I am not afraid to get fired”. I can break this down simply into two of our company values.

Value 1: “Drivers Before Solutions”

There’s a reason I am doing the work that I am doing. I have some experience or some technical knowledge that allows me to produce quality solutions. When I am working on a project, I always make sure that we are solving the right problem. Keeping this “drivers before solutions” mindset starts with planning but needs to be front and center throughout the entire execution of the project. You may come into a project where a proposal has already been generated. At this point you need to Trust But Verify, you were brought into this project because of your value add to the project in the form of knowledge or experience. In an agile environment (which I assume most of you are in) requirements change frequently and we need to keep the driver in mind when making any decisions that change the scope of the project. Trust your expertise and don’t be afraid to call out deviations from the driver. Some people fear challenging their peers, especially those that are more senior, that’s where the “not being afraid of getting fired” mantra comes into play. All of us engineers in the industry are here to solve problems, we should all work together to do this to reach the common goal aka driver.

Value 2: “Candid and Constructive”

I recently won a peer recognition award for this value and I humbly accept it. I call it like I see it and as my mantra says, “I am not afraid to get fired”. When I see a something that could be done better, I not only suggest it but I jump on the chance to improve it. When something does not make sense to me, I acknowledge that I need to learn something or I question why that decision was being made and call out risks or propose alternatives based on my knowledge. Some of these questions could be because I know less about the technology being used and that is also okay because I acknowledge that. I raise these questions with confidence because I trust my knowledge and experience and am only trying to do so in a constructive manner. I have this confidence because I have developed T-Shaped skills over the past 10 years of working in the industry that allows me to make very educated, experienced and well thought out decisions.

T-Shaped Skills Fueled by Passion

The main reason i was able to kick the imposter syndrome and get that promotion was because of this, I have built a T-shaped skillset. I have acquired a vast depth of knowledge when it comes to operating and maintaining cloud infrastructure. And I have also found a passion for doing foundational work to accelerate myself, my team and the entire organization. It all starts here, from when you’re a new college graduate (NCG) all the way to Principle Engineer. You can not be an expert in everything, so you need to choose where you will build your depth of knowledge. Choosing what you learn deeply about will come with time but ultimately needs to be something that you are passionate about. If you do not love what you do, then you should think about developing depth or breadth in another area. Another thing about doing what you love, sometimes you are limited to work on or learn only a certain things because of the limitations set on your role, team, organization or company. That might be the time to move on to another team or company because hindering yourself from learning what you are truly passionate about will only hurt you in your career and in life. I myself switched from an application developer into the DevOps realm and never looked back.

Conclusion

There are many paths to becoming a high level engineer. In the end it all comes down to providing value in a scalable manner. What that value is comes in many shapes and colors. You must operate with confidence, in a drivers before solutions manner to work together to build great software. We engineers are always learning and building these T-shaped skills as engineers and we need stay passionate about what we are working on to reach our full potential.

Takeaways

  • There are different vehicles (work you can do) to get to that next level.
  • High performing engineers are ultimately force multipliers.
  • Don’t be afraid to get fired, trust your knowledge and experience and operate with confidence, in a drivers before solutions manner.

Updated:

Leave a Comment