Resources

Additional resources on Staff-plus engineering

None of the Staff Engineer I spoke with got there alone. Most got there either through voracious reading or building a powerful network of colleagues. This section is a collection of recommended resources.

Your Network Almost unanimously, Staff‐plus engineers’ most valu‐ able learning resource wasn’t a book, blog, talk, or paper, but instead their network of peers and mentors. If you only have one hour to de‐ velop yourself as an engineer, your best bet would be building a net‐ work of people in similar roles.

If you’re looking for a Slack community, #staff-principal-engineering in the Rands Leadership Slack is a fairly lively room.

What do Staff-plus Engineers do? Folks’ descriptions of their roles:

• Being a principal engineer at Skyscanner

• Defining a Distinguished Engineer by Jessie Frazelle

• How I operated as a Staff engineer at Heroku by Amy Unger

• Not all engineering leaders are engineering managers by Tanya Reilly

• The Nuts and Bolts with Tanya Reilly

• On Being A Principal Engineer by Silvia Botros

• On Being a Senior Engineer by John Allspaw

• Staff Engineering by Sam Kleinman

• Thriving on the Technical Leadership Path by Keavy McMinn

• What’s a senior engineer’s job? by Julia Evans

• What a Senior Staff Software Engineer Actually Does, Part 1: The Role and My Tasks and Part 2: The Mindset and Focus of the Role by Joy Ebertz

• What does Staff level mean at GitLab?

Becoming a Staff-plus Engineer Folks sharing their stories of becom‐

ing a Staff‐plus engineer:

• Becoming a Staff Engineer – Interview with Kristina Fox, Staff iOS Engineer at Intuit by Kaya Thomas

• On becoming a senior technical leader by Jesse Pollak

• On Mid‐Career and Managers by Ryn Daniels

• How does one become a Staff Software Engineer at Google? on Quora

• The Engineer/Manager Pendulum by Charity Majors

• THings to Know About Engineering Levels by Charity Majors

Operating as a Staff-plus engineer

• Being Glue by Tanya Reilly

• Computers can be understood by Nelson Elhage

• Effective Mental Models for Code and Systems by Cindy Sridha‐ ran

• “I Wouldn’t Start From Here.” How to Make a Big Technical Change by Tanya Reilly

• Migrations: the sole scalable fix to tech‐debt by Will Larson

• On Mid‐Career and Team Dynamics by Ryn Daniels

• Reclaim unreasonable software by Will Larson

• Surviving the Organisational Side Quest by Tanya Reilly

• Systems that defy detailed understanding by Nelson Elhage

• Team Objectives by Marty Cagan

• Technical Decision Making by Cindy Sridharan

• Technical Research and Preparation by Keavy McMinn

• The Behind‐the‐scenes Work of Tech Leadership by Jean Hsu

• Understanding Project Management Will Improve Your Devel‐ oper Job by Daniel Na

• What Does Sponsorship Look Like? by Lara Hogan

• Where to Start by Keavy McMinn

• Design Docs, Markdown and Git by Caitie McCaffrey

Technical Specifications

• A practical guide to writing technical specs

• Design Docs at Google

• Design Docs, Markdown, and Git

• Documenting Architecture Decisions

• How to write a better technical design document

• Technical Decision‐Making and Alignment in a Remote Culture

• Writing Technical Design Docs

Engineering Strategy Articles on engineering strategy in general:

• A Framework For Responsible Innovation

• How Big Technical Changes Happen at Slack ‐ Several People Are Coding

• On Drafting an Engineering Strategy

• Defining a Tech Strategy

• Delivering on an architecture strategy

• Stepping Stones not Milestones

• Achieving Alignment and Efficiency Through a Technical Strat‐ egy

• The difficult teenage years: Setting tech strategy after a launch by Anna Shipman

• Learning to have an engineering vision

Examples of engineering strategies:

• Run less software by Rich Archibold

There are also many great resources on other facets of strategy as well, for example, Marty Cagan’s series on Product Strategy.

Books Although I’ve found that many folks don’t read too many books, when I asked Staff engineers for their most valuable resources, they inevitably mentioned a personal mentor or a book. They had blog posts and tech talks they might mention related to a more specific problem, but they were most changed by this larger, more papery format.

