Getting the title where you are

The best advice I’ve heard is that often reaching Staff is a com‐ bination of luck, timing, and work. ‐ Bert Fan

Most technology companies have a “career level,” which is intended to be the highest level that most folks achieve. Senior engineer is the ca‐ reer level at most companies. While you might get let go for not mov‐ ing from entry‐level engineer to mid‐level engineer quickly enough, most companies have no expectation that you’ll ever go from Senior to Staff. Six years at mid‐level? Ah, that’s a problem. Twenty years at Senior? Sure, that’s fine.

More than the expectation of progress going away, companies’ promo‐ tion systems will often impede your further progress once you attain the career level. Sometimes the folks who already have Staff engineer titles are protective of diluting their prestige. In other cases, organi‐ zations may be wary of having multiple Staff engineers on a single team due to team health or budgetary concerns. However, I think the strongest source of friction is that the nature of the job changes. A Staff Engineer isn’t a better Senior Engineer, but someone who’s moved into fulfilling one of the Staff archetypes.

Even after you’ve developed the prerequisite skills to become a Staff Engineer, there will still be one last hurdle: getting your company to grant you the Staff title. For some, this process is a relative non‐ event, perhaps taking one or two cycles longer than anticipated but ultimately succeeding, and for others, it may not happen at all at their current company. About two‐thirds of the Staff Engineers I surveyed attained their title as a promotion at the company they were already working at, and the remaining third changed companies to attain the title.

If pursuing that sort of role is your goal, then take the promotion to your career level as an opportunity to reset your approach to navigat‐ ing your career. From that point onward, there is no standard path to follow. The promotion and performance system will no longer be designed around attaining a timely promotion and may, at times, take on the feel of gatekeeping.

To go further, you will have to take more deliberate control of your progression, and this chapter shares the tools that have worked for folks who’ve made the progression ahead of you.

Finding your trail

If you’ve been relying on your manager to steer your career up to this point, the transition to a self‐directed career can feel rather abrupt. There are many books about managing your software career, but most focus from your first job until you reach Senior Engineer. Few focus on managing your career beyond the Senior title, which is where this chapter focuses:

• Your promotion packet is your foundational tool to demystify the Staff promotion, prioritize the right personal development to ensure you get there and activate your internal sponsors and network in support of your progression.

• There is a widespread belief that moving into a Staff‐plus role requires successfully completing a Staff project. This section discusses the reality that most Staff Engineers do not have a Staff project but also describes how to approach one if you’re at a com‐ pany that does require them.

• A frequent complaint from engineers is that they’re not “in the room” where decisions happen, and they’re usually right: there is a room, and they’re not in it. What’s less frequently acknowl‐ edged is that you’re probably not in the room for a good reason. This section describes how to get into the room, and also how to stay there.

• Finally, you won’t get promoted if your company’s leader‐ ship doesn’t know who you are. How do you become visible internally without hogging all the oxygen?

Apply these techniques consistently, and you’ll be on the way towards a Staff title, although even the best‐laid plans falter if you’re conducting them at the wrong company.

Opportunity is unevenly distributed

One inconvenient reality you’ll encounter in pursuit of a Staff role is that opportunity at any given company is unevenly distributed. If your company leadership views infrastructure engineering as inherently “more complex” or “more leveraged” than product engineering, then opportunity will consolidate within infrastructure teams. If you work in an organization that emphasizes shipping features, then it will be easier to be rewarded for fixing an outage you cause than preventing future outages. Your work will be more visible if you work in your company’s headquarters than in a distributed office.

Many companies believe they have a vested interest in pretending op‐ portunity is evenly distributed, even when it clearly isn’t. This makes it hard to have conviction these dynamics exist, but the trends become clear as you collect more data.

Once you recognize these challenges, you have to assess how fixable they are and where you want to prioritize your energy. It’s much sim‐ pler to align your approach with these unspoken currents rather than reroute the river creating them. If you choose to address the causes of inequality, start by finding a senior sponsor who supports the cause. You can only change a system with sponsorship from within.

Should you try management?

Most folks who reach Staff‐plus roles do not spend time in engineer‐ ing management, but some do. It’s easy to view this as a critical, life‐ changing decision, but that’s probably overthinking it a bit. If you want to give management a try, you should. Most companies understand that management isn’t the right role for everyone and will be glad to let you rotate back into an engineering role.

Those that try management gain a broader perspective that helps them even when they move back into a software engineering role. This was Dan Na’s experience,

I still enjoy both shipping code and running teams, and I think the ability to do both at a high level is critical for long‐term en‐ gineering success. Charity Majors has a fantastic blog post on this topic that I recommend reading: “The Engineer/Manager Pendulum”. Charity argues that “manager career path vs en‐ gineering career path” is a false dichotomy, and taking time to alternate between both roles makes you better at both. This maps to my own experience. I’m a better manager because I know how terrible it is to be an IC on a poorly planned project, and I’m a better IC because I know how and when to sound an alarm when a project is going poorly.

