Overview

At most technology companies, you’ll reach Senior Software Engineer, the career level for software engineers, in five to eight years. At that level, your company’s career ladder won’t require you to work towards the next promotion, and being promoted beyond it is exceptional rather than expected. At that point, your career path will branch, and you have to decide between remaining at your current level, continuing down the path of technical excellence to become a Staff Engineer, or switching into engineering management. Of course, the specific titles vary by company, and you can replace “Senior Engineer” and “Staff Engineer” with whatever your company prefers.

Over the past few years, we’ve seen a flurry of books unlocking the en‐ gineering management career path, like Camille Fournier’s The Man‐ ager’s Path, Julie Zhuo’s The Making of a Manager, Lara Hogan’s Re‐ silient Management and my own An Elegant Puzzle. The management career isn’t an easy one, but increasingly there are maps available for navigating it.

On the other hand, the transition into Staff Engineer, and its further evolutions like Principal and Distinguished Engineer remains chal‐ lenging and undocumented. What are the skills you need to develop to reach Staff Engineer? Are technical abilities alone sufficient to achieve and succeed in that role? How do most folks move into this role? What is your manager’s role in helping you along the way? Will you enjoy being a Staff Engineer, or will you toil for years to achieve a role that doesn’t suit you?

In my engineering management career, I’ve developed an increasingly clear point of view on answering those questions around the Staff En‐ gineer role, but my perspectives are shaped by my own experiences, and I believe it’s important to go beyond boldly presenting my beliefs as universal truths. In writing Staff Engineer, I interviewed more than a dozen Staff‐plus engineers across the industry about their lived ex‐ periences, and have folded their experiences into my own to create something richer in nuance, breadth, and perspective than I could have ever written on my own.

If you’re already in a Staff‐plus role, I hope these writings will energize you in your journey as a leader outside the management track. If you aim for such a role, I hope they will provide a pragmatic aid in its pur‐ suit. This book can be read cover to cover, but depending on which of those best describe you, feel jump to the sections that sound most interesting.

• Overview ‐ a survey of the Staff Engineer role, how it varies by company, and why the title matters

• Operating at Staff ‐ how to do the work on the other side of the title

• Getting the title where you are ‐ how to attain a Staff‐plus role at your current company

• Switching companies to get the title ‐ when and how changing companies can support the pursuit of a Staff‐plus title

• Stories ‐ collected stories from Staff‐plus engineers about what they do and how they reached their role

• Resources ‐ a collection of templates and further readings if you’re looking for more

Every company puts its own spin on Staff‐plus roles, so it’s likely that some parts won’t map to your experience. If that’s the case, please take what resonates and discard what doesn’t!

Staff engineer archetypes

Most career ladders define a single, uniform set of expectations for Staff engineers operating within the company. Everyone benefits from clear role expectations, but career ladders are a tool that applies better against populations than people. This is particularly true for Staff‐plus engineers, whose career ladders often paper over several distinct roles hidden behind a single moniker.

The more folks I spoke with about the role of Staff‐plus engineers at their company, the better their experiences began to cluster into four distinct patterns. Most companies emphasized one or two of the pat‐ terns, and one pattern only existed in companies with many hundreds or thousands of engineers. A few companies didn’t feature any tech‐ nical leadership pattern and pushed all their experienced engineers towards engineering management. In literature, recurring character patterns are called archetypes, such as the “hero” or the “trickster,” and the archetype term is helpful for labeling these frequent variants of Staff‐plus engineers.

The four common archetypes of Staff‐plus roles I encountered are:

• The Tech Lead guides the approach and execution of a particu‐ lar team. They partner closely with a single manager, but some‐ times they partner with two or three managers within a focused area. Some companies also have a Tech Lead Manager role, which is similar to the Tech Lead archetype but exists on the engineering manager ladder and includes people management responsibili‐ ties.

• The Architect is responsible for the direction, quality, and ap‐ proach within a critical area. They combine in‐depth knowledge of technical constraints, user needs, and organization level lead‐ ership.