Some books which were recommended:

• A Philosophy of Software Design by John Ousterhout

• Accelerate: Building and Scaling High Performing Technology Organizations by Forsgren, Humble and Kim.

• Becoming a Technical Leader: An Organic Problem‐Solving Ap‐ proach by Gerald Weinberg

• Building Evolutionary Architectures by Ford, Parsons, and Kua

• Escaping the Build Trap: How Effective Product Management Creates Real Value by Melissa Perri

• Good Strategy Bad Strategy: The Difference and Why it Matters

• High Output Management eBook: Andrew S. Grove

• The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change by Camille Fournier

• The Mythical Man‐Month by Fred Brooks

• The Phoenix Project by Kim, Behr, and Spafford.

• The Passionate Programmer by Chad Fowler

• The Pragmatic Programmer by Andrew Hunt, David Thomas

• Resilient Management by Lara Hogan

• Software Design X‐Rays: Fix Technical Debt with Behavioral Code Analysis by Adam Tornhill

• Thinking in Systems: A Primer by Donella Meadows

If you’re looking for, even more, recommended book lists abound, in‐ cluding my own at Irrational Exuberance’s Best Book.

Talks The Staff‐plus engineers I’ve chatted with have generally men‐ tioned giving talks as valuable to them more than listening to talks, but there certainly are some excellent talks out there. Cindy Sridharan (Twitter) is the best source of amazing talks, in particular, her write‐ ups of Best of 2019 in Tech Talks, Best of 2018 in Tech Talks, and Best of 2017 in Tech Talks.

Papers Relatively few Staff‐plus Engineers are avid readers of Com‐ puter Science papers. However, most are familiar with a handful of foundational papers, and the small subset who do spend time reading papers tend to get quite a bit out of it.

If you aspire to join the category of frequent paper readers, there’s no better place than Adrian Colyer’s the morning paper, which will send you a summary of a computer science paper every weekday. If you’re more interested in getting some foundational exposure to some well‐ known papers, first read one of How to Read an Academic Article by Peter Klein or How to Read a Paper by S. Keshav, and then jump into this list of recommended papers:

• Dynamo: Amazon’s Highly Available Key‐value Store

• On Designing and Deploying Internet‐Scale Services

• No Silver Bullet ‐ Essence and Accident in Software Engineering

• Out of the Tar Pit

• The Chubby lock service for loosely‐coupled distributed systems

• Bigtable: A Distributed Storage System for Structured Data

• Raft: In Search of an Understandable Consensus Algorithm

• Paxos Made Simple

• SWIM: Scalable Weakly‐consistent Infection‐style Process Group Membership Protocol

• Hints for Computer System Design

• Big Ball of Mud

• The Google File System

• CAP Twelve Years Later: How the Rules Have Changed

• Harvest, Yield, and Scalable Tolerant Systems

• MapReduce: Simplified Data Processing on Large Clusters

• Dapper, a Large‐Scale Distributed Systems Tracing Infrastruc‐ ture

• Kafka: a Distributed Messaging System for Log Processing

• Large‐scale cluster management at Google with Borg

• Mesos: A Platform for Fine‐Grained Resource Sharing in the Data Center

Probably the best place to find high‐quality papers to read is Papers We Love, which also run meetups to discuss papers. A few other re‐ sources are the ACM SIGOPS Hall of Fame Award list and Irrational Exuberance’s paper collection.

Other nice things As I did the research for these resources, I found some other pieces that didn’t quite fit anywhere above, but which I think are good and worth looking at nonetheless: • Testing in Production, the safe way and Testing in Production: the hard parts by Cindy Sridharan

• A decade in review in tech by Cindy Sridharan

• Boogeyman Problems by Dan Na

If you find more, please send them my way!

Where do Staff-plus engineers fit into the org?

When I work on the organization design of an engineering organiza‐ tion, I think a lot about “organizational mathematics,” the guideline that each team should have one manager and six to eight engineers, and each manager of managers should support four to six managers. From those numbers, you can rapidly determine an appropriate struc‐ ture for your organization that’ll work fairly well. It might not be per‐ fect, but it’ll work.