Ritu Vincent shared a similar perspective,

I do pendulum a decent amount because I’m interested in so many things on both sides of the career ladder. I’m interested in growing people, I really like working with recruiting, I’m one of those engineers that actually enjoy interviewing, I like understanding how teams grow. But I also really like writing code, and after I spend some time managing, I want to get back into the code and hack around a little bit.

Some folks try management and end up hating it. Joy Ebertz didn’t care for engineering management much,

I actually managed for about a year and a half in the middle of my time at Box and found that I hated it (you can find more

about that in my blog post on that topic). That said, I found that there is actually a lot of overlap between management and staff+ roles in most companies.

Even though Joy hated her management experience, she felt it might have helped her longer‐term career,

It’s possible that if I hadn’t taken a meander through manage‐ ment, I would have gotten to Staff sooner. That said, I don’t regret doing it, and I learned a lot about how people think, how organizations are run, and how larger projects are prioritized. All of these have continued to help me do my job on the IC track and likely helped me further get promoted to Senior Staff. While I do think it’s distinctly possible that it slowed down when I got to Staff, I’m actually less sure for the next level ‐ I think there’s a real chance I would have hung out at Staff longer without it. All of this is to say that even though I didn’t take the most direct route, I still learned a lot that has helped me out long term.

The final caveat I’d give for someone considering this switch is that people management is bigger than simply maximizing your trajectory to a Staff Engineer role. You’ll have a profound impact on the folks you support as a manager, and if you take it on with the wrong motivations, you’ll regret the experience, but not nearly as much as your team will. If you’re motivated to help your team grow and succeed, then go ahead and do it; if you’re only doing it for yourself, then don’t.

A semi-permeable boundary

As a final caveat, Staff‐plus titles are leadership positions. It’s uniquely challenging to gain a leadership position if the existing leadership team doesn’t identify with you as a potential member. What that means is, unfortunately, folks with the privilege of seeming like they are already part of the existing leadership team have a much easier

time making the transition.

If you read through this chapter and become increasingly frustrated that you’re already doing everything here, then it’s possible that you’re experiencing that structural disadvantage. Roughly half the women I spoke with had to change companies to attain the Staff title, whereas promotion friction generally didn’t come up as a topic during discus‐ sions with other folks.

Don’t ignore those experiences–they’re real and many folks feel stymied by them–by also take hope that there are many successful role models out there regardless of how you identify and how you want to plot your course towards Staff Engineer.

Promotion packets

Some folks think of their promotion packet as the capstone of reaching a Staff‐plus role, but I’ve seen many folks succeed by taking an oppo‐ site approach: starting to write their first Staff promotion packet long before they think they’re likely to be promoted to Staff, much the way they might use a brag document. Used this way, your packet becomes the map to accomplishing your goal.

It’s likely your company will have its own format for promotion pack‐ ets, and eventually you’ll need to translate your packet into that format before it’s submitted to an internal promotion committee or process, but there’s no need to rush it. You’ll spend more time relying on it as a guide than as a formal artifact for official review, so optimize for the former.

For traversing towards your Staff‐plus promotion, a general template format that’s useful is:

• What are your Staff projects? What did you do? What was the project’s impact (including a well‐defined goal)? What made this project complex? Keep it very short and then link out to support‐ ing design documents

• What are the high‐leverage ways you’ve improved the organiza‐ tion?

• What is the quantifiable impact of your projects? (Did you in‐ crease revenue by $10 million? Did you reduce year‐on‐year cus‐ tomer support tickets by 20%?)

• Who have you mentored and through what accomplishments?

• What glue work do you do for the organization? What’s the im‐ pact of that glue work?

• Which teams and leaders are familiar with and advocates for your work? What do they value about your work? One sentence, include data (e.g. survey data) when possible

• Do you have a real or perceived skill or behavior gaps that might hold you back? For each, how would you address the concern? One sentence each

It’s useful to spend some time to write out those answers yourself, but getting promoted into a leadership role isn’t a solo activity – it’s some‐ thing you can only accomplish with a team of folks supporting you along the way.

The approach that I recommend for iterating on your packet is:

1. Answer why you’re doing this. Many folks choose not to pursue the Staff level; you should have a reason why this is important to you. If you don’t, you’re liable to find yourself in a role you don’t enjoy.