• The Solver digs deep into arbitrarily complex problems and finds an appropriate path forward. Some focus on a given area for long periods. Others bounce from hotspot to hotspot as guided by organizational leadership.

• The Right Hand extends an executive’s attention, borrowing their scope and authority to operate particularly complex organizations. They provide additional leadership bandwidth to leaders of large‐scale organizations.

This taxonomy is more focused on being useful than complete, but so far, I’ve been able to fit every Staff‐plus engineer I’ve spoken to into one of these categories. Admittedly, some folks are easier to classify than others.

Tech Lead

Figure 1: Example calendar for a Tech Lead archetype

Stories featuring Tech Lead archetpye: Diana Pojar, Dan Na, Ritu Vincent Tech Leads are the most common Staff archetype and lead one team or a cluster of teams in their approach and execution. They’re comfort‐ able scoping complex tasks, coordinating their team towards solving them, and unblocking them along the way. Tech Leads often carry the team’s context and maintain many of the essential cross‐team and cross‐functional relationships necessary for the team’s success. They’re a close partner to the team’s product manager and the first person called when the roadmap needs to be shuffled.

Earlier in their career, they will have implemented their team’s most complex technical projects, but at this point, they default to delegating such projects across the team. They do this both to grow their team‐ mates and in acknowledgment that the team’s impact grows as the Tech Lead ’s coding blocks shrink. While they’re coding less, they are still the person defining their team’s technical vision, and stepping in to build alignment within the team on complex issues.

The Tech Lead role is, for many folks, their first experience as a Staff en‐ gineer. A few forces conspire towards that result. First, the Tech Lead role tends to develop early on within companies that have a strong con‐ cept of team, which is common among companies using agile method‐ ologies, and most companies attempt an agile approach at some point. Another factor is that the day‐to‐day work of a Tech Lead is most simi‐ lar to the work you’d already be doing as a Senior engineer, making it a fairly intuitive transition. Most importantly, an organization needs roughly one Tech Lead for every eight engineers, making it far more common than other archetypes.

Somewhat confusingly, some companies use Tech Lead as a title, and others use it as a role. In this list of archetypes, the Tech Lead is one approach to operating as a Staff engineer, but it’s quite common to per‐ form the Tech Lead role without having the impact expected of a Staff‐ level engineer. Indeed, you’ll find non‐Staff engineers acting with the behaviors of every archetype. Being a Staff‐engineer is not just a role. It’s the intersection of the role, your behaviors, your impact, and the organization’s recognition of all those things.

Architect

Figure 2: Example calendar for Architect archetype

Stories featuring Architect archetype: Joy Ebertz, Katie Sylor‐Miller, Keavy McMinn

The Architect title has fallen out of style in many companies, but the Architect role remains alive and well for folks operating at Staff‐plus levels. Architects are responsible for the success of a specific technical domain within their company, for example, the company’s API design, frontend stack, storage strategy, or cloud infrastructure. For a domain to merit an Architect, it must be both complex and enduringly central to the company’s success.

There is a toxic preconception that Architects design systems in isola‐ tion and then pass their designs to others to implement. That does happen in some cases, but reciting that stereotype would slander the architects I interviewed. Influential architects dedicate their energy to maintaining an intimate understanding of the business’ needs, their users’ goals, and the relevant technical constraints. They use that insight to identify and advocate for effective approaches within their area of focus, and do it with organizational authority that they’ve earned by demonstrating consistently good judgment.

The Architect role tends to evolve in relatively large companies, com‐ panies with exceptionally complex or coupled codebases, and com‐ panies that are struggling to repay the technical debt they created in their initial sprint to product‐market fit. Some companies push for Architects to remain deep in the codebase, and others set a clear expec‐ tation that Architects must not write code: both models work for some companies.

Solver

Figure 3: Example calendar for Solver archetype

Stories featuring Solver archetype: Bert Fan, Nelson Elhage

The Solver is a trusted agent of the organization who goes deep into knotty problems, continuing to work on them until they’re resolved.