As I’ve applied that approach to designing multiple organizations, one of the recurring edge cases that have come up is deciding where the senior‐most engineers should report. Should they, as the org math dic‐ tates, report to managers in the organizational leaf nodes? Or should they, as key leaders in your organization, report to more senior leaders to have better access to the information and authorization they need to excel in their role?

Before answering, it’s worth describing the most common configura‐ tions you’ll find in companies today, in particular how configurations vary across the Staff‐plus archetypes:

• Tech Leads typically report to a manager responsible for one team. Less frequently, they’ll report to a manager responsible for two to four teams. In both cases, they’ll operate at the same scope as that manager. Examples: Dan Na reported to the man‐ ager for the Internationalization Platform.

• Architects typically report to a more senior manager, often a manager of managers. Often they’ll be responsible for a horizontal‐slice across that manager’s area of responsibility, for example, data modeling. Examples: Keavy McMinn reported to the CTO.

• Solvers typically operate in companies that feature a “weak team concept,” and often reporting hierarchies are less defined or de‐ liberate in such companies. It is most common to see them re‐ porting to a team manager, but you’ll find a bit of everything. Another common pattern is collecting these folks into an “Office of the CTO” or “Office of the CEO” where they report to an execu‐ tive who directs their work. Examples: Ritu Vincent is part of an incubator reporting to the CEO.

• Right Hands report into a senior leader, often managers respon‐ sible for a hundred or more folks, operating with that leader’s authority. Examples: Rick Boone reported to the VP of Infras‐ tructure; Michelle Bu reported to the Chief Product Officer.

Understanding how these different archetypes typically report differ‐ ently into the organization helps decode some of the seeming arbitrari‐ ness of reporting structures.

Office of the CTO

An aside on the “ Office of the CTO ” concept, as many folks haven’t en‐ countered it in their work. Typically, the CTO, although sometimes a CEO will do something similar, will have two to eight Staff‐plus engi‐ neers who report to them directly. These folks are treated as senior leaders in the sense of getting a problem or opportunity to pursue, very little management support, and the proximity to lean on the ex‐ ecutive for support when necessary.

Within these offices, you’ll find a mix of Architects, Solvers and Right Hands.

Typically the Office of the CTO comes relatively late in a company’s evo‐ lution and is often introduced as a workaround to an existing organi‐ zational problem that is a challenge to address, for example, lack of trust between Staff‐plus engineers and management teams, or an in‐ ability to delegate by the CTO. If you find yourself reaching for it early in a company’s evolution, ask yourself if you’re avoiding a problem you should be fixing instead of introducing this concept into your struc‐ ture.

But in practice…

Based on the archetypes, there is usually a theoretically correct place for every engineer to fit into the organization, but you’ll find that in practice, few organizations fully align their actual reporting structure with that theoretical structure.

Sometimes this is due to a lack of attention to organizational structure by your management team. In other cases, it’s due to a lack of managerial bandwidth to support folks at the correct positions. For example, the “correct” manager is already managing a team of twelve and can’t support another engineer effectively. Another common scenario is that the structure is shifting frequently enough that managers are reluctant to change the engineer’s manager again, espe‐ cially as manager‐changes often lead to abstract, middle‐of‐the‐road performance reviews.

If you find yourself reporting to someone who you believe is the wrong manager, it’s a reasonable conversation to have with your manager, but it’s worth acknowledging that many managers will react defensively to the implication that they’re not the right manager for you. If your manager is mature and you have a strong relationship with them, go ahead and have the conversation. If not, it may be less risky to instead have a more abstract discussion with their skip‐level about where Staff‐ plus engineers report in their organization.

Before you rush to advocate for change, ask yourself what you think would be different if your reporting structure changed. The report‐ ing structure is a form of authority, and generally, folks over‐estimate how authority will help them. The classic trap is, of course, that the folks who benefit the most from additional authority–minorities and women–are the folks whose managers are most likely to react defen‐ sively to the suggestion of the change.

How should it work?

If you’re looking to design a proposal for your management team on how they ought to perform these sorts of organizational adjustments over time, a few things to consider. When possible, reporting changes should happen immediately. Delaying forces folks to navi‐ gate two transitions, including a particularly challenging intermediate environment between the previous and new roles. It’s always lower risk to navigate a single role transition, even if it means agreeing to reduced manager support if your new manager is underwater with their workload.