Michelle Bu warns, “My first piece of advice to engineers is that they should avoid pattern matching in ways that lead them to‐ wards work they don’t enjoy. I’m deeply energized by the work I do, partnering with teams to solve abstract modeling and de‐ sign problems. It takes a certain amount of fortitude to try again and again after many rounds of feedback. To be honest, it’s not for everyone. If you’re more focused on hitting Staff than on set‐ ting yourself up to do work that energizes you, it’s easy to end up stuck in a role you don’t want.”

2. Temper your expectations. Promotions, especially at this level, are built over quarters, halves, and years. Avoid the expectation of instant results

3. Bring your manager into the fold. Bring the promotion packet to your next 1:1 with your manager, and tell them that attaining a Staff promotion is a goal of yours. Review the empty packet with them, and ask them what’s missing, what to emphasize, and if they’d recommend adding steps to the workflow. Your goal is to ensure they know this is something you’re interested in and to solicit their guidance on your approach.

Ritu Vincent suggests, “People frequently come to me and ask, ‘What should I do next to reach Staff?’ One of the things that I tell them is to be super open and honest with their manager about what you want from your career. A mistake I made early on in my one‐on‐ones was telling my manager what I thought they wanted to hear, instead of what I actually felt.”

4. Compile the promotion packet. Now write the packet

5. Edit the promotion packet. Wait two days, reread your promotion packet and edit for content, clarity, and context

6. Edit the promotion packet with peers. Share your promotion packet with several trusted peers to get feedback, preferably peers already in a Staff‐plus role. Peers are often better at identifying your strengths and contributions than you are, and they are closer to your work than your manager might be

7. Edit the promotion packet with your manager. Share your promotion packet with your manager requesting feedback. Ask for a particular focus on enumerating gaps to address. Ask if you can spend time in the following 1:1 discussing the kinds of projects and opportunities to both address gaps and make the packet stronger

8. Periodically review the promotion packet with your manager. Continue to review the promotion packet with your manager dur‐ ing your career and performance‐oriented 1:1s. Both you and your manager should use it to steer you towards demonstrating the promotion criteria over time. This is particularly important to do if your direct manager changes. Maintaining this sort of document and reviewing it across managers will help mitigate the loss of progress towards your promotion that often occurs after a manager change

If you methodically follow this advice, then you’ll put together your first Staff promotion packet long before you’re nominated for promo‐ tion. From there, you’ll use the packet to focus your attention and your partnership with your manager towards that goal. It won’t necessarily get you there quickly, and it even might not get you there at your cur‐ rent company, but it will consolidate your energy on the development and work that’ll move you towards your goal.

When it finally does come time to write your formal packet, it’ll be a matter of editing down what you’ve collected into the official tem‐ plate rather than an archival process of dusting through years of ef‐ fort. Hopefully, nothing goes awry in the promotion process, and a Staff title follows.

Find your sponsor

Having a sponsor was also definitely important. My manager and I had a fantastic relationship, and I also had a great rela‐ tionship with my skip‐level manager. I think that played a big part as well. ‐ Ritu Vincent

As I’ve spoken with more folks trying to reach their first Staff‐plus role, most folks run into similar challenges. Many have miscalibrated their own impact and simply haven’t done the work yet to operate at that level: a Staff Engineer isn’t just a faster Senior Engineer. However, there’s a large cohort who have done the work–they’re visible across their organization and have pulled together a strong promotion packet–but are still struggling to have that work recognized.

These folks are often frustrated by the distance between their impact and their recognized impact and ask their managers and peers for feedback on closing that gap. They’re told to complete a staff project or to create space for others. For folks who haven’t done the work yet, this is great advice, but for folks who have these checkboxes are a dis‐ traction: what they’re really missing is a sponsor willing to push for the recognition of their existing work.

It’s common to view promotion systems through the lens of other systems that have evaluated us throughout our life such as school, but this falsely frames performance evaluation as a solo activity. Whether your company does ad‐hoc promotions or uses a calibration process, promotions are a team activity and as Julia Grace, then of Slack, advised me once during a job search, “Don’t play team games alone, you’ll lose.”

Finding your sponsor

The most important member of the team guiding your promotion is you yourself. The second most important person is your organiza‐ tional sponsor. Lara Hogan has written on sponsorship at length, but roughly this is the person speaking up for your work in forums of influ‐ ence and when advocating for constrained resources (like the budget for salary increases).

While you’ll likely have a variety of sponsors, in the context of getting promoted—especially to a Staff‐plus role—this almost always needs to be your direct manager. They’ll be the person to take your drafted pro‐ motion packet and turn it into the company’s format. They’ll be the person to advocate for your promotion during a calibration meeting as others drill into your qualifications. They’ll also be the person who has to have an honest conversation with you about the gaps you still have before you’re a strong promotion candidate.

