The Staff Engineer’s  Path

Staff Engineer responsibilities build upon skills you have already developed as a Senior:

1. Big picture thinking. Broaden your context in both space and time. Start thinking in terms of multiple teams and multiple years.
2. Project execution. The projects you take on will be more difficult and ambiguous. Your ability to navigate human factors will dictate your success or failure.
3. Leveling up other engineers. You are probably already leading by example. As Staff Engineer you are expected to exert more direct and explicit influence in service of raising standards of performance.

Because Staff Engineer is a leadership position, many engineers will never achieve this level. They do not have the interest and/or skills necessary to lead people and that’s okay. Not everyone needs to be a people leader.

If however you do want advancement to Staff Engineer, you need to grow your people leadership skills and consistently demonstrate those skills in a group setting. Ask your manager for direct feedback on your people leadership skills and opportunities for improvement.

As a Staff Engineer, you will often start solving a problem and get just far enough that another engineer can take over. Use this project and transition as a growth opportunity for that engineer.

To hand over projects successfully, you would be smart to bring along the other engineer from the onset. Do lots of planning, pair programming, and diagramming together. Let them see and experience how your mind works, getting the real thing not just summarized documentation.

The reason you need to transition the project over is two-fold. First, you need the project to have an owner going forward. Someone who can fix bugs, lead improvements, and serve as the point of contact. That likely isn’t you. Second, you probably have higher leverage initiatives to work on and at some point this is a better use of a Senior Engineer’s time than a Staff Engineer’s time.

Related to this is another point that Tanya Reilly makes: Staff Software Engineers need to pick projects that actually need them. Will Larson describes the problem as “snacking” in his Staff Engineer book, whereby you pick problems that give you immediate gratification but ultimately are better suited for someone less experienced. Snacking is appropriate sometimes, but not all the time. Pick problems that actually require your specific expertise, both technical and interpersonal.

Every tech company wants to move faster and more effectively. Human challenges like conflicting requirements, unclear decision making processes, and goal ambiguity are more likely to slow down a project than technical challenges.

What does this mean for a Staff Software Engineer? You need to consider the human challenges more than the technical ones. Transitioning from a tech-first mindset to a human-first one is difficult for many engineers and it takes some people years to make this transition. Outside of individual contributor roles like Staff Engineer, I have also seen this challenge among new Engineering Managers.

If you’re someone hoping for advancement to an Engineering Manager or Staff Engineer role, I would challenge you to be deliberate in spending more time on the human challenges than the technical ones. Pull out a notebook and write down the human challenges that will inhibit reliable delivery.

As you transition from Senior to Staff Engineer, you also gain the responsibility of authoring technical strategy. Technical strategy exists at every level, so the kind of strategy docs you author will differ from those written by your manager or your manager’s manager. As a Staff Engineer, the engineering leadership above you is probably expecting you to author strategy at the level of a technical area that applies across multiple teams – for instance, how to decide which data storage technology to use when starting a new project.

Good strategy is usually boring. It does not involve introducing a bunch of new technologies that will revolutionize engineering. You make progress in a deliberate and stepwise fashion, not in giant leaps. In other words, technical strategy does not equal innovation.

For technical strategy to be successful, you will need to gain high level support. Shop around your ideas and thinking with senior leaders, including those above you in the org chart. A common mistake here is only surfacing your strategy with people you consider friendly supporters. You shop around these ideas to get alignment and support, but also to expose your strategy to reality and make it more resilient. If you are nervous about a particular individual’s feedback, show them the strategy early on and make it feel like a collaborative process.

Once your strategy has garnered support from leadership and demonstrated resiliency, you need to communicate your strategy to the rest of the engineering org. A strategy that isn’t communicated may as well not exist.

Staff Engineers face highly ambiguous problems. If there is an obvious solution, then it’s probably a challenge better suited for someone less experienced.

To tackle ambiguous engineering problems successfully, you need someone you can be vulnerable with. Someone that you can have “how might we” and “what if” conversations with, knowing that they will not take your ideas as gospel or an edict.

This partner in experimental thinking probably needs to be at your level or above. When you pick someone below your level for these conversations, you run the risk of unintentionally introducing confusion. For instance, you may present a question of, “What if we restructured our code in this way…?” to which that lower-level engineer might start to believe that you really want to restructure the code, when in fact you’re just exploring all possible options.

When I coach Senior Engineers on growing into Tech Lead and Staff Engineer roles, I like to emphasize the importance of always having milestones identified and driving alignment with the project team around those milestones.

Tanya Reilly expands upon this idea in The Staff Engineer’s Path by pointing out not just the importance of milestones and alignment, but that those milestones should also be usable and demonstrable in some way. That might be a demo, an internal beta, or a customer-facing release.

Software Engineers often make the mistake of picking milestones that are purely technical, or ones that can not easily be demonstrated outside of engineering. This problem of non-usable milestones frequently occurs when the lead engineer organizes execution around layers rather than slices.

Why is working in slices better than layers? Let’s explore an example: you are building an employee directory for a human resources SaaS product. If you work in layers, you might build the API layer first including all the necessary API endpoints. Then you move onto the next layer, which is the web client. Then you move onto the next layer, the mobile client. The problem with working in this layered approach is that only at the end do you achieve anything usable. A layered approach not only prevents you from demonstrating progress but also prevents you from engaging in the iterative development approach we know as Build-Measure-Learn from The Lean Startup. Hard to learn from your customers (internal and external) until you have something usable.

A better approach is to work in slices. Build the API endpoints necessary for just the employee list, then build the web client and mobile client interfaces to display that employee list. Ship it. Now you have both demonstrated progress and shipped something that you can gain user feedback ground. Your milestone was usable. Now you move onto the employee detail view, building the API endpoint, web client UI, and mobile client UI. That’s your next milestone. Continue iterating.

If most problems in tech companies are caused by human factors, then it follows that Staff Engineers should not spend most of their time writing code.

When you’ve built your career and personal identity around writing code, the expectation to transition away from coding (at least in part, but not fully) can create existential questions and an identity crisis. You may fight the transition and that may be the signal that you’re not really ready for a Staff Engineer role.

As we look to the future, I see a world where AI technologies like ChatGPT are more beneficial to Senior and Staff Engineers than to junior engineers because these technologies are good at producing boilerplate – exactly the kind of low-value but necessary code that Staff Engineers should minimize their time writing.

When every meeting attendant is looking around quizzically wondering, “Isn’t somebody going to say something?,” you are the person they are looking to. Staff Engineer is a leadership role and people expect leaders to speak up. You don’t have to be the loudest or longest voice in the room, but you do need to focus people on the heart of the issue.

Below are some good ways to be the adult in the room:

• Have the difficult conversation
• When an chat or email conversation gets longer than a few messages, redirect it to a more personal interaction like video chat or in-person meeting
• Refocus the conversation from technical problems/solutions to customer and business problems/solutions.
• Discuss the human challenges as equally important to the technical challenges
• Question your own thinking and encourage others to do so
• Learn to recognize groupthink and explicitly call out when it’s occurring.

In my career, I’ve seen several Staff+ engineers who are highly respected for their knowledge and contributions… that nobody wants to work with because of how they approach others in conversation. These people are often better suited for a Senior Engineer role than a Staff Engineer role because their impact is usually limited to their own individual contributions.

How do you know if you’re the engineer everyone wants to work with? Take an inventory of the engineers in your company or proximity and count how many have reached out to you in the last three months. That’s a reasonable proxy for approachability and value.