Staff Engineer: Leadership Beyond the Management Track

by Will Larson

Technical interviews are an inconsistent and unreliable predictor of success, which is bad for the industry and bad for companies, but works in your favor if you’re set on attaining a Staff-plus role and are willing to conduct a broad search. Interviewing creates the opportunity to play “bias arbitrage,” finding a company that disproportionately values you. That might be a company that values folks with conference speaking visibility, your experience designing APIs, or your Ph.D. thesis on compilers.

If you’ve worked in tech hubs, at larger companies, and for more than ten years, then you almost certainly have mutual connections with the folks interviewing you.

That said, much like the interview process in general, references and backchannel reference checks are deeply random.

Well-run organizations value you for what you’re good at. Less well-run companies value you for your identity.

One that’s particularly important is understanding if the company’s leadership fundamentally subscribes to an exception-heavy “meritocratic” view of the world or a consistency-heavy “proceduralist” view.

This style is particularly common in Silicon Valley, is heavily exception-driven, and consolidates its efforts feting a small cadre of treasured individuals. Generally, in these companies, you’re going to be very successful if you pattern match with whatever they believe high potential looks like. You’re likely in for a rough ride if you don’t.

Companies with rigid compensation bands and who actually stick to them tend to be run by Proceduralists. Those that willingly eschew their bands are Meritocrats. Companies that create one-off roles for individuals to get them on board tend to be run by Meritocrats. Those that hire to their planned roles are Proceduralists. Companies with ad-hoc or unstructured interview processes looking to get your “feel,” particularly for senior roles, tend to be run by Meritocrats. More structure means Proceduralists. Companies that perform ad-hoc conjurations of new, rubric-less interviews tend to be run by Meritocrats. Those that evaluate you rigidly, even if they don’t let you shine, tend to be Proceduralists.

Sufficiently large companies end up with at least some folks operating in each of the archetypes, but it takes a long time until that’s the case, usually after their engineering organization has scaled to thousands of engineers.

The flying wedge pattern of one senior leader joining a company and then bringing on their previous coworkers is a well-known and justifiably-despised pattern that relies on this built-in referrer-as-sponsor, but it doesn’t have to be toxic if done sparingly.

This is also where having an external presence and network can greatly aid your search. Folks who’ve seen your presentations, read your blog posts, or nodded in agreement at your tweets are more likely to become your proactive sponsor in the interview process and later during promotion discussions.

Job searches for leadership roles are much slower than the typical software search, taking months rather than weeks, and trying to rush it rarely works out.

You’ll refresh your resume, work through Cracking the Coding Interview, and do some research on the company to prepare questions. When you go into the interview, you know it’s going to be five-ish interviews composed of a few programming exercises, something about technical architecture, and some cultural, behavioral, or career questions.

One line that many folks in Staff-plus roles draw is they’re unwilling to practice interview programming. This often means they are slower or make more mistakes in the sort of algorithmic questions that many companies use to evaluate early career candidates. Folks who don’t practice take that stance because they’ve decided that a company who cares about fast programming is likely to misuse its Staff-plus engineer.

It might feel like asking these questions could push the company to reconsider your candidacy, but it’s always reasonable to ask the recruiting team and hiring manager for more details about your interview process. At the Staff-plus level, it’s almost a point of concern if you don’t ask for more details. Companies want you to succeed, and understanding the process is an essential part of preparation.

Take notes about how you want to approach the different kinds of questions. Prepare materials for any presentation interviews. Briefly research the interviewers to tailor questions to their background.

Some companies advertise roles with level-specific titles, which lets you apply directly to the level you think is appropriate. If you’re hoping for a Senior engineer role, then apply for the Staff engineer job posting. However, many companies use those as provisional titles and finalize them later; other companies are quite rigid. The only way to know is to ask.

It may feel very unnatural to take more control over your interview process, and in theory, you might miss out on some opportunities this way, but that’s a good outcome: your goal is to find the best available leadership opportunity, not the first available opportunity.

Even if you skate through the interview process, always negotiate the details, and remember to finish well. Brief your references on the role’s details. Send follow-up emails to interviewers. Accept the offered sell chats and bring thoughtful questions into them. In this case, the last mile is the easiest as long as you take the time to walk it.

Our current approach is treating reviews of our documents like user testing: watching as individuals on teams read the documents, seeing where their cursor goes, what they’re reacting to, etc.

If two people asked the same question, we immediately added it to a FAQ that we kept.

When Stripe first introduced levels, I had been at the company for two and a half years and was leveled as an L2, a level that we expect a recent college graduate to reach in 6-18 months. I was honestly pretty disappointed, since my peers were already reaching “senior engineer” levels.