While you’ll always need your direct manager engaged as your spon‐ sor, you may need additional sponsorship. If your manager has never promoted someone to a Staff‐plus role before, they’re likely going to get surprised or make a misstep along the way. Invest in establishing a relationship further along your management chain. You don’t need to spend much time with your skip‐level manager, but if they aren’t familiar enough with your work’s impact to remember it in a meeting two months from now, you’re unlikely to get promoted into a senior role.

Activating your sponsor

The first step of activating your sponsors is explicitly sharing your goals. “I’m looking to be recognized as a Staff Engineer” is a great start. Ritu Vincent mentioned this as her top advice for folks seeking Staff‐plus roles,

People frequently come to me and ask, “What should I do next to reach Staff?” One of the things that I tell them is to be super open and honest with your manager about what you want from

your career. A mistake I made early on in my one‐on‐ones was telling my manager what I thought they wanted to hear, instead of what I actually felt.

Once they’ve identified their sponsors, many folks see their work as complete: it’s up to the sponsor to do the heavy lifting. This usually fails! Sponsors are folks with more organizational capital than band‐ width to deploy that capital, and they’ll help you most when you align the pieces for them. Ask your sponsor how you can support their spon‐ sorship. Owning your career isn’t only about asking for things. It is about that, but it’s much more about facilitating those things happen‐ ing.

Reviewing your promotion packet collaboratively with your sponsors is a great way to facilitate this conversation. Focus on asking for what the gaps are in a way that doesn’t prompt your sponsor to make up an answer. Most folks forget they can answer questions with, “I don’t know,” and instead make up unhelpful answers if you push them to answer questions they’re uncertain about. If you keep getting answers like, “Work on larger, high impact technical projects,” then you’re ask‐ ing in the wrong way, the wrong questions, or the wrong person.

One starting prompt is, “If I don’t get promoted this cycle, what are some of the likely causes?” Another question worth asking is, “What’s the most effective thing I can do to make myself a stronger candidate?” That said, the best questions are very specific and do a lot of the work for the answerer. Think about how hard it is to answer those ques‐ tions compared to a question like, “This quarter I completed the API refactor, which I thought would demonstrate Staff‐level work, but the schedule slipped a lot, and it ended up frustrating our product man‐ agers because their work got dropped. How could I have handled this project more effectively?” The latter question is much easier to give a useful answer to, even if the answerer isn’t too familiar with the details of the project.

Finally, remember that activating your sponsor isn’t a transactional thing to do once before your promotion. Build a relationship over time, and put in the work to help them when they need your support. Stay aligned with their initiatives. Suppose they need folks to join a working group, volunteer, and put in the work. These folks have a lot of folks asking them for things, and they are pretty cognizant of folks who show up right before promotion time. I once had a colleague who rarely visited the office but always visited the office the week before promotion decisions were made. People noticed.

What if it doesn’t work?

If you find yourself in a situation where you and your manager don’t work together well, which isn’t quite the same thing as liking each other, then you’re not going to get promoted into a leadership role. Your manager has too direct an influence on your impact and your perceived impact for that to happen. Similarly, you might have an amazing relationship with your manager, who then leaves the com‐ pany. You’re hardly doomed, but your promotion clock will likely get reset as you build a relationship with your new manager. (Sometimes, this works out the other way, with your new manager working hard to prove themselves to you by advocating on your behalf.)

You’ll cheat yourself if you immediately try to switch teams or compa‐ nies after running into friction with your manager. Companies gener‐ ally don’t allow transfers unless your manager approves it, so you may burn a bridge to nowhere that you’re standing on. More importantly, you’ll lose the opportunity to develop your skill of working with folks you don’t immediately click with: it’s not a fun skill to develop, but leadership always involves influencing and building relationships with folks with conflicting goals and styles.

If you’ve spent six months proactively trying to make the relationship work, then it probably is time to explore moving teams and to perhaps consider switching companies. This is one of many cases where it’s extremely helpful to have developed your relationship with your skip‐ level manager, who can help you find a new team, even if you and your manager aren’t working together effectively.

Staff projects

There isn’t an explicit expectation, nor is it listed anywhere as a formal requirement, but it is understood that you’ll complete a Staff Project to get promoted. I can’t think of any Staff pro‐ motion that didn’t include a really strong project, typically a multi‐person project where the engineer was the Tech Lead. ‐ Ritu Vincent

A popular recurring idea around reaching a Staff‐plus role is that first, you need to successfully complete a “Staff project.” A project that is considered complex and important enough that the person who com‐ pletes it has proven themselves as a Staff engineer. However popular this idea is, if you’re pursuing a Staff‐plus role, it’s important to pierce the mythology of these projects and focus on the experiences of folks who’ve walked the path before you.

The short answer on Staff projects is that most engineers don’t com‐ plete one as part of reaching a Staff role, although a large minority do complete one, particularly folks who attain the role via promotion at a company they’ve grown up in. For the folks who don’t complete one, typically, it’s either because they accumulated a track record of suc‐ cess over a longer period without a single capstone or because they switched companies to reach the title.