If you can’t make them immediately, always set a timeline for report‐ ing to the correct manager after a role change. If you don’t have a timeframe to clearly reopen the structure, it’s relatively less likely to happen.

Most companies struggle to set up this sort of organizational infras‐ tructure to fully support Staff‐plus engineers as genuine leaders, so you should look at this as a problem you want to make progress on over years, rather than one that’ll get fixed overnight. If you go into it expecting an immediate, permanent solution, you’re likely in for some turbulence.

Managing Staff-plus engineers

While getting feedback on StaffEng, one request was for more content on managing Staff‐plus engineers. It doesn’t quite fit the theme–that effort is focused on the Staff engineers themselves rather the company or the manager–but it’s an interesting topic and a worthy appendix.

Of course, not all aspects of managing Staff‐plus folks are unique to the level: there are fundamentals that apply to managing anyone in any role, like doing effective 1 on 1s or giving feedback. For that sort of thing, read Lara Hogan’s Resilient Management or Camille Fournier’s The Manager’s Path. What I wanted to get into here is how managing someone at the Staff‐plus level differs from managing, say, a Senior engineer.

These roles vary enough across companies that some aspects of man‐ aging your Staff‐plus engineers will depend on the Staff archetypes your company emphasizes and where your Staff‐plus engineers should fit into the engineering organization, but there are some approaches that will be helpful for you across most configurations.

• Sponsor and support more than you direct. If you’re giving daily direction to your Staff engineers, you’re utilizing them in the wrong roles. If you aren’t giving them weekly feedback, you’re delaying their growth. If you aren’t lending your spon‐ sorship to their initiatives, then you’ll train the initiative out of them.

• Help them rewire their definition of success. Working in a high‐ performing product engineering team is a flywheel of positive feedback. Your product manager appreciates your work. Your engineering manager engages the team. Your peers enjoy work‐ ing together. Your users love your product. Your business loves the user adoption. Conversely, the Staff engineer’s flywheel of feedback is a lot less immediate. You spend more time working through conflict. You work on longer time horizons. You’re rep‐ resenting important priorities that require deprioritizing some business or product goals. Many folks don’t address this shift and wake up a year later hating their new role, and as their manager, you can help them recognize this shift and find compensating strategies to remain energized.

• Give feedback. One particularly important strategy for rewrit‐ ing their definition of success—and to keep them growing—is to give frequent feedback. If they’ve picked the wrong battle, tell them, and tell them why. If they’re prioritizing work you wouldn’t, tell them, and tell them why. Nothing is more stress‐ ful for a high performer than not knowing how they’re doing! If you don’t give feedback, especially about their best work, they’ll keep changing their approach until you do give feedback (often to your regret).

• Keep them informed. As a manager, it can be easy to forget how much more access you have to information than the engi‐ neers you work with. The reality is that most organizations build their information flows around managers communicating key information to other managers. Your Staff‐plus engineers will be hamstrung if you don’t find a deliberate, reproducible process for sharing your context with them. Some folks do this at the be‐ ginning of their 1:1s, which works OK, but I’ve come to prefer dropping them into the team’s chat channel as they happen and aggregating them into my weekly email update.

• Involve them in planning and prioritization. Many engineers get frustrated that “the right work never gets prioritized,” and one of the best solutions to this is to proactively involve more en‐ gineers in the planning process. This works on two fronts. First, they understand more of the competing work and why that work is important, and second, they’ll be present to advocate more ef‐ fectively for the sorts of technical work they see missing.

• Agree on how to stay aligned while acting independently. As you push Staff‐plus engineers you support towards leadership, they’re going to start leading more, which will sometimes include surprising you. If leaders you work with never surprise you, then you’re not delegating enough, but if they frequently surprising you, it may be helpful to explicitly establish your controls.