Folks in this role are moved onto problems identified by organizational leadership as critical and either lacking a clear approach or with a high degree of execution risk.

Where most Staff‐level roles require a very heavy dose of organiza‐ tional wrangling, the Solver generally operates on problems that are already identified as organizational priorities and thus are called on to do relatively little org‐level chiropractics. On the other hand, they gen‐ erally stop working on problems once they’re contained, which can create the feeling of transience and requires a soft touch to avoid infu‐ riating the teams left behind to maintain the “solved” problem.

The Solver is most common in companies that think of individuals, rather than teams, as the atomic unit of planning and ownership. In such companies, it’s common to see the Solver become prevalent in the place of the Tech Lead. You’re less likely to encounter this role at tra‐ ditionally managed sprint‐centric companies until those companies become relatively large or long‐lived enough to acquire their own va‐ rietal of technical debt.

Right Hand

Stories featuring Right Hand archetype: Michelle Bu, Rick Boone

The Right Hand is the least common of the archetypes, showing up as an organization reaches hundreds of engineers and is akin to oper‐ ating as a senior organizational leader without direct managerial re‐ sponsibilities. Rick Boone compared his role to the Hand of the King in Game of Thrones and Leo McGarry from The West Wing, operating with the borrowed authority of a senior leader. However, borrowing authority comes with the obligation of remaining deeply aligned with that leader’s approach, beliefs, and values.

Folks in this role attend their leader’s staff meetings and work to scale that leader’s impact by removing important problems from their plate.

Figure 4: Example calendar for Right Hand archetype

Problems addressed at this level are never purely technical and in‐ stead involve the intersection of the business, technology, people, cul‐ ture, and process. Right Hands often dive into a fire, edit the approach, delegate execution to the most appropriate team, and then pop over to the next fire elsewhere in the organization. The joy of these roles is that you only work on essential problems. The tragedy is that you’re always on to the next issue by the time those problems are solved.

Which is right for you?

As you think about which of these archetypes would fit you, start by reflecting on the kinds of work that energize you, and then consider which roles are available within your company.

All companies develop a need for engineers who can fill the Tech Lead role, which makes it the most accessible archetype to attain your first Staff engineering role. Companies that emphasize individual owner‐ ship rather than team ownership often develop the Solver early. On the other hand, companies that operate under strict sprints or agile methodologies tend to develop that role late, if ever. In the recent crops of fast‐growing technology companies, the Architect and Right Hand roles have generally emerged as the organizations reached one hundred and one thousand engineers, respectively, and simply don’t exist beforehand. Companies with other strains of cultural DNA often develop them earlier, or sometimes never.

Success in these roles requires remaining engaged; it’s essential to un‐ derstand what kinds of work energize you. The Tech Lead and Architect tend to work with the same people on the same problems for years, developing a tight sense of team and shared purpose. Some months their focus will be a top company priority, and sometimes they’ll be humming along so well that executives forget their team exists.

The Solver and Right Hand bounce from fire to fire, often having more transactional interactions with the folks they’re working with on any given week. They’re tightly aligned with executive priorities and are likely to receive recognition for addressing leadership’s most pressing problems. On the other hand, while they’ll nominally be on a team with other folks, there will generally be little‐to‐no overlap within their team’s areas of focus, and they’ll often have a limited sense of commu‐ nity.

For each archetype, you’ll find folks who love it and find it deeply re‐ warding, along with folks who find the work despair‐inspiring. While it’s important to aim towards an archetype that fits you well, it’s also worth remembering that over your thirty or forty‐year career, you’ll have long enough to spend some time sampling every archetype.

What do Staff engineers actually do?

The role of a Staff‐plus engineer depends a lot on what the team needs and also what the particular engineer’s strengths are. From my experience, the responsibilities of a Staff‐plus engineer can change over time. Still, usually, their main focus is working on projects/efforts that have strategic value for the company while driving technical design and up‐leveling their team. ‐ Diana Pojar