We’ll dig into a few different angles on staff projects:

1. Folks who didn’t complete Staff projects

2. Folks who did complete Staff projects, including where they don’t end up working as planned

3. Identifying and approaching your Staff project

Into the messy details, we go.

No Staff project required

When I asked folks whether they had a Staff project, some of the an‐ swers were quite concise:

• Joy Ebertz, “I actually didn’t really have a Staff Project.”

• Diana Pojar, “No, I did not have an assigned ‘Staff Project,’ and that is not something that is part of the promotion process at Slack.”

Some folks were even skeptical of the Staff project concept overall. Nelson Elhage said,

I’m instinctively a little bit wary of this sort of idea of a staff project, in part because one of the archetypes of Staff Engineers that I’ve seen are people who don’t necessarily run grand projects themselves or do big things. But just are sort of incredibly effective gurus and routers who make the whole engineering organization run better.

There are also folks like Dan Na or Damian Schenkelman who took a detour through engineering management to reach the role. Damian describes bypassing the Staff project,

I did not. Because of how I grew at Auth0, I kind of “skipped that part”. As a Director at a startup, I got the opportunity to technically lead a lot of big, critical initiatives, but there was no specific/explicit “staff/principal project”.

From these stories, it’s clear that anyone who tells you that you must complete a Staff project to reach a Staff‐plus title is wrong: there are many avenues to reach Staff‐plus titles without doing a Staff project, with a stint in engineering management prominent among them.

Staff project required

However, it’s also true that many companies require, or informally en‐ force, Staff projects for internal promotions, and consequently, many folks do take on a Staff project as part of their role transition.

Ritu Vincent describes her experience at Dropbox,

I definitely had a Staff Project. Back in the day, Dropbox was initially a consumer product that people downloaded and in‐ stalled on their machines. When we launched Dropbox for Busi‐ ness, there was a request for both your personal and work Drop‐ box accounts to work simultaneously, including being able to switch across them without needing to log out and log back in. The initial implementation was written under immense time pressure, and it ran multiple Dropbox processes. One for your personal account and another for business. My Staff project was to make it so a single Dropbox process could run with multiple users logged in. The hard part was that the project stretched from the kernel all the way to the user interface. I had to un‐ derstand every single layer of the Dropbox system. Initially, we thought it would take six months, and it ended up taking eigh‐ teen months. It took up most of the Desktop Client team’s re‐ sources for quite a while.

Ras Kasa Williams joined an inflight project that he later became the lead on, which served as his Staff project:

I joined Mailchimp as a Senior Engineer. I was immediately added to a project team (which included an Engineering Director and two Principal Engineers) meant to build out Mailchimp’s first internal, self–service analytics platform.

A key aspect of this project was being effective and executing at a high level. For better, or for worse, having two other Principal Engineers meant expectations for me likely weren’t that high.

But I was able to jump in immediately and start contributing to core aspects of the project with very little hand‐holding from them; by the end, I was one of the key contributors on the team. I would ultimately be formally installed as a tech lead to help continue shepherding that project work as it was absorbed into my current engineering group, Data Services.

Few companies write down their Staff project requirements. They’re more frequently the sort of “soft gate” that’s brought up during a pro‐ motion meeting, sometimes to the surprise of both the manager and the would‐be Staff engineer. The most reliable technique for uncov‐ ering these requirements is your “sure thing” promotion not getting approved, but that isn’t much fun. Almost as reliable and much less frustrating is relying on the strategy of maintaining and getting feed‐ back on your promotion packet well in advance of your promotion at‐ tempt.

Why you should do a Staff project

Sometimes it’s hard to determine the precise line between gatekeep‐ ing and evaluation, and the premise of a Staff project exists in that hazy realm. Taking on a project of immense scope, navigating that ambiguity, and delivering it successfully is an effective way to distin‐ guish folks who’ve reached Staff‐plus impact, but it’s also clear that many folks attain Staff‐plus roles without completing such a project.

My advice is that although you can attain a Staff‐plus role without com‐ pleting a Staff project, they’re a particularly valuable opportunity to develop yourself as an engineer. You will personally be stretched and grown by this kind of project in a way that other varieties of Staff level work won’t.

Keavy McMinn describes how her Staff project helped her,

I’ve never heard it given a name, but I understand the idea.

I did lead and architect that type of project ‐ solving gnarly engineering problems, with large impact for the company ‐ a few times, but unfortunately, they didn’t lead to me being pro‐ moted. They did lead to my career progression though. Those projects gave me the experience, knowledge, and confidence to position myself differently. Even to give public conference talks or know that “I’ve done X and could do X again.”

