Staff Software Engineer


A Staff Engineer role is the beginning of an engineering leadership role where you lead without direct management authority. Staff Software Engineers are commonly expected to act as an enabler for at least two teams and think about bigger problems across a team boundary. A common setup is to assign a staff engineer a portfolio of teams to influence as an Architect. Some companies with very complex problems may assign Staff Engineers to be Solvers. Read more about the different Staff Engineer Archetypes

How to get there


As a Staff Software Engineer, you will be expected to communicate across teams and share designs / best practices. As a result, you will need to learn how to:

For more details, check out this article about Documentation in Software Architecture

Learn how your organization works

Learning how your organization works will inform your outlook on:

  • exactly what technical skill you need to invest effort into getting better at that will actually be rewarded
  • how to build lasting relationships with other people on your team or organization that will ultimately dictate the success of a project
  • how to effectively pitch projects or improvements and see these through to completion
  • how to navigate ambiguity
  • how to manage conflicting priorities or expectations
  • how to best deal with setbacks
  • how to weigh the pros and cons of technical choices in the larger context of the organizational realities and needs
  • how to identify and drive quick wins
  • how to discern what’s achievable in precisely what time frame
  • how to use this knowledge to judiciously pick battles
  • and in the worst case, to know when to cut your losses and quit

Managing your work

Because you will be working across multiple teams, it's less likely that you will be following the standard 1-week / 2-week sprints like you did when you were a Software Engineer in the team.

Instead, you will be most likely be managing your work via some kind of kanban board. Why kanban? Because:

  • You act as a center of excellence instead of working for a particular product, so sprints doesn't appear to fit very well
  • You will have a lot of emergent issues, either proactively identified by you or escalated by an engineer in your portfolio
  • Your work is generally not well-defined

Although you are not strictly following the sprints, it is still very important to stay close to the team. Read this article on The Agile Manifesto: A Software Architect's Perspective.


As you are straddling between multiple teams, you would usually have less control over what the team does as compared to the Engineering Lead. Use the trust you have built with many engineers over your time in the company to help you pitch an idea.

If you are new to a company, then you would need to build the trust from scratch. You should not use your title to drive people towards action. That never works well in the long term. Instead, ask a lot of questions and have direct conversations with your engineers to learn about the problems they face.

Once you have learnt their problems, it is a lot easier to come up with a solution that directly addresses their problems and make their lives easier. This book about Driving Technical Change talks about this topic and a lot more.


A big part of your role is to discover new ideas to solve problems. Most of the time, you have a hypothesis and you can test that hypothesis by creating proof-of-concepts (POCs). From this article about How to run PoCs

The goal of a Proof Of Concept is not to deliver working functionality. Rather, it is a way to test if the project is technically feasible. In a more general description, you could also say that the goal of Proof of Concept is to de-risk the project by implementing all the risky technologies and architectures that the developer doesn’t know yet if it’s possible to implement or not.

These POCs go a long way in helping you as a staff engineer:

  1. They show others that you are not just an ivory tower architect who has ideas but don't know how to implement them.
  2. It's much easier to communicate with engineers through code.
  3. The next time someone has a similar problem, just point them to your POC and they can take it forward from there.

Documentation should be done for your POC so that others can easily refer to a single document, understand the analysis and conclusions.

Your Reading List for this page