• Create space for them to think without detaching them from the day‐to‐day realities of the organization. Many folks in these roles are so motivated by impact and “doing the right thing for the business” that they’ll grind themselves down without exter‐ nal intervention. If you’re their manager, then “external inter‐ vention” means you. If you see them spending too much time firefighting and helping unblock urgent work, work with them to protect more time for deep thinking work as well. Conversely, if you see them only doing deep thinking work, they’re likely to lose context and potentially the respect of their peers and the business if they don’t adjust that mix.

• Remind them they’re a role model. Much like they do for man‐ agers, engineers in an organization watch Staff‐plus engineers to learn which behavior and actions are rewarded (and tolerated). This is a great responsibility, but also a huge opportunity for im‐ pact: by living positive values, they have the opportunity to cre‐ ate a positive organization around them.

• Minimize manager overflow. In the quest for efficiency over effectiveness, many companies trap their managers in a stag‐ gering amount of coordination and bureaucracy. When you’re drowning, you’re going to look for help wherever you can, and in many cases, that causes managers to offload management work to their Staff engineers. This is absolutely going to happen sometimes–your relationship with Staff‐plus engineers you manage is a partnership–but try very hard to minimize the amount and ensure it’s a temporary overflow rather than a permanent one.

• Give them unrefined problems. This is a senior role where you ought to give them a problem space that they narrow into a more specific problem and solution. They have better technical con‐ text than you do, and if you point them too precisely at what you think is the problem, you won’t benefit from their judgment. Picking precisely the right problem creates at least as much im‐ pact as finding precisely the right solution, and is only possible when you create space.

• Cede space to their leadership. When you’re managing a Staff‐ plus engineer, find ways to move pieces of your ownership ex‐ plicitly into their realm of responsibility. For example, how can you enable them to hold their team responsible for technical quality, rather than you doing it? This creates leverage for both of you and a sense of ownership for the Staff‐plus engineer.

• Appreciate them. Great Staff‐plus engineers operate fairly inde‐ pendently, so it can be easy to deprioritize them when the orga‐ nization is on fire. Ignoring your most important people is the manager version of “snacking”–something that feels important but usually isn’t the right priority. So keep your 1:1s, and gener‐ ally remember to show up for them, especially if they aren’t the sort of person to demand it.

• Build and insist upon alignment with the business. Some engineers succeed despite harboring a mentality that technical work is more important than the business requiring that work. This mentality is generally toxic, but it exceptionally toxic when held by a Staff‐plus engineer. This is someone who is a role model for the wider organization, and stretching them beyond that perspective is essential for them to remain in a leadership role. Companies undermine and eventually eject leaders who are misaligned with the business.

• Hold them responsible for the full role. While few folks reach Staff‐plus roles with major technical weaknesses, it’s my lived experience that many folks reach these roles hampered by sig‐ nificant leadership or behavioral challenges. These folks get the title but tend to linger in Staff purgatory where they’re expected to lead but are kept away from most leadership opportunities. They’re viewed as too unreliable or “expensive to involve.” You’ve gotta give these folks feedback on their gaps and hold them accountable to the full role expectations. Don’t let them linger as quasi‐leaders indefinitely. Maybe they initially got the role via title inflation, so you decide to just cover for their gaps instead of fixing it–don’t do that, instead, figure out a plan to support them while shifting that responsibility to them.

• Give them access to the room but don’t treat it as a status sym‐ bol. Folks often get fixated on status symbols, and one that’s particularly common for engineers to focus on is “being in the room.” Sometimes meetings are where the work happens, but most routine reporting meetings have too many people in them, and you can create a great deal of time and space for both you and the Staff‐plus engineer you’re supporting by sharding atten‐ dance across various meetings rather than doubling up for all of them.

The transition from Senior to Staff‐plus engineer is a major one that changes the sort of work being done, whereas previous transitions of‐ ten only change the work’s extent. Many folks struggle with that tran‐ sition, and many managers aren’t sure how to help support the Staff‐ plus engineers they work with. Certainly, this is an incomplete list of helpful things you can do to support them, but hopefully, it’s a useful starting point.

Designing a Staff-plus interview loop

When we talk about designing a Staff‐plus engineer interview loop, the first thing to talk about is that absolutely no one is confident their Staff‐ plus interview loop works well. Many loops end up looking for a senior engineer who’s really fast at solving problems, which doesn’t reflect the actual role. Others focus on communication skills, which are a key part of the role but certainly not the entirety of it. A few compa‐ nies even construct their process to assess whether the candidate feels like a member of their existing senior engineering team, conflating excellence with familiarity.