Although each of these projects is different, there are a few typical characteristics that capture why they’re so effective at stretching you as an engineer:

• Complex and ambiguous ‐ early in your career, you’re given well‐defined problems, but as you get deeper into it, you’ll increasingly encounter poorly defined or undefined problems, and Staff projects will generally start with a poorly scoped but complex and important problem. Your project might start with only the assertion that your company’s aging monolith is crippling product development. From that broad, unclear (and potentially wrong) statement, you’ll have to identify a concrete approach that works.

• Numerous and divided stakeholders ‐ the easiest projects start with organizational alignment around both the problem and the solution, but your Staff project might likely start with neither. It might be an area in which management views as an existen‐ tial risk, but many engineers feel it is good enough. It might be an area that everyone agrees is a problem, but with strong factional disagreement about approach, for example, disagree‐ ment between pursuing a service strategy or reinvesting in your existing monolith.

• Named bet where failure matters ‐ it’s going to be a project im‐ portant enough that senior leadership talks about it at all organi‐ zation or all‐company meetings. This means folks will be watch‐ ing your work closely, and any failures will be very visible. Suc‐ cess will be highly visible, as well!

If you meet these, it’s probably a staff project. These can be pretty nerve‐wracking, which is also why they’re so effective at developing you.

Getting access to Staff projects

While deciding that you want to take on a Staff project is the first step, you still need to get access to these projects, which depends on your management chain trusting you enough to bet on your success.

This comes down to three factors.

1. First is learning to stay aligned with your leadership team, some strategies for which are described in Getting in the room and Staying aligned with authority.

2. Second, you need to be known to have the technical aptitude for the problem at hand, which requires Being Visible.

3. Third, is less in your control, which is your company having a pressing need to solve a Staff‐level problem, which can require some patience.

Should you pursue a Staff project?

In summary, if you’re looking to get promoted within your current company and haven’t previously held a Staff or management title be‐ fore, then you’ll likely need to pursue a Staff project to establish your‐ self at that level. In other cases, you likely won’t.

In any case, it’s worth keeping in mind that whether or not these projects are required, they are also some of the most challenging work you can find and are the sort of work that will stretch and develop you into a better engineer. In the short‐term pursuit of the title, it may well be optimal to avoid these projects, but in the long‐term pursuit of self‐growth, they’re irreplaceable.

Get in the room, and stay there

One of the most common frustrations I’ve heard from engineers is that they’re not in the room where important decisions are being made. They don’t understand the company decisions and have important context that seems to be missing or ignored. Staff‐plus engineers frequently cite access to “the room” as a major benefit of their level, and titles do increase the likelihood that you’ll be involved in decisions that impact you.

However, it’s important to remember there’s no single “room” to en‐ ter. Getting into the right room isn’t a one‐time challenge to be faced. Entering rooms will be an ongoing, iterative career challenge. That means it’s worth getting good at!

Early in your career, it might be a sprint pre‐planning meeting with your tech lead and product manager. Later it might be a quarterly planning meeting, an architecture review, the performance calibra‐ tion, the engineering leadership team, or the executive team. There will always be another room to enter. To reach senior levels, you have to become effective at not only entering but also staying in these rooms of power.

Getting in the room

To get into the room, you need:

• To bring something useful to the room… This could be details on a critical project, context from a critical team, subject mat‐ ter expertise related to the room’s purpose, experience running a similar project or team at a previous company, a relationship with a key relevant customer, or something else entirely.

• …that the room doesn’t already have. It’s not enough to have something useful to bring to the room. It also needs to be a per‐ spective that isn’t already present within the room. Small groups function better than larger ones, so operating forums generally sacrifice redundancy and representation for efficiency. To be included in those rooms, you’ll need to bring something distinct from the current membership.

• A sponsor in the room. These rooms have limited slots and have to function well as a group. To get into the room, you’ll need someone to sponsor your membership. Your sponsor is allocating their social capital towards your inclusion, and their peers will judge them based on your actions within the room. These rooms often have a mix of seniority levels, so it’s often the case that your sponsor’s manager is in the room evaluating them based on their decision to sponsor you.

• Yoursponsorneedstoknowyouwanttobethere. Your sponsor is probably in many different rooms and probably daydreams of leaving most of those meetings behind them. They won’t neces‐ sarily assume you want to be in any particular meeting, and in fact might assume you don’t want to be there at all. Make sure that they know if you want to be included.

How you bring something useful to the room is going to be context‐ specific to you and the room you’re trying to enter: there isn’t any sin‐ gle pattern to follow. Whether someone with similar context is already in the room is also unique to your circumstances, and at some points in time, the only options are to wait or look for another room to enter.

On the other side of things, sometimes the easiest way to increase your value to the room is by decreasing the cost of including you. Some of the approaches that work well are:

