The path to Staff Engineer

What happens after you are a Senior Engineer in a startup? How do you align your career goals with what the company you work for needs? In this post, I share my personal experience while I also talk about the Staff Engineer book.

In the last five years, I have worked in different roles at Thinkific: I started as a Full-stack Developer, and then I was Team Lead for three years. The Team Lead role was great, and I had great support from the organization, but it was not for me.

Moving back to a Technical track of my career, I found the Staff Engineer book written by Wilson Larson, which helped me a lot how to see my role and my potential. The book covers the different types of Staff+ titles we see in this industry (Staff Engineer, Principal Engineer, Architect, and others) and contains interviews with fourteen professionals who share their career trajectories.

You can buy Staff Engineer ↗︎ as an ebook, audiobook, or physical copy, and if my post doesn't convince you, listen to these two ↗︎ podcasts ↗︎ about the content of the book.

Next, I will share a few topics of the book along with my personal experiences.

Archetypes

The book starts by identifying the different archetypes of Staff Engineers. I previously noticed how my colleagues act in different ways in their projects and teams:

• Tech Lead guides the approach and execution of a particular team;
• Architect is responsible for the direction, quality, and strategy within an area;
• Solver dips deep into complex problems and finds an appropriate path forward;
• Right-Hand borrows executive scope and authority to operate particularly complex organizations.

The archetypes do not necessarily reflect a job title, but the Architect one sounded like what I was doing at work. The book has a "typical calendar example" for each role, and his Architect's Weekly Calendar looked pretty similar to mine.

The calendar looks very busy compared to an Individual Contributor calendar. It reflects that Staff Engineers are in a leadership position. They influence people, not like a Team Lead or Engineer Manager, but differently: with technology.

Getting the title

The book also covers how to "get there". It is a combination of different factors, and I will comment on some of the mentioned in the book, starting with Staff Project.

Staff projects

This is not a promotion requirement, but delivering a Staff project is a popular step around reaching a Staff+ role. Staff projects are typically:

• Complex and ambiguous: the project might start with only one unclear statement, and from there, you'll have to identify a concrete approach that works;
• Numerous and divided stakeholders: the complexity can also happen in the organizational alignment around both the problem and the solution;
• Highly visible: the kind of project that leadership talks about it in their all-company meetings. Any failure or success will be visible.

I didn't have a Staff project to move to an architecture role; however, I delivered a complex project with the characteristics above during my Team Lead years.

Promotion packet

Once you identify why you want the role - "this is not a faster Senior Engineer" - the next step is writing a promotion packet. Organizations will do this in different ways, but mainly the outcome is mapping your impact as a professional and identifying areas or skills that you can develop in the next while.

The promotion packet is a living document. Review it with your manager once you have the first version, and periodically check/update it to follow your progress towards a career change.

Finding your sponsor

"The most important member of the team guiding your promotion is you yourself" is a quote I couldn't agree more. Nobody will drive your career for you, but it is crucial to find people that will support your journey.

Your direct manager will be the person to advocate for your promotion and the one having honest conversations about the gaps you need to fill to become a better professional. They may/may not have worked with someone aspiring to the same careers goals that you have, and for that, invest in other relationships.

Get in the room, and stay there

This chapter is great no matter the area you work or the title you have. The content is available online ↗︎ and here is a short summary of the main points:

There is no single "room" to enter: entering rooms will be an ongoing, iterative careers challenge. It might be a sprint pre-planning with your tech lead, a quarterly planning meeting, or an architecture review.

There are some strategies to increase your value "to the room":

• Stay aligned with your manager: being on the same page as your manager is something that many take a while to comprehend;
• Optimize for the group: optimize your message for others build trust and confidence in your judgment;
• Speak clearly and concisely: good advice no matter what occasion you are interacting with other human beings;
• Be low friction: learn how to navigate difficult conversations effectively, and you're more likely to be involved;
• Come prepared: good advice no matter what occasion you are interacting with other human beings;
• Focus and be present: good advice no matter what occasion you are interacting with other human beings;
• Volunteer for low-status tasks: being helpful, especially for not exciting tasks, is an underestimated skill.

Being visible

The last topic about the book I want to highlight here is visibility. Visibility is crucial in this type of role, and there are ways to improve visibility in the workspace:

• Executive visibility: develop relationships beyond your manager;
• External visibility: have a blog/podcast and speak in a meetup/conference creates visibility for yourself and your work;
• Internal visibility: work on things that matter is the best way to create internal visibility, however a few other things that can help you, including writing long-lived documents (ex. architecture docs), leading company events (ex. architecture reviews, company all-hands), contributing to your company's blog and attending/hosting office hours for your team or organization.

I am a true believer in external visibility; otherwise, I wouldn't be writing about development here since 2005 or speaking at meetups (even without a polished English) since 2016. In different organizations I worked with, I had written docs, led company events, and attended/hosted events.

Stories

Each story of a Staff or Principal is fascinating to read. My favourite snippet, which is very similar to what I was doing before reading the book, is from Katie Sylor-Miller ↗︎:

"I'm a frontend architect, but by far the main thing I've been writing lately is SQL, because I'm doing a lot of data analysis. I've been looking at our performance metrics to figure out where the areas for improvement are, and what would be the most impactful issues to fix to improve performance and business metrics. I will write little bits of JS or PHP here and there, but it's mostly to help unblock teams or to run small performance-related experiments."

Conclusions

Figuring out what to do in our careers is hard, but there is help out there. For a while, I stayed in the "manager path" then I returned to the "technical path" with the support of my [great] manager and research.

I hope that the experience I shared here and Larson's book can help you identify how to navigate your career development. Share your thoughts in the comments!