Anyone who has been cornered by relatives at a party and asked to explain what software engineers actually do knows that explaining the work can be challenging. Over time you may have created a compelling answer for your relatives, but many folks’ minds go blank when their coworker leans over and asks, “What’s a Staff engineer do?”

The most straightforward answer is that Staff engineers keep doing much of what made them successful as Senior engineers: building relationships, writing software, coordinating projects. However, that’s a misleading answer. Staff engineers do those same tasks, but whereas previously they were the core of their work, now they’re auxiliary tasks. Their daily schedule varies a bit by archetype, but there’s a shared foundation across all archetypes: setting and editing technical direction, providing sponsorship and mentorship, injecting engineering context into organizational decisions, exploration, and what Tanya Reilly calls being glue.

Setting technical direction

I feel most impactful when I can facilitate setting a technical vision for an area and get people moving toward that vision. I think we would all agree that we want our code to be better architected than it is or improved in some way. However, I’ve

found that often people have some vague sense of wanting better without having a clear idea of what that thing they want is. I like to help the group decide on a shared understanding of where exactly they’re trying to get (it’s actually okay if we never get there) and come up with a general game plan of how to get there. ‐ Joy Ebertz

Much as the Lorax speaks for the trees in his popular children’s book, Staff engineers speak for their companies’ technology. Technology cannot speak for itself and requires effective advocates on its behalf. Folks who successfully advance technology are pragmatic, deliberate, and focus more on the long‐term trend of progress than viewing each individual decision as a make‐or‐break crisis. It can be helpful to think of this as being a part‐time product manager for technology.

Some Staff‐plus engineers are explicitly hired to lead a specific area such as API design, and in other cases, they find themselves editing and aligning approaches across a broad area. One constant across all roles is that the reality of setting technical direction is far more about understanding and solving the real needs of the organization around you and far less about prioritizing technology and approaches that you personally are excited to learn about. In earlier roles, you may have tried to influence decisions towards technology choices you were mo‐ tivated by; in senior positions, you’re accountable to the business and organization first and yourself second.

Mentorship and sponsorship

In my current role, I feel energized when someone I’ve spon‐ sored sends an announcement that they’ve shipped their work, or when I see that I’ve helped shape or shift an engineering team’s model of an important topic. It’s these teams, not me, who are doing the hard work day‐to‐day of building and supporting their technology. I measure my impact based on

their progress and, more importantly, the directionality of that progress and the alignment of their work to the company’s goals. ‐ Michelle Bu

There’s a popular vision of heroic leadership that centers on extraordi‐ narily productive individuals whose decisions change their company’s future. Most of those narratives are intentionally designed by public relations teams to create a good story. You’re far more likely to change your company’s long‐term trajectory by growing the engineers around you than through personal heroics. The best way to grow those around you is by creating an active practice of mentorship and sponsorship.

Sometimes folks see a requirement for mentorship in their career lad‐ der and try to mechanically check that box, which is a shame because mentorship is one of the most valuable activities in a Staff‐plus role. Sharing your experience and advice, along with building an ongoing relationship to understand the recipient’s context, is high impact work. The most effective Staff engineers pair a moderate amount of men‐ torship with considerably more sponsorship: putting your thumb di‐ rectly on the scale to help advance and support those around you. If you haven’t read it already, Lara Hogan has written the canonical piece on the distinction between sponsorship and mentorship, What does sponsorship look like?

Providing engineering perspective

I have a seat at the table at higher level engineering discussions that occur at a level above individual projects and teams. We have recurring staff engineering meetings where we discuss problems that span teams which are both technical and non‐technical in nature. ‐ Dan Na

Effective organizations streamline routine decision making. A good example of this is the process of reviewing contracts for potential en‐ terprise customers. Early on, there will be some contracts signed that the product and engineering teams are uncomfortable supporting. Af‐ ter that happens a few times, the process will include more stakehold‐ ers in the review steps, and over time the right people will be in the right places at the right time.