• Stay aligned with your manager. Folks evaluate leaders on how aligned their teams are with their announced approach. If they’ve proclaimed a shift to continuous deployment, but their team is chanting for release trains, then folks get skeptical about who is leading who. You’ll be much more likely to be sponsored into the room if you’re highly aligned with your sponsor. If you’re particularly aligned, they’re more likely to yield their own seat to you and stop attending.

• Optimize for the group. One of Stripe’s old operating princi‐ ples was “Optimize for Stripe,” and that mentality of optimizing widely for others builds trust and confidence in your judgment.

• Speak clearly and concisely. Learn to speak concisely: as you develop an economy of speech, you’ll be able to contribute more ideas with less time. Learn to speak clearly: if folks don’t under‐ stand your proposal, then it doesn’t matter how good it is. Keep in mind that it’s your obligation to be understood, not the obliga‐ tion of everyone else to understand you.

• Be low friction. It’s easy to fall into the trap of viewing each discussion as the last opportunity to stop an impending disaster. With that mindset, each discussion is a near‐emergency, and emotions run high. Those sorts of discussions usually spend their time draining frustration rather than making forward progress. If you’re known as someone who can navigate diffi‐ cult conversations effectively, you’re much more likely to be involved.

• Come prepared. Some companies infantilize their engineers, accepting that even very senior engineers won’t read the agenda, do the pre‐reads or prepare for the discussion. There’s a consid‐ erable gap between what’s tolerated and what’s rewarded, and you’ll stand out if you take the time to organize your thoughts be‐ fore each meeting. Equally more important is following up on what you committed to.

• Focus and be present. Once you’ve entered the room, be sure to show up and engage. Be attentive and engaged. Whatever else you want to be doing, it will wait.

• Volunteer for low‐status tasks. If someone needs to take notes, raise your hand. If someone needs to follow up on action items, be available. Prioritize being useful, especially when it isn’t the most exciting work.

To get into the room, you have to work both the numerator and denom‐ inator: keep developing a unique and useful perspective while also becoming more effective at delivering that perspective within the con‐ straints of a meeting.

Staying in the room

Getting into the room is your first hurdle, but the second hurdle is stay‐ ing in the room. Most important is to keep doing the things that got you into the room: bring important context into the room, present a polished version of yourself, be concise, be flexible.

There are a few patterns that will consistently get you kicked out of the room:

• Misunderstanding the room’s purpose. Each room has its own purpose, and you’ll create friction if you attempt to use a room against the existing group’s intent. It’s very common for the ex‐ ternal perception of a given room’s function (“they make all the decisions in the leadership team meeting”) to be rather far from how the room thinks of its role (“we don’t make decisions, just surface problems to discuss”). Take the time to understand how the room operates and integrate into it with respect for that in‐ tention.

• Being dogmatic. As rooms get more senior, they have to discuss very sensitive topics (compensation, layoffs, promotions, acqui‐ sitions, etc), and they have a fixed amount of time to work to‐ gether each week. If you’re dogmatic, you will create friction that slows down discussion and impedes the group’s ability to make progress.

• Withholding consent. Effective groups are formed from individ‐ uals who are willing to disagree and commit. You can often force a group towards your perspective by withholding your consent until thinking moves your way, but the group’s pace will slow to a halt, and you’ll likely get removed from it.

• Sucking the oxygen out of the room. There are brainstorm dis‐ cussions where every idea is welcome, and there are moments when you’ve shifted into operating mode to unblock project ex‐ ecution, and you have to read the room on which is happening. Usually, this comes from an urge to show value, but remember that you’re in the room because of what got you into the room, not in the hopes that entering the room will magically transform you into someone entirely new.

• Embarrassing your sponsor. Remember that you got into a room because someone in the room advocated for your inclusion.

• Being flakey or not showing up regularly. There are only so many slots, and the person running the meeting will prioritize them on people who show up.

That said, I think it’s easy to get caught up worrying too much about staying in the room. Sometimes you’re better thinking about whether the room’s a valuable place to invest your time.

Exiting the room

It’s important to remember that while there are infinite rooms to be in, there’s no room where the work actually happens. You’ll be most impactful if you’re selective on which rooms you stay in. While I’ve met many folks who resent not being allowed entry into some room they’re fixated on, I’ve never met anyone who regrets leaving a room too soon. If any given room doesn’t feel useful, exit the room. While exiting, sponsor someone else into the opportunity you’re leaving be‐ hind.

Being visible

When folks, particularly women and non‐binary people, come to me for advice, I think they expect me to talk about how to grow as a technical leader, and are surprised when I say “You’ve probably already got the technical chops, what you need to do is work on your reputation at the company.” For better or for worse, you can’t get to Staff without a good reputation. ‐ Katie Sylor‐Miller

