Blog -
Staff Engineer: Defining a Role and Deploying It
When I joined FloQast, we had four engineering teams. Today, we have more than 20. We started with a core monolithic application and continually split off new verticals that were subsets of the main FloQast application or new customer verticals entirely. One of those four teams I mentioned earlier is now nine different teams.
Keeping technical architecture and practices aligned became even more challenging as we grew. When we had fewer teams, our engineering managers could keep a close eye on the architectural patterns of teams while also responsible for the people and processes. Today eight teams could be four or five engineering managers.
How could we lean on a role that would merge understanding customer pain points with architectural concerns across multiple teams?
Enter: The Staff Engineer
We rolled out Staff Engineers in disciplines like QE and DevOps, but not in Software Engineering. How would it look if we were to deploy this role in the software engineering discipline? Who would they work with? How would they work with them?
The Staff Engineer
First off, what is a Staff Engineer? As a software engineer at FloQast, you may come to a fork in the road in your career: would you like to stay as an individual contributor, or would you like to transition into management? Staff Engineer is our next career path level after Senior Engineer. A software engineer doesn’t have to become a Staff Engineer – they can stay at Senior as long as they like.
Will Larson wrote an excellent book about the topic that speaks about Staff Engineer archetypes, and it’s worth a read. We liked many parts of the book and borrowed to what FloQast needed.
The Vision
Our CTO Cullen Zandstra wrote up a one-pager of the vision for a Staff Engineer. In it, he breaks down the high-level goals as:
- Keep teams and architecture decoupled
- Be clear about what actually matters (the customer)
- Use technical debt wisely
- Contribute to FQ shared tech
- Look for ways to reuse product technology
The above provides a clear grounding for the role, as it’s a role that consistently must zoom out from the details and look at the forest from the trees for a number of teams.
Defining Success for Staff Engineers
Success for the role didn’t mean that they do 10x a Senior Engineer’s work. (Obligatory 10x engineer tweet) Nor did we want Staff Engineers to work in isolation as Ivory Towers and act as gatekeepers. Instead, we looked to goals based on engineering data we were already internally tracking.
Goals
- Improvement of team delivery
- Practical implementation of architectural decoupling in product roadmaps
- T-shaped domain knowledge
- Technical mentorship
For each of these, we map success to the Lead Time and Predictability of the teams under their purview. That is, how quickly are teams able to get a piece of code from an engineer to production, and how accurate were the teams in estimating delivery dates.
Integrating Staff Engineers with the team
If we look at engineering as a whole, we can split general responsibilities into three buckets: People, Process, and Tech.
Some teams at FloQast don’t have a Staff Engineer. In those spaces, when broken out into a RACI matrix it looks like:
Engineering Manager
- Responsible for People, Process
- Accountable for Tech
Team
- Responsible for tech
In the case above, the Engineering Manager is responsible for employee growth and serves as an Agile Lead for team processes. The team is responsible for the tech, but the Engineering Manager is accountable for it.
If that sounds confusing, the example I usually lean on is: We use React at FloQast as our standard frontend library. If a team decided that they wanted to replace React with jQuery on an upcoming epic, the Engineering Manager would guide the team away from that decision as that isn’t an overall technical direction we want to follow. That said, the team writes the code and decides the technical direction for most cases.
In teams with a Staff Engineer, it would look like this:
Engineering Manager
- Responsible for People, Process
Staff Engineer
- Accountable for Tech
Team
- Responsible for tech
In this case, the tech moves to the Staff Engineer for accountability. This change doesn’t mean that our Engineering Managers aren’t involved in technical issues; they have all had career progression as software engineers. That experience is invaluable in code reviews, engineer growth, or many other facets. However, the Staff Engineer is where the buck stops at architectural decisions for a group of teams.
RACI with others
To split this out to a set of software engineers, a point person, staff engineer, engineering manager, and a Sr EM/Director:
Finally, to put it all together in a Venn Diagram, it would look like:
Coaching
Sponsorship of opportunities for the team to grow in scope and impact
Delivery
Shared responsibility amongst all members of the team, leaning to the team first. The team is focused on the Now and the Next.
Later Roadmap
The EM and SE are not only involved on the Now and Next, but also aligned on the Later roadmap
Mentorship
Technical mentorship for the team
Questions we considered when defining the Staff Engineer role
The above is constantly being iterated upon based on feedback. Several questions came up internally while building this role out for ourselves.
Is a Staff Engineer doing tickets in a sprint?
Generally, no. If Staff Engineers (the way FQ is doing it) were part of the day-to-day sprint work, they wouldn’t be able to scale out as much as we need them to across multiple teams for our customers. Instead, they “float” between teams and zooms in/out as needed. They may sit with a team member on an upcoming ERD, or pair program with another engineer on a ticket in the sprint, but they should not generally be counted as part of a team’s overall velocity.
Does this mean that Engineering Managers don’t mentor anymore?
Not at all. There are multiple ways to grow a team, and each person’s perspective strengthens the group. The Engineering Manager may also have more day-to-day interactions with the team, and the Engineering Manager and Staff Engineer are peers that work together.
Should all PRs go through the Staff Engineer?
This leans closer to gatekeeping and it’s a pattern we want to avoid as it can create delays for the customer and mounting frustration with engineers. Instead of creating a bottleneck, we look to our staff engineers to mentor the teams to regulate their architecture and patterns. That is, if teams are aware and care about the appropriate patterns and practices themselves — they won’t need a Staff Engineer looming over their shoulders.
How does a team know when to reach out to a Staff Engineer?
At first, we weren’t sure what the best avenue would be if they aren’t on the team day-to-day. However, this has been interesting to watch as Staff Engineers may show up in a Design Review (a meeting where engineers talk about technical details), a Backlog Grooming, or even do an Office Hours setup. Either way, engineers have been pulling in Staff Engineers as a gut-check before or during working on various gnarly technical issues, which is a positive outcome.
How does the Staff Engineer stay connected to the product?
It can be very easy for a person in this role to care only about architecture and code, but one of the core values for engineers at FloQast is to care about the customer, which applies to the Staff Engineer role as well. They regularly collaborate with Product counterparts and can be especially impactful on the long-term roadmap.
Summary
The Staff Engineer is a critical role in FQ Engineering, tasked with unblocking and enabling multiple teams through their abilities. We see them as part of our long-term growth strategy by setting them up with a clear set of customer and team-centric values and a framework for their success.
Back to Blog