Even companies that are great at making routine decisions often strug‐ gle when an unexpected decision shows up. The sort which is both time‐sensitive and important, and it’s challenging to even pull the right folks together before the decision needs to get made. It’s frequent for an organizational restructure to occur without valuable input that would have changed the outcome. Similarly, it’s common for interview loops for infrequent roles–those where you might hire one person into them each year like executives or Staff‐plus engineers in an early‐stage company–to not evaluate the candidate on an important dimension. For some companies, even things like roadmap planning fall into this category.

Staff‐plus engineers are the folks who will often get unexpectedly pulled into the room where this sort of decision is happening. This gives them the opportunity to inject the engineering context and perspective into a decision while it’s still possible to change the out‐ come. These brief moments of input on critical decisions are unduly impactful and will allow you to inject an engineering perspective where it would otherwise be missed. Just remember that you’re representing the interests of all of engineering, not just your own.

Exploration

In my current role within the incubator, I’m spending all day prototyping, but in my previous tech lead role, I did a lot of different things. ‐ Ritu Vincent

Hill‐climbing is a simple optimization algorithm. Imagine you’re standing on a mountain somewhere and want to get to the top. You turn around in a circle, identify the highest nearby point, and then walk there. Once you get there, you turn around in a circle again, find the highest nearby point from your new location, and go there. If you keep doing this, you’ll get to the top of whatever mountain you’re on. However, imagine you tried this on a foggy day. Because you can’t see very far, you might get to the highest nearby point and later realize there was a much higher point just out of sight.

Hill‐climbing can’t solve every problem, but it’s so effective that many companies struggle to take other approaches. This can be a consumer‐ oriented company struggling to support enterprise deals or a mature company struggling to compete with a smaller competitor’s release ca‐ dence. It can even be the case that your current business is so valuable that it’s hard to prioritize new businesses, even though the valuable business’ growth rate is trailing downwards.

In the long‐term, companies either learn to explore, or they fade away; this isn’t an ignorable challenge. Simply assigning a team that’s mas‐ tered hill‐climbing to do exploratory work is far from a sure thing, so many companies take a different approach. They find a couple of trusted individuals with broad skills, allocate some resources, and check back in a few months later to see what they’ve discovered. One of those engineers is often a Staff engineer.

This isn’t always a business problem either; it can be any ambiguous, important problem that the company’s systems are ill‐shaped to ad‐ dress. It might be reducing your infrastructure costs by an order of magnitude. It might be identifying a multi‐region strategy that takes six months instead of three years. It might be addressing the sudden realization that your primary database only has three months of re‐ maining disk space, and you can’t upgrade to a larger size (in my expe‐ rience, a surprisingly frequent problem at fast‐growing startups).

This is some of the most rewarding and the riskiest work companies do. It takes a great deal of organizational trust to be trusted with this work, including having enough respect from the business that if you fail, it’s a reflection on the problem and not you.

Being Glue

Tanya Reilly wrote a wonderful post, Being Glue, which captures an‐ other core element of successful Staff engineers: doing the needed, but often invisible, tasks to keep the team moving forward and ship‐ ping its work. It’s not glamorous, but high impact organizations often have one or more Staff engineer working behind the scenes expediting the most important work and ensuring it gets finished.

But will you still write software?

It’s impolite to end any discussion of the Staff engineer role without opining on the first question that Staff engineers ask when they con‐ gregate in a room together: “Do you still find time to write software?” The answer is, of course, it depends!

Ras Kasa Williams said, “I still contributed code regularly—certainly less than the rest of the engineers on my team; but it was important that I sustained”hand to keyboard” work to ensure that my technical strategy (and other macro‐level decision–making) was informed by the on–the–ground experiences of the rest of my team.”

Katie Sylor‐Miller said, “I’m a frontend architect, but by far the main thing I’ve been writing lately is SQL, because I’m doing a lot of data analysis. I’ve been looking at our performance metrics to figure out where the areas for improvement are, and what would be the most impactful issues to fix to improve performance and business metrics. I will write little bits of JS or PHP here and there, but it’s mostly to help unblock teams or to run small performance‐related experiments.”