Even if no one feels great about their loop, there is still a body of collec‐ tive learnings to incorporate into your attempt to design a loop, which is what we’ll cover here. We’ll start with examining the frequent fail‐ ure modes of Staff‐plus interview loops, discuss the signals that you do want to test for in these loops, and finally discuss some interview formats which can be useful for assessing those signals.

Challenges

While technology interviews, in general, are a bit of a mess, interviews for very senior candidates have enough issues of their own to pack a dedicated struggle bus. It’s helpful to start with understanding some of the common failure modes before we move into considering what might work better:

• A senior engineer, but better. Many interview processes look at Staff‐plus engineers as Senior engineers who are a bit better at everything. They’re a bit faster. They’re a bit clearer in their communication. They’re a bit more nuanced in architecture discussions. This stems from most folks being unfamiliar with Staff roles and usually causes Staff‐plus engineers to perform poorly on these loops. In particular, most Staff‐plus engineers are programming less than Senior engineers, and consequently are slower rather than faster at rote programming tasks. You’ll find some Staff‐plus engineers who remain very quick program‐ mers, but you won’t find much correlation between that speed and their impact.

• A senior engineer, but worse. Conversely, other interview processes recognize that Staff‐plus engineers are spending less time programming and anticipate slower performance on some of the more mundane programming exercises. This makes it more likely for Staff‐plus engineers to succeed in the loop but doesn’t get signal on what makes these sorts of engineers exceptionally impactful. If you don’t add additional interviews to capture those strengths, reduced speed on rote work will likely correlate with seniority to some extent, but it correlates more strongly with many other factors.

• A senior engineer, but they’ll accept the offer. Another fail‐ ure mode is companies that are struggling to hire Senior engi‐ neers and decide to inflate their titles without changing the role expectations. In these cases, the interviews are appropriate to the actual work, but the title isn’t. With neither the company nor the candidate fully willing to acknowledge the inflation, all future Staff‐plus hiring at the company acquires a veneer of un‐ certainty.

• Someone like us. Many loops focus on whether the Staff‐plus candidate projects the same wisdom and confidence as the exist‐ ing Staff‐plus engineers at the company, where the interview de‐ brief might include statements like, “They feel like they’d be a natural part of this team.” This sort of approach is more likely to anchor on semi‐arbitrary features like how they project their confidence than on the candidate’s capabilities.

• Not better than me. Especially when hiring your first Staff‐plus engineers, you’ll often find some earlier career interviewers who undervalue the candidate’s strengths and instead anchor on the candidate’s capability to perform the interviewer’s current role. You’ll have an impressive Staff‐plus candidate, but the interview panel will be skeptical of their ability to thrive as a mid‐level en‐ gineer. This seems to be brought up most frequently for women and minority candidates.

• The reverse filter. Certain kinds of interviews are signals that you as an organization don’t know how to use Staff‐plus engi‐ neers: whiteboard algorithmic interviews, interviewers are pre‐ dominantly early career, and so on. Many Staff‐plus processes cause the best candidates to opt‐out early in the process, often somewhat invisibly to the recruiting metrics.

• Too title‐oriented? At a certain level of accomplishment, peo‐ ple don’t care much about internal leveling, generally because they’re already financially secure. This creates a peculiar pres‐ sure on folks newly reaching Staff‐plus levels to avoid appearing overly career or title motivated, making it harder for folks to at‐ tain the title for the first time.

Some of these are quite difficult to address, others are easy as long as you keep them in mind, but all of them are worth considering as you start to design or re‐envision your Staff‐plus interview process.

Signals

The best interview loops reason forward from the signals you want to capture back to the interview topics and format, which means the first important question to answer is, “Which signals are important for hiring successful Staff‐plus Engineers?”

The signals I’d recommend focusing on are:

• Self‐awareness. Are they accountable for mistakes? Have they demonstrated growth in areas where they’ve previously been weaker?

• Judgment. Are they able to see around corners to identify prob‐ lems? Are they able to navigate broad, ambiguous problems? Can they effectively mediate between folks in an argument about tradeoffs or design? Can they derisk the execution of difficult problems?

