open calendars, take a look at your manager’s schedule and the number of 1: 1s they conduct a week. Is that a schedule that you would enjoy?
Foreword
but from around the “senior” level on (and arguably earlier), technical skills aren’t enough. Success will often mean interpreting business needs, communicating a clear direction, defusing a looming crisis, convincing teams to agree on tradeoffs, or just being a good influence. Engineering bookshelves don’t have a ton to say on these subjects. Instead, engineers read business or management books, picking out the topics that can apply to technical decision making, architecture, and so on, along with the techniques that can work without direct authority. For now, manager reading groups are often the best learning communities we have. (And, to be clear, we are grateful to be invited! Please keep inviting us, manager friends.)
Foreword
The lack of resources for senior engineers is part of a larger problem: it’s easy to lose track of what the job even is. Engineers promoted beyond “senior software engineer” can find themselves alone as they navigate an under-defined new role, grappling with the mysterious notion of “impact” to understand whether they’re working on the right things, and struggling to adjust to feedback loops that come in quarters or years instead of sprints. Overview
Over the past few years, we’ve seen a flurry of books unlocking the engineering management career path, like Camille Fournier’s The Manager’s Path, Julie Zhuo’s The Making of a Manager, Lara Hogan’s Resilient Management, and even my own An Elegant Puzzle. The engineering management career isn’t an easy one, but there are maps available to help navigate it.
Staff engineer archetypes
There is a toxic preconception that Architects design systems in isolation and then pass their designs to others to implement.
Companies that emphasize individual ownership 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.
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.
What do Staff engineers actually do?
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.
Tanya Reilly wrote a wonderful post, Being Glue, which captures another core element of successful Staff engineers: doing the needed, but often invisible, tasks to keep the team moving forward and shipping its work.
..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.
Does the title even matter?
While these gauges are believed to evaluate ideas objectively, their sheer informality becomes a broad vector of bias and often conflate confidence with competence.
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!
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.
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.
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. Operating at Staff
spend some time with Lara Hogan’s What Does Sponsorship Look Like?, and for being glue, spend time with Tanya Reilly’s piece that bore the phrase, Being Glue.
Work on what matters
I’ve taken to using the word “energized” over “impactful.” “Impactful” feels company-centric, and while that’s important, “energized” is more inwards-looking. Finding energizing work is what has kept me at Stripe for so long, pursuing impactful work. - Michelle Bu
If you’re in a well-run organization, at some point, you’re going to run out of things that are both high-impact and easy. This leaves you with a choice between shifting right to hard and high-impact or shifting down to easy and low-impact. The latter choice– easy and low-impact– is what Walk refers to as snacking.
In senior roles, you’re more likely to self-determine your work, and if you’re not deliberately tracking your work, it’s easy to catch yourself doing little to no high-impact work.
Preening is doing low-impact, high-visibility work. Many companies conflate high-visibility and high-impact so strongly that they can’t distinguish between preening and impact, which is why it’s not uncommon to see some companies’ senior-most engineers spend the majority of their time doing work that’s of dubious value, but that is frequently recognized in company meetings.
It’s surprisingly common for a new senior leader to join a company and immediately drive a strategy shift that fundamentally misunderstands the challenges at hand.
Folks often chase leadership’s top priority, but with so many folks looking to make their impact there, it’s often challenging to have a meaningful impact.
What are priorities that will become critical in the future, where you can do great work ahead of time? Where are areas that are doing ok but could be doing great with your support? Sometimes you’ll find work that’s worthy of attention but which an organization is incapable of paying attention to, usually because its leadership doesn’t value that work. In some companies, this is developer tooling work. In others, it’s inclusion work. In most companies, it’s glue work.
Teaching a company to value something it doesn’t care about is the hardest sort of work you can do, and it often fails, so you should do as little of it as you can, but no less.
It’s surprisingly common that coaching a teammate on how to tweak a project into something finishable and then lending them your privilege to budge the right friction points will transform a six-month slog into a two-week sprint with almost an identical impact.
Suppose you’re interviewing for a new role twenty years into your career. Will the folks interviewing you understand your real impact on any of your previous projects or companies? No, I guarantee they won’t. Instead, you’ll find yourself judged by a series of surprisingly subjective measures: your accumulated prestige, the titles you’ve had and companies you’ve worked at, your backchannel reputation, and how you present in your interview process.
Writing engineering strategy
To write an engineering strategy, write five design documents, and pull the similarities out. That’s your engineering strategy. To write an engineering vision, write five engineering strategies, and forecast their implications two years into the future.
If you can’t resist the urge to include your most brilliant ideas in the process, then you can include them in your prework. Write all of your best ideas in a giant document, delete it, and never mention any of them again. Now that those ideas are out of your head, your head is cleared for the work ahead.
A good design document describes a specific problem, surveys possible solutions, and explains the selected approach’s details.
If you’re stuck articulating the problem, show what you have to five people and ask them what’s missing: fresh eyes always see the truth.
Prefer minimal design document templates that allow authors to select the most useful sections and only insist on exhaustive details for the riskiest projects.
Particularly as you become more senior, it’s toxic to push every design to meet the bar of your own best work.
It takes a lot of practice to write great design documents. If you want to improve yours, my best advice is to reread your designs after you’ve finished implementing them and study the places where your implementation deviated from your plan– what caused those deviations? Oh, and of course, just keep writing more of them.
Write until you start to generalize, and then stop writing. If you can’t be specific, wait until you’ve written more design documents.
Managing technical quality
Still, like most narratives that move accountability towards the folks with the least power, it’s both unhelpful and wrong.
..hasn’t spent a career era advocating for better internal documentation), but I don’t trust my intuition like I once did.
However, as you look at how software changes over time, there are a small handful of places where extra investment preserves quality over time, both by preventing gross quality failures and reducing the cost of future quality investments. I call those quality leverage points, and the three most impactful points are interfaces, stateful systems, and data models.
As you identify these leverage points in your work, take the extra time to approach them deliberately. If it’s an interface, integrate half a dozen clients against the mocked implementation. If it’s a data model, represent half a dozen real scenarios. If it’s stateful, exercise the failure modes, check the consistency behaviors, and establish performance benchmarks resembling your production scenario.
Most misalignment comes from missing context, and these are the organizational leverage points to inject context into decision-making.
There’s no world where you write the vision document, and the org immediately aligns behind its brilliance. Much more likely is that it gathers dust until you invest in building support.
For example, you could measure the number of files changed in each pull request on the understanding that smaller pull requests are generally higher quality.
How many functions acquire low-granularity locks? How many hot files exist which are changed in more than half of pull requests? You’re welcome to disagree that some of these properties ought to exist in your codebase’s definition of quality: your definition should be specific to your codebase and your needs. The important thing is developing a precise, measurable definition.
Trust metrics over intuition. You should have a way to measure every project. Quality is a complex system, the sort of place where your intuition can easily deceive you.
Slow down to get these details right. Hide all the accidental complexity.
It’s a good sign when your team has more available high-impact work than you can take on: if you aren’t selective about which projects to take on, then you’re not thinking broadly enough. This means you shouldn’t necessarily try to grow your technical quality team if you have a backlog.
However, it’s essential that you provide the map to success! So many programs demand participation from other teams without providing clear directions on how they can accomplish their part. The program owner is the subject matter expert, don’t offload your strategy to every team to independently reinvent.
Do as much as you possibly can to avoid every team having to deeply understand the problem space you’re attempting to make progress in.
…both a scorecard for each team’s work and also provide breadcrumbs for each team on where to focus their next efforts. There are three distinct zoom-levels that your dashboard should support. The fully zoomed-out level helps you evaluate your program’s impact. The fully zoomed-in level helps an individual team understand their remaining work. A third level between the two helps organizational leaders hold their teams accountable (and supports your program sponsor in making concrete, specific asks to hold those leaders accountable).
Remember, attention is a scarce resource! If you waste folks’ time with a nudge email or ping, they won’t pay attention to the next one.
Stay aligned with authority
People need to be confident that I’ll always give the same answer that Matthew would give if he were there.
During 1:1s, dig for the feedback! Ask if there are other areas you should be focused on and how your current priorities align with your manager’s. If you continue to surprise each other, then identify the controls you’ll use to partner together.
Be clear that you’re not bringing them a problem to solve, rather conveying information you believe will be useful. Opinions are helpful, but even more helpful is data when you can find it.
Instead, I recommend sharpening your awareness of the distinctions between the values that you hold and those that the organization operates under and find a way to advocate for them without getting kicked out of the room.
To lead, you have to follow
First, leaders have a sufficiently refined view of how things ought to work such that they can rely on their distinction between how things are and how they ought to be to identify proactive, congruent actions to narrow that gap. Second, they care enough about the gap to actually attempt those narrowing actions.
But this sort of leadership can only take you so far, and personally, it took me years of blundering to understand why my approach to leadership created so much early success for me when first joining a company but slowly eroded how my contribution was received over time. The lesson that I slowly learned was that you couldn’t be an effective long-term leader until you learn how to follow.
Make your feedback explicitly non-blocking. This can be classifying a code review comment as an “optional nit,” but it can also be writing up detailed feedback but delivering it to someone mentioning that you wanted to share your perspective rather than necessarily change their approach.
Learn to never be wrong
who I’ve seen reliably disarm contentious discussions with his commitment to finding the best outcome for everyone, willingness to leave his starting position and the default assumption that there’s always an additional piece of context that reconciles seemingly conflicting perspectives into a unified view.
To get good at this, you need to master three approaches: listen through questions, define the purpose, and know how to read the room.
If you ever find yourself in a conversation with an unclear goal, then define the purpose.
In this case, a jerk is someone who withholds their consent from the group, isn’t willing to compromise, or doesn’t listen. This is someone who hasn’t learned that their career depends more on being easy to involve than being technically correct.
The two most effective ways to deal with jerks are: including someone they can’t be a jerk to in the meeting (like their manager or the CTO) investing heavily into aligning with them before the meeting, so they feel heard and are less likely to derail the discussion
Create space for others
long-term success as a Staff-plus engineer is that the organization around you increasingly benefits from, but doesn’t rely upon, your contributions. Because many folks reach their first Staff-plus role by being the “go-to” person for the organization, it can be a difficult transition from essential to adjacent.
There’s a well-worn model of genius encapsulated in the Feynman algorithm: “1) Write down a problem. 2) Think very hard. 3) Write down the solution.”
By writing down the process of finding an answer, as well as the rationale for the answer, folks around us can begin to learn from our decisions rather than simply being directed by them
Instead of involving them in your work, make the work theirs. This final step is sponsoring others for the kind of work that got you to a Staff-plus role. When critical work comes to you, your first question should become, “Who could be both successful with and grown by this work?” See if you can get them to lead the work, and then work with them to scaffold the project for their success.
ultimately sponsorship includes letting them take an approach that you wouldn’t. It might end up going poorly, and they’ll learn from that– just like you’ve learned from your mistakes over your career. It might end up going very well, and then you’ll learn something instead.
Present to executives
Everyone has worked with a terrible executive at some point in their career, but most executives aren’t awful. Almost all executives are outstanding at something; it’s just that often that something isn’t the topic you’re communicating about with them. When you combine that lack of familiarity with your domain with limited time for the topic at hand, communication is a challenge.
For example, some executives have an extraordinary talent for pattern matching. Their first instinct in any presentation is to ask a series of detailed, seemingly random questions until they can pattern match against their previous experience.
When you’re communicating with an executive, it’s almost always one of three things: planning, reporting on status, or resolving misalignment.
Go into the meeting to understand how you can align with their priorities. You’ll come across as strategic and probably leave with enough information to adapt your existing plan to work within the executive’s newly articulated focuses or constraints.
Controlling the sequence in which you present your ideas is the single most important act necessary to clear writing. The clearest sequence is always to give the summarizing idea before you give the individual ideas being summarized. I cannot emphasize this point too much.
There is no such thing as a permanent decision: almost every decision will be reconsidered multiple times over the next two years.
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.
Many companies believe they have a vested interest in pretending opportunity 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.
Promotion packets
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 supporting design documents What are the high-leverage ways you’ve improved the organization? What is the quantifiable impact of your projects? (Did you increase revenue by $ 10 million? Did you reduce year-on-year customer support tickets by 20%?) Who have you mentored and through what accomplishments? What glue work do you do for the organization? What’s the impact 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
Find your sponsor
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 Staff role.
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 asking 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.
These folks have a lot of people 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.
this works out the other way, with your new manager working hard to prove themselves to you by advocating on your behalf.)
Staff projects
This is a project that is considered complex and important enough that the person who completes 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 complete 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 success over a longer period without a single capstone or because they switched companies to reach the title.
The hard part was that the project stretched from the kernel all the way to the user interface. I had to understand every single layer of the Dropbox system. Initially, we thought it would take six months, and it ended up taking eighteen months.
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.
Get in the room, and stay there
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 calibration, 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.
…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 perspective that isn’t already present within the room.
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. Your sponsor needs to know you want to be there.
Your sponsor is probably in many different rooms and probably daydreams of leaving most of those meetings behind them. They won’t necessarily 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.
If you’re particularly aligned, they’re more likely to yield their own seat to you and stop attending.
Those sorts of discussions usually spend their time draining frustration rather than making forward progress. If you’re known as someone who can navigate difficult conversations effectively, you’re much more likely to be involved.
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.
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.
Being visible
One of the most effective ways to get luckier is to be more visible within your organization.
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.
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. Deciding to switch companies
There used to be a meme that many engineers spent either one or four years at each company to maximize their equity grants and then bounced on to the next.
On the other hand, if you’re considering leaving due to burnout or exhaustion, it’s sometimes possible to negotiate a paid or unpaid sabbatical where you can take a few months recharging yourself, often in conjunction with switching internal roles. This is more common at larger companies. (In case you were wondering, no, your coworkers taking parental leave are not “on sabbatical” or “on vacation.”)
There’s a fairly simple checklist to determine if this is a good option for you: Does your visa support this? Are you financially secure for at least a year without working? Do you work in a high-density job market remotely, or are you flexible on where your next job is? Do you interview well? Could you articulate a coherent narrative to someone asking you why you left without a job lined up? Are there folks who can provide positive references on your work? If all of those are true, I don’t know anyone who regrets taking a sabbatical.
Folks taking shorter stints have appreciated them but often come back only partially restored. If you do take a sabbatical, I highly recommend flushing out your experiences into writing. Even if you don’t share what you’ve written, it’ll help process the experiences.
Finding the right company
If career velocity is your aim, then join a company that, for whatever reason, disproportionately values what you’re good at.
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. Few companies exist exclusively at one end of this continuum, but most slant heavily in one direction. Of course, folks won’t describe themselves in these terms.
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.
The easiest sponsors to find are folks who you’ve worked with before.
Interviewing for Staff-plus roles
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. Is that a line you want to draw? Maybe, decide for yourself.
Negotiating your offer
Back in 2012, Patrick McKenzie wrote Salary Negotiation, which has since become the defacto guide to negotiating salaries for software engineers.
Michelle Bu - Payments Products Tech Lead at Stripe
I’ve taken to using the word “energized” over “impactful.” “Impactful” feels company-centric, and while that’s important, “energized” is more inwards-looking. Finding energizing work is what has kept me at Stripe for so long, pursuing impactful work.
When I worked directly on a team, I felt most energized when I was able to directly interact with users
One concrete example from recent memory is when another staff-plus engineer and I categorized the shapes of APIs we commonly see: labeling some as flows, some as engines, some as configs, etc. The intent of this work was to build up a shared mental model and vocabulary for categorizing existing APIs and for discussing and designing new ones. Folks started to organically use these categories after seeing them once!
One thing that’s taken some getting used to is that now folks expect me to have an opinion about whatever we’re discussing! That
This was the first time that I realized people looked to me to have an opinion and to support their ideas! I’ve been careful since then to always stay engaged during meetings and to give feedback, even if it is just to explicitly say that I haven’t fully formed any opinions yet.
To maintain context in my new role, I spend a good amount of time in one-on-ones with engineers and PMs working directly on execution. This week alone, I had 12 30-minute 1-1s. I also follow every incident that’s reported at Stripe. (We have a Slack group you can join to be automatically invited to Slack rooms for each incident!) The hum of incidents is particularly useful to tune into. By reading through the details of each incident, I’m able to estimate the distance between the reality of our systems and the idealized architecture / product that I spend my days thinking about.
I haven’t yet figured out a scalable way to bring everyone along. Even writing documents (the most scalable way of distributing information!) is hard because different teams are (by definition) coming at the interface from a different angle and so very different framings of the problem and solution will resonate with each team. 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. That’s worked pretty well so far!
We created a canonical document that defines our idealized abstractions. Even today, folks working on that team use these abstractions as a north star:
If two people asked the same question, we immediately added it to a FAQ that we kept. We took everyone’s feedback and questions very seriously and put the burden of proof on ourselves. Finally, we worked to be fully transparent in our work, even creating a decision log that anyone at the company could use to follow our progress. Each entry in the decision log concisely describes a product or technical decision, documents who was involved in the decision, and links to detailed supporting technical design documents that generally contain the full problem statement and evaluation of alternatives.
In retrospect, L2 was 100% fair based on the ladder. I worked hard and stayed late because I was naturally a bit slower than others in writing good code due to my lack of experience. I didn’t yet have a good foundation for software development, mostly because I just didn’t have enough practice yet! The impactful work I did was valuable, but also not something that I uniquely could have done. I was, at the time, solidly a high-performing L2.
Over time, I started having a reputation for caring deeply about our users and for being a fountain of knowledge about the product. (“ Users first” is still my favorite Stripe operating principle.)
two in particular that I worked on while I was a senior engineer might qualify as Staff projects: Stripe Radar and Stripe Elements. With Radar, we built a brand new product from scratch, making thoughtful tradeoffs about what to build and what we could safely descope in order to get something out to users as soon as possible.
In making sure new engineers could onboard onto a pretty complex product that involved a ton of IFRAME-shenanigans, I wrote a lot of documentation. I found that telling a story worked well for teaching folks why things needed to be the way they were:
Second, my manager was managing a relatively small team and was able to spend a lot of time keeping track of and understanding the details of what I was working on. If I’d been reporting to a manager supporting say, 10 + engineers, I likely would have had to put a lot more work into my own promotion packet.
Thinking back, a potentially-surprising important factor for me was (and is) my imposter syndrome. It made me extraordinarily open to feedback; to learning and growing and to taking responsibility for anything remotely related to my work. It made me proactively seek out feedback on everything from the validity of my comments on PRs to how I ran a particular meeting.
Ras Kasa Williams - Staff Engineer at Mailchimp
First was from my manager, Marc Hedlund. He told me to write my performance review in the third person. The idea being that you’re more likely to praise others, and be less critical, when giving them a review. It’s pretty simple, but has been super useful to me. Oddly enough, it’s played a part in helping me understand how to build a coherent narrative around the work I do and the value it provides to the business. Second was from Dan McKinely, one of the senior engineers on the “Staff project” I talked about. He provided direct feedback on my strengths and weaknesses when I asked for them.
Try to make your managers’ job easier. Don’t just bring them problems; also bring them (multiple if possible) recommendations / suggestions for solutions to that problem and ask for their feedback. This way, the manager doesn’t have to do all the work of solving the problem for you (they likely have enough on their plates) and they have an opportunity to draw from their experiences to help you rule in / out your suggestions. Funny enough, it’s probably much easier for someone to provide feedback on why your solution is bad than it is to come up with a fleshed out solution on their own.
The first is ”Delivering on an architecture strategy” from Pete Hodgson that presents a framework for achieving a sustainable balance between feature delivery and foundational architectural work. The second is “Stepping Stones not Milestones” from James Cowling which is about delivering real value with big architectural initiatives.
Keavy McMinn - Senior Principal Engineer at Fastly
One of the things that I’ve been advocating hard for in my current job is design documents for API changes. So before anybody writes any code, when the cost of making changes is low, they write down the user workflows and what would an interface look like that could enable those workflows. Sometimes it turns out that a seemingly simple thing is really difficult, particularly when the group isn’t used to flexing those muscles.
That makes it easy to question when folks think, “Oh, well, maybe we’ve just always done it this way.” It can be liberating not to be tied to the past.
Bert Fan - Senior Staff Engineer at Slack
gathering usage metrics around a particular user flow to better understand how to improve the system.
I acknowledge that most people don’t have that option but for me I thought it was important to work on things that I felt were meaningful - things that I personally used that I thought were having a positive impact on the world. And
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,
It’s kind of a running joke in engineering but a lot of people get into this profession because they don’t like talking to people but to be effective at your job as a Staff Engineer, you’re likely going to spend a lot of your time talking to people.
open calendars, take a look at your manager’s schedule and the number of 1: 1s they conduct a week. Is that a schedule that you would enjoy? The desire to write code isn’t black and white since there are tech lead manager positions where you write code and Staff-plus engineer roles where you never write a line of production code and spend the majority of your day in Google Docs or Dropbox Paper. But in my career, I’ve never had to lay someone off or deny them a promotion or write performance reviews - I know which side of the coin I’d rather be on.
Katie Sylor-Miller - Frontend Architect at Etsy
Web Performance is something that I think many companies either ignore or don’t focus on. When I started at Etsy, we had a great performance culture thanks to folks like Lara Hogan, but due to organizational changes a few years ago, we no longer had a web performance team, and I think that as an organization, we rested on our laurels and deprioritized web performance. Now, we’re bringing it back to the forefront because there have been a lot of changes in the industry around how “good” performance is defined and measured, particularly for SEO. Google is really pushing for web performance being a criteria that companies focus on as part of their search ranking.
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. Now that I don’t have that kind of team context to help me organize my day, I’ve had to rely much more on my own to-do lists and I’m still working to improve my systems for that.
These are all little things that in the moment don’t feel like much, but taken together show real impact.
So I personally think that frontend-leaning folks make great Staff Engineers, because they’re so used to constantly thinking about users and how users are going to interact with what they build. User empathy is a superpower that frontend people bring to the table.
Especially being a remote, I think that unless you’re proactive a lot of your work can go unnoticed because it happens over Slack, in pull requests or documents, and not out in the open where managers tend to operate. You’re always going to be your best advocate, but that’s even more true as a remote. You have to put a lot of effort into making sure your accomplishments are out there and they’re known.
Ritu Vincent - Staff Engineer at Dropbox
The incubator works directly with the CEO, and is a very small team. I’d been at Dropbox long enough that I built really close bonds with a lot of people here, so when folks pitched me this role it sounded really fun. I’d also been a manager for a couple of years and was getting a little itchy to code again. Putting those together led me back to Dropbox. There
Initially I was thinking, “I’ll break it into twenty pieces, assign out eighteen pieces, and keep the two hardest for myself,” and my manager pushed me to delegate the hard pieces to the team to stretch and develop them.
As a tech lead I spent a lot of time advocating for change. I would jump into a lot of different architecture and technical discussions, even in areas that weren’t directly within my area of expertise, because people seemed to trust my intuition. I know tons of engineers who have amazing technical intuition and don’t have the Staff Engineer title, but the title does formalize having that intuition.
In addition to the title, the other thing that gave me confidence was realizing that everyone else is also struggling with imposter syndrome.
One of the big factors for me was definitely visibility. Part of that came from doing so many things outside of normal engineering responsibilities.
Rick Boone - Strategic Advisor to Uber’s VP of Infrastructure
Specifically I like mentors who are constructively antagonistic. What I mean by that is that they throw me into things that utterly terrify me but they’re certain I’m ready for. They’ve helped push me way beyond what I thought was possible for me.
Nelson Elhage - Formerly Staff Engineer at Stripe
Certainly the one that’s easiest to trace the impact of was Sorbet, where in two years a three person team took Stripe from a dynamically typed code base to a substantially statically typed code base. That impacted all of the company’s six hundred engineers’ daily experience in their editors and development environment.
If I knew the organization had a goal of launching a specific product, I would have the perspective to see the reason why it would be hard is because of these previous architectural decisions, or that this downstream system wasn’t currently up to the task.
In the end you have to say, “There are all of these things that I wish I could work on, and I’m not going to do all of them. This year I’ll pick one or two to work on, and I’m going to deliberately ignore the other for a while, even though I think they’re major problems.”
Diana Pojar - Staff Data Engineer at Slack
Joining a newly-formed team at Slack was a unique opportunity that definitely contributed to reaching Staff Engineer. It gave me the opportunity to work on projects that had org or company wide impact. For example, the first big project I worked on moved about 25% of the load on the production MySQL database off to the Data Warehouse, saving the company millions of dollars. Another critical factor that influenced my path to become a Staff Engineer were the people around me, as I was lucky to have amazing role models and mentors in my team. When I joined Slack, I was the 4th person in a very senior team (everyone else was Senior Staff), which contributed to my desire to prove myself and show that I belong.
Dan Na - Staff Engineer and Team Lead at Squarespace
As a result I created a slack room— #connect-engineering— that uses a bot to randomly pair two people in engineering for coffee every two weeks. That room has been pairing people for coffee for over two years now.
Caring about more things is hard.
Every rung up the ladder means you care about another layer of abstraction, in addition to caring about all the layers beneath your current one.
My favorite engineering leadership book of all time is High Output Management by Andrew Grove. I pick it up from my bookshelf once a year and end up unintentionally re-reading it.
On the human side of leadership, I really loved Lara Hogan’s book: Resilient Management. I had the absurdly good fortune of starting my NYC tech career at Etsy in 2013 where Lara was my first engineering manager. Lara is a master of unpacking and addressing the hardest parts about navigating emotions and personalities, fostering psychological safety, and sponsoring coworkers.
Joy Ebertz - Senior Staff Software Engineer at Split
I’m still somewhat new, so I’m still working to define my role, which is part of the beauty of more senior roles. Today, I’m still ramping up, so I’m probably spending around half to three quarters of my time on tasks for my specific scrum team, just like any other engineer here. With the rest of my time, I’m participating in conversations and working with other engineers to define a lot of our longer term architecture and strategy,
a lot of my job is to keep an eye out for pitfalls I’ve seen before or larger patterns of problems.
As I pushed back, engineers around me also realized that they could push back. At first Product mostly opted to not add more notifications, but eventually they decided to fix the system. In this case, it was mostly a matter of explaining to them the risks of the system and sticking to what I thought was the right course of action in terms of keeping our systems running.
Our managers also submit their recommendation and the two go to a promotion committee made up of managers and ICs (at least one level above the level we’re applying to). They review the case, call in the manager to answer any questions and then make a recommendation. Our VP was able to change any of the decisions (although to my knowledge this never happened). If the answer was no, feedback was given as to why and you could repeal the decision with additional information or try again the following time. Appeals did sometimes go through, so if you disagreed with the feedback, it was worth trying.
all of the cases are going to be very positive. No one says anything negative when they go up for promotion. So instead of looking for negative things, that committee is going to be looking for what isn’t said.
I had a manager who every time I came to him with a problem, he would always turn it around on me and ask me what I thought I should do. This got to the point where I could hear him telling me to give feedback to someone directly or telling me to figure out how to fix something without me ever having to talk to him. He really taught me that while, as a manager, he was willing to support me, I would learn the most and be the best version of myself if I could do it on my own. He taught me to take responsibility for everything.
Damian Schenkelman - Principal Engineer at Auth0
Design and Architecture workgroup (a.k.a. DNA).
Dmitry Petrashko - Tech Advisor to the Head of Infra at Stripe
We choose enginers for PTL position that are good at representing opinions of others. Even before I became a PTL I felt that prior PTL, Paul Tarjan, always made sure my perspective was presented.
Mentorship is about helping people grow and deliver impact. Sponsorship is about helping a person get in a position where they could demonstrate their ability to deliver greater impact.
A technique that helped me in that was asking for feedback in a private chat immediately after the meeting, in particular after meetings that didn’t not go perfectly.
Location: I came to the US from Switzerland to join Stripe. I came to Switzerland from Russia to join one of the best PhD programs in Computer Science. I came to Russia to join one of the best ex-USSR universities from Ukraine. In each of these relocations, I feel, I played geographical arbitrage: I was looking to escape the place where I was among the best to the place where I’d be average.
All of these played to our strong points: I had prior experience with type checkers (this is what my PhD was about), Paul has a huge skill for programmatic codemods and Nelson is both very knowledgeable in systems in general and has been at Stripe long enough and early enough to know pretty much every system at Stripe.
Stephen Wan - Staff Engineer at Samsara
Over time, teams would narrow in scope and only be able to see a smaller part of the puzzle. Having a big part of the engineering history in my head not only helped me connect pieces across those divisions, but also gave me a headstart on keeping personal connections over to parts of the organization I stopped working with directly. That breadth naturally lent itself to being able to figure out what could be most impactful for the org.
He notes, “I could only write in simple, short [English] sentences. Which meant that, however complex and numerous the thoughts running around my head, I couldn’t even attempt to set them down as they came. The language had to be simple, my ideas expressed in an easy-to-understand way.” Writing software is a totally different domain, but it feels like the sentiment fits into some tenet that I really value about communicating: having an understanding in your head is half the battle - being able to express that understanding is just as hard and valuable.