Joy Ebertz said, “The more senior you get, the less your job is about code. Sure, unlike a people manager, you still have a very technical slant, and even through principal, you’ll likely be doing at least some coding. However, the higher you get, the more your job becomes about mentoring and growing the people around you (and more broadly), building your team through building your company’s public tech brand, noticing larger technical trends that can be improved upon or corrected, helping to set the tech vision for your team or the company and advocating for resourcing for tech debt projects.”

Most write some, some write none, but none write as much as they used to earlier in their career. There will be the occasional week that is purely coding, but those won’t be the norm, and if they happen too often, it’s usually a sign of working on something comfortable rather than important. Even if you’re not writing much, you’ll be reading a ton of your coworkers’ code and doing a fair number of code reviews.

Slow but rewarding

One unifying theme across Staff‐plus work is that the timeframes are longer. Early in your career, it’s easy to get attached to software devel‐ opment’s quick feedback cycle–write, test, ship, repeat–and most of the work you’ll be doing at this level replaces that feedback loop with one that takes weeks, months, and years. These longer timeframes can feel surprisingly demoralizing when you first take on a Staff‐plus role. It’s normal to end some days as a Staff‐plus engineer feeling like you haven’t accomplished anything–keep at it!

The impact and the personal growth lives in those longer timeframes, and while everyone I spoke with wished they’d occasionally get more time to code, and admitted worrying some days that they weren’t ac‐ complishing much, none of them regretted their transition into their current roles.

Does the title even matter?

If you’re safely nestled within the comfortable clutches of the Senior Engineer career level, you might wonder if you ought to pursue the Staff title. It’s a considerable investment of time and energy, along with requiring a good amount of luck. Is that investment worth your time?

The answer is, of course, that it might be! The three consistent advan‐ tages that generally come with a Staff‐plus title are:

1. allowing you to bypass informal gauges of seniority,

2. facilitating access to “the room,”

3. increase in current and career compensation.

A potential fourth advantage is that some folks find that the title grants more agency to select the projects you work on, but others find that in‐ crease in agency is swallowed by a commensurate increase in account‐ ability to the business.

Informal gauges of seniority

When I spoke with Nelson Elhage about whether reaching the Staff level allowed him to take on new work, he answered:

The question of “allowed” is interesting and might not be quite the right question because there were very few official policies on who got what kind of role. Most things relied on more informal gauges of seniority.

Many technology companies describe themselves as pursuing meri‐ tocracy, defined as creating the conditions for talented employees to rise to the top naturally. Given there isn’t any widely accepted mea‐ sure of individual merit, such companies come to rely on what Nelson aptly termed “informal gauges of seniority.” While these gauges are be‐ lieved to evaluate ideas objectively, their sheer informality becomes a broad vector of bias and often conflate confidence with competence. Freedom from the cycle of re‐establishing one’s competence came up frequently as a key advantage of the Staff title. These informal gauges weren’t mentioned by every Staff‐plus engineer I spoke with, but they were routinely mentioned by individuals who didn’t conform to their company’s stereotype of an experienced technologist.

Keavy McMinn shared,

When you have a title, you don’t have to spend so much energy putting your credentials on the table. It helps set the context for others. You’re more respected from the outset, and that’s been really noticeable.

A Staff‐plus title allows you to reinvest the energy you’ve previously spent on proving yourself into the core work you’re evaluated on. If you find that you’re not investing much energy into proving yourself, that’s great! Perhaps you’ve been at your current company long enough and proven yourself enough times that it’s no longer an issue. If you do find your time diverted towards proving and reproving yourself, the title will return a considerable measure of time to you for reinvestment.

Being in the room

Another frequent advantage of a Staff‐plus title is “being in the room.” Dan Na described this as,

I have a seat at the table in higher‐level engineering discussions that occur at a level above individual projects and teams. We have recurring staff engineering meetings where we discuss problems that span teams which are both technical and non‐technical in nature. As a hypothetical example, I’d feel comfortable surfacing what I perceive as shortcomings in the engineering onboarding process in this type of meeting.

