[October 10, 2021] If you enjoy this article, check out my new post on this topic: Staff Software Engineer Responsibilities — Align With Authority.
The path of the Staff Software Engineer represents the career progression of a technologist. Senior Engineer leads to Staff Engineer which leads to Principal Engineer which hopefully leads to a comfortable retirement. Unfortunately, Staff Software Engineer responsibilities are often poorly defined by management. The goal of this article is to give clarity to these responsibilities so aspiring Staff Engineers—and their managers—can perform their jobs more effectively.
Context
These responsibilities make the most sense within a specific context:
- An organization that makes money by selling software
- This is important because it forces alignment between engineering and business goals.
- An organization that has separated the technical track (Staff/Principal) from the managerial track (Director/VP)
- This is important because it implies that the company has created a space for technologists to make an impact. The risk is that this space can be ambiguous.
- An organization with at least few hundred software developers
- This is important because a minimum people scale implies a basic organizational hierarchy and an ample need for collaboration.
These responsibilities will not make as much sense if you’re in a completely different context.
Preface: Product <> Engineering
Software companies strive to create inspirational product visions and effective product strategies. The vision is the what and the strategy is the how. If done well, these two items are extremely powerful. The vision of “Become A Space-Bearing Civilization” is enough for SpaceX to recruit thousands of engineers to work on rockets.
The company’s vision is set by product management—not engineering. The engineering organization is in service to the product organization which is in service to the business. Software must be designed to support the product strategy and ultimately realize the product vision.
Product management respects engineering; they know that tech debt is no laughing matter and that nothing ships without sustainable software. Similarly, engineering respects product management; they are fully aware of the technical implications baked into product goals.
- Does the company want to expand internationally?
- Does the company want to provide a Developer Platform?
- Is the target customer an enterprise or a person? Both?
- How quickly do we have to ship given the competition and market?
In this context, product and engineering collaboration is paramount. Staff Software Engineers are responsible for understanding product goals and aligning their work with what’s best for the business.
Staff Software Engineer Responsibilities
Problem-First Mindset
Every engineering organization has an overwhelming amount of technical problems. A Staff Engineer is responsible for discovering the problems that pose a risk to the business.
- The developer experience in a particular domain is terrible, which kills developer velocity and hurts product development.
- The responsibilities of a microservice are nebulous, which causes teams to stall and hurts product development.
- A business-critical codepath can’t handle a 10X magnitude bump and needs a re-architecture.
A large list of problems is not useful by itself. In additional to discovering problems, a Staff Engineer also has the responsibility to prioritize them.
A common risk is for Staff Engineers to hand off prioritization to managers. While an Engineering Manager can help with operational logistics, they may not be as informed on the technical implications of the problems at hand.
Transform Competing Opinions Into Decisions
Software developers inevitably grow attached to their work. Attachments often lead to conflicting technical opinions, and in the worst case scenario, block progress for the company.
Tensions are high surrounding the responsibilities of a particular microservice. There is no clarity for the service’s future. One team wants to expand its scope; another team wants to narrow it. Both groups have valid arguments and concerns, but development has stalled. Staff Engineers are responsible for breaking technical stalemates. They do this by talking to stakeholders, weighing trade-offs, and arriving at strong, opinionated recommendations.
Recommendations are only recommendations. Staff Engineers must push through friction and create decisions. Decision-making is a difficult process and will leave certain engineers upset; this is something that can’t simply be delegated to management. As a Staff Engineer, turning a prolonged technical debate into a recorded decision is a huge win for the company.
Concede With Humility
As a Staff Engineer, you may find yourself holding on to an opinion. Discussions surrounding an important architecture decision are going nowhere and now a Principal Engineer needs to conduct a tiebreaker. Even though arguments can be healthy, these situations are costly and must be minimized. Staff Engineers should practice egoless programming and know when to compromise; there is a difference between standing up for what you believe in and being stubborn.
Create More Staff Software Engineers
As with any other role, the end goal is to replicate yourself. For Staff Engineers, this means creating more Staff Engineers. A convenient byproduct of creating a prioritized list of technical problems is that you’ve automatically created a set of high-impact projects for growing senior engineers. This is a great way to elevate your colleagues while giving yourself extra bandwidth.
Choose The Right Problem To Solve
Staff Engineers must thoughtfully choose which problems they want to personally handle. A Staff Engineer can solve problems that most engineers cannot. By definition, there are fewer of these problems and they must be properly identified out of the sea of technical issues.
There are two common risks if business-impacting problems are not properly assigned. First, if a Staff Engineers chooses to work on a “comfortable” problem, then a senior engineer misses a growth opportunity and the Staff Engineer’s time is underutilized. This is counterproductive because the engineering organization doesn’t grow. Second, if a complex problem is delegated to an engineer who isn’t ready for it yet, an inadequate solution implemented for a critical business problem could put the company in worse shape than how it started.
Broadcast
A common sentiment heard around software organizations:
I’m not really sure what {staff_engineer} actually works on …
Other Engineers
The communication required of Staff Engineers is very different than that of individual contributors, team leads, or engineering managers. Engineers mistakenly believe that the Staff Engineer role requires less communication—it’s not less, just different.
Staff Engineer projects are often isolated. This might be a deep untangling of debt or a broad, self-navigated exploration. It is impossible for the organization to benefit from this work if they’re unaware of it. Common mediums for this type of communication are sending newsletters, holding Q&A Meetings, and providing progress updates at relevant All-Hands Meetings.
A focus on consistent broadcasting is a quality that sets a Staff Engineer apart from his or her peers. This benefits both the company and the individual. For the company, you never know when a developer might pivot strategies based on a Staff Engineer’s explorations and recommendations. For the individual, actively communicating your work gives you a voice in the organization. This is essential for Staff Engineers because they must be able to influence without authority.
Observe
As a Staff Engineer, you have deeper technical context and experience than other engineers. You will see nuances where other engineers do not. Since it’s impossible to be involved in every project, the next best thing to do is to observe how the software is being built.
- Actively participate in architecture review meetings
- Read through architecture proposals and product briefs (new and old)
- Sift through chatrooms, paying extra attention to cross-team inquiries
You notice that an engineer pops into another team’s Slack channel and asks about a certain piece of critical code. While you can easily tell them how the code works, it’s more important to determine why they are asking about it in the first place.
The goal of active observation is to get ahead of technical problems. It’s not practical to expect every engineer to ask for guidance when necessary; they don’t know what they don’t know. Staff Engineers have the responsibility to keep a pulse on the software before a minor gotcha turns into a technical mess. There is never an expectation to catch everything, but there is an expectation to speak up when necessary.
Expedite Instead Of Block
As a Staff Engineer, one of your main responsibilities is to provide guidance. This includes approving architecture proposals, reading pull requests, and giving up your time for other engineers. This guidance is essential if it’s in the critical path of a project. If a developer needs your sign-off for the sake of moving product development forward, then that item should immediately be re-ordered to the top of your TODO list.
When too many projects depends on your guidance, there is a risk of creating an organizational single point of failure. A common cause of this is when select engineers accumulate too much historical context and have neglected knowledge dissemination. This is irresponsible; SPOFs inevitably slow down projects and must be avoided at all costs. As a Staff Engineer, you are responsible for using your position to expedite work, not block it.
Conclusion
Many people mistake the path towards Staff Engineer as a way to stay out of the limelight, a way to avoid meetings and dealing with people. While these positions exist, their impact and growth are limited, especially in the context of a growing software company.
Successful Staff Engineers are much more than technical experts. They are role models that understand how their actions affect the engineering culture. They respect product management and optimize their efforts in service of the business. Finally, they don’t work in ivory towers, but are actively engaged with the organization.
1 comment
This is a great article. Although this article gives a good insight into the responsibilities of a Staff Engineer, I had a couple of questions.
1. “An organization that has separated the technical track (Staff/Principal) from the managerial track”. I don’t think there’s a clear demarcation in my current company in this respect, what can I do about this?
2. I understand there are various ways to influence people and Staff Engineers don’t have the capability of influencing using authority. Can you help me understand, how exactly can a Staff Engineer go about positively influencing a subordinate?
3. Considering there’s an improvement that can be made in an existing piece of code, a system, or a framework, what would be the right way for a Staff Engineer to bring in the change in bandwidth-constrained work environment considering every other product-based company prefers releasing features over supporting stabilizing systems?