In fact, I’m pretty sure it’s the relationships I built during those first few years that made a canceled 1.5-year technical project not feel like too much of a setback to my career.

Breaking API changes are always to be expected as an API product expands and we learn more about how developers use them in practice.

If something was broken (whether it was technical or organizational), I felt unsettled and was deeply, intrinsically motivated to go learn about it and to fix it.

What are some resources (books, blogs, people, etc) you’ve learned from? I love reading fiction and I learn a lot about the world from great literature. I don’t like reading non-fiction business or technical books nearly as much. When it comes to learning about topics more directly relevant to my job, I treasure my peer relationships.

Often industry peers tend to make the case that titles don’t matter. But I disagree 100% with this statement; my personal experiences and observations across the companies that I’ve worked at have shown me otherwise.

Another key aspect of this project was a lot of visibility across the company.

Also, my manager and the team’s Principal Engineers were intentional about creating opportunities for me to present the work of the project team; I ended up presenting at an Engineering All Hands, a company–wide All Hands, and co–delivering a tech talk at an Engineering recruiting event.

Make sure to write … A LOT. When thinking through problems or ideas, write it down (even if you don’t intend to share them).

Were public speaking or public visibility important to reaching your current level? Yeah, I think it’s been a huge factor for my career development in general. I don’t think it’s necessary, but I think it can definitely be helpful, it’s been helpful for me.

Later the speaker networks led to job opportunities for me.

There was someone that was a strong advocate for hiring me specifically, and I’m sure that helped. They weren’t someone I’d directly worked with before, but they were familiar with my work.

You make a deliberate effort to have the conversations and build relationships. Also, my companies have been largely distributed. I can imagine it being more of a potential issue if being remote is the minority, or the company doesn’t fully embrace being distributed.

Chad Fowler, and his book The Passionate Programmer, is at top of that list. Dave Thomas is another one of those people whose workshops I used to go to when I was first learning Ruby and his book The Pragmatic Programmer is another great one.

This is not a meritocracy and your professional network is important. I’ve gotten jobs because I’ve applied on the company’s website like everybody else but I’ve also gotten jobs because I’ve awkwardly e-mailed a manager there that I haven’t talked to in years but that I respect and know that they respect me as an engineer.

Maybe at one point you’ll become the kind of engineer that when you announce on Twitter that you’re starting a new job, people who you’ve worked with before will create a calendar reminder for four years in the future when you’re fully vested so they they have the highest likelihood of poaching you, but until then, you’re going to have to write awkward e-mails to people that you would like to work with again.

I think you can progress early in your career by focusing on just writing better and better code but at some point you should probably shift to focusing on working better with other people.

If you haven’t already, try to become the engineer that people want to work with.

I didn’t realize, until I moved into the architect role, how much I relied on sprints and JIRA boards and the ritual of completing a ticket and moving it to the “done” column as a way to check in with myself and know that I am accomplishing the things that I need to accomplish.

One thing that has definitely been helpful is making sure that I’m keeping track of all of the different tasks I complete every day - logging meetings, emails, Slack discussions, etc.

I really enjoyed reading Camille Fournier’s The Manager’s Path.

There wasn’t anything I wasn’t able to do without the title, but the title did give me confidence.

Initially we thought it would take six months, and it ended up taking eighteen months. It took up most of the Desktop Client team’s resources for quite a while.

Early in my career, my instincts were to ask for projects that I felt I would be able to execute well on instead of projects with more ambiguity that would push me to grow. The advice I got was to push myself out of what I was comfortable with, and to ask for the hard projects on the team.

The way to have an effective relationship with your manager, including having them sponsor you, is to be super honest and open with them.

I read a lot, but my reading is very recreational. What’s been most impactful for me is having a lot of people who I think of as mentors, usually friends, former managers and folks that I’ve worked with. I have a decent number of recurring monthly lunches, coffee chats and dinners with people who’ve worked with me in the past, know me, and I trust.

I keep a list of people in my head of folks who are good at surfacing problems and giving feedback on approaches, and I reach out to them frequently.

I have to be careful not to get in the critical path of our actual product though, because I know I won’t have much bandwidth to maintain the code going forward.

When I got started, he asked me, “What do you want to do in five years? What are you aiming for?” At the time, I really didn’t have clear answers to those questions. For a long time my perspective has been that being able to write code, in our current time, puts you in one of the best positions in the history of humanity, in terms of job security and trajectory, and that seemed like enough for me.

When I’m involved with something that gets written up publicly or I give a public talk, then I’ll post a link on LinkedIn, but I don’t write my own content at all. I think about doing it, and I’m interested in doing it, but I don’t.