• Collaboration. Do they partner well with others? What about folks less experienced than them? More experienced than them? Their managers? Cross‐functionally? Executives?

• • Communication. Are they good listeners who understand the points made by others? Are they able to communicate their ideas clearly? Can they communicate in the formats that your com‐ pany relies upon (written, verbal, etc)?

• Development. Do they grow others around them? Does the “or‐ ganizational bench” grow in areas they lead or atrophy? Do bro‐ ken systems and processes get cleaned up?

It’s interesting to note that many would not consider these to explicitly be technical skills. Domain expertise is a major factor in success at all of them, but it’s exercising that expertise in conjunction with other critical skills and behaviors that transition someone from a tenured Senior engineer into a Staff‐plus one.

Formats and structures

The two key questions to ask yourself when designing an interview loop are always:

1. What tasks and behaviors will this person need to succeed on a day to day basis?

2. How can we get them to demonstrate actually doing them?

Most senior candidates become increasingly diplomatic and asking them about their work is never as helpful as watching them do the work. If mentorship is the most important activity, don’t rely on them talking about mentorship, but instead find a way to see them mentor‐ ing someone. If it’s architecture, present your current systems and ask them to bring their questions to see how they react to decisions they disagree with – get away from the ambiguous abstract.

Moving beyond the typical one‐on‐one discussions and programming interviews, some of the interview formats and structures that I’ve found particularly effective for evaluating Staff‐plus signals are:

• Structured presentation. Have the candidate prepare and present for twenty to thirty minutes on a narrow topic to a group of peers. The format gives a great signal on structured thinking, communication, listening to, and answering ques‐ tions. Depending on the topic you select, you can get strong signals on one or two areas of your choice. This format is particularly effective at hearing how folks talk about their peers and coworkers.

• Code review. Prepare a pull request and ask the candidate to provide feedback on it, focusing on empathy, clarity, and useful‐ ness.

• Data modeling, interfaces, and architecture. Have the candi‐ date walk through the design of a system, typically with a focus on evolving it to meet changing requirements. These interviews often try to do too much: narrow your focus and add layers to the question to allow you to continue drilling deeper for candidates who make significant progress.

• Subject matter expertise. Interviews that test their areas of do‐ main expertise. For example, a frontend engineer might collab‐ orate with a designer and product manager on how technical constraints would impact a proposed design and launch time‐ line. For backend engineers, you might provide the candidate with a broken piece of software or environment and have them debug the problem back to a fix.

• Mentorship panel. It’s challenging to hire Staff‐plus candidates if your panel consists entirely of earlier career folks, but it’s equally risky to hire a Staff‐plus candidate if they haven’t demon‐ strated success mentoring folks earlier in their careers. Have a panel of three to four folks they might be expected to mentor come with questions. Especially watching folks redirect roughly framed questions into a useful discussion is a great insight into their ability to mentor in their new role.

If these formats aren’t enough, then start asking around! Most compa‐ nies have designed bespoke approaches to their Staff‐plus loops, and you can learn a great deal from that discussion.

How to pull it together

You might reasonably expect this to end with a precompiled interview loop for your company to use to evaluate Staff‐plus engineers, and I hate to disappoint, but I think most of the value comes from thinking through the signals that matter to you and designing formats that get at those signals in a way that resonates to you and your company.

Whatever interviews you end up using, test them, gather candidate feedback, and keep evolving them to be better!

Staff-plus career ladders

There are so many different career ladders shared in public these days that there’s no reason not to read a half‐dozen different ones before attempting to design your own.

Some that are particularly worth reading through:

• Rent the Runway

• Kickstarter

• Patreon

You can find even more collected at progression.fyi.

I think it’s important to recognize that career ladders only apply ef‐ fectively against populations of individuals, they rarely, if ever, apply cleanly against any individual. This effect becomes particularly pro‐ nounced in Staff‐plus roles, which are often only populated by a couple of folks. Ladders are essential but don’t get caught believing they’re a map of how things actually work rather than a mythos of how things are intended to work.

Charity Majors has also written a helpful guide of things to know about engineering levels.