Staff Engineers at Policygenius
At Policygenius, we believe that all employees can expand their scope and influence as they grow. Each of us can solve larger problems, deal with more ambiguity, work with folks across more disciplines, and effect broader changes. As with most modern software companies, our engineers grow into the Senior role, and then tend to either expand their scope with people management (as a Manager, Director, etc) or without people management (as a Staff Engineer).
This article details how we have recently increased clarity around the Staff Engineer role at Policygenius.
Wait, isn’t “Staff Engineer” already clear enough?
Well, not really. Go to a conference, randomly select two engineers, and ask them to define “Senior Engineer,” and you’re likely to get similar answers (no guarantees, though). Beyond Senior, companies have a broad mix of titles, expectations, and responsibilities. Some folks (such as Will Larson and his StaffEng project) are working towards a shared understanding, but given the variety of needs in our industry, it is still wise for each company to build their own clarity.
For the past few years, Policygenius has defined success in our Staff Engineer role via a structured career rubric. This rubric focuses on capabilities and skills (for instance, our Staff Engineers “improve product/tech partnership at Policygenius”), but it doesn’t give much insight into day-to-day responsibilities. As you might predict (or have personally experienced), this can lead to muddled expectations and cause the engineer to stay on one project for longer than they strategically should. Having faced a few of these issues, we decided this year to add a framework on top of our rubric.
As with all things at Policygenius, we began by defining our goals. Some of the things we wanted to accomplish were:
- Give Staff Engineers more clarity and autonomy in deciding how to focus their efforts
- Help Senior Engineers and their Managers understand how (and whether!) they should work towards the Staff level
- Provide other parties (Engineers, PMs, stakeholders, etc) a clear understanding of how best to engage with Staff Engineers
- Give candidates visibility into the Staff role at Policygenius
- Add clarity for Managers and Directors when deciding which level to budget and hire for
- In the end, improve the quality of technical vision and execution across Engineering
After deliberation and research that spanned months, we felt that the best way to reach these goals was to create (a) an easily digestible summary of the role, and (b) descriptions of different modes in which Staff Engineers might be working at any given point in time.
As the process of deliberation during those few months is outside the scope of this article, let’s jump straight to the results.
What does a Staff Engineer do?
Our summary of the Staff Engineer role is as follows:
As a Staff Engineer, you are expected to solve problems and implement transformations that impact the engineering department as a whole. You and your manager share the prioritization of your efforts, but you do not wait for work to be handed to you. You are responsible for deeply understanding the department, its software, and its customers, and for identifying leverage points at which you can apply your expertise to affect the greatest change. After prioritization, you are capable of owning every part of execution: aligning leadership on goals, identifying and mitigating risks, researching alternate technologies, designing a solution, leading its implementation, and equipping the rest of the organization to incorporate and benefit from the results.
At this level, you’re expected to have the knowledge, judgment, and understanding to work cross-functionally with your business and product partners, and to influence the roadmaps of business units with which you interact. You are capable of mentoring anyone, including more senior engineers, in your particular areas of expertise. You are expected to be a force multiplier for any project on which you are deployed, and to make the entire engineering organization better.
In comparison with the role of Senior Engineer, you should expect to:
- Spend more time aligning engineering around high-value problems and solutions
- Spend more time aligning cross-functional counterparts on your vision
- Have longer periods of time in which you don’t write a line of code
- Perform code reviews more often on a wider range of projects
- Frequently equip others to complete work rather than see it through to the end yourself
- Context switch more often
- Spend more time in strategic planning, and then executing on the Engineering Strategic Plan
How does a Staff Engineer engage with teams?
More tactically, Staff Engineers report to a member of Engineering Leadership who is accountable for a group of engineering teams (which we’ll refer to as a “Director” here, for simplicity’s sake).
On an ongoing basis, it is the Director’s responsibility to be aware of the technical progress, vision, and status of each of their teams, and to involve the Staff Engineer as areas for improvement arise. In this way, the Staff Engineer and their Director will commonly have accountability for the same set of teams.
However, Staff Engineers are not restricted to working only with their Director’s teams. At any point, Staff Engineers may identify areas for improvement across a different cross-section of the department, and in collaboration with other Directors and Staff Engineers, may decide on a medium-term engagement working across reporting boundaries.
The most unique part of our new definition, however, is to lay out three common modes of work for our Staff Engineers. We expect that each engagement in one of these modes (a) is targeting an explicit transformation in the team or organization, and (b) has a (rough) expected timeframe.
Embed Mode
In this mode, the Staff Engineer embeds on a Product Engineering team, attending team ceremonies and contributing directly to the team’s objectives. During this time, the Staff Engineer should be helping the team through their explicit transformation. This could be a process transformation, a technology transformation, or simply helping the team level up through its work on a challenging project.
Day-to-day activities are variable, but may include writing code, pairing with other engineers, and creating, collaborating on, or reviewing designs or documentation. In this mode, the Staff Engineer can take on tickets. However, Embed Mode as a whole is not meant as a supplement to a team’s capacity, or as a “catch up” mechanism when a team is about to miss a deadline.
Embed mode is the preferred initial mode when onboarding Staff Engineers.
Bootstrap Mode
In this mode, the Staff Engineer is responsible for a new project or initiative that either (a) spans multiple Product Engineering teams or (b) is too nascent to be owned by a Product Engineering team. During this time, they are less likely to be operating under our standard Scrum process.
During an assignment in this mode, the Staff Engineer will be creating designs, implementation plans, and other documentation, while also writing code and working with engineers and stakeholders to create a long-term future for the initiative. In this mode, the Staff Engineer may have other engineers assigned to work with them full-time.
Shepherd Mode
In this mode, the Staff Engineer is not assigned to a particular team, but is working to improve the execution and vision of multiple teams at once, most commonly the teams in their Director’s purview. This is the mode in which the Staff Engineer will spend the most time collaborating with their Director, as both are responsible for the proper functioning and technical vision of these teams.
Shepherd mode should be considered the default mode, to be assumed when there is no active need for Embedding or Bootstrapping.
Can you give me an example?
Sure. Let’s say Alice Johnson joins Policygenius as a Staff Engineer in January, reporting to a Senior Manager over multiple back-end teams. After a few weeks of onboarding, Alice officially begins her first assignment with a team in Embed mode. The team is embarking on a new project (codenamed Traffic Train), and they do not currently have the expertise to tackle it themselves. Alice will not only help the team complete the initial project, but equip them along the way to handle similar projects themselves in the future. Alice and her manager estimate that the engagement will last until the end of May.
Around the end of April, Alice and her manager identify that Traffic Train is coming into the station early, and the team is now equipped to complete it themselves. Over the past month, Alice has identified that her team (and the corresponding Growth team, which does not report to her manager) would benefit from a new CI/CD system. Alice, her manager, and the other directors and staff engineers agree that this would be a good project to tackle next, so at the beginning of May, Alice switches over to Bootstrap mode on her new project (codenamed Shipit Squirrel), and estimates that this engagement will last until the end of August.
How about one more?
Yep, okay. Say Branden Callahan has been a Staff Engineer at Policygenius for two years, reporting to a VP of Engineering over the front-end teams. Nine months ago, Branden started the Skydiving Insurance effort from scratch, operating in Bootstrap mode. Branden worked with Doug and Eliza, two mid-level engineers, to define and build the Skydiving Insurance platform. Policygenius now has customers for this new line of business, and an entire Skydiving team has grown up around Doug and Eliza, which now includes an Engineering Manager and other engineers. Branden has completed his work on bootstrapping this new line of business.
After an ongoing discussion with his manager (the VP), they identify that no other team needs an imminent transformation (thus, Branden does not need to be in Embed mode anywhere), and no new initiative needs to be bootstrapped. However, three of the VP’s teams have been struggling with building clear, actionable technical visions. Branden shifts to Shepherd mode for those teams, spending his time working with their Engineers and Engineering Managers. Branden and the VP are planning for this phase to last approximately 3 months, as they continue to weigh the Bootstrap and Embed opportunities on the horizon.
So, how’s this new way of thinking going?
So far, so good. Once we (as Staff Engineers and Directors) got these ideas together and put them in an RFC, the rest of the department found that it answered a lot of questions they had had, but never knew how to ask. Since that point, Staff Engineers have come off of prior engagements and used this framework to identify and plan out how their next efforts will yield the most important transformations.
Outstanding questions we still have are:
- Will Staff Engineers spend some periods of time in a mix of these modes? Is that bad?
- Will prior engagements stick with them and drag them back when they’re trying to move forward with a new transformation? That would be bad, but honestly, that’s probably an evergreen question for every engineer ever.
- Are we right to leave accountability for teams’ technical visions with Directors rather than giving that to Staff Engineers? We think so (as this context switching could diminish the effectiveness of a Staff Engineer in Embed or Bootstrap mode), but we could have gone either way.
Time will tell whether this definition leads to more or less autonomy, but as with all process or governance, we’re aiming to offload small cognitive burdens onto the framework so that our engineers’ minds are free for the germane, creative work we all want them to be doing.
And, of course, we’ll iterate as we learn more!
Policygenius is America’s leading online insurance marketplace. Our mission is to help people get insurance right by making it easy for them to understand their options, compare quotes, and buy a policy, all in one place.
Interested in learning more about how we work? Policygenius is hiring! Check out our careers page to see open roles: https://www.policygenius.com/careers/