For any important decision, there’s the time leading up to the core de‐ cision being made, and then there’s everything afterward. In more senior roles, you’re often in the right place to provide input when it’s relatively cheap to incorporate, where otherwise your feedback might not be incorporated–despite being very valuable–because the related roll out or implementation has advanced too far.

Compensation

Small companies tend to have fairly ad‐hoc compensation, and increases come from direct negotiation with your manager. A pro‐ motion to a Staff‐plus role in such a company might not even come with a corresponding increase in your compensation. However, most companies introduce compensation bands for each role by the time they reach one to two hundred folks. Those compensation bands will generally ensure your compensation increases along with the role.

The highest‐paid roles at any company tend to be the executive and senior management roles. As companies grow, they typically create a compensation mapping between management and engineering roles, such that reaching Staff‐plus roles (and sometimes this is Sr Staff or Distinguished roles rather than the initial Staff role) will significantly bump your compensation.

Even if your current company doesn’t compensate for Staff‐plus engi‐ neer roles much differently than for Senior engineer roles, some com‐ panies do. Throughout your career, you can choose to steer towards such companies, and doing so with a Staff‐plus title will meaningfully increase your lifetime earnings.

Access to interesting work

Many folks take on Staff‐plus roles believing it will give them access to the most visible or exciting work. That’s true to some extent, but it depends on the Staff archetypes which are most prevalent at your com‐ pany. For example, Solvers often do get access to the most interesting work. Conversely, a Tech Lead would probably be undermining their team if they operated that way.

Among the folks I’ve spoken with, the most consistently effective way to get access to interesting work is being hired to do it, such as Ritu Vin‐ cent who was hired to launch Dropbox’s product incubator and Keavy McMinn who was hired to design Fastly’s API strategy.

This doesn’t always work out. Sometimes the interesting work will be plainly visible but still inaccessible. You’ll be too obligated to the busi‐ ness’ needs to pursue a project out of personal interest. In earlier roles, you might be able to sneak that sort of project into your backlog, but now you’ll have a responsibility to model good behavior. Even in cases where the project is the best thing for the company, you’ll often de‐ cide to pass the opportunity on to another engineer who would benefit from it more than you would.

Different rather than better

Even though the title does matter, it’s not necessarily the case that you ought to pursue the role. Even if you love the privileges and perks of a Staff‐plus title, it’s important to recognize that they come on the back of a very different job. Michelle Bu captured this in her advice for folks pursuing the Staff title,

If you’re more focused on hitting Staff than on setting yourself up to do work that energizes you, it’s easy to end up stuck in a role you don’t want. Being a Staff‐plus Engineer, especially a broad‐scoped Staff‐plus Engineer, is a very different job than being a Senior Engineer. It’s important to take a step back and think about whether it’s a job you really want.

The advantages of senior titles are real, and for some folks, those ad‐ vantages shift their career from one characterized by survival to one with the necessary prerequisites for their success. However, many folks find that their Staff role’s heightened expectations eliminate the work that used to excite them. In your career, there are few choices without consequences, and this isn’t one of them.

Material but not magic

You’ll occasionally meet an engineer who believes that attaining a cer‐ tain title is the only thing standing between them and an important ac‐ complishment or opportunity. Such folks might express frustrations, such as, “If I just had the Staff title, I could decide the technology stack for our team.”

Increased organizational authority does provide new tools for solving problems, but successfully retaining organizational authority in a well‐ managed organization requires a great deal of nuance and restraint. If you have a problem and believe that your title is the only thing hold‐ ing you back, I want to reassure you that focusing on developing your approach and skills will be far more impactful than the title. The title will get you over the ledge once you’re close, but it’ll never do as much work as you’d expect.

The one consistent exception to this rule is that women and minorities often do find they spend significantly less time and energy, proving themselves once they attain a Staff‐plus title. The title doesn’t unlock new abilities for them, but it does remove some of the weight they’d been carrying with them throughout their career.