Bert Fan’s best advice for those trying to reach a Staff‐plus role was, “Often reaching Staff is a combination of luck, timing, and work.” Tim‐ ing is a particular sort of luck, so you can simplify this even further down to just luck and work.

If you’re fortunate, then you won’t have to pursue a deliberate path to a Staff‐plus role. You’re already working on your company’s top pri‐ orities, have a well‐positioned manager who cares about supporting your career and are working from your company’s headquarters office. If you’re starting with none of those things, getting promoted will be quite a challenge, but don’t count yourself out: it’s easy to underesti‐ mate your own role in getting lucky.

One of the most effective ways to get luckier is to be more visible within your organization. There are, of course, very quick, very negative ways to increase your visibility, so I’ll refine the statement a bit. Your goal is to be known for good things while minimizing the organizational bandwidth you consume to do so.

Why visibility matters

Katie Sylor‐Miller describes visibility as a critical piece of getting pro‐ moted to Staff,

Something I haven’t talked about enough is communication and transparency. A big part of being promoted to Staff is mak‐

ing sure that your work is visible, that people know your name and you have a good reputation.

Staff‐plus roles are leadership roles, and by recognizing you with such a position, the company is bringing you into its leadership team. The existing members of that team want to be comfortable that they’re ex‐ panding their ranks with folks they believe in, and they can’t believe in you if they don’t know you.

If you’re operating without much visibility within your company, this may likely come across as cliquey or gatekeeping behavior. Conversely, if you are well‐known internally, this may feel like the necessary cost for maintaining a consistent set of expectations and criteria for folks taking on leadership roles – how could you maintain consistency if you are unfamiliar with their work?

It’s interesting to briefly reflect on how inclusive organizations miti‐ gate the negative gatekeeping aspects of validating folks as appropri‐ ate additions to your leadership team. The answer is that they design mechanisms to ensure the full swath of potential leaders get exposure to the folks who will evaluate them for leadership roles. Conversely, less inclusive organizations inadvertently center access on folks who most aggressively self‐advertise.

Internal visibility

The single best way to create internal visibility is to work on the things that matter to your company and company leadership. This path is also the most aligned with how a well‐managed company will evaluate your contribution.

Sometimes that isn’t enough, though, and some other strategies are:

• Write and distribute more long‐lived documents, like architec‐ ture docs or technical specifications.

• Lead (and, to a lesser extent, participate in) company forums like architecture reviews, company all hands, and learning circles.

• Be a cheerleader for your team’s and peers’ work on Slack.

• You can also cheerlead via email instead of Slack.

• Share weekly notes of your work to your team and stakeholders in a way that other folks can get access to your notes if they’re interested.

• Contribute to your company’s blog.

• Attend, or potentially even host, office hours for your team or org.

Find the right mix of activities that leverage your strengths, aren’t al‐ ready overburdened with volume, and feel authentic to you. If you’ve never done much communication of your work, it may feel awkward to self‐promote your work. You never want to wholly lose that sense of awkwardness–restraint helps–but you will have to get comfortable with some of it.

Executive visibility

To be promoted to a leadership role, the most important kind of inter‐ nal visibility is executive visibility. Using the promotion packet, you will create visibility with your manager, but it’s helpful to go further. It’s particularly valuable to find opportunities to build a relationship with your manager’s manager, but all positive, visibility at that layer will be helpful to you.

These are the folks who tend to be in the room that approves promo‐ tions into Staff‐plus roles, and they rarely support folks whose work they don’t know.

External visibility

It’s helpful to complement your internal visibility work with external visibility work. There are many successful Staff‐plus engineers with no external presence, but many find external visibility contributes to their career.

Compared to an exclusively internal focus, one advantage of building an external presence is that there’s a lot more room to create a niche and name for yourself. Internal efforts often end up competing for attention with your peers in a way that external efforts simply don’t.

In terms of how to create this sort of visibility for yourself and your work, it could be giving a conference talk like Keavy McMinn or Dan Na, going on a podcast like Michelle Bu, turning a problem into a web‐ site and book like Katie Sylor‐Miller ’s ohshitgit, or creating a mailing list like Stephen Whitworth’s High Growth Engineering.

Should** **you focus on visibility?

You can always have more visibility within your organization, but at some point, increasing your visibility is likely reducing the opportuni‐ ties for others to create visibility for themselves. Internal visibility is not strictly zero‐sum, but it’s constrained by the attention of the folks you want to see your work.

My advice would be to use the promotion packet exercise to identify if the lack of visibility is likely to hold you back in the promotion process. If so, work to clear that threshold, but not much further. Visibility is a transient currency. Learning and developing yourself is a permanent one; focus on the latter once you’ve done the minimum to clear the former’s cliff.