Stories

It didn’t take me long to realize after publishing my first book that I wasn’t the sort of person who enjoyed reading reviews of my work. At best, I felt good about myself for a moment, but often I just felt sad. During that window when I was still reading reviews, and I read one commenting that it was too Silicon Valley‐centric for most folks to ben‐ efit.

That line stuck with me as I started to brainstorm what eventually be‐ came this book, and I wanted to avoid centering my own experiences to the exclusion of all others. Even more importantly, it’s clear to me that my career is built on a particular set of perspectives, luck, and privilege, and I wanted this book to be a useful guide for folks who experience the industry differently.

All of that is to say that the best parts of this book rest heavily on the candid and insightful interviews from industry practitioners, and I’m grateful to be able to include those interviews in this final, following chapter. Even if you didn’t get much from the book thus far, I hope you’ll find something unique in these career stories.

Michelle Bu - Payments Products Tech Lead at Stripe

April, 2020 blog, twitter, linkedin

Tell us a little about your current role at Stripe: what’s your title and generally the sort of work do you and your team do?

I’m the Payments Products Tech Lead at Stripe, working directly with our Chief Product Officer. I support critical initiatives and work on mitigating urgent problems across the organization. I typically spend 80% of my time on one or two large cross‐organizational design projects. I spend the remaining 20% reviewing and supporting technical and product design (in particular, API design) across the organization.

Sample of a “top 3” document I keep evergreen:

I manage two engineers who embed into high priority areas. This both helps me scale my impact and also gives these engineers the chance to dip into many areas of Stripe. Right now, one is working on the core payments APIs and the other is focused on improving integration experience. I’m still evaluated on the IC ladder—the plan is to never have more than a few reports at a time.

What does a “normal” Staff‐plus Engineer do at your company? Does your role look that way or does it differ?

Most engineers in Staff‐plus roles at Stripe work on specific teams. There are some Staff‐plus Engineers who also have a Tech Lead title, and take on broader projects across a particular product area or technical domain.

There are two kinds of Staff‐plus Engineers at Stripe: those whose scope is deep and those whose scope is broad.

Broad‐scoped engineers create impact by working on vague, cross‐ organizational projects. They tend to accumulate a lot of context across many different domains and play a support role in many projects across the org. This shape of Staff‐plus Engineer is most common on our product engineering teams.

Deep‐scoped engineers tend to be subject‐matter experts in a specific domain. They lead ambitious multi‐year projects. This shape of Staff‐ plus Engineer can generally be found on our product infrastructure and systems teams.

Where do you feel most impactful as a Staff‐plus Engineer?

This has changed over time for me as I’ve moved into my current Pay‐ ment Products Tech Lead role. (For some context, Payments Products is made up of over 20 teams. We’re responsible for most of our user‐ facing APIs and UI libraries.)

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, whether it was helping users on the #stripe IRC channel or designing and shipping an API that users can integrate seamlessly.

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

One concrete example from recent memory is when another staff‐plus engineer and I categorized the shapes of APIs we commonly see: label‐ ing 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! It’s in these moments that I feel like I’m creating leverage and scaling my own impact by disseminating useful mental models and ideas.

I spend time on several of our review forums like API Review, but often these sorts of forums work more like code review. They happen so late in the design process that they tend to do a better job of preventing bad outcomes than of partnering with teams to steer great outcomes. I feel more impactful when I’m able to give engineers on product teams the tools to design great APIs.

Canyouthinkofanythingyou’vedoneasaStaff‐plusEngineerthatyou weren’t able to do or wouldn’t have done before reaching that title?

I’ve been at Stripe for a long time (since 2013!). While I’ve always had some amount of clout because of my tenure, my role of Payment Prod‐ ucts Tech Lead (and the fact that I report directly to the CPO) has def‐ initely changed how people interact with me. I’m definitely feeling lonelier at work now (and am actively working on adapting to this new normal).

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 didn’t happen as often when I was a staff‐level engineer working directly on a team. I remember being in a meeting shortly after my role change where I was a bit quieter than usual because I was a little tired. I later heard that the presenters were worried that I hadn’t liked their pro‐ posal because I didn’t say anything. This was the first time that I real‐ ized 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.

It’s a bit disorienting that some folks take my opinions more seriously and are nicer to me than when I wasn’t in such a visible role. Previ‐ ously, there were cases where people weren’t collaborative or would dismiss my opinions. I think it was a good thing to have experienced that. I was confident enough (and trusted enough by the organization) to give them strong feedback on their collaboration so that I could en‐ sure things like this weren’t happening to others like me. I now worry that I’m losing visibility into where these interactions are happening.

How do you maintain empathy for other engineers’ development expe‐ riences as you spend less time programming?

I’ve only had one year in my new role, so I don’t feel too disconnected yet. Maybe this is something that will change over time. I was previ‐ ously tech lead for a smaller area. In that role, I wrote a small amount of software and contributed to some of my teams’ “run rotations,” where we triaged incoming requests and fixed urgent bugs.

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 want to know the shapes of issues that engineers are running into, the pits of failure they’re falling into, and how the developer environment was or wasn’t supporting them in getting out of those pits. I see myself as an advocate of engineers to leadership, so it’s important for me to deeply understand our present reality.

Do you spend time advocating for technology, process or architectural change?

At this point I spend less time advocating for specific technologies or programs and more time empowering others to advocate for the tech‐ nologies and programs that they think are important. I also try to be a source of knowledge and support that people can reach out to for feedback, especially on cross‐cutting product decisions and on presen‐ tation of ideas to the rest of the organization.

I do work on projects where I’m explicitly thinking about idealized ar‐ chitecture and interfaces. However, at the end of the day, migration to any idealized state is going to be done by individual teams, so they need to feel a sense of ownership and empowerment. I spend a lot of time having direct conversations with the engineers and PMs who are actually making day‐to‐day decisions. The ideal outcome is that we’re able to get directionally aligned, and they’re then able to advocate for our north star within their teams and make good local decisions.

It’s a lot harder to do this for the project I’m working on right now because it involves defining the idealized architecture and interfaces for many, many teams—essentially every team working in payments! I haven’t yet figured out a scalable way to bring everyone along. Even writing documents (the most scalable way of distributing informa‐ tion!) 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!

Designing the Payment Intents API, a rethinking of our beloved Charges API for the changing payments space, was a similarly cross‐ cutting project that I worked on previously. It took two years for the vision to fully land with everyone in the company. Even with that organizational buy‐in, we still haven’t realized the full potential of its original idealized design. This is not a bug, though! We focused on delivering incremental value to users while proving out the design. I expect any sufficiently‐ambitious design project to continue even when I am no longer on the team. An important part of making this work was writing everything down.

We created a canonical document that defines our idealized abstrac‐ tions. 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 se‐ riously 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 general, I’ve found that for ambitious design projects, being extremely transparent but also explicit about whether or not you’re ready for feedback has landed well with folks who care about the topic. Here’s some wording you can find at the top of the (public) notes docs for some projects I’ve led:

Is sponsoring other engineers an important aspect of your role?

Yes, and it’s one of my favorite parts of the role! I care a lot about the people I work with—they’re the main reason I feel energized to go to work.

A big part of sponsorship for me is creating the space for ICs to do the impactful work that they care about. I’m lucky that in my current role I don’t have to spend time actively proving that I’m competent, so I can spend a good chunk of time in support roles for projects and el‐ evating others. I rarely feel like I have to “claim credit” for work or have my name explicitly mentioned on a byline for a project I helped with (though it’s always a nice feeling when it happens). For more open‐ended projects, it’s sometimes useful for me to lend my name to the project. For example, I recently kicked off a product quality mentorship program where I play more of a facilitator role, selecting mentees, pairing them with mentors, and occasionally reviewing their work. I’m not doing nearly as much as the mentors in the program are, but we were able to get this org‐wide program off the ground because I sponsored it.

Day to day, I find that I can be helpful as a “rubber duck” for folks who want advice on how to navigate a complex project or resolve a tech‐ nical disagreement. I find this work—helping others make progress without getting directly involved—particularly rewarding.

Finally, I always keep in mind a list of folks who are amazing at what they do and advocate for them as visible opportunities that align with their interests become available. There’s a balance here, though. I’ve learned that it’s sometimes difficult for folks to say no to me. Recently, I asked an engineer on a team I work with to send an email about some good work she had done. She told me after she sent the email that she originally didn’t want to do it, but she also didn’t want to say no to me. She then showed me the relevant entry in her “no log”:

Stripe is the first company you’ve worked full time at, and you’re still at Stripe. What was your path to the Staff level?

I joined Stripe right out of college. I actually had a slower growth curve when I joined than the other engineers in my cohort. My trajectory over my first four years was slow compared to other ambitious new college graduates. I think this was partially because I hadn’t been cod‐ ing for that long (I took my first programming class in 2011 and joined Stripe in 2013), and partially because my first large project at Stripe was a 1.5‐year rewrite project that was ultimately canceled.

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 disap‐ pointed, since my peers were already reaching “senior engineer” lev‐ els. At that point I’d already done a lot of impactful work, spun up most of the new product engineers who joined, and consistently jumped in to help during incidents. I worked so hard and on so many impactful things, even outside of my main projects! What else would they want me to do? Should I not help others out?

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 foun‐ dation 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.

In those early days, I spent a lot more time learning about the prod‐ uct and about the payments domain than I did writing code. I spent a lot of time helping our users (developers) with their integrations on IRC. I did smaller tasks (bug fixes, small features, bandages to paper cuts) that weren’t technically challenging but were important to those users. This sort of work doesn’t always map to growing as an engi‐ neer (though I did fine‐tune my debugging skills—I’m a pretty great debugger now). I also built up relationships with other teams and other engineers by being overly helpful on Slack and on tickets and by helping teams navigate to the best solutions for our users. I helped spin up most of the new product engineers that joined in my first two years. 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.)

Later on I realized that during that time, while I wasn’t efficiently map‐ ping towards growing on the technical side of being a software engi‐ neer, I was actually learning critical skills that allowed me to move very quickly from senior to Staff, and from Staff to my current role (to‐ gether, this only took 3 years!). In fact, I’m pretty sure it’s the relation‐ ships 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.

I slowly and deliberately built out my technical foundation when I worked on the first versions of Stripe Radar and Stripe Elements. I strongly believe that long as I’m being thoughtful about my technical gaps, about filling in those gaps for the projects I’m working on, and about challenging myself with projects that take me outside of my tech‐ nical comfort zone, I can build up and practice my technical skills or‐ ganically. The softer skills, the connections across the company, the user focus, understanding the product deeply—these are the skills that took much longer to learn and ultimately helped me accelerate my path to Staff after I built my technical foundation.

Did you have a Staff Project?

I’ve worked very broadly on just about every component of Stripe’s product. Over time, the projects that I’ve worked on have generally spun off into their own dedicated teams, and 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. When we launched in October 2016, it was one of the smoothest product launches we’d ever had. It’s since become a very successful product.

With Stripe Elements, I built out the infrastructure, designed the ini‐ tial Card Elements API from scratch, and shipped to production in un‐ der 3 months. This was only possible because we did extensive dog‐ fooding. While building Elements, I created three tiny e‐commerce stores with different design frameworks and designs (of varying qual‐ ity) to test the limits of its customization APIs. Since then, dozens of engineers have successfully developed in the codebase, it’s the home of the new Stripe Checkout, and most importantly, we’ve had very few regrets about its original API design. Breaking API changes are always to be expected as an API product expands and we learn more about how developers use them in practice. We did a good job validating our initial API design to avoid these breaking changes while still shipping rapidly.

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:

Looking back now, the product architecture has generally held up since launch for both projects. At the time, in addition to implement‐ ing these products, I had to wait for a while after they launched for the product choices to prove themselves out with our users and for the technical choices to prove themselves out with engineers internally as they ramped up.

I think that’s an important criteria for Staff‐plus Engineers in product:

not to just build something that ships, but for it to roll out smoothly and continue to succeed and grow over time with as few regrettable choices as possible. There will always be corners cut and features de‐ scoped during product development, especially for new products. A Staff product engineer makes those product and technical choices de‐ liberately, taking on various different user personas to make the best choice possible and documenting rough edges thoroughly for future engineers.

Did you have to put together a promotion packet?

When I was promoted to Staff, I was fortunate to have a manager who was extremely engaged in supporting my promotion. To be honest, at the time I didn’t really understand how to write my self‐reviews the right way. I wrote self‐reflective development plans for what I wanted to learn over the next year instead of documenting the impact and scope of my work. My manager actually did most of the work by writ‐ ing out my impact in his review.

There were a couple of other things that helped me. First, I worked with the same manager for much of that time. If you change managers then your manager loses context and that pushes the work of creating continuity onto you. Second, my manager was managing a relatively small team and was able to spend a lot of time keeping track of and un‐ derstanding 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.

What two or three factors were most important for you to reach the Staff level?

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 any‐ thing 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. If something was broken (whether it was technical or organizational), I felt unsettled and was deeply, intrin‐ sically motivated to go learn about it and to fix it. No part of Stripe’s product was “not my problem.” This developed into two superpowers that are perhaps even more important to have as a Staff‐plus Engineer than technical superpowers are:

1. Truly listening to and empathizing with others.

2. A deep care for solving all types of problems.

Of course, imposter syndrome is a double‐edged sword. It often makes me scared and self‐conscious—early on I constantly felt like I would get fired for not being fast or effective enough. I grew more secure about my own strengths over time, but to be frank, this took a lot of time and positive reinforcement from my managers and from leaders at the company.

Is it harder to reach Staff‐plus roles when working in product engineer‐ ing rather than in infrastructure engineering?

I do think that is the case. I also think it’s a bit easier at Stripe, where the core product is infrastructure. This means there are many oppor‐ tunities within product engineering to work on projects that need to consider scale, robustness, migration path, and well‐designed inter‐ faces.

It can definitely be tricky to reach Staff if you’re on a team that mostly builds UI, because UI products are by nature more temporary and al‐ low for more iteration and experimentation. To reach the Staff level of impact as an engineer on a UI team, you need to be able to create lever‐ age. You could do this by building well‐designed component libraries, experimentation frameworks, etc.

Another aspect of building leverage as a product engineer is creating processes and systems to manage “product debt.” Folks often talk about “technical debt,” but equally important is the “product debt” caused by supporting old versions of your product, and much of the difficulty of product engineering at scale is related to managing product debt and product drift (that is, products that need to inter‐ operate with each other moving in different directions) over time. I believe that a company’s accumulation of product debt does create Staff‐complexity roles within product engineering at a certain scale.

Can you remember any piece of advice on reaching Staff that was par‐ ticularly helpful for you?

I haven’t gotten much generically useful advice. There was good situation‐specific advice that I got along the way, but those pieces of advice are always tied to the situations at hand.

The most useful general learning for me was becoming comfortable with uncertainty. Sustained success in senior roles depends on your ability to adapt and grow as the needs of the organization change.

Advice for someone who wants to become a Staff‐plus Engineer?

Some caveats:

• I think I’ve been particularly lucky with the managers I’ve had.

• My interests have always been aligned with what was most im‐ portant for the company. (At this point it’s a bit unclear to me if my personal interests (i.e., developer products, mentorship) were aligned, or if over time I’d aligned myself to what was im‐ portant for the company. I feel like it’s the former, but in either case, I feel like I’ve always been really interested in my work.)

I’m probably one of the most visible product engineers at the com‐ pany, so engineers will sometimes see what I’m doing and try to pat‐ tern match on that to become a Staff‐plus Engineer. That feels great, and I’m lucky to be able to be a role model for others like me.

That said, my first piece of advice to engineers is that they should avoid pattern matching in ways that lead them towards work they don’t enjoy. I’m deeply energized by the work I do, partnering with teams to solve abstract modeling and design problems. It takes a certain amount of fortitude to try again and again after many rounds of feedback, and to be honest, it’s not for everyone. If you’re more focused on hitting Staff than on setting yourself up to do work that energizes you, it’s easy to end up stuck in a role you don’t want. Being a Staff‐plus Engineer, especially a broad‐scoped Staff‐plus Engineer, is a very different job than being a Senior Engineer.

Instead, pursue work that you find energizing, even if on paper it doesn’t seem like it’d get you to a Staff‐plus. A big component of being successful as a Staff‐plus Engineer is being able to identify and scope net‐new impactful work and to convince others of its value and impact. If the work you’re doing energizes you, it’s actually much easier to achieve this because you’ll enjoy thinking deeply about your work a lot more!

What about advice for someone who has just started as a Staff‐plus En‐ gineer?

Your job as a Staff‐plus Engineer is specific to your team and orga‐ nization, and it’s important to avoid taking advice that doesn’t apply to your situation. For example, when I moved into my current role, many of the other Staff‐plus Engineers were focused on writing per‐ sonal charters describing what they want to accomplish over the next 1‐2 years. That approach likely works well for deep‐scoped engineers, but it hasn’t been as helpful for me as a broad‐scoped engineer who needs to respond quickly to organizational changes and shifts to prod‐ uct strategy.

Did you ever consider engineering management?

I do manage two engineers right now. That said, I don’t do a lot of the things that a traditional manager would do. I’m not involved in recruiting like a hiring manager would be, and I don’t experience the same sort of performance management situations that other managers would because the engineers who are selected for my team are already high performers.

I care a LOT about Stripe: when I see something out of place I feel antsy and want to fix it. In some organizations I think that could have led me towards engineering management rather than my current role, and I’m grateful that management wasn’t the only path that was available to me. My strengths and interests lie in product engineering and API design and execution, and I’m able to use these strengths every day in my role.

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 lit‐ erature. 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. My peers give me valuable in‐the‐moment feedback and help me tease out the answers that were in my head all along.

Stripe also has a program called “Leadership In Practice” which is taken by all managers and some senior engineers. That program included a class on adaptive leadership which was particularly helpful. I’ve since applied the frameworks I learned to many situations.

I’ve never been a person who looks to a single mentor for advice. In‐ stead, I follow what I used to call a “Frankenstein,” build‐your‐own‐ mentor approach, similar to what Lara Hogan wrote about in her post on building a manager voltron. Programs that match me up with a sin‐ gle mentor have never quite felt natural to me. I tend to be intentional about the particular topic or area I want to grow in, and will gravitate towards individuals who excel in that area, even if they’re not my “of‐ ficial” mentor.

I spend most of my time on hard, specific questions that don’t have an easy, generic answer. Figuring out the right approach requires a lot of situational context that someone outside the situation won’t have much insight into.

Some non‐fiction that I’ve read recently and enjoyed:

• Draft No. 4, John McPhee: I spend most of my time writing at work, and experience writer’s block quite a bit. But it’s super important to power through that, because a good piece of writ‐ ten communication is the most effective means of broadcasting ideas and scaling yourself.

• Creativity Inc., Ed Catmull: The tone of this book definitely made me raise my eyebrows, but there’s a LOT to learn here about how to foster a creative working environment at scale. This is something I think about a lot as we grow our product organization and our product engineering function.

• Impro, Keith Johnstone: I see my superpower (especially as the company grows) as being able to learn and adapt quickly, so I love reading books about different forms of learning and teach‐ ing. This book is about learning how to act / improvise, and pushes on conventional metaphors and narratives about educa‐ tion.

Ras Kasa Williams - Staff Engineer at Mailchimp

July, 2020 linkedin

Tell us a little about your current role: where do you work, your title and generally the sort of work do you and your team do.

I’m a Staff Engineer at Mailchimp, working in the Data Services engi‐ neering group. Data Services can be seen as the home of data engi‐ neering within the company. Our group builds systems that primarily support our data science and analyst teams (i.e. product analysts, fi‐ nance analysts, marketing analysts, etc.).

I have been serving as one of the tech leads in this group where I fo‐ cused on building scalable data processing pipelines that power our internal analytics platform and supporting the advancement of criti‐ cal business intelligence initiatives. I have been performing a signifi‐ cant portion of the Eng Manager responsibilities for the team as well (although I wasn’t formally the Eng Manager). After almost 2 years in this role, I am actively transitioning it to another engineer.

What does a “normal” Staff‐plus engineer do at your company? Does your role look that way or does it differ?

At Mailchimp, once you become a Staff Engineer, you’re a member of “Engineering Leadership”. Since a formal engineering ladder was im‐ plemented only a couple years ago, the answer to “What does it mean to be a Staff Engineer?” or “What does it mean to be a member of Engineering Leadership?” will likely vary.

In my view, it’s about thinking globally. That means partnering with other members of that cohort to understand the company–wide busi‐ ness / product strategy and distill that into an Engineering–wide tech‐ nical strategy that seeks to enable execution for Product, Marketing, and our peers across other functions. That means partnering to im‐ prove on processes like hiring, onboarding, cross–team communica‐ tion, and production operations. That means partnering to grow the entire department’s technical and social skills.

It’s about taking that global thinking and applying it locally. That means aligning your team’s (technical) initiatives / roadmaps to the Engineering–wide technical strategy; and being intentional about when you veer off of that path to serve the needs of your team’s immediate stakeholders. That means collaborating with your team’s managers in adopting successful practices in hiring, onboarding, and production operations from other teams; and sharing practices from your team that would be beneficial for others. That means taking context from company–wide business / product strategy and translating that to how it impacts your team’s immediate projects. That means being intentional about creating opportunities for your team’s individual contributors to grow their skills, get visibility, and access to others across the company.

Of course, I don’t get it right all the time. But it’s been a successful mode of operation for me.

How do you spend your time day‐to‐day?

As mentioned before, I have been serving as one of the tech leads in Data Services (and performing a lot of the Eng Manager responsibili‐ ties).

As tech lead, I was responsible for defining, and accountable for execu‐ tion of, my team’s technical strategy and approach. I worked to under‐ pin this strategy in its value to our internal customers (or the business) and effectively communicate that across the company when needed. A couple of times a year I reflected on what progress was made, and if anything had changed within the business that required adjustments to this strategy. I still contributed code regularly—certainly less than the rest of the engineers on my team; but it was important that I sus‐ tained “hand to keyboard” work to ensure that my technical strategy

(and other macro–level decision–making) was informed by the on– the–ground experiences of the rest of my team. A focus for me was growing and developing the other engineers on the team as a result of the technical direction I set. More concretely: I worked to help my teammates (via mentoring or coaching) understand how to approach technical decision–making and how it should be underpinned by the customer / business problem it’s solving and the value it’s providing; I worked to help them understand how to drive engineering projects from problem statement to production release / long–term operations; I worked to help them understand the proper communication prac‐ tices for different audiences (i.e. engineering peers, vs. engineering management, vs. non–technical stakeholders, etc.). In aggregate, I worked to help them get to a level of self–sufficiency where they can operate and communicate in a way that aligns with my technical strat‐ egy, direction, and approach without me having to be in the room or in the conversation.

Our group doesn’t have product managers. But those needs around things like understanding internal customer needs and stakeholder management still exist. The recently hired Eng Manager for my team is accountable for this; but we shared a lot of the responsibility here. I did a fair amount of chatting with internal customers, answering quick one–off questions, understanding needs for new pieces of work (i.e. new datasets), recommending paths forward, setting expectations around when we’d be able to execute on the new piece of work, etc.

Our group doesn’t have project managers either. But, again, those needs exist. I believe in empowering each team member to own the project management responsibilities for their assigned project (i.e. sta‐ tus updates to stakeholders, etc.). I did a fair amount of coaching on project management tactics like proactively communicating risks / blockers so that I can help unblock them and how to continuously deliver incremental value to maintain momentum.

I spent a good amount of time building passive internal customer and business context. I’d occasionally read merged pull requests for repos that I didn’t maintain; I’d read tech specs and proposals that are shared publicly; I’d occasionally attend various internal presentations from the data science and analyst teams where they presented projects they completed or ideas they’re exploring. All of these are small tactics, but they aided in my situational awareness and was one key input into my team’s quarterly planning activities.

As a tech lead, I was a member of the Eng Tech Lead Cohort. It’s a formal group of all of the tech leads across the Engineering depart‐ ment meant to share context, talk through ideas, and help advance the Engineering–wide technical roadmap. There’s some ad hoc conver‐ sations and work that may come out of this group from time to time. There’s also a recurring call for all Staff, Senior Staff, and Principal Engineers meant as a space to surface and discuss problems, assign owners and actions items when needed, and generally build commu‐ nity with each other. We have a close partnership with Google; they serve as our cloud provider. Occasionally, I’d spend time talking with our assigned partner team about challenges we’re running into, plans we have, proper approaches to solutions, formal training that would be helpful, etc.

As I’m transitioning out of the tech lead role, there will definitely be a change in how I spend my time day–to–day. But I’m honestly not sure what that will look like.

Where do you feel most impactful as a Staff‐plus Engineer?

It’s always a rewarding feeling if I can end the work day and feel like I’ve helped my peers get unblocked and maintain momentum.

That can mean helping one of my Data Services team members think through options for solving a complex technical problem and trade–offs like providing immediate value versus being sustainable long–term. Or helping them think through how to deeply investigate a new technology and if it can be applicable to solving one of our top 3 problems.

That can mean helping a peer on another team think through their de‐ liverables over the past quarter, whether those deliverables provided real business / customer value, and how to build a narrative around that impact to make the case for promotion.

That can mean identifying that a short–term piece of “org work” is at a standstill because consensus wasn’t achieved, encouraging an in‐ volved peer to take ownership of making a decision (with proper feed‐ back from interested parties), and drive it to completion.

This is a feeling I’ve always felt throughout my career; I enjoy the suc‐ cess of my peers as much as I do my own. But taking on the tech lead role certainly elevated the importance of doing it. It morphed from something I just liked doing, to something that I liked and was also important for the health of the team I was responsible for.

Can you think of anything you’ve done as a Staff‐plus engineer that you weren’t able to or wouldn’t have done before reaching that title?

As mentioned before, once you become a Staff Engineer at Mailchimp, you’re a member of Eng Leadership.

It’s noticeable that Staff+ Engineers generally have more agency and ownership of their time. They encounter less resistance when they make time for work outside of their primary responsibilities. This has certainly been my personal experience.

I’ve also had a lot more organic opportunities to coach, mentor, and generally support more peers outside my team. It was something I was certainly doing before being promoted to Staff Engineer; but it noticeably increased. It’s definitely a rewarding part of my work day, so I welcome it.

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

There is a popular idea that becoming a Staff Engineer requires com‐ pleting a “Staff Project.” Did you have a Staff Project, and if so what was it?

In some sense, I guess.

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

A key aspect of this project was beingeffectiveand executingata 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 in‐ stalled as a tech lead to help continue shepherding that project work as it was absorbed into my current engineering group, Data Services.

Another key aspect of this project was a lot of visibility across the company. The project team’s work was categorized as a company– level initiative. This meant a lot of executive–level visibility; and, of course, the associated pressures of that. But the overall project team was able to sustain good momentum throughout and ultimately succeed in building out an initial iteration of the analytics plat‐ form. 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. Because of the visibility of the project and general culture at Mailchimp, I was able to collaborate with engineers at all levels in the company and engage with analysts from other departments in a very short time after joining—which is something most folks take a year or so to have the opportunity to do.

So, it was a combination of doing good work and being really effective alongside more senior engineers; and those senior engineers (and oth‐ ers) being intentional about giving me visibility and access across the company even though they were the technical leaders on the project. Important note: The promotion didn’t come until I had also served some meaningful time as tech lead and delivered a lot of value there. But this project was definitely the firestarter.

Can you remember any piece of advice on reaching Staff that was par‐ ticularly helpful for you?

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. He noted that my strength around building relationships across the company is an important skill to have since the people / social aspects of engineering don’t go away; in fact, they are key to getting anything done.

Third was from Coda Hale, the other senior engineer on the “Staff project” I talked about. He talked about scaling your impact. Specifi‐ cally:

first, effectively setting technical direction for other engineers; second, mentoring them and developing their talent as a conse‐ quence of the work you’re structuring for them.

This advice is core to how I think about my role as tech lead; like, really being intentional about creating opportunities for the team to extend, flex their skills, and learn a lot.

What about a piece of advice for someone who has just started as a Staff Engineer?

Don’t think you’re going to solve ALL of the Engineering department’s problems; from what I’ve seen, it’ll get exhausting and you’ll get jaded pretty quickly. Slowly build up to those things. Hopefully, you were promoted because you were already operating at the Staff level; so you shouldn’t have to do anything dramatically different. Continue to do the great work that got you to this title. Once you feel like you’re set‐ tling into things, extend from there.

Communication and building narratives are key. Make sure to write … A LOT. When thinking through problems or ideas, write it down (even if you don’t intend to share them). Usually when I can’t capture a problem statement or idea in a coherent, concise paragraph it means I need to do more research and / or I’ll have a rough time trying to convince others it’s a worthwhile investment. Also, the written word allows you to scale your ideas and discussion around them more ef‐ fectively; much easier than scheduling a meeting with every possible person to pitch the idea.

Try to make your managers’ job easier. Don’t just bring them prob‐ lems; also bring them (multiple if possible) recommendations / sug‐ gestions 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 prob‐ lem 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 some‐ one to provide feedback on why your solution is bad than it is to come up with a fleshed out solution on their own.

Start thinking intentionally about creating opportunities for other en‐ gineers you work directly with to grow their skills and get access and visibility to others in the company that they usually wouldn’t.

Build relationships early. It can help in situations where you need to spend some social / political capital to take a stance on something. If the first time you engage with someone is when, as an example, you’re fighting for opposing solutions to a hiring problem, you’re al‐ ready starting from a deficit with that person. To be clear, you should never look to “people please”. But your working relationship and abil‐ ity to collaborate productively on future endeavors with a specific per‐ son can be significantly easier if a relationship was built up before‐ hand.

Frankly speaking, trying to apply all of this is a lot; and it’s just one per‐ son’s opinion. Treat it like a restaurant menu; choose what resonates with you and try to apply it. Then, pay it forward by sharing your ex‐ perience with the next person trying to make it to Staff.

Did you ever consider engineering management, and if so how did you decide to pursue the staff engineer path?

I get asked this regularly.

I do have a goal of being a CTO; but that’s more of a directional thing to ensure I don’t get complacent about my career progression. In the context of Mailchimp, getting promoted to Principal Engineer would satisfy that goal for me. I’ve been able to deliver real, tangible business value at my current level; so I think I could continue that and continue to feel rewarded by sticking with the individual contributor track.

Also, I had been fulfilling a lot of the responsibilities of an Eng Man‐ ager for my team (without formally being the Eng Manager). So, a lot of the things I would have wanted to start doing if I switched to man‐ agement, I was able to put in practice and get that experience. So, I’m sure that satisfied any itch I had for the time being.

What are some resources (books, blogs, people, etc) you’ve learned from? Who are your role models in the field?

Verbal communication about technology with various technical and non–technical audiences is a skill. It’s one that I try to cultivate and hone everyday. One person that I watch for a visual on how to do it right is Kelsey Hightower. Another is my college professor for a couple of my Software Engineering courses. He rarely ever came to class; but when he did I usually learned more about software development than I have in any other academic setting. They both know how to explain things well and tailor it to the audience.

There are a couple blogs that I’ve come across that have helped me hone, and fine tune, how I develop a technical approach and strategy. The first is ”Delivering on an architecture strategy” from Pete Hodgson that presents a framework for achieving a sustainable balance between fea‐ ture delivery and foundational architectural work. The second is “Step‐ ping Stones not Milestones” from James Cowling which is about delivering real value with big architectural initiatives.

Keavy McMinn - Senior Principal Engineer at Fastly

March, 2020 blog, twitter, linkedin

Tell us a little about your current role: your title, the company you work at, and generally the sort of work your team does?

I’m a senior principal engineer at Fastly. Fastly is an edge cloud plat‐ form that provides services like a CDN. I work in OCTO, the Office of the CTO, which is composed of about ten principal or distinguished en‐ gineers who report directly to the CTO. Each member of OCTO tends to have their own focus, and mine is being the API Lead.

What does a Staff‐plus engineer do at your company? How do you spend your time?

There are several quite different types of principal and distinguished engineers in OCTO. There are also principal engineers that work within engineering teams directly, rather than within OCTO. In the OCTO group, some work on internet standards or academic research, some do deep technical research and prototyping, some help incubate a team building something completely new. I’m closely involved with the broader engineering organization in my API Lead role.

We all work on different things, but we have a common goal of taking a holistic, long‐term and system‐wide view on things. We also try to find and help with the sort of things across engineering that might get overlooked or fall between the cracks. Our CTO supports our work, but doesn’t identify the projects to work on, that’s up to us.

I’ve never thought about my time in terms of percentages. Some of my work goes in phases, with more of one thing this week, more of that the next. A massive amount of my time is spent doing written work, research, and talking to people. I’ll have regular meetings with the teams and managers that build APIs. I’ll spend time breaking a long‐term strategy into little chunks, doing research, and writing a proposal on that. Then I’ll have to market that proposal around the company. Less on writing code lately, but in other phases I’ll build demos or tooling to support the wider work. That coding work is still really enjoyable.

Where do you feel most impactful as a Staff‐plus Engineer? What’s something you’ve done as a Staff‐plus engineer that you wouldn’t have done earlier in your career?

As a regular engineer, it can be hard to carve out time. You have to work more within the constraints and cadence of regularly scheduled projects. As a principal, you have the trust, the time and the space to try something out.

When you have a title, you don’t have to spend so much energy putting your credentials on the table. It helps set the context for others. You’re more respected from the outset, and that’s been really noticeable. You also get access to executives, so you get information earlier and might have a seat at the table to influence things.

Do you spend time advocating for technology, practice, process or ar‐ chitectural change?

I was hired specifically to set the direction for strategy for the API. Part of that is steering the technical direction and choices we make. I ap‐ proach it as a collaborative exercise. You know I’ll do the grind work of doing the research, I analyse all the information, present tradeoffs, and make a recommendation. I’ll take in all the organizational and engineering group context.

I present what I think is the best case for us, and people can disagree with that. And, you know, they often do. I’m steering and influencing more than saying, “I’ve got the authority to just tell you what to do.” I’ve never seen that style work well.

For controversial decisions, I’ll meet up with representatives from dif‐ ferent, relevant groups. I’ll meet with a group of engineers, tell them what I’m going to recommend, and ask “What do y’all think about that? What am I missing?” I’ll also meet with the management and product side, and maybe legal, docs, security or different people depending on the project. I’ve also done it the opposite direction of just present‐ ing the thing first, and then having calls to get feedback instead of just waiting for people to leave a comment in the document.

What’s something you’ve advocated for?

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 en‐ able those workflows. Sometimes it turns out that a seemingly simple thing is really difficult, particularly when the group isn’t used to flex‐ ing those muscles.

My approach to advocacy is to remind ourselves what the pain points are that everyone felt that led us to trying to make a change. We’re not trying to be perfect for sake of theory, code beauty, or a lofty concern. I bring it back to “These are the pain points that everybody said they felt, and this is an approach that you know ultimately is going to help with that.”

I help get other people to care about the same things, like I’m going to start pairing with more engineers on API reviews. While I do the reviews, I try to help teach others what I’m looking at, and be encour‐ aging through the processes and conversations.

How have you sponsored other engineers? Is sponsoring other engi‐ neers an important aspect of your role?

This hasn’t been as much of a focus for me in my current role. At GitHub I was conscious that I had privileges from my seniority and tenure, and sponsored an engineer there. I would give him more and more challenging things to work on, encouraged him to question any‐ thing that was unclear or curious to him about my work, and advocated for further responsibility and recognition for him.

How did you build organizational trust?

At Fastly, I was given trust from the beginning. When I joined, I was hired to come in and work on specific things. I remember asking, “Is there a time scale for this?” and for their notions about strategy, and being told explicitly that they wanted me to figure it out and tell them. So definitely a lot of trust and responsibility.

There are pros and cons of when you build that trust instead of being hired with it. As you build up trust, you simultaneously build up a lot of context, which is how it worked for me at GitHub. Although, I find in my current job that it was actually really useful to come in without context and be a set of fresh eyes. 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.

There is a popular idea that becoming a Staff Engineer requires com‐ pleting a “Staff Project.” Did you have a “Staff Project,” and if so what was it?

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 un‐ fortunately they didn’t lead to me being promoted. They did lead to my career progression though. Those projects gave me the experi‐ ence, 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.”

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 gen‐ eral. I don’t think it’s necessary, but I think it can definitely be helpful, it’s been helpful for me. My very first conference talk I was asked to do ‐ because the organizers thought I had an interesting perspective to share, coming from an art background. It was terrifying, and initially I wanted to say no. But my mother persuaded me to say yes. So pub‐ lic speaking was a slightly more accidental than deliberate strategy to start with.

Mostly, I enjoyed the people I met at conferences. Later the speaker networks led to job opportunities for me.

How did you first get a Staff or Principal title? What factors con‐ tributed most in you reaching that title?

I was hired at Fastly as a Principal Engineer. So, to be honest, for me the biggest factor was changing companies. The type of work I was do‐ ing didn’t dramatically change, but changing companies was the thing that ultimately enabled me to get the title.

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

Has working remotely impacted your career trajectory?

Not that I’m aware of. I’ve always been a remote employee and I’m sure it’s been a factor in being able to have serendipitous conversations but I’ve just been doing it so long. 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.

Did you get any advice on reaching Staff that was particularly helpful for you?

Not really, I got some bad advice. It’s such a cliche, but the “This is great. Now you have to prove it again.” There’s some advice that pushes people more in the sort of hero direction, like saying that you need to invent something unusual or magical to qualify. There are so many different directions one can make it. Engineering ladders often contribute to these beliefs.

What about a piece of advice for someone who has just started as a Staff Engineer?

The thing that springs to mind is to find your peers or support network. Just like management, it gets lonely the higher up you go and it’s impor‐ tant to find peers that will still challenge you and you can brainstorm ideas with. It doesn’t even matter if they’re in your similar area of work or even are in different companies.

Did you ever consider engineering management, and if so how did you decide to pursue the staff engineer path?

I tried it once and didn’t have a good experience. I realized it’s just not where my passions lie. I have too much respect for engineering management to do it for anything other than the right reason. The right reason is to support other people.

What are some resources (books, blogs, people, etc) you’ve learned from? Who are your role models in the field?

Conferences have been a resource for me, as well as getting to work with mature, low‐ego, wonderful engineering leaders and engineers. Chad Fowler, and his book The Passionate Programmer, is at top of that list. Dave Thomas is another one of those people whose work‐ shops I used to go to when I was first learning Ruby and his book The Pragmatic Programmer is another great one.

Bert Fan - Senior Staff Engineer at Slack

May, 2020 blog, twitter, linkedin

Tell us a little about your current role: where do you work, your title and generally the sort of work do you and your team do.

I’m a Senior Staff Engineer on the Platform team at Slack. I was lucky enough to join Slack shortly after we launched the Slack App Directory so I’ve had the opportunity to help evolve the Slack Platform into what it is today.

It’s hard to generalize the work that I do but the goal is always the same: enable developers to build on top of Slack to make our cus‐ tomers’ working lives simpler, more pleasant, and more productive. Examples of this include building new platform features, improving API performance, writing documentation, and working with partners, internal integrators, and third‐party developers to ensure that they can build impactful software.

What does a “normal” Staff‐plus engineer do at your company? Does your role look that way or does it differ?

The work that Staff‐plus engineers at Slack do is incredibly varied de‐ pending on which part of the company you’re in, the composition and size of your team, and what the business needs from you. Staff‐plus engineers are often the tech leads of projects, which means that they help write the tech spec, get feedback from various stakeholders, work closely with design and product to decide what to build, and lead the technical implementation for the project. They also mentor other en‐ gineers, improve our interview process and engineering culture, de‐ velop engineering processes and tools, and provide technical direc‐ tion for refactors and tech debt. Staff‐plus is all about enabling other people to do better work ‐ to be a force multiplier.

My role includes all the things that I’ve mentioned but I tend to focus less on specific pieces of technology and more on what the technol‐ ogy is enabling. So I might spend time prototyping concepts that will almost certainly be thrown away or gathering usage metrics around a particular user flow to better understand how to improve the system. I will often build apps on top of the Slack Platform to keep myself honest about what the developer experience is actually like and actively try to build on other people’s platforms to see what works and what doesn’t. A lot less of the code that I write makes it into production than other engineers at the company and I’m completely fine with that.

Can you think of anything you’ve done as a Staff‐plus engineer that you weren’t able to or wouldn’t have done before reaching that title?

I’ve done a lot of experimentation with various product ideas in the last year, some of which have evolved into actual features of our Platform. Part of the reason I was given the opportunity to do that is that I’ve established trust through other projects that I’ve successfully shipped, but having a Staff‐plus title seems to bestow a little more flexibility in what I choose to work on.

For better or worse, I’m also in a lot of strategy and planning meet‐ ings I was never in before. If you’ve ever wanted to know how the sausage was made from a leadership angle, maybe consider if you ac‐ tually want to know how the sausage is made.

How do you keep in touch with how things really work as you spend less time on hands‐on development?

The best way I’ve found is to have regular 1:1s with engineers across the company and spend a lot of time listening. You can learn a lot about the current state of engineering if you take the time to develop relationships where engineers feel like they can be honest with you. As a Staff‐plus engineer, you have no real influence over how much money someone makes or their next promotion, so engineers can be more candid with you if you make yourself accessible to them.

What two or three factors were most important in you reaching Staff? How have the companies you joined, your location, or your education impacted your path?

I come from a fairly privileged background ‐ I graduated from college with a computer science degree and no debt or student loans and part of what that bought me was the flexibility to leave a job without wor‐ rying how I was going to make rent or if I was going to find a new one. And I leveraged that flexibility into becoming pickier and more strate‐ gic about the places that I wanted to work.

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 meaning‐ ful ‐ things that I personally used that I thought were having a positive impact on the world. And I believe those choices have paid dividends because companies like that attract like‐minded folks who will go on to other companies that hopefully are aligned in the same way. This is not a meritocracy and your professional network is important. I’ve got‐ ten 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 man‐ ager there that I haven’t talked to in years but that I respect and know that they respect me as an engineer. We work in an industry where there are a lot of options of how to spend your time and if you’re lucky enough to be in a position where you have the flexibility and privilege to choose, you’re doing yourself a disservice by not regularly evaluat‐ ing what you work on.

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 like‐ lihood 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.

Can you remember any piece of advice on reaching Staff that was par‐ ticularly helpful for you?

The best advice I’ve heard is that often reaching Staff is a combination of luck, timing, and work. Here’s a path of events that I’ve observed and personally experienced:

1. Develop a relationship with your manager where they implicitly trust you and you implicitly trust them. Be honest and direct with them about what you want. Developing this trust will re‐ quire you successfully delivering on the things they ask you to work on.

2. Because your manager trusts you, when they hear about projects that will have a significant impact for the company, they will ad‐ vocate for you to lead those projects. Alternatively, you’ll have to find or create a project yourself and advocate for it to happen. This is much harder but still plausible.

3. Deliver the project successfully.

4. The project has a significant impact on the company.

5. Because you successfully delivered a project that had a signifi‐ cant impact on the company, it’s easy to advocate for your pro‐ motion to Staff, which your manager is happy to do.

Hopefully you can see where luck and timing can affect this simple plan ‐ what if you don’t get along with your manager? What if your manager leaves the company or gets promoted? What if you’re in an area of a company that gets no interesting projects? What if the project is doomed to fail? What if the project succeeds but has no impact?

These are all possible and there’s no generic piece of advice that I can give to overcome any of them except that sometimes you’re never go‐ ing to get promoted and you should probably be honest with yourself and identify when you’re in that situation. In that case, sometimes the only way to get promoted would be to leave the company and do some‐ thing else. You may boomerang back into the company at a higher level than you left at later in your career, but much like a failed rela‐ tionship that you revisit, do you still want to be there or is there too much baggage to ever make it work?

What about a piece of advice for someone who has just started as a Staff Engineer?

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 ef‐ fective at your job as a Staff Engineer, you’re likely going to spend a lot of your time talking to people. 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. Trusting other people and giving them the freedom to make technical decisions (even ones that you disagree with!), un‐ derstanding other people’s motivations, learning to give difficult feed‐ back, knowing when to pick your battles ‐ these are all useful skills to have.

If you haven’t already, try to become the engineer that people want to work with. There are a handful of engineers at every company who, if you ever left your job, you would try to circumvent a non‐solicitation agreement to work with again. Become one of those engineers for other people and it’ll unlock a lot of doors for you in your career.

Did you ever consider engineering management, and if so how did you decide to pursue the staff engineer path?

Early in my career, I once told my manager I was concerned that I would have to go into management at some point and they said some‐ thing like, “Don’t worry about that! At this company we have two dif‐ ferent tracks, the management track and the IC (individual contribu‐ tor) track, and there are equivalent roles in the IC track for the highest management positions, so you’ll never have to switch to management in order to move up in the company.” While technically true, the omis‐ sion that seems obvious to me now is that at a lot of companies, the management track is a lot less vague than the engineering track.

The higher up you climb in the engineering ladder, the less examples you’ll have of what to emulate and the examples seem more and more unattainable. When you start to dig into it, you may realize that some‐ one had gotten the title when their company was acquired or they were the author of a programming language or framework or they unlocked tens of millions of dollars in revenue for the company.

A lot of my colleagues have gone into management for various rea‐ sons and I suspect one of those reasons may be the more obvious, reliable progression that I’ve described. But I believe strongly that that shouldn’t be your primary motivating factor. If you have 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 major‐ ity 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

August, 2020 website, linkedin, twitter

Tell us a little about your current role: where do you work, your title and generally the sort of work do you and your team do.

I work at Etsy, which is the world’s leading online marketplace for sell‐ ers of handmade goods. We let sellers put their items up for sale and sell them to folks all around the world. We really focus on providing people with unique, special or handmade goods that are an alternative to kind of the facelessness of big box stores.

I’m currently on the Frontend Systems team, which is a product in‐ frastructure team that’s responsible for our frontend architecture ‐ in‐ cluding our PHP view rendering framework, although I’m not super actively participating in the work that the team is doing right now. For the last several months I’ve been focusing on web performance ‐ func‐ tioning in an advisory capacity for all things performance ‐ improving our monitoring and reporting systems, identifying areas for improve‐ ment, and being available to product teams for help with performance related questions.

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 per‐ formance culture thanks to folks like Lara Hogan, but due to organiza‐ tional 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 indus‐ try around how “good” performance is defined and measured, partic‐ ularly for SEO. Google is really pushing for web performance being a criteria that companies focus on as part of their search ranking. So it’s very much a top of mind area, especially for retailers.

What does a “normal” Staff‐plus engineer do at your company? Does

your role look that way or does it differ?

The interesting thing to me about how we think about the role of a “staff engineer” is that we take two different ways that a person can be senior and we put all of those people into one bucket called staff engineer. But really, there are two different buckets.

Someone can become really senior in their role by being an expert in a particular subject area, by really taking on the role of tech lead, where they are driving their team or org’s technical approach and roadmap. Then there’s this other way to be a senior engineer, which are the folks who broaden their scope of work and their focus such that they’re thinking about problems that are cross cutting, they’re driving the creation of systems and practices that operate across multiple teams. That second bucket is what I think of as an architect. It’s not that you aren’t a subject matter expert, but it’s just that the scope of influence that you have is greater than operating as a tech lead for a particular team.

At Etsy we have a few levels of seniority: Senior Engineer I and II, then Staff I and II, then Senior Staff which is considered equivalent to a Di‐ rector level role. I’m technically a Staff Engineer II, and that’s how I think of myself, but my specific role is as the frontend architect. That means instead of being responsible for just what my team is doing, I’m responsible for looking at what all of Etsy is doing in the frontend space. What does the future look like? What are the problems we need to solve? How are we going to get there? I think about all that, and ad‐ vocate for the technical approaches that will get us there at the com‐ pany level.

In your role as an architect, do you spend much time doing software development?

Yeah, it’s funny. I’m a frontend architect, but by far the main thing I’ve been writing lately is SQL, because I’m doing a lot of data analysis. I’ve been looking at our performance metrics to figure out where the areas for improvement are, and what would be the most impactful issues to fix to improve performance and business metrics. I will write little bits of JS or PHP here and there, but it’s mostly to help unblock teams or to run small performance‐related experiments, or if there is something important that needs to be done but other folks don’t have time for.

I’ve definitely found that I’m moving slower, and it’s taking me longer to actually find the dedicated focus time to write code as my calendar fills up with meetings. So I don’t think you want me to write much code anymore! I’m much more focused on identifying areas for opportunity and then trying to sell that as work that my team or other teams should be doing.

How do you spend your time day‐to‐day?

I would say 50% meetings, and the rest of the time it varies pretty widely from day to day. Sometimes I spend the other 50% writing docs, sometimes I’m in SQL doing a lot of data analysis, sometimes I’m in slack talking to people across multiple teams and roles. At times my meeting load will spike a bit as projects come into my lap where I’m reaching out to other teams to learn more about what they’re work‐ ing on, or trying to influence them to make changes. It varies pretty widely.

I’ve found that folks in these roles often struggle to quantify their work, have you found any useful ways to measure your impact?

I’m glad to hear that because it is something that I really, really strug‐ gle with. I always have a bunch of different projects and discussions happening at any given time, and I have a bad tendency to get caught up in the newest thing or let my focus wander, so I have to be really thoughtful and cognizant about how I organize my work and my notes. I’m always looking at everything that I could potentially be doing and picking what is the most impactful or the most important thing for me to do that day, and that can be really hard.

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.

One thing that has definitely been helpful is making sure that I’m keep‐ ing track of all of the different tasks I complete every day ‐ logging meetings, emails, slack discussions, etc. Then, when I have my of‐ ficial quarterly goals check‐in with my manager, I review all of my notes and realize, wow, I helped engineers fix performance issues on six different experiments, or I influenced this team to take a better di‐ rection with their new feature, or I gave that engineer feedback that helped them. These are all little things that in the moment don’t feel like much, but taken together show real impact.

Where do you feel most impactful as a Staff‐plus Engineer?

What I absolutely love to do the most is to identify a new or unique problem that hasn’t been tackled before, come up with a wild idea to solve the problem, and then my brilliant coworkers take that idea and really run with it to build something awesome. It starts with taking in a ton of input from the work folks are doing ‐ seeing that this team has a problem doing x, and another team has a problem doing y. Then you mix all that input up with your experience and what’s happening in the industry as a whole and let it sit in your brain for a while, until finally it all clicks and you realize that the deeper cause underlying both problems is z, so you come up with a plan to fix that problem which is really hard to fix.

An example of this process from before I moved into the Architect role was when my team owned our Design System components. Making changes or fixing issues with our shared components was really diffi‐ cult because we didn’t have a single source of truth for the markup and the templates for each component. Rather than everyone in the com‐ pany reusing the same template file, folks were copying and pasting the HTML into a bunch of different places. So when we had to make changes to a component, it was hard to find all the places to update because the pieces of the component were spread out and managed in different places ‐ sometimes in JavaScript, sometimes in Mustache, sometimes in PHP logic.

So I had this wild idea: what if we extended our custom PHP frame‐ work to enable reusable template blocks in mustache that represented all of our components, and we were able to easily compose them to‐ gether the way that you would in a React application. I went out and made a proof of concept and wrote up a proposal for the project and brought that to the team. Then the team really took the ball and ran with it, they built the infrastructure to support this component system and it turned out far better and more robust than anything I could have done on my own.

The part that I really enjoyed was identifying the problem and think‐ ing creatively about how we can solve it, then shopping the proposal around and getting other people engaged with the work to execute it.

Can people doing frontend work create leverage for a company simi‐ larly to folks in developer productivity or infrastructure roles?

Yes, most definitely. I personally only know a handful of other Frontend‐specific staff engineers, and I think that frontend as a skillset is not valued in the industry as much as I think that it should be. I’m very lucky that I got my foot in the door at a place like Etsy, which tends to hire “full stack” engineers, by having computer sci‐ ence fundamentals in my background ‐ I went to school for Computer

Science, and I have experience working in and understanding the whole stack. But really, my passion and my focus has always been the frontend because it’s what’s in front of your users. I’d love to see more companies value the frontend, because I believe we bring valuable skills and a unique way of thinking to the table.

As far as becoming a staff engineer, I think that the qualities of a good Staff Engineer transcend what stack you’re working in. Ultimately, staff engineers need to be able to think about engineering decisions as a series of tradeoffs, and articulating those tradeoffs is a skill that you can have from any perspective within the stack.

I also think that Staff Engineers should have a broad understanding of all of the adjacent fields of work to their own specialty. For me, work‐ ing in the frontend, I put a lot of time and effort into understanding marketing, business goals, user experience, visual design, the view and business logic layers on the server, how we ship code the browser, how browsers take all that code and turn it into a website, and then how users interact with it. Having expertise in all of these different areas makes it easier for me to see the broader impact of my technical decisions and understand those tradeoffs better.

Having empathy for your users, in particular, is an important skill for all types of engineers to develop, and I think it can be undervalued in many infrastructure or developer support orgs that don’t understand that yes, they actually do have users! I work in Frontend Infrastruc‐ ture, and we really try to see ourselves as product engineers ‐ it’s just that the products we’re building are systems for other engineers to use. So we have customers. We have users. When we think about the API for the systems that we build, we’re designing our APIs for users, and we need to understand our users ‐ aka product engineers ‐ to do that well.

So I personally think that frontend‐leaning folks make great Staff Engi‐ neers, 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.

How do you maintain empathy and awareness of the realities of devel‐ oping at your company when you do less development yourself?

Networking, networking, networking, networking. One‐on‐ones are particularly important because I’m a full‐time remote. Obviously, everyone’s remote right now, but as a remote on a not‐completely‐ distributed team, you have to be really cognizant of who you’re talking to, and make sure that you have connections across multiple teams and multiple groups to leverage those networks.

At Etsy, we are really lucky that we have a few different Employee Re‐ source Groups for folks to connect across the company. I’m fairly ac‐ tive in the ERG for marginalized gender identities in tech (MAGIC), and it’s great because there are folks who are part of that community who work in every single department in engineering. The same is true with the community of remote employees. I make time to mentor more ju‐ nior folks, have regular 1:1’s, and participate in slack discussions to foster and grow these connections, because it helps so much to have a finger on the pulse of what’s happening broadly in the org. I also try to make sure that I’m talking to engineers throughout product en‐ gineering in particular, because product engineers are our customer base.

Something I’m working on getting better about is connecting a lot more with managers. For a long time I’ve had really good networks inside the Individual Contributor track and I’ve been working a lot in the last few months on broadening the reach of my network to include more engineering managers. A lot of times the work that I do requires “influence without authority”, I’m not making the decisions myself, but trying to influence the decisions that others are making, and a lot of times, managers are the ones who make the final decisions on things.

How have you sponsored other engineers? Is sponsoring other engi‐ neers an important aspect of your role?

I was very lucky to work with Lara Hogan for a few years at Etsy and she’s talked a ton about sponsorship and as a woman in tech I’ve ben‐ efited from and seen the value of sponsorship myself. I definitely put a lot of time and energy into that.

About a year and a half ago, my colleague Andy Yaco‐Mink, another Staff Engineer, and I noticed there wasn’t really a good method of com‐ munication for product teams to share what they are working on with each other, or to connect with teams working on product infrastruc‐ ture. To try and fix that, we proposed and started up a monthly meet‐ ing that we call the Product Engineering Confab. It’s an open forum for folks to bring up questions, share their work, celebrate wins, and for us folks in infra to share what we’re working on.

Something that I don’t think we fully anticipated is that it’s also been a really great way to create opportunities for sponsorship . Every month Andy and I have to figure out what folks are doing that would be inter‐ esting to share more broadly. What are experiments that have run that have gotten interesting results? Who’s out there doing cool stuff that should be shared? Then we’ll reach out to engineers on those teams and say, “You should come and talk about what you’ve been working on at the confab!” It’s really easy. It’s five minutes. It’s super informal, but it’s a good way to get public speaking experience.

Since then, we’ve had a couple of folks who’ve come and spoken at the meeting, and then went on to speak at company all‐hands meetings or local meetups. At least one person ended up giving an expanded version of their talk at a big conference. We’ve also heard from folks that giving a talk at the confab was something they used as evidence of leadership in their promotion packet, which is an amazing feeling! You first got the title Staff Engineer at your current company. What was the process of getting promoted to Staff?

I was hired as a Senior Engineer because at the time we didn’t hire into the Staff title, although we’ve since changed that policy. I was working in the industry for almost ten years before I joined Etsy, but largely at smaller and lesser known companies. I’d been serving as a frontend tech lead for more than five years before I came to Etsy. Because of that, I was already extremely comfortable in the role of being a men‐ tor and a leader. I’d already spent a lot of time working closely with management, product and design, as well as figuring out roadmaps and execution. Altogether, I felt like I had the tech lead role down pat.

But, when I came to Etsy the scope was much bigger than what I’d seen previously. The engineering department was many magnitudes bigger than any engineering department I’d worked at before. I had a lot to learn about operating at a really big scale and how that’s very different than when you’re at a smaller company. I learned to be more cognizant of looking at data: I had to go out and teach myself basic statistics to understand the experimentation framework.

From the beginning, though, I was always looking around for places we could improve. I came in and said, “Oh hey, we’re not doing this thing. We should be doing this thing.” For example, I noticed that folks had been writing the design system JavaScript components any old way, so I said “Let’s come up with a framework and a standard boil‐ erplate for that.” It was such a small thing and it felt obvious to me, but it was a big improvement in our practices. I think a lot of what gets someone to Staff is noticing problems and acting on solving them proactively, instead of letting them go.

Altogether, I had been at Etsy for a little less than two years when the promotion to Staff came. My manager at the time was brand new and didn’t know my track record, so we worked really closely and collabo‐ ratively on putting together my packet. I’ve heard experiences on both ends of the spectrum of manager‐driven versus IC‐driven, and I’m glad that I ended up being a big part of the promotion process. 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 ac‐ complishments are out there and they’re known.

What two or three factors were most important in you reaching Staff? How have the companies you joined, your location, or your education impacted your path?

I’ve discussed a few things in this vein already: creativity, proactive‐ ness, empathy, etc. Something I haven’t talked about enough is com‐ munication and transparency. A big part of being promoted to Staff is making sure that your work is visible, that people know your name and you have a good reputation.

I’m lucky to be on a team that builds frontend infrastructure because we naturally write a lot of emails to everyone in engineering about the work we do, so we get a lot of visibility. But a bigger part of being in infrastructure is customer service ‐ helping folks who come into your Slack channel with questions or issues to be solved. I worked in the service industry for several years before going back to school to finish my degree in computer science, and I always try to model the lessons I learned about customer service from that experience in every interaction I have with folks at work: be available, be humble, and focus on really hearing and understanding people’s needs. When you truly care about helping our colleagues it shows.

Do you think some companies are particularly good at growing Staff

engineers?

To be perfectly honest, I don’t really know how Staff engineering works at companies other than Etsy, so I am totally biased! I think Etsy is good at growing Staff Engineers because we have a strong internal culture that values technical excellence combined with a culture of blamelessness and a desire to do good in the larger world. I think that leads to really smart and kind people working at Etsy, and that combination of intelligence and humbleness makes folks great staff engineers. This kind of environment feeds on itself, creating good role models and people who want to emulate those role models in order to get promoted. So I think that on the whole, we have a great cohort of folks who work or have worked at Etsy and model good practices for Staff Engineers.

I think it’s important to remember, though, that there are lots of smaller and less‐well‐known companies with amazing people who do Staff engineering type work, but aren’t called staff engineers, they’re acknowledged as technical‐track leaders in other ways. In many companies people who are strong technical leads become managers, and might not even have the idea of something like a Staff engineer role. It’s easy in a big name company to get stuck on this title of Staff as the end‐all be‐all, but remember that there are as many different ways of growing your career.

Can you remember any piece of advice on reaching Staff that was par‐ ticularly helpful for you?

One of the best pieces of advice that someone gave me, and that I make sure to pass on to other staff engineers, is that there’s a misconception that you become a Staff Engineer and then you’ll be in control of the work you do, and everyone will listen to you and do what you want them to do. That’s absolutely the opposite of what happens! You have this really tangible goal of getting a promotion for so long, and then you become a Staff Engineer, and all of a sudden, everything is vague and ambiguous. You transition from solving somewhat clear‐cut prob‐ lems, to being responsible for finding the right problems, and then figuring out how to convince people that it’s important to solve them. You are going to be challenged in a completely different way than you have been in your career thus far.

What’s your advice to people pursuing a Staff role?

I was nominated for the Staff Engineer promotion twice before I got promoted; the third time was the charm. I think what finally pushed it forward for me was that I had a good sponsor in my Director. So my advice is to make sure that you develop your network and start meeting with your Director or your VP, because those are the people who are in the room making the decision about whether you’re getting promoted or not. It’s not your peers and it’s not really your manager, it’s this other group of people, so you want them to know your name and your work. During that promotion discussion, you want them to think, “Oh, she sent that engineering‐wide email about this project.” or “I see him in Slack answering people’s questions all the time.” or “They spoke at that conference, didn’t they?”

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 techni‐ cal 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. I think people want or expect it to be a meritocracy, when it’s really not. There are so many factors that go into getting a Staff‐level role.

Advice for navigating uncertainty and ambiguity that comes with more senior roles?

It’s important to develop a lot of self‐knowledge to see when you’re pursuing something because it’s what you want and not because it’s going to be beneficial for the organization. That can be really hard to do. You have to be ready to kill your darlings, pivot, and try something new. If an approach you’re taking doesn’t work, don’t try to force it.

I also really love Dan Na’s talk about pushing through friction, because that’s something you experience constantly when you’re growing as a technical leader. I think about this concept of “influence without authority” a lot, because when you’re a Staff Engineer then your job is to figure out what the team or organization needs to do, align the organization around that goal, and figure out how to get people to do that when you have no authority over staffing or final decision making. It takes a lot of tenacity and you have to flex a whole bunch of quote‐ unquote non technical skills to push things forward.

What are some resources (books, blogs, people, etc) you’ve learned from? Who are your role models in the field?

A lot of names that I’ve already said, especially Lara Hogan, Dan Na. I just love everything that Julia Evans does and I am really lucky that I got to collaborate with her on a project. Ryn Daniels who used to work at Etsy blogs a lot on career progression. Tanya Reilly is a big inspi‐ ration to me as another badass working Mom who is also a respected technical leader. In the frontend space, Nicole Sullivan, Jen Simmons, and Ethan Marcotteare huge inspirations to me to name just a few. I re‐ ally enjoyed reading Camille Fournier’s The Manager’s Path. I’ve never done the management track so it was a bit of a black box and anything that gives you insight into the world of management is helpful because as a Staff Engineer you’re almost like a manager without the people as‐ pect.

Ritu Vincent - Staff Engineer at Dropbox

March, 2020 linkedin

Tell us a little about your current role: your title, the company you work at, and generally the sort of work your team does?

I’m a Staff Engineer at Dropbox. I actually was a Staff Engineer at Drop‐ box, left to join a different startup, and then recently came back to Dropbox just a few months ago. I came back because a really inter‐ esting opportunity opened up within Dropbox to launch an internal incubator. We’re working to foster innovation within the company. Dropbox has become a strong brand in the file sync space, but there’s beginning to be a lot of competition there now, so we need to do more and branch out into new products. 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 Drop‐ box.

There are two parts to the incubator.

The first is a more classic incubator where engineers across the com‐ pany can pitch ideas and get funding to join the program, and try to show product‐market fit or other forms of progress to continue getting funded every few months. The goal is for successful projects to grad‐ uate into their own lines of business, although we’re still early.

The second part is engineers who are permanently part of the incu‐ bator, and are always generating ideas from within the incubator and operating with a lot of autonomy. I’m one of the two engineers on that permanent “scouting” team, and we’re planning on growing over the next year. It’s very different from anything I’ve done before, which is why I wanted to sign up for it. It’s a huge paradigm shift for me. Hon‐ estly, the first few months have been a combination of really fun and really frustrating because it’s harder to measure obvious impact when your primary goal is to very quickly try out a ton of new ideas, many of which will not go anywhere. I’ve had to learn to think of impact in longer timescales ‐ not in terms of what I’m shipping today, but what I could influence the company to ship in the future,

What does a Staff‐plus engineer do at your company?

I’d say there are two different profiles of Staff Engineer at Dropbox. One is a tech lead who does a lot of coordination, designs work for their team, and spends time driving projects. The other is more of a specialist.

The tech lead was definitely my profile when I initially became Staff where I took a team of about eight engineers and drove an eighteen month project. That project had a lot of dependencies, a lot of gnarly parts. I had to control the communication around the project, as well as figure out how to allocate pieces of the project to the team in a way that both helped them grow and got the project done.

The specialist is deeply specialized in a particular area, for example Guido van Rossum, the creator of Python. Specialists would take on really complex projects and execute it themselves, often projects that no one else could take on effectively. There were fewer specialists than tech leads.

Were the specialists predominantly external hires?

There were some specialists that came in from industry, like Guido and a lot of very experienced folks on the ML team, but a lot of spe‐ cialists ended up being homegrown. That might be related to rolling out titles relatively late at Dropbox, which gave folks longer to develop deep context in our technology.

How do you spend your time day‐to‐day?

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

I was coding, but I wasn’t coding very much, maybe 20% of my time. I was the tech lead for the desktop client area, and spent a lot of time coordinating and providing guidance on projects. I also spent a lot of time partnering with recruiting, which was something that I did because I was interested in it, not because it was required.

For example, I worked on designing speciality interview loops, mod‐ erating debriefs and candidate screening. I also did a lot of work on di‐ versity initiatives. That’s one of the reasons that I’ve tried engineering management multiple times during my career, because I enjoy partic‐ ipating in organizational growth.

Where do you feel most impactful as a Staff‐plus Engineer?

One of the things that I’m really proud of having worked on was a big revamp of our engineering levels. Back in 2017, I was one of the few individual contributors selected to work on an engineer levels refresh, most everyone else was a director or manager. I’m proud because the new ladder impacted every person at Dropbox working in Engineer‐ ing, Product and Design.

It was also just really interesting to think deeply about how company growth changed roles and responsibilities. We were starting to bring in people from a lot of different backgrounds, and we wanted to be able to reward everyone in a healthy way. That was very different from my normal day‐to‐day responsibilities and pushed me outside of my comfort zone pretty significantly.

I’m also proud of my Staff Project, which was very technically complex. That project also gave me a chance to help a lot of people on the team grow. Years later, I’ve had engineers who left the company email me and say how much more confident they are or how much they learned because of that project.

It was also on that project where my manager helped me understand that my first impulse as a tech lead didn’t scale. 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.

Do you spend time advocating for technology, practice, process or ar‐ chitectural change?

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 peo‐ ple 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.

I do prefer for the team that’s going to own a project to make the final decisions about it. In cases where I have a very clear “right decision” in my head, I’ll try to lead the team towards that decision rather than going in and saying “this is the right decision.”

How have you sponsored other engineers? Is sponsoring other engi‐ neers an important aspect of your role?

I definitely think of myself as a sponsor. Execution is one of the most rewarding parts of my job–I love building stuff–but I’ve always loved helping people grow. I feel really proud when I see somebody who I informally mentored or helped on a project go on to do something great.

As a Staff Engineer, and especially as a woman who is a Staff Engineer, I feel like a lot of people look up to me. There seem to be a lot more role models on the manager career path, so I try to make being a role model part of my responsibilities, instead of just keeping my head down cod‐ ing. I mean, I could just keep my head down coding and that would be great, but I want to help other people, especially people with imposter syndrome.

I often get people coming to me and saying, “I don’t know how to make the next step.” or “I don’t know how to become a staff engineer, so I’m going to go be a manager instead.” I want to try to help them figure out their path. As a Staff Engineer, I think being visible and available for people to ask these sorts of questions is an important part of the role.

What’ssomethingyou’vedoneasaStaff‐plusengineerthatyouweren’t able to or wouldn’t have done earlier in your career?

There wasn’t anything I wasn’t able to do without the title, but the title did give me confidence. In addition to the title, the other thing that gave me confidence was realizing that everyone else is also struggling with imposter syndrome. The latter I learned in a pivotal conversation with someone who I thought was the most confident engineer I’d ever worked with, and when I talked with him about it he said, “I question every single thing I do. I go home and agonize over what I said earlier that day, and whether it was silly.”

It was really that conversation in combination with the title that pushed me to believe in myself as a Staff Engineer. Together they gave me the confidence to ask for the harder projects, or to ask my manager to give me more projects to work on.

What was your proces of getting promoted to Staff Engineer at Drop‐ box?

They rolled out external titles a while after I joined Dropbox. In the first review season with titles, they gave the Staff title to a very small number of engineers. They were really still calibrating the titles at that point. It was in the second review season that I got my Staff title.

By the second season, I’d been a Tech Lead for a while and my manager and I both felt that I had clearly been executing at the Staff level. We did go over the new career level definitions to identify any gaps before the review cycle, but overall it went pretty smoothly.

What two or three factors were most important in you reaching Staff? One of the big factors for me was definitely visibility. Part of that came from doing so many things outside of normal engineering responsibil‐ ities.

For example, I helped recruiting with running the intern program one summer. During the program I worked with a ton of intern mentors across different teams, and since Dropbox tended to have very large intern classes, that ended up meaning that I gained visibility across pretty much the entire company. The hiring work helped too. If you’re moderating dozens of hiring debriefs every month, and driving hir‐ ing and calibration conversations, then you’ll get to interact with ev‐ eryone in engineering. I also helped with onboarding, giving a core engineering presentation to incoming new hires.

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

Was that work, which some companies would call “glue work,” directly valued?

This work was highly valued by leadership at Dropbox. Leadership and many of the very senior engineers were heavily involved in these efforts, especially recruiting, and it was not considered glue work. That being said, it would not have gotten me to Staff on its own. It was a question of finding a good balance between having cultural impact and having something technically strong to showcase.

There is a popular idea that becoming a Staff Engineer requires com‐

pleting a “Staff Project.” Did you have a Staff Project, and if so what was it?

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 promotion that didn’t include a really strong project, typically a multi‐person project where the en‐ gineer was the Tech Lead.

I definitely had a Staff Project. Back in the day, Dropbox was initially a consumer product that people downloaded and installed on their ma‐ chines. When we launched Dropbox for Business there was a request for both your personal and work Dropbox accounts to work simultane‐ ously, 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 understand every single layer of the Dropbox system.

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

Would you share a piece of advice on reaching Staff that was particu‐ larly helpful for you?

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 ambi‐ guity 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. To reach Staff Engineer, you have to know and do more than what you currently know. It’s important to always push beyond what you’re doing and not be scared of asking for things you think are too hard for you.

This is tied into imposter syndrome, where you might not want to try anything until you’re absolutely sure you’ll excel at it. But you have to get comfortable with the fact that you might crash and burn. That’s okay, you’ve got to try it.

What about a piece of advice for someone who has just started as a Staff Engineer?

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 hon‐ est with your manager about what you want from your career. A mis‐ take 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.

They’d ask me if I was interested in a piece of work, and I’d wonder why they were asking, did they _want _me to take the work? So I’d say I was interested even if I wasn’t. Or they’d ask me how a project was going, and it might be going horribly, but I’d tell them it was going fine to avoid disappointing them, instead of saying I needed help.

Somewhere along the way I realized that your manager is really on your team. They’re looking for a way to make you grow, be productive, be happy and become the best engineer you can be. The way to have an effective relationship with your manager, including having them sponsor you, is to be super honest and open with them.

This became particularly obvious to me when I became a manager my‐ self, because I wanted everyone on my team to become a Staff Engineer and to get promoted. I wanted to find reasons to promote them, and worked with them on that.

Did you ever consider engineering management, and if so how did you

decide to pursue the staff engineer path?

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 engi‐ neers 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.

Once I started mentoring and managing I definitely found myself thinking about career growth very differently. The pendulum has helped me see a lot of different perspectives. As a manager you have very explicit responsibilities for things like headcount and performance reviews. Staff engineer responsibilities are really fuzzy and differ across companies. That ambiguity around Staff roles leads many folks to make the lateral switch to management who would have been happier staying as an engineer. That’s why it’s so valuable to get more information on the Staff role out there for people to read.

What are some resources (books, blogs, people, etc) you’ve learned from? Who are your role models in the field?

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. It’s those conversations about career challenges and growth that have gotten me to where I am in my career.

Rick Boone - Strategic Advisor to Uber’s VP of Infrastructure

April, 2020 linkedin

Tell us a little about your current role: where do you work, your title and generally the sort of work do you and your team do.

I’m the Strategic Advisor to Uber’s Vice President of Infrastructure, which means I’m part of the Infrastructure leadership team along with the engineering directors and org‐wideProgram Managers. Infrastructure Engineering at Uber is about 700 people across six sub‐organizations like Metal which handles our data centers and servers, Storage, Developer Platform and so on. I work with the VP on things like technical strategy, cultural strategy and special projects.

Strategic Advisor is a wide ranging role, for example I might work on:

• assessing our technology needs over the next two years

• helping prioritize innovation in the roadmap for the next six months

• digging into important areas without a clear owner and helping streamline the ongoing related projects

• learning how the engineers are feeling before or after a big orga‐ nizational change

• talking to two teams who need to agree on something but are very far apart and seem like they’re having communication is‐ sues, figuring out how to help them find an effective path for‐ ward

It’s just a really, really broad role that’s a mix of engineering, culture, psychology, organizational design and strategy. There are two ways that I describe it, both from pop culture. The first is like being the Hand of the King in Game of Thrones, and that’s the best analogue I have for it. The second is Leo McGarry from The West Wing, who always said, “I serve at the pleasure of the President.” In my role, I say that I serve at the pleasure of the Vice President of Infrastructure.

Although right now it’s just me, previously there were two of us in the Strategic Advisor to VP Infrastructure role, and we would split the work based on our natural affinity to the projects. She often focused more on projects related to managers and leadership while I focused more on IC’s and engineering projects ‐ though we still managed to do things in both areas

The Strategic Advisor role is a bit unorthodox; it was created by Matthew Mengerink a little while after he started in the VP of Infras‐ tructure role. To my knowledge, our org, and the office of our CTO, are the only orgs which have a role of this type. Matthew created the role because of the value of having full context from within the engineering teams themselves , and he wanted to create that feedback loop to inform his decision making.

It’s a particularly valuable role in Uber’s Infrastructure organization because it’s a really, really broad organization, and I help serve as a synthesized view across all of it.

How does this role compare to a TPM role?

This is an interesting question, because I was just thinking about the distinction between Chief of Staff and my own role the other day. Within the Infrastructure Leadership Team, we have the strategic advisor and program managers, and in the past, we’ve also had someone who filled a Chief‐of‐Staff role.

The way I see it, the program managers are an organization‐scoped op‐ erational role. They’re working at a high‐level, ensuring that the ma‐ jor programs and areas within Infra are progressing along and eval‐ uated at a regular cadence, operationalizing efforts + initiatives, etc. The Chief of Staff role was one which ensured that the entire leader‐ ship machine was working well together ‐ that all the people, groups, messaging, etc, involved in running and leading Infra were operating effectively.

My strategic advisor role is more about taking broad domain knowl‐ edge, both technical and cultural, getting into the details of the prob‐ lems on a personal and organizational level, and then mixing in engi‐ neering acumen. From that I’ll synthesize a set of recommendations or insight which I deliver to either the organizational leader or the entire leadership team. Day‐to‐day, the vast majority of my work is done directly with the org director and with the PM’s ‐ delivering rec‐ ommendations to the director of the org, and then, with his input and approval, working with the PM’s to turn them into a reality.

How do you think about the importance of remaining aligned with your sponsor?

It’s funny, because that alignment is key ‐ almost a necessity ‐ for the role. Matthew and I are very aligned on our principles, values, world views, emphasis on emotional intelligence, approach to execution, and philosophies. On so many things we’re lined up, such that it’s almost a symbiotic relationship.

Alignment with the sponsor is really critical to be effective, but it’s more than just the dispassionate connection between Strategic Advi‐ sor and Vice President. It’s also about the connection between Rick and Matthew as people, and making sure that’s a good fit.

In my role we’ll often go weeks without being in the same room to‐ gether, but I still have to operate as if I’m his direct proxy. So I go into a room and think, “What would Matthew do here? What is the question he would want to ask? What guidance has he given on this problem?” Because I can’t always run back to him for clarification, it’s essential to develop and maintain a deep understanding of his world view. That’s essential for me to retain the very deep trust required to be his representative and effectively carry out his strategy and vision. People need to be confident that I’ll always give the same answer that Matthew would give if he were there.

It also means that I have to truly understand his goals, intent, values and principles, to make sure that I’m ready to stake my reputation and credibility on pushing them forward. Often, part of my role involves advocating for or translating his vision and/or implementation to en‐ gineers, sometimes when supplemental context isn’t always known. When I do this, I have to make sure that I not only understand the logic and value of what he’s doing, but that I also believe in it myself ‐ otherwise, advocacy becomes hard, not to mention disingenuous.

This is something I really struggled with a lot when I started in the role. Matthew would constantly tell me, “You’re my representative; you should feel free to push on and perform things using my name and role .” That was difficult for me because I’ve never been in a role like that before. Previously I’ve always operated using my own name and reputation, and now I was operating under the aegis of the Vice President and everything which that carried . Over time I’ve learned how to be deliberate with using that hammer, since you don’t want to overuse it.

I’ve also learned that I have to let folks know which hat I’m wearing sometimes. I love to mentor people, but sometimes folks aren’t sure if they’re getting the strategic advisor working for the benefit of the organization and company or the mentor, working for the benefit of that person and their career; I try to let them know which role I’m currently in within a particular conversation. If I meet with someone I’m mentoring, they might want to get advice about changing teams, or even leaving the organization or the company, and they want to know which perspective I’m giving advice from.

What does a “normal” Staff‐plus engineer do at your company? Does your role look that way or does it differ?

I think the biggest difference is that other senior‐plus engineers work primarily on technical work. They are leaders, so they do get into the realm of emotional intelligence, communication, collaboration, con‐ flict resolution, evangelism and so on, but still 80% of their daily ef‐ forts are driven by technical concerns.

Whereas with me, there might be weeks where I’m focused on a project around group psychology or organizational design. Technical concerns are not always the pure focus that drive my day to day ‐ though they are always there, if even just in the background.

How do you stay aware of reality on the ground now that you’re devel‐ oping less?

When I was an engineer I could do this passively, because you’re in the code, trying to push commits, dealing with the friction of provision‐ ing and operating services, etc. That approach doesn’t work anymore, since I’m not touching code very much; so now, gaining that data and awareness requires an active process.

One thing I’ve done is continue to sit next to my old team so I can hear them work. Maybe they’ll complain about a service’s stability, or a gap in our tooling, and it’s helpful to keep hearing that.

I also constantly ask folks questions about their developer experience. 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. Sometimes these reach outs are more structured, literally a survey for input, and other times it’ll just be a quick message check‐ ing in.

I also tell folks to send me non‐critical path work that doesn’t have a strict timeline, and I try to use that as an opportunity to stay fresh in writing actual code. 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.

How have you sponsored other engineers? Is sponsoring other engi‐

neers an important aspect of your role?

One of the things that’s special about this specific role is that it’s es‐ sentially a built‐in mentorship with the Vice President. 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.

As I spent time thinking about my goals, what I really came away with was that I love being a visible reference for other engineers, especially other minority engineers, and helping people here at Uber or earlier in their career. I especially enjoy helping people who are just getting into the industry, and might still be a little intimidated by it. That’s a huge part of what drives me, and this role has helped me realize and admit that to myself. Before I didn’t accept that as a valid purpose, but I realized that if it’s what you love, if it’s what you’re passionate about, then you have to go for it.

Another reason mentorship is important to me because throughout my life and career, I’ve had six people that I consider key mentors. Each of them, at various times, have provided massive impact and in‐ fluence upon my life ‐ I would not be anything close to who I am with‐ out their past and continued guidance. And I’m both extremely grate‐ ful for them and also constantly aware of how much they’ve guided me. So, I always recognize the power of a mentor and want to make sure I can provide that for others. And sometimes, mentors don’t even know how their words or actions change you, the ripple effect they can have, even years later. So, I always try to make myself available for others as a mentor, because you never know when you can have that type of life‐changing impact on someone, or how. It might just be the right word, the right perspective, the right push from you, at just the right

time for them.

I’ll always tell people, “Seriously, if you need me, just come ask for help.” This is one of the most exciting parts of what I do, and there are a few different ways I try to make myself available.

One is that I give an Engucation (what happens when you blend engi‐ neering and education into a single word) class every month to most new hires in engineering. That class is called “Lessons + Questions” and it’s literally just a place where they can ask me anything they want about Uber ‐ technical, cultural, whatever ‐ and I’m as candid as pos‐ sible. At the end of that, I let people know my email and that they’re welcome to reach out. A good number reach out to me after that and I give them advice on their careers, working at Uber, or whatever. Other times I’ll have people who just run into me while I’m around the office and ask for advice.

I want to be visible as a Black engineer, showing others that we are here and this is doable. Once I realized this was an important motivation for me, I knew that I had to get better at public speaking, because that’s such an important way to scale myself as a role model. Public speaking used to terrify me. I used to hate public speaking. But because it’s such a key way to reach large numbers of people, I told myself I had to learn to like it, and since then I’ve learned to be an effective public speaker and have actually fallen in love with it. It’s now one of the most exciting things I do ‐ it’s like a roller coaster; everytime I do it, I get nervous, but it’s a thrilling, fun type of nervousness and I get a huge rush while I’m doing it.

Do you think about building your external brand?

I have a couple of friends that spend time building their external brand, one of whom is getting back into it right now. He realized that his work at Uber was so intensive that he’d pushed external work to the wayside.

I’m a bit more passive about it. 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. I tend to think through speaking, so writing this way requires a lot of preparation to organize my thoughts, and I’ve not spent much time doing it externally so far.

You first got the title strategic advisor at your current company. Were you hired as a strategic advisor? If not, what was the process of getting promoted to that role?

My path was completely unorthodox. It wasn’t planned, and there re‐ ally isn’t a reproducible pathway to it, more of a fortunate series of events. Previously Rob Punkunus was in the same role, and when he decided to leave he was asked by Matthew to suggest potential succes‐ sors. He suggested me and Kate, and both of us ended up serving in the Strategic Advisor role.

Matthew and I had already had several positive interactions before that, where we’d started to identify that we had similar views and val‐ ues. For example, at one point we had a rash of nasty comments sub‐ mitted anonymously to our Questions & Answers meeting, and it really bothered me to see our culture heading that direction. I stood up and spoke at one of the Q&As asking folks to find a more constructive way to surface their concerns, and I think that resonated with Matthew.

When he first suggested that I take the role, I had a ton of imposter syndrome about it. I tried to get him to rescind the offer, thinking it wouldn’t be a good fit, but ultimately I did accept and have been in the role since.

What two or three factors were most important in you becoming a strategic advisor? How have the companies you joined, your location, or your education impacted your path?

In addition to Rob’s recommendation, the most important factor was doing visible work that aligned with Matthew’s values. One project I worked on was joining the working group to understand and improve SRE’s culture back in 2017. The working group was already planned before Susan Fowler’s blog post went out, and our first meeting was coincidentally three days after she posted it. I really think the culture working group did some great work, work which myself and the other group members are extremely proud of and over eighteen months we really moved the culture of a hundred person organization in a mean‐ ingful way.

Additionally, I’ve always just been personally fascinated with things in the realm of both culture and human psychology + behavior. In my career, at the companies I’ve worked at, culture + group psychol‐ ogy has often been the hidden x‐factor that turns organizations from good to great. I’d already been satisfying my own personal curiosity in the area with books and papers on things like behavioral economics, behavioral science, etc, so that natural interest has helped nudge me towards where I’m at now.

Can you remember any piece of advice on reaching Staff that was par‐ ticularly helpful for you?

Throughout my career people have always told me that I’m much more impactful and have more potential than I realized. I never listened to that, and for me, as well as many other engineers, especially engineers that are minorities, we spend a lot of time doubting ourselves. It’s so easy to only see the bad parts. We might not recognize when we’re in a meeting and speak passionately about something, and that people are really listening to us. It really helped to have people keep telling me that I didn’t realize the impact I was having, that my viewpoints were not only valid, but actually influential in the organization.

Another thing that’s helped is having mentors. Specifically I like men‐ tors 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. These have generally been managers who I’ve worked with, but where we’ve been able to mutually learn from each other.

What about a piece of advice for someone who has just started as a Staff Engineer?

This goes back to how I got where I am based on having a broad set of interests in organizational psychology, culture, mentorship and so on, in addition to the technology. I’ve never been a pure engineer that’s just deep in the code 24/7. I’ve never been that person, and I had to make my peace with that.

For me it’s been important to follow my passions. Recently that’s been around mentorship, but it’s also been around other things like ma‐ chine learning, which has always been a hobby of mine. I love how machines can generate insights that mimic how people think ‐ it’s the perfect marriage of my interests in technology + psychology.

So I have these passions that I stoke, and then when opportunities to align those passions with something the company needs arise, I take them. For example, my previous team at Uber was generating insights into fleet utilization for capacity planning purposes, and that a great chance to pull together my interest in machine learning and site relia‐ bility.

Small companies give you the chance to do many different things, but at a certain size companies also give you the unique opportunity to spe‐ cialize in your passions, and that for me has allowed me to maintain both impact and passion despite never being the person to sit beyond the keyboard and knock out code all day.

Did you ever consider engineering management, and if so how did you decide to pursue the staff engineer path?

It’s something that I think about sometimes, even now it’s something I’m thinking about. It’s on my list of possibilities, and throughout my career folks have asked, “Have you considered moving into manage‐ ment?”

What I want to focus on right now is becoming effective as a high‐level, big‐picture leader. Eventually I’d like to develop the people manage‐ ment skill set too, maybe somewhere in the medium future. The thing that appeals to me is that human behavior excites me to no end, and people management is a great opportunity to spend time on that.

What are some resources (books, blogs, people, etc) you’ve learned from? Who are your role models in the field?

You know, for the first two‐thirds of my career I used to love reading as much technical content as I could. I would be on YCombinator or my RSS feed all day reading about distributed systems, reliability, etc. These days I’m much more into reading about behavioral economics, behavioral science, human psychology, organizational strategy and so on. Some people I really enjoy in those realms are Daniel Kahneman, Tim Harford, Dan Ariely. There are also some amazing podcasts out there ‐ Freakonomics, Choice‐ology, Hidden Brain.

Also, last year I started compiling a reading list of books about the hu‐ man brain and behavior which I share with anyone who’s also inter‐ ested in the topic(s).

I do still keep up with r/linux and r/programming on Reddit, which have replaced RSS feeds for me in discovering new things to read.

Nelson Elhage - Formerly Staff Engineer at Stripe

April, 2020 twitter, blog

Tell us a little about your current role: your title, the company you work at, and generally the sort of work your team does?

I was most recently at Stripe. They do online payment processing, and it’s a pretty fast growing startup of about two thousand people. Engi‐ neering was around six hundred. When I left, I technically didn’t have a title. If I had stayed another two months, I would have been a Staff Engineer, because they finally rolled out titles after some years of in‐ ternal debate.

The team I worked on most recently was called Payment Architecture, which was a team of three or four fairly senior engineers. Payments are the core of Stripe’s product, and we looked after the payments code‐ base. We were particularly focused on the financial infrastructure lay‐ ers of the codebase, and building the data model and abstractions we needed to support all of Stripe’s current and aspirational product lines.

We looked at how code structure fits into organizational structure, in‐ cluding how to structure code within a rapidly growing organization that was adding teams, products, countries, and payments methods. It was particularly important that our architecture support spreading ownership across a number of offices and timezones.

We drove a lot of initiatives around code quality and code architecture, and did some implementation and rewrite projects. For each of those initiatives, we developed metrics and goals, got teams to take on those goals, and then gave teams tools to help them migrate to the new stan‐ dards.

Was the “Payments Architecture” team a permanent team or more of a project team?

A little bit of both. It wasn’t a super tactical team with a narrow project or scope to its mandate. But it was also unlikely to last forever as a team. We were taking an experimental approach to evolving our ar‐ chitecture, with the goal of revising and updating our approach as we went. We hoped that the team would eventually work itself out of its job.

What does a Staff‐plus engineer do at your company?

It’s hard to say with too much confidence because Stripe was only just introducing titles. It wasn’t public who was a Staff Engineer, but you did have a sense of who the senior engineers were based on the people working on the most significant, impactful things.

There are some clear Staff Engineer archetypes. One is working on deep technical projects, maybe scoping out or building new pieces of infrastructure. Before the Payment Architecture team, I worked on building Sorbet, which is our static Ruby type checker. I spent about a year with two other senior engineers building that from scratch, which was a good example of the deep, highly leveraged technical work archetype.

There were also Staff Engineers who spent time wrangling cross‐ cutting projects, serving as a combination of architect and project manager to pull together different parts of the organization to work on a large problem. Typically these problems weren’t well‐aligned with our current architecture or organization such that they required collaboration across many different teams.

There were also Staff Engineers who worked with one team, or a small group of teams, and they served as the keepers of the team vision. They’d identify what the team was building towards, and where they wanted to be in one to five years. They’d work across the organization to build and share that vision, then work to implement it.

How do you spend your time day‐to‐day?

This looked very different between the Payment Architecture role and the Sorbet role. Sorbet was more of a “heads down and code” project. On Payments Architecture, there was still some amount of coding be‐ cause we had a specific approach that we wanted to both try out and to demo the ideas that we were pushing for.

I did a decent amount of project management as well. Things like tend‐ ing to the task tracker, running the daily stand up, figuring out who needed help or who was blocked. I also spent time being communica‐ tion glue across the company and engineering organization, especially talking to teams that were interested in the tools and patterns we were building and advising them.

In that effort, I spent time in various meetings figuring out the tech‐ nical strategy, and also a fair amount of my week writing design doc‐ uments on the problems we saw along with promoting the shape of architecture that we thought would solve them. Finally, I worked to explain and sell those ideas to leadership and other teams, as a way of setting the agenda and advocating for their investment and prioritiza‐ tion.

Where do you feel most impactful as a Staff‐plus Engineer?

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.

That said, it’s hard to know whether that was truly the most impact‐ ful project. There’s a more nebulous argument that the architecture strategy work will be more impactful in the long run.

What’ssomethingyou’vedoneasaStaff‐plusengineerthatyouweren’t able or allowed to do in earlier roles?

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

But that said, both Sorbet and the Payments Architecture team were relatively ambitious projects. Sorbet for example required pulling three senior engineers off of more concrete projects. Starting them required high levels of organizational respect and trust to get permis‐ sion and support to pull the team off their existing work and having them instead work on these projects for a year.

Do you spend time advocating for technology, practice, process or ar‐ chitectural change?

This is somewhat seasonal around the planning process. Prioritiza‐ tion ultimately means staffing, and staffing decisions happen during planning.

The planning season was a particularly acute period, but I was more or less continually thinking about prioritization at the engineering‐wide level. It might be noticing a problem that a lot of engineers were en‐ countering, or seeing something that was slowing teams down. It was a constant, recurring thread that I thought about and it would period‐ ically become an acute priority where I’d spend time advocating for a team to be created or to work on a problem.

How have you sponsored other engineers? Is sponsoring other engi‐ neers an important aspect of your role?

That wasn’t an angle that I spent a lot of time thinking explicitly about in those terms, and I can’t think of clear examples where I would de‐ scribe that as what I was doing. An adjacent thing that I did a couple of times was helping to bootstrap teams that I wasn’t part of. For ex‐ ample, some team would spin up to take over a system that used to be part my capacity, and I would work with them in a close advisory role to give them context and advice.

You first got the Architect title at Oracle after the Ksplice acquisition. What was your process for getting both the Architect title?

I don’t remember if Ksplice had titles in place pre‐acquisition. After the acquisition I spent one year at Oracle and had the title Architect, which I think at the time was their highest individual contributor level. There was definitely some acquisition title inflation going on there. I don’t know if I would have reached that title if I had not come in via acquisition.

After Ksplice was acquired by Oracle and you became an Architect, did the work you were doing on a day‐to‐day basis change from before the acquisition?

I was broadly doing the same style of work. The thing that changed was that I spent a lot more time interfacing with the Oracle Linux orga‐ nization within Oracle. I was focused on figuring out how our product would integrate with theirs, and also bringing them up to speed on our technology so that they were able to use it. I had previously spent time training new hires, but that was a much slower rate than what hap‐ pened at Oracle which was, “We’re dropping you into this 400‐person org, and now training them is a big part of your job.”

What two or three factors were most important in you reaching Staff?

The specific path I took was very dependent on coming in quite early at Stripe. I was roughly employee #30. The thing that I did with that though, which I think is not identical to what everyone else did, is I tried to build very broad context and awareness across Stripe. That was comparatively easy to do, when there were 15 engineers; there weren’t that many things then.

But I spent a lot of effort as the company grew trying to stay aware of everything that was going on in engineering: the interactions between teams, the scaling pain points. I tried to have an unusually global per‐ spective. That helped me know which problems were important to work on and especially what the one level removed important prob‐ lems were. If I knew the organization had a goal of launching a spe‐ cific 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.

As the organization got really big, seeing those one level removed de‐ pendencies got increasingly hard, and trying to keep a broad view and systems level view helped with that. It also helped me connect teams together, making me a router of information and ideas, as well as an originator of proposals.

Many teams get stuck looking at their section of the world, and have a less developed conception of how their internal customers are in‐ tegrating with them. This happens because they’ve never worked on the internal customer teams they support. I helped bring teams the context of how other teams truly used their systems, and connected them to other people across the organization whose perspectives they should gather,

It’s hard to keep all this context as the organization grows, but it’s even harder for someone who didn’t start building that global context when the company was smaller. By starting early, you have a huge compet‐ itive advantage relative to someone starting later who tries to reverse engineer the architecture and organizational dependencies.

When I spoke with Keavy McMinn, one interesting point she made was that sometimes it’s helpful to be able to see things without the full his‐ torical context. Did you ever find that your context made it harder to move forward?

Absolutely. I would notice myself coming into conversations with a team and I was prepared to give them a seven year history of every time someone had attempted the thing that they’re doing and why it didn’t work. It would take deliberate effort to review that history and ask myself, “Why is this information helpful or relevant to them?”

Sometimes the information isn’t useful. On the other hand, if some‐ one tried to do this thing and died on the rocks, there may be some really hard technical problem that’s still around. There might be some value in pointing out the rocks, but also there’s a lot of value in having the audacity to try again because it’s years later and we’ve become a different organization.

There is a popular idea that becoming a Staff Engineer requires com‐ pleting a “Staff Project.” Did you have a Staff Project, and if so what was it?

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.

Maybe my closest thing to a Staff Project is that I got my final pro‐ motion for work on something called the “Data Model Stripe Release Plan.” I led this six month long plan to get a bunch of teams to co‐ ordinate on a handful of projects addressing the weaknesses in our data models, and advancing the data model in ways that would, aspi‐ rationally, be transformative.

I don’t think it’s a great instance of a Staff Project in some ways. For one, we did good work, but it was much less transformative than any‐ one hoped due to a combination of reasons. Some of which were in my control and some of which were that the problems were just too hard and the organization didn’t have the resources to actually fix them in six months.

While that project wasn’t necessarily better work than I did in other halves, it was a very visible, high profile role. It created visibility and increased my standing in the company in important ways.

Can you share a piece of advice on being a Staff Engineer that was help‐ ful for you?

One lesson that I learned was the importance of focus and prioritiza‐ tion. That’s especially true when you have the broad organizational context that I talked about earlier. It’s very easy at any moment to iden‐ tify thirty different things that you would like to be working on.

Occasionally you can push each of those thirty things forward a little bit. And that’s productive for a while, but you need to be careful. If these are things that aren’t getting worked on and that you think should get worked on, you’re going to have much better luck picking one of them at a time and really focusing your effort rather than pushing a little across many different projects at once.

One big distinction is whether there are already teams working on those thirty things. If there are already teams working on them, but not in the direction that you think is effective, you can get a lot of lever‐ age out of going to those thirty teams and helping unblock them.

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.”

What about a piece of advice for someone who has just started as a Staff Engineer?

One thing is that I’m a huge believer in the primacy of Conway’s Law to guide organizations’ technical architecture.

Another is to build and invest in your relationships with engineering leadership: the managers, the directors, and the vice‐presidents. I think some of this might be specific to organizational structure, but certainly at Stripe those people often had a lot of implicit power be‐ cause they were the obvious people to go to with questions. They also have a lot of influence over staffing and prioritization.

It’s important to have good relationships with them both so that you can influence them with your ideas, but also so that you can under‐ stand what problems they’re seeing. You need to know what their in‐ centives are, and what problems they perceive that you don’t perceive. Having better alignment with leadership makes a lot of things much easier.

Something else that has been quite valuable for me is estimation. I find it really valuable to be able to look at a system and have the habit of estimating how many gigabytes‐per‐second is this thing, or how much storage would this data take? You don’t have to get it perfect, getting the nearest power of ten is usually enough to be useful.

Did you ever consider engineering management, and if so how did you decide to pursue the staff engineer path?

I considered it but not very seriously. I have a pretty good understand‐ ing of myself that, at least for now, I wouldn’t really enjoy that work. I think I’d find all the interactions not a sustainable way to spend my time. I occasionally wish I was more interested in it, because I do per‐ ceive it as a way to get a lot of power, but I fortunately have enough self awareness to believe, I think correctly, that I wouldn’t enjoy it and therefore wouldn’t be good at it.

What are some resources (books, blogs, people, etc) you’ve learned from?

I get that question decently often because I have an unusually broad breadth of general knowledge, and I don’t have a good answer for where it came from. I’m pretty voraciously curious about computing, software and architecture. I read lots of different things, and I spend more time reading links on software engineering Twitter than

perhaps is healthy.

It’s also been really valuable for me to cultivate a good personal net‐ work of other senior engineers. I chat with them informally about whatever it is that we’re working on and thinking about. When you have personal connections, you can get very unvarnished views of the problems people are seeing and the solutions they’re considering.

I’ve mostly bootstrapped this through the friends‐of‐friends networks of people I’ve known professionally or going all the way back to when I was in school. It’s not something I sought out post facto.

I read the occasional technical paper, but it’s not something I do ac‐ tively. It’s mostly when it’s referenced by someone or comes up in some other context. It’s definitely not something I make any effort to keep track of systematically or to review the recent publications. I do think that having a decent handle on the quote unquote foundational literature is really handy.

Diana Pojar - Staff Data Engineer at Slack

April, 2020 blog, twitter, linkedin

Tell us a little about your current role: your title, the company you work at, and generally the sort of work your team does?

I’m a Staff Data Engineer and the Technical Lead for the Data Platform team at Slack. I joined Slack in February 2016 and I was one of the first engineers in the Data Engineering team. I was heavily involved in building many of the tools and infrastructure to make data available for long‐term analytics. When I joined, the team had just made the decision to use Thrift as the logging format. If anyone wanted to get insights, they had to schedule cronjobs on top of the read replicas of the production MySQL database.

The purpose of the Data Engineering team at Slack is to enable anyone in the company (data science, engineers, product managers, etc) to access data, so they can compute insights, drive business decisions or build new features. The Data Platform team focuses on building services and frameworks that work at scale to empower everyone that needs to process or use data in the Data Warehouse. Some things that our teams own are: the Data Discovery service that exposes task, table, column lineage and general metadata, the event logging structure and the pipeline that consumes the events and exposes them in raw tables in the Data Warehouse.

What does a Staff‐plus engineer do at Slack? How do you spend your time day‐to‐day?

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

There are two big categories that I’ve seen Staff‐plus engineers fall into: focus more on depth (specialist) or focus more on breadth (generalist). For the first category, folks that focus more on depth are usually ex‐ perts in a particular domain and most of their time is spent on writ‐ ing code or working on technical design documents to find solutions in their area of expertise. Companies deal with unique challenges and subject matter experts are needed to drive technical solutions for these extremely hard problems. For example, at Slack, as the com‐ pany grew and our system needed to scale and perform, there is a principal engineer that his main focus and passion is to detect and fix performance problems.

Folks that focus on breadth usually work more closely with the lead‐ ership team, influencing the org or company wide technical vision, improving processes and culture. Due to their breadth, they are more flexible and can work on different areas of the engineering organiza‐ tion based on the company priorities and needs.

Personally, for now, I enjoy and focus more on breadth and how I spend my time depends a lot on what my team and organization needs. I would say that so far this year, about 50% of my time is spent on technical leadership and talking with people about larger technical in‐ vestments that we should focus on, and 50% of my time is focused on mentoring, reviewing code, writing code, jumping on incidents and fixing critical issues, etc. The ratio does change quarter by quarter.

Where do you feel most impactful as a Staff‐plus Engineer? What’s something you’ve done as a Staff‐plus engineer that you wouldn’t have done earlier in earlier roles?

Personally, I feel that it’s quite noticeable the increase in trust and re‐ spect from people that did not work with me before my promotion / title change. Having the title strongly correlates with one’s ability to in‐ fluence the organization/company roadmap and priorities ‐ basically you get to be in the “room where it happens”.

I get to be part of building things that have impact for the direct suc‐ cess of the company. Advocating for such projects and being part of them was not something that would’ve been achievable in earlier roles.

I’m also able to uplevel others that are more junior and make their voices heard. Having a Staff+ title brings some privilege that others don’t have and I try to leverage that to help uplevel my team / peers.

Do you spend time advocating for technology, practice, process or ar‐ chitectural change? What’s something you’ve advocated for?

A significant amount of my time is actually spent on advocating for technical solutions, processes, architectural or cultural changes ‐ it’s not only all about writing code. I’m constantly involved in the tech‐ nical design review process for many of the teams that need to build systems that rely on the Data Engineering tools and services. Besides being involved in advocating for technical projects, an area of my fo‐ cus is to improve culture or process changes.

One area that is dear to my heart and that I believe I had a significant role in my organization is around Incident Management and Analy‐ sis. I’ve been involved with the company’s resilience team to improve our Incident Analysis processes, but for my Data Engineering organi‐ zation I was very involved in driving our general oncall expectations and structure, while also adopting the company’s Incident Response Structure.

How have you sponsored other engineers? Is sponsoring other engi‐ neers an important aspect of your role?

Sponsoring is actually an important area for me, as I focus on build‐ ing amazing relationships with many people that I work with and I strongly believe that we need to lift each other up. Through my jour‐ ney to get to Staff Engineer and fighting with my own impostrome syn‐ drome, I had the opportunity to work with amazing people that spon‐ sored me and had a huge impact on my growth. A couple of people that I worked with and have been my mentors and role models over time are Josh Wills, Stan Babourine, Bogdan Gaza and Travis Crawford.

Mentoring and growing people around me has always been important to me and being in a Staff+ role, you have a type of privilege and power that others don’t have and I try my best to use this to help and uplevel people around me.

You first got the title Staff Engineer at Slack. Were you hired as a Staff Engineer? If not, what was the process of getting promoted to Staff?

I joined Slack as a mid level engineer and after one year I got my Se‐ nior promotion. As a Senior Engineer I had the opportunity to work on multiple projects with org/company wide impact, many of them that were directly tied into how our company business metrics are be‐ ing computed, which were critical for getting the company ready to go public.

After being 2 years in the Senior role, my manager told me that I am op‐ erating at the next level and that he believed there was a strong case to make and he planned to put me up for promotion. At Slack, the Staff+ Engineering promotions need to have a promo package put to‐ gether that illustrates with clear details and measurable information that a person operates at a certain level. The main areas of focus are: Technical Quality, Impact, Collaboration and Execution. We worked together to write and fill in all the necessary details for the promotion package. As an IC, I highly recommend, if it’s possible, to work with your manager and write this document together: it should be a team effort. After the packet is ready, the promotion package is evaluated by a special promo committee where some leadership and staff+ engi‐ neers from the whole company are present.

What two or three factors were most important in you reaching Staff? How have the companies you joined, your location, or your education impacted your path?

As I look back and contemplate on how I felt and thought about this when I was a junior engineer, the main factor to get to Staff Engineer is to actually believe that YOU CAN DO IT and don’t let the impostrome syndrome win.

In general, I’ve always tried to be very intentional with my career choices and usually I spend some time every year to think about what I’m doing and the areas of growth that I want to focus on. I’ve found this extremely valuable, because it makes me take a step back and assess what I am currently doing, to ask if I’m still growing in my current environment and think about new opportunities.

So at the end of 2015, when I decided I wanted to leave Twitter, I found out that Slack was starting to build their Data Engineering team. Being able to build and design from scratch the systems, services and frame‐ works was extremely exciting for me. Joining a newly‐formed team at Slack was a unique opportunity that definitely contributed to reach‐ ing 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 Engi‐ neer 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. Build‐ ing a track record of mentoring, visibility and technical quality in ev‐ ery project also contributed to my path towards Staff, I did not see my job as just a job, but I’ve put a lot of passion into every project or prob‐ lem we tried to solve.

There is a popular idea that becoming a Staff Engineer requires com‐ pleting a “Staff Project.” Did you have a Staff Project, and if so what was it?

No, I did not have an assigned “Staff Project” and that is not something that it’s part of the promotion process at Slack. There is a career ladder that describes the general expectations and scope of impact for every level and with Staff+ levels this level of scope starts to expand from org wide impact towards company wide impact.

I usually always try to challenge myself and I was always looking to drive change and impact in my organization. I think the most impact‐ ful project that I worked on and contributed to my path towards Staff Engineer was being involved in thinking through and implementing the technical design on how our company business metrics (ex: ARR) are computed to make sure the process is reliable, scalable and most importantly, reproductible. This was a critical initiative as Slack was completing a public company readiness process.

Can you remember any piece of advice on reaching Staff that was par‐ ticularly helpful for you? Looking back, is there an easier path to Staff that you could have taken?

Something that I felt was extremely helpful was to understand that a Staff+ Engineer’s work and responsibility is more than writing code. Basically what got you to senior level will not get you to Staff+. It’s im‐ portant to understand the expectations of this role in your company, but also in the industry as a whole, as there are some differences be‐ tween companies.

Work with your manager or more senior peers to find projects that will challenge you and increase the scope of your work. Something that was extremely helpful to me is that I started investing in developing my leadership and communication skills more. I also started framing and thinking about certain things in a different way, when I was start‐ ing feeling stressed or unsure of my own abilities, that’s often a sign that I’m growing and stumbled into an area that offers a lot of growth opportunities.

What about a piece of advice for someone who has just started as a Staff Engineer?

Reaching Staff Engineer brings a lot of responsibility and you should always be a strong advocate for your peers. As an IC, I think execu‐ tion and being hands on are always the “easy” thing to do and the hard things are actually driving change and impact in your organization.

I think that in different moments of your tenure as a Staff engineer, you might see yourself focusing on different things and that is ok and expected. There’s not a single clean cut definition of what a Staff Engi‐ neer should do.

Did you ever consider engineering management, and if so how did you decide to pursue the staff engineer path?

This is actually a question that I ask myself every couple of years. Every time that I self‐reflect and think about the answer to this question, the answer, for now, is no ‐ I don’t want to be a manager. I love coding too much and I strongly believe that to be a successful manager you should not write code, and should instead be fully focused on growing your team. I like being involved in technical decisions and thinking about technical solutions way too much to give up this hands‐on experience, even though as you get in more senior roles, the time you spend coding will decrease.

Not being an Engineering Manager doesn’t mean that you cannot influ‐ ence and help people grow. As a Staff+ engineer you do need many of the core management skills, even though you are not a manager and I have found reading management books extremely helpful. I actually think that these two roles, even though they are on separate, parallel tracks, they are closer to each other than people think.

It’s possible that at some point in time, the answer to this question might change and that is ok.

What are some resources (books, blogs, people, etc) you’ve learned from? Who are your role models in the field?

I use Twitter extensively, but I’m mostly a consumer and follow many people in tech. I usually follow people that I saw talking at confer‐ ences or I worked with and I find their content relevant to me. Here’s a couple, in no specific order: Camille Fournier,Lara Hogan, Josh Wills, Vicki Boykis, David Gasca, Julia Grace, Holden Karau, John Allspaw, Charity Majors, Theo Schlossnagle, Jessica Joy Kerr, Sarah Catanzaro, Orange Book

I also enjoy reading (I read about 50 books each year) and since last year, I always try to leave a mini review on my Goodreads account for every book I read, but here are a couple of books that I found useful:

• Thanks for the Feedback

• Radical Candor

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

• Leadership and Self‐Deception: Getting Out of the Box

• The Coaching Habit: Say Less, Ask More & Change the Way You Lead Forever

• First, Break All the Rules: What the World’s Greatest Managers Do Differently

• The Courage To Be Disliked: How to free yourself, change your life and achieve real happiness

• Give and Take: A Revolutionary Approach to Success

• Mistakes Were Made (But Not by Me): Why We Justify Foolish Beliefs, Bad Decisions, and Hurtful Acts

Dan Na - Staff Engineer and Team Lead at Squarespace

March, 2020 blog, twitter, linkedin

Tell us a little about your current role: your title, the company you work at, and generally the sort of work your team does?

I’m a Staff Engineer at Squarespace. Squarespace is the leading all‐in‐ one platform to build a beautiful online presence: websites, domains, online stores, marketing tools, scheduling appointments, etc. I also operate as the Team Lead of the Internationalization Platform team, which is responsible for building and maintaining the foundational primitives of internationalization across Squarespace products. Engi‐ neers use the tools and libraries we own to create localized products.

What does a Staff‐plus engineer do at Squarespace? How do you spend your time?

I think in practice the day‐to‐day responsibilities of Staff‐plus engi‐ neers vary, depending on both your precise role and how your respon‐ sibilities map in the organization.

My position as a Team Lead means I’m fully accountable for the out‐ put of my team, both from a business and technical perspective. On the business side, I spend a lot of time meeting with different teams and functions across the company. These stakeholders include prod‐ uct, strategy, customer operations, etc. I want to ensure that I have as many inputs as possible to validate that my team’s roadmap reflects our company’s most important priorities.

On the technical side, I often find myself reviewing technical docu‐ ments or scoping work in front of a whiteboard for my team’s work in flight. My role has evolved to less hands on coding work and more ask‐ ing probing questions about architectural decisions and deployment strategies. One irony is that as a Staff Engineer I actually code signif‐ icantly less than I did as a non‐Staff. By no means is that universally true across the role, but in the context of my team, closing vim and op‐ erating in more of a strategic/oversight role was the highest leverage use of my time. I’m lucky in that my team is already composed of awe‐ some engineers so my specific code contributions are less material to our output.

But many Staff‐plus engineers at Squarespace are not Team Leads and code a lot. Others focus on engineering process and culture. In gen‐ eral I’d say Staff‐plus Engineer responsibilities are highly contextual.

Where do you feel most impactful as a Staff‐plus Engineer? What’s something you’ve done as a Staff‐plus engineer that you weren’t able to or wouldn’t have done in earlier roles?

I have a seat at the table at higher level engineering discussions that occur at a level above individual projects and teams. We have recur‐ ring staff engineering meetings where we discuss problems that span teams which are both technical and non‐technical in nature. As a hy‐ pothetical example, I’d feel comfortable surfacing what I perceive as shortcomings in the engineering onboarding process in this type of meeting. It can be hard to attribute a topic like engineering onboard‐ ing to a specific team but a lack of formal ownership doesn’t make it less important. I think a key responsibility of Staff‐plus is a willing‐ ness to own all of the things that contribute to (or block) engineering output, which includes both technical strategy and culture.

Regarding something that’s changed, on an everyday basis my title af‐ fords a high level of credibility at the outset of conversations. While I’m not advocating for a culture that values titles over ideas, I’d be lying if I said it didn’t help me escalate or push through issues that I previ‐ ously might’ve had a harder time getting through.

Do you spend time advocating for technology, practice, process or ar‐ chitectural change? Can you share a story of influencing your organi‐ zation?

I don’t really think about advocacy in terms of categories. I mostly just want our engineering team and product to be the best it can be and address things that experience tells me I can help change. Some examples:

• When I first joined the company we were in the midst of enormous employee growth, and I noticed it felt hard to get to know anyone on other teams unless you happened to work on a project together. 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.

• I knew based on personal experience that engineering leader‐ ship roles can feel isolating and talking to coworkers I could hear some of those feelings of loneliness. As a result some peers and I created an unofficial Engineering Management Book Club, open to Team Leads and Engineering Managers. There are now two self‐organized book clubs with ~10 participants each, providing a safe space for both new and experienced leaders to support each other. The feedback about book club has been enormously positive.

To be fair, neither of these examples required a Staff‐plus title. But I do think part of being an effective Staff‐plus engineer is caring about and addressing cultural gaps as much as technical gaps.

You first got the title Staff Engineer at Squarespace. What was the pro‐ cess of getting promoted to Staff?

I was hired as a Senior Software Engineer II (one level below Staff). I was fortunate to land on a team working on a high impact project that I was able to contribute to immediately. The hardest parts about the project concerned a problem space I was already familiar with — wide, sweeping changes across codebases — and I proposed, prototyped and eventually shipped an alternative architecture that I felt would better position the company for success. That became our frontend transla‐ tion system, which I wrote about on our engineering blog: Building a System for Frontend Translations.

I also owned the communication and education effort around the new translation system, presenting the architecture at internal meetings and sending relevant emails about the status of the project. Grouping this technical contribution to some meaningful cultural initiatives — other internal presentations, #connect‐engineering, etc. — my man‐ ager had a good case for promotion that was agreed upon by the Engi‐ neering Directors.

What about a piece of advice for someone who has just started as a Staff Engineer?

I feel like progressing up a career ladder is an additive exercise in forc‐ ing you to care about more things than you previously cared about. Caring about more things is hard.

As a trivial example: The intern cares about the small aspect of a feature they can build in three months. The full‐time engineer on the team cares about the entire lifecycle of that feature. The team lead/manager cares about the suite of features that compose a product. The director cares about the suite of products owned by their organization. And so on.

Every rung up the ladder means you care about another layer of ab‐ straction, in addition to caring about all the layers beneath your cur‐ rent one.

I feel like a Staff Engineering role is similar in that you’re leaving the comfort zone of a specific technical domain to a more general prob‐ lem domain: engineering. And as leaders you’re leaving a potential technical comfort zone to the realm of the system of challenges that impact engineering output. What are the biggest problems holding back engineering teams that fall between the cracks of team owner‐ ship? Those are your problems now, in addition to all of the problems of your technical domain.

So while Staff is an aspirational title to achieve, it also includes signif‐ icant added responsibility. You’re a leader now, whether you want to be or not.

How have you sponsored other engineers? Is sponsoring other engi‐ neers an important aspect of your role?

I think sponsorship is a key responsibility of any senior role and ma‐ terial to the growth of any engineering organization. I suppose the definition of “sponsorship” varies, but to me one tangible way is to provide opportunities for exposure. For example:

• Giving less senior teammates the opportunity to own and present their work at wider meetings.

• Reaching out to a team who just shipped an awesome feature to write a post for our engineering blog.

• Encouraging someone I met in a #connect‐engineering coffee who has unique experience or perspective to give an internal pre‐ sentation.

• Ensuring that meetings are not dominated by the perspectives of a vocal minority and soliciting opinions from everyone in the room.

• Giving public kudos in a large slack room to someone who just did something great that everyone didn’t see.

Lara Hogan has a great post on sponsorship in practice: What does sponsorship look like?

Did you ever consider engineering management, and if so how did you decide to pursue the staff engineer path?

Yes, and I still actively consider it. I know it’s more convenient to think about the two ladders as mutually exclusive but I don’t.

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 engineering 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 engineering 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.

I think one of the most important strategic skills for building software is the ability to converge towards pragmatic decision making. A fail‐ ure mode I’ve seen repeatedly is when a product manager comes with business requirements and an engineer comes with technical push‐ back and neither are willing to budge. The ability to empathize with both sets of incentives and navigate that tension is the only way to get anything done, and the best way to build that empathy is to sit in both seats.

To specifically answer this question: my previous role prior to join‐ ing Squarespace was an Engineering Manager. I love being an Engi‐ neering Manager but I wanted to keep my technical skills sharp so I accepted an IC role. Then I was promoted to Staff.

What are some resources (books, blogs, people, etc) you’ve learned from? Who are your role models in the field?

In the context of engineering leadership, two books stand out.

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. Many ideas from

Grove’s book have significantly shaped how I view work and leader‐ ship: “the measure of a manager is the output of the organization underneath them,” “delegation is not abdication,” the concept of engineering/managerial leverage, etc. In terms of communicating the tactical aspects of engineering leadership I still think Grove’s book is best.

On the human side of leadership, I really loved Lara Hogan’s book: Re‐ silient 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 psycho‐ logical safety, and sponsoring coworkers. And having worked directly under her for close to four years, she is totally the real deal and prac‐ tices what she preaches.

In terms of non‐books, I subscribe to and enjoy reading “Irrational Exuberance”, where Will Larson regularly blogs about engineering management with a highly pragmatic and strategic perspective. I’ve also recently discovered and enjoyed reading Marty Cagan’s “Insights Blog”, mostly because product leadership is a domain I’m less familiar with and am interested in learning more about.

My role models are some of the amazing coworkers I’ve worked closely with over the years. I sat next to Daniel Espeset for four years at Etsy and learned an immeasurable amount about coupling technical exe‐ cution with cultural impact. I learned a lot watching Lara do things like advocate for and achieve pay equity across our engineering group. I learn a lot watching current coworkers like Tanya Reilly institute and evolve our engineering processes to match our ever‐growing scale. I’m inspired most by people whom I’ve personally witnessed have the courage to change companies for the better, despite whatever friction they encountered along the way.

Joy Ebertz - Senior Staff Software Engineer at Split

March, 2020 blog, twitter, linkedin

Tell us a little about your current role: your title, the company you work at, and generally the sort of work your team does?

I’m a Senior Staff Software Engineer at Split.io, working on the back‐ end of what we call the COE team. Split is a feature flagging and exper‐ imentation framework. We focus on enabling our customers to sep‐ arate deployment and release in CI/CD and also enabling A/B testing. My team is responsible for most of the main business logic of our web application, including everything from data storage to the APIs. There is a separate team that focuses on the experimentation side, including all of the detailed statistics that goes into that, so we’re able to focus more on the main platform.

What does a Staff‐plus engineer do at Split? How do you spend your time?

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 work‐ ing with other engineers to define a lot of our longer term architecture and strategy, including our future API and platform strategy, how we want to develop our authorization framework, breaking up and decou‐ pling our builds and more. I’ve recently also taken over leadership of our backend chapter and now co‐lead it with another engineer and we’re working to put together a backend technical vision, prioritize tech projects and lead standards discussions. If that wasn’t enough, I also continue to write regularly on my blog and speak at conferences.

Where do you feel most impactful as a Staff‐plus Engineer? What’s something you’ve done as a Staff‐plus engineer that you weren’t able

to or wouldn’t have done in earlier roles?

I feel most impactful when I can facilitate setting a technical vision for an area and get people moving toward that vision. I think we would all agree that we want our code to be better architected than it is or im‐ proved in some way. However, I’ve found that often people have some vague sense of wanting better without having a clear idea of what that thing they want is. I like to help the group decide on a shared under‐ standing of where exactly they’re trying to get (it’s actually okay if we never get there) and come up with a general game plan of how to get there. This way we’re all marching in the same direction. Having a clear idea of what we want allows us to work with Product to get it pri‐ oritized. Even if we never get the whole thing prioritized, knowing how to get there, allows us to slowly make changes that will lead us in that direction. For example, if I’m touching a file anyway and can make a few tweaks that brings me closer to that vision, I will. Without knowing that vision, those tweaks would never happen. The vision alone isn’t enough, we need everyone to understand that vision and internalize it. Part of the power of those small changes I just men‐ tioned is if everyone is making them as a part of their normal coding. Suddenly we have everyone working toward a common goal.

I think the biggest thing that differs between now and when I was more junior is my sense of ownership and responsibility. I’ve always been willing to push back or to drive for improvement. However, when I was more junior, I would often just assume that something was someone else’s problem. Now, it’s all my problem. I may choose to not prioritize something because I think that it’s less important than something else, or I may choose to delegate or pass a problem off to someone else, but I still see it as my problem. I no longer ever assume that someone else will handle something. I’m still a big believer in picking my battles, I won’t work on everything ‐ that’s too much. I also, however, won’t assume that anyone else will either, so if it’s worth getting done, it’s up to me to either do it or to pass it on to someone else.

Do you spend time advocating for technology, practice, process or ar‐ chitectural change? What’s something you’ve advocated for? Can you share a story of influencing your organization?

Yes. All of those. In my current role, I would say this is a huge part of my job. While, as an engineer, I am also contributing on a scrum team, I would say a lot of my job is to keep an eye out for pitfalls I’ve seen before or larger patterns of problems. I see my job as making all of engineering more efficient ‐ be that through technology, through architecture or through process. However, I should never be making changes for the sake of changes. I’ve advocated for a number of things over the years, from rewriting our email notification system to rethink‐ ing testing to reworking several authorization frameworks.

For some things, like the email overhaul, I didn’t do anything big or grand, I just reminded Product every time they wanted to add a notifi‐ cation that our system was ready to fall over and that we really couldn’t add any more until we fixed it. 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.

For other things, such as the authorization frameworks, I was tasked with finding a solution. In these cases, even when people want a new/better solution, you still need to convince them that you’ve picked the right thing. With incredibly complex systems, people will often think they’ve found things you’ve forgotten about (and maybe they did), so it’s really important to seek feedback early and often and to carefully record and communicate both what you chose and why but also what else you considered and why you didn’t chose something else. People need to feel heard and they need to know that you fully considered their concerns. They also want to understand what your thought process was, but even more important, they want to understand that you did thorough research and didn’t just pick the first thing to come along. In fact, when I’m vetting someone else’s design, this is one of the things I really look for ‐ what else was considered?

How have you sponsored other engineers? Is sponsoring other engi‐ neers an important aspect of your role?

Yes. As soon as you get to any sort of more senior role, this is always a part of your role assuming you chose to take advantage of it. Since I’m still new at Split, I haven’t had much of a chance to here, but I’m pos‐ itive that will change. Sometimes sponsoring is the big stuff ‐ recom‐ mending people to lead projects or manage a team, but a lot of spon‐ soring is smaller things ‐ encouraging someone who is a little unsure of themselves, showing off their accomplishments to more senior peo‐ ple they wouldn’t normally have access to, finding ways to delegate your work to people who could get a growth opportunity from doing it. I think it’s possible to be a senior staff engineer without sponsoring, but I’m not sure it’s possible to be a great senior staff engineer without sponsoring. Sponsoring is one of the most powerful ways we can grow those around us and I would say that growing others is one of the most important aspects of our role.

You first got the title Staff Engineer at Box. What was the process of getting promoted to Staff?

At Box, we submit a promotion case that outlines how, based on the engineering rubric, we’ve already been operating at the next level. 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. I liked this process because it allowed the person with the most context on our accomplishments be the one to write them up and it allowed you to go up for a promotion even if your manager didn’t agree. On the other hand, I didn’t like the process because it subtly discriminates against those with a little less self confidence and those who struggle with self‐promotion. It also resulted in managers taking a little less initiative in starting off the promotion process (letting engineers come to them saying they wanted the promotion rather than suggesting it).

What two or three factors were most important in you reaching Staff? How have the companies you joined, your location, or your education impacted your path?

I would say that my location probably hasn’t mattered too much. Edu‐ cation helped me a lot in terms of getting interviews when I was more junior, but a lot less so (at least directly) since then. I would say that the three biggest factors for me were company, visibility and opportu‐ nities.

I think it’s possible to advance at a lot of companies. However, I found that being at a fast‐growing startup really helped me out. When I joined Box, engineering was around 30 people and when I left, 8 years later, it was at a few hundred, but much of that growth was in the first half. This allowed me to come into a smaller engineering envi‐ ronment where it was possible to really get to know the environment, people and code. Then, because we were growing, there were lots of leadership opportunities and technical challenges for those motivated and willing to take them. Because we grew, the opportunities grew with me. At the same time, there were also enough people around me for me to learn from (I was previously at a really tiny startup ‐ 2‐4 people, where that really wasn’t available).

By visibility, I just mean finding some way to be known. I’ve always worked onsite, which I find makes this a little easier, but I think this is possible even if you are remote (although possibly a bit more challeng‐ ing). If you do really great work, but no one knows about it, when it comes time for promotion, you’ll be passed over. Furthermore, as you become more senior, part of your job becomes mentoring and teach‐ ing others and helping your company to create a tech brand ‐ all of these are by definition, visible. Visibility can take a number of forms, but for me I would say that a few things contributed. I was very active in our Slack discussion forums, answering questions for people wher‐ ever I could. I also did a lot of blogging and some speaking both inter‐ nally and externally. Finally, I was active in our women in tech group, which allowed me to form connections with various people through‐ out engineering.

Finally, opportunities. These can look vastly different as well. For me there was one in particular that was really helpful ‐ I joined our API standards committee. I was actually a bit hesitant to do so at first be‐ cause I didn’t think I was an expert at APIs, but after reading a few (short) books on REST, along with my work on various APIs previously, I had a pretty solid grasp. The powerful thing about this group is that it cross‐cut many teams in engineering, which gave me a chance to work with a lot of different engineers (and gave me that visibility I just mentioned). It also allowed me to have something clear to point to in terms of influencing others and being someone who fights for quality. Our projects there had broad impact across engineering and allowed me to think about something (our API, in this case) holistically.

There is a popular idea that becoming a Staff Engineer requires com‐

pleting a “Staff Project.” Did you have a Staff Project, and if so what was it?

I actually didn’t really have a Staff Project. At the time that I was pro‐ moted, I had transitioned back from management around 6 months prior, so I referenced some of my time managing for leadership. At the time, I was leading (from the technical side) the very small Box team on a cross‐company collaboration project, which involved understand‐ ing another company’s development team’s requirements and figuring out how to build as little as possible while meeting their needs. I was a member of an engineering‐wide API working group responsible for establishing and maintaining our API standards and I had several side projects going on. I would say that all of these contributed to various parts of my promotion and together helped me establish that I could demonstrate all aspects of what they expected.

Can you remember any piece of advice on reaching Staff that was par‐ ticularly helpful for you? Is there an easier path to Staff that you could have taken?

One piece of advice I got at some point was to amplify my strengths. All of us have strengths and weaknesses and we spend a lot of time talking about ‘areas of improvement.’ It can be easy to feel like the best way to advance is to eliminate all of those. However, it can require a lot of work and energy to barely move the needle if it’s truly an area we’re weak in. Obviously, you still want to make sure you don’t have any truly bad areas, but assuming you’ve gotten that, instead focus on amplifying your strengths. How can you turn something you’re good at into your superpower? The other thing to think about is how can you use something you’re good at to compensate for something you’re weak at? For example, I’m a giant introvert and don’t particularly like mingling with people I don’t know. I’m terrible at networking with strangers. However, I’m good at writing and enjoy doing it. I’ve used writing on my public blog to meet people I wouldn’t otherwise and get exposure more broadly. In fact, I’m sure I’ve gotten far more from that than I would have by going to many, many meetups.

The other more tactical thing that comes to mind is directly related to the process we have at Box of writing a promotion case. A few things were suggested to me ‐ first to write the promotion case well before I was sure I was ready for the promotion. This allows you to see where there might be gaps and can give you very tangible things to work on. (Or maybe you’ll be surprised and realize that you’re ready for promo‐ tion before you thought you were). The second is to be very aware of where those gaps are. When a promotion committee is reading through promotion cases, all of the cases are going to be very posi‐ tive. 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. Where are the blank spots? What seems to be avoided or talked over. Take a look at your case from that light ‐ what things might be missing? What things are you brushing over? Be sure to work on those. Finally, tell your story.

Our promotion cases had templates with pointed questions, but, es‐ pecially at the higher levels, everyone isn’t the same, nor do we want them to be. Instead of just answering the questions, think first about what your strengths are. What are your superpowers? What is your story? Then figure out how to fit that story into the prompts. You’ll have a much better overall case if you include your best strengths in it.

It’s possible that if I hadn’t taken a meander through management, 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.

What about a piece of advice for someone who has just started as a Staff Engineer?

The more senior you get, the less your job is about code. Sure, un‐ like a people manager, you still have a very technical slant and even through principal, you’ll likely be doing at least some coding. How‐ ever, the higher you get, the more your job becomes about mentor‐ ing and growing the people around you (and more broadly), building your team through building your company’s public tech brand, notic‐ ing larger technical trends that can be improved upon or corrected, helping to set the tech vision for your team or the company and advo‐ cating for resourcing for tech debt projects. It becomes much more about seeing broader things and getting others on board. Suddenly, communication, leadership and persuasion are even more important than they were previously.

Did you ever consider engineering management, and if so how did you decide to pursue the staff engineer path?

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 compa‐ nies. Both roles require mentoring others, leading and the ability to persuade people. They require thinking bigger and more attention to longer term ‐ both in terms of technologies and people. While I don’t plan to go back to management, I did learn a lot during my time man‐ aging and the experience has actually helped me as I’ve advanced to Staff and beyond.

What are some resources (books, blogs, people, etc) you’ve learned

from? Who are your role models in the field?

I don’t tend to follow any particular person, but instead learn from and find inspiration from almost everyone around me. I’ll list a few here, but in all honesty, I would say that I’ve learned from countless different people at all levels (including many more junior than myself).

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 feed‐ back to someone directly or telling me to figure out how to fix some‐ thing 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.

As a counterpoint, I would also mention a principal engineer I worked with, who later taught me that I didn’t need to try to do everything my‐ self. After I learned to take responsibility, I started to forget that I wasn’t alone. Of course I had heard people talk about delegation, but it’s one thing to hear about it or think about it in terms of sprint tasks, but it’s another to delegate getting something prioritized or delegate figuring out tech vision for a team or delegate following up on an ini‐ tiative.

There was another co‐worker that I worked with who would drive me completely bonkers sometimes because her approach to solving prob‐ lems was so different from mine. She would ask for clarification when I thought it was obvious and she would ask for detailed explanations when I thought everyone was on the same page. However, she’s also one of the smartest engineers I’ve ever worked with and working with her made me realize that not only can different styles be just as good, but that sometimes putting together two clashing styles can result in much better results than either of us would have gotten on our own.

She found holes in things I thought were obvious and while she drove me nuts sometimes, we got some amazing things accomplished and I am better for it.

Damian Schenkelman - Principal Engineer at Auth0

August, 2020 blog, twitter, linkedin

Tell us a little about your current role: where do you work, your title and generally the sort of work do you and your team do.

I’m a Principal Engineer at Auth0, an Identity as a Service platform. I work in the Systems Architecture group, which today has three Prin‐ cipal Engineers. We work with different teams on strategic initiatives and also shape Auth0’s technical strategy, architecture decisions, and guidelines.

At the time of writing, I am working with a group of Identity and Access Management (IAM) teams as a tech lead of a large new product feature, as well as driving reliability and scaling related initiatives with other teams.

What does a “normal” Staff‐plus engineer do at your company? Does your role look that way or does it differ?

Within Engineering, we are organized in domains (today Identity & Ac‐ cess Management, Developer Experience, Service Management, and Platform). Auth0’s Staff Engineers are people that can technically lead teams within a domain. A Staff Engineer would typically be part of a single team in a domain, while also being able to actively contribute to initiatives across the scope of a domain.

Principal is the next level in our ladder. Principal Engineers can ei‐ ther be in a specific team (depth) or work with multiple teams and their scope spans the entire organization (breadth). Today I am oper‐ ating in “breadth mode”. This means both working on specific initia‐ tives and also the definition of technical strategy, technology choices for our Platform, and leading the Design and Architecture workgroup (a.k.a. DNA).

DNA has 6 members (3 permanent Principal, and 3 Staff/Senior II that rotate every 6 months). The workgroup defines decisions and guide‐ lines to help drive Auth0’s technology in a specific direction (e.g. avoid language proliferation so we can build libs once and people can switch teams easily) and also collaborate with teams in technical reviews of large initiatives.

The biggest way in which my role differs, because I have been at the company for 6+ years, 3+ of those as a Director of Engineering, is that I have the “broadest scope”. I work with both Product and Platform teams on initiatives and also work often with other parts of the com‐ pany: joining conversations with high profile prospects, working with our legal team on contract language, or collaborating with Marketing.

How do you spend your time day‐to‐day?

This varies a lot :). A typical week involves a lot of meetings, so I am trying a new thing: grouping meetings on Mondays, Wednesdays, and Fridays. Thursdays are completely blocked, and Tuesdays are only for urgent matters. Because we are remote all meetings are over Zoom.

On meeting days I have recurrent: ‐ 1:1s: to catch up with my man‐ ager (VP of Engineering), or a team manager or tech lead. Those con‐ versations are great to stay up to date with them and know their chal‐ lenges. I feel being too detached from that would impact my ability to get things done effectively. ‐ team meetings: Engineering leadership, Design & Architecture workgroup.

Non‐recurrent meetings also take place. Some example topics might be: ‐ specific initiatives I am tech leading ‐ helping a group of teams figure out how to get something started ‐ doing a sync design review

On Thursdays (and as much of I can on Tuesdays) I spend my time thinking about: ‐ current initiatives and how they are going ‐ what we could/should be doing in the future (next quarter, next year) ‐ writing docs, guidelines, blog posts ‐ (not often) doing POCs and/or writing small tools

Where do you feel most impactful as a Staff‐plus Engineer? A specific story would be grand.

The biggest impact comes from being able to help achieve “people scale”, positively influencing the work of as many people as possible internally. The book Scaling Up Excellence provides an easy to un‐ derstand analogy: scaling is a ground war, not a one‐off airstrike. It requires a lot of time, and patience but to get to your goals you need to align the whole company in terms of goals and how to get to them.

As a Principal Engineer, I try to find opportunities/gaps that I believe will set a direction for as many people as possible in the long term. There’s a lot more value to align the ~200 people we have in our Product Delivery organization around a certain topic than to code a solution for a problem myself. The former has more impact, it scales better.

Can you think of anything you’ve done as a Staff‐plus engineer that you weren’t able to or wouldn’t have done before reaching that title?

Before becoming a Principal I was a Director of Engineering at Auth0. The most interesting thing is that as a Principal Engineer people get a lot less defensive when I provide feedback and they seem a lot more open in 1:1s. I think it might be related to the fact that as a Principal Engineer you are not “representing a part of the organization”.

In that regard, being an individual contributor feels a lot better.

Do you spend time advocating for technology, practice, process or ar‐ chitectural change? What’s something you’ve advocated for? Can you share a story of influencing your organization?

A common problem for fast‐growing companies is that there’s usually some “lack of clarity”. In our case, there was a lot of confusion about what was coming in the future and that made us slow and inefficient in making technological decisions. Teams were uncertain if they should be using a particular technology because they didn’t know if that tech‐ nology would be supported in the future, they were uncertain if they should be building a particular product in a certain way because they didn’t know if that approach was aligned with our long‐term technical strategy, etc. Naturally, this caused a lot of inefficiencies.

We believed we needed a long‐term direction that explained how to approach the technical implementation of problems today and how to bridge the gap between our initial situation and the future vision. More precisely, we needed a documented technical strategy that would detail what we should and shouldn’t be doing to be successful in the long run.

After talking to a great number of people I learned that all of them have been exposed to inconsistent information, and rumors, which made them afraid of making decisions, e.g.: “I heard the company is going for X in the future” or “I heard this particular technology Y is not going to be supported by our platform teams”. A lot of confu‐ sion was caused by a particular rumor that we were going to support a certain customer need and its technical implications. People kept hearing about it, but concrete plans were never announced. I wrote down these issues, connecting all the dots and aiming to translate that information into knowledge. I realized we needed both short and long term ways of solving the problem.

Short term: We had to fill the gap of uncertainty relating to some more urgent and short‐term matters. Teams needed to make techni‐ cal decisions and couldn’t wait for a full‐fledged technical vision and roadmap. We also realized that once we had that long term vision and decisions, there would naturally be the need to review decisions for specific exceptions. I put together the “design and architecture” (DNA) group, which also wrote guidelines and recommendations, including “approved” technology choices, to guide teams towards independent decisions that don’t require review, and also established an RFC re‐ view process.

Long term: I came up with a set of topics that I believed the company needed to make decisions about. I tailored my presentations to suit two different audiences – executive and technical. For the executive audience, I developed a succinct presentation, applying non‐technical analogies and explanations, and providing actionable solutions. The technical presentation was much more detailed and included many technical terms. I used nemawashi (an informal process of quietly laying the foundation for some proposed change or project, by talk‐ ing to the people concerned, gathering support and feedback, and so forth) and shared with my VP of Engineering, other execs, my peers, and other senior leaders through to get buy‐in before formally making a decision. More specifically, I approached people asking them for their thoughts and opinions securing the buy‐in, so that by the time we met to discuss our decisions, it wouldn’t be the first time they were seeing the ideas. We finally met, discussed tradeoffs, and arrived at a set of decisions. All decisions were documented in a decision log and we committed specific owners – in writing – to carry them forward.

How do you keep in touch with how things really work as you spend less time on hands‐on development?

There are two aspects of this, keeping up with technology in general and keeping up with what goes on at Auth0 and the current “state of affairs” in Engineering teams.

These are the things I do to keep in touch with things related to Auth0: ‐ Internally: keep an ear to the ground both through Slack and having 1:1s with some tech leads and Engineering Managers. This helps me understand what challenges they are having first hand, and also find patterns or arrive at global solutions instead of local ones. ‐ Externally: talk with customers/prospects to see how they use the product, read tweets and news, etc.d mentioning Auth0 and the identity space.

I don’t feel I am “keeping in touch” as much as I’d like technology‐wise, but I do try to :). So many new important new things are happening in our industry every month that it is hard to keep up. Accepting the fact that meetings and not being hands‐on means that I will likely be less in touch than I’d like with things is important. Once I accepted that I could start prioritizing what was valuable.

I read books, carve out time to do some POCs or read blogs/papers about specific topics, and ask to lead specific initiatives to stay up to date with how we are developing even if I don’t code that often.

How have you sponsored other engineers? Is sponsoring other engi‐ neers an important aspect of your role?

Yes, a lot! I am a member of our Engineering Leadership team. We meet twice a week to discuss topics around the organization. This, to‐ gether with keeping an ear to the ground, and being part of meetings about mid‐term plans helps me know about (and sometimes propose) opportunities that might be available ahead.

Whenever that happens I typically propose the names of people that I believe would benefit from that opportunity, explain why I think they would be good at it, and, if helpful, offer to mentor them in case there are any perceived skill gaps.

You first got the title Principal Engineer at Auth0. Were you hired as a

Principal Engineer? If not, what was the process of getting promoted to Principal?

My story here is a particular one. I started at Auth0 in May 2014 as the fifth engineer, ~tenth employee. There were no titles, no ladder, noth‐ ing like that. Around 2015, I started mentoring and doing 1:1s with a couple of new hires. Towards the end of 2015, I was working on my initiatives, and also leading others, helping with hiring, etc. Late 2015 Matias Woloski, Auth0’s CTO and co‐founder, was looking for someone to lead Engineering teams and he asked me if I would be a Director of Engineering.

I’ve been privileged enough to be able to approach my career in a way that maximizes learning and opportunities for hard problem‐solving. That’s the main principle that helps me make decisions. When he of‐ fered me, a 25 year old living in Argentina, the opportunity to lead the Engineering organization for a “Silicon Valley”, remote‐first com‐ pany that was growing exponentially I naturally said “yes”. I had never thought “I want to manage”, it just happened because I wanted to learn and solve hard problems.

Things worked out great. I learned a lot about building teams, organi‐ zations, leading people, etc. Because I was one of the first engineers, had built a lot of the systems and I enjoyed technical conversations I also did a lot of technical leadership in that role, both with Product and Platform/Infrastructure teams. Towards early 2019 as a Director of Platform, I started thinking that I was not learning as fast as before and that I wanted a broader scope than just working on our platform. After many conversations with Christian McCarrick, Auth0’s VP of En‐ gineering at the time, I realized that the challenge I wanted to take up next would be being one of Auth0’s technical leaders. I transitioned to Principal Engineer in August 2019.

What two or three factors were most important in you reaching Prin‐ cipal? How have the companies you joined, your location, or your ed‐ ucation impacted your path?

A quote I love from Seneca is “Luck is what happens when preparation meets opportunity.” . Getting to Principal required getting some things right, but also a lot of luck. I want to call out some of the key factors that got me to Principal and also show how luck played a part in them. First job

In Argentina it’s common to start working while you are in University. When I finished high school I found a job at a fantastic company called Southworks. The two key things about that place were that:

• the company worked on projects with cutting edge technologies, which gave me lots of opportunities to hone my learning skills

• the company worked mainly as a Microsoft US vendor remotely, which meant that not only technical skills were valued, but also we got to practice communication, expectation management, and other interpersonal skills often.

The reason I could work in software right out of high school was that when I was 11 I started telling my mom I wanted to “build video games” and my parents found and paid for a high school that taught program‐ ming.

How luck played a part: I was about to take a job at another company when a friend of mine from high school told me her brother worked at Southworks and they were looking to hire junior people. He did a good job selling the company to me and I decided to put the other opportunity on hold to see if I could get into Southworks.

Auth0

I was one of the first engineers at Auth0 and over the years I worked on many parts of its product and infrastructure, which makes it easy for me to help people and provide valuable input on various topics. Be‐ ing a Director of Engineering also helped me understand many things about our business that help me be a more effective contributor.

How luck played a part: the success of any startup requires a lot of luck at many different points in time. If Auth0 had not grown as it did, I wouldn’t have had the opportunities to learn what I did and be where

I am. This is particularly important because I live in Argentina where the Software industry is much smaller than it is in the US and most companies don’t have dual tracks.

Team sports

I played basketball as a kid and during my teens and I realized early on it felt a lot better to win by scoring any amount of points than to lose scoring lots of points. That shaped how I worked in two ways: ‐ it led me to help team members often to see how we could succeed as a team

• it led me to learn and do things that would be required to “cover gaps”, which helped me build leadership and interpersonal skills that are very useful as I grew in my career

There is a popular idea that becoming a Staff Engineer requires com‐ pleting a “Staff Project.” Did you have a Staff Project, and if so what was it?

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”.

I think implicitly the closest thing to a “Staff Project” was the work I led in 2017 & 2018 to increase the reliability and scalability of Auth0, leading some projects to offer higher SLAs for a subset of our key cus‐ tomers.

What piece of advice do you have for someone who has just started as a Staff Engineer?

Staff means different things at different places, so the first piece of advice I would give is to talk to as many people as possible to define expectations where they are.

The next thing I would tell people is to be patient. They probably got to where they are because they are fairly technical and got results, but as you grow in the ladder the outcome of your work takes time to de‐ velop. You might be working on more things at once, and the impact of them has a longer time horizon. You are also now influencing more people in different roles, and sometimes it takes them longer to “see” the things that you might see clearly. Being patient, progressively in‐ fluencing people, and teaching others pays off long term.

Finally: get used to writing things down and repeating them to others. Writing down thoughts, plans, reasoning, and standards is the way you will scale yourself. When you document something you make it easy for anyone to access it and read in the future, it is easier to reference. It is a lot better than “just talking about it”: it scales better and it also reduces the chances of things being misunderstood. Repetition is also necessary as just publishing written documents is not useful, so you have to share your ideas with people. Hosting AMAs, brown bags, and other sessions to explain what your thoughts are very valuable.

Did you ever consider engineering management, and if so how did you decide to pursue the staff engineer path?

I wasn’t planning for it, but when the opportunity came to be Direc‐ tor I took it. However, my thinking is that there’s a pendulum where you can go back and forth between the two paths. How easy it will be will depend on the company and how specialized the skills as a Staff/Principal are, but I think it is possible.

Nowadays I am very interested in continuing to develop my technical skills and leadership skills, as that’s what I think will bring the most valuable learnings and challenges.

What are some resources (books, blogs, people, etc) you’ve learned from? Who are your role models in the field?

I try to follow people on Twitter who I think are doing interesting things and from who I can learn. There are so many people doing interesting things and so much to learn! Some of the names that come to mind: ‐ Aphyr’s work with Jepsen and general content about distributed systems is great. ‐ Tanya Reilly has some very ‐ good content like RFC process @ Squarespace and Being Glue. David Fowler shares a lot of content about the .NET Framework and ASP.NET internals which I find interesting. There’s also this video of him sharing how he became the ASP.NET Architect. ‐ At Auth0 I work with Jon Allie who is a fantastic engineer and person. He strives for simplicity, can explain things very clearly, and is extremely humble considering how much he knows.

I haven’t found a lot of books or similar content specific to senior “in‐ dividual contributors” (might be interesting to write one). I recently read Fundamentals of Software Architecture that does a fairly good job at describing that role while also understanding the nuances and gray areas of it.

Some books about management are useful to get organizational aware‐ ness and help with mentoring, 1:1s, hiring which are things one typi‐ cally helps with as a staff‐plus engineer. In High Output Management Andrew Grove refers defines the “know‐how manager” as “people who may not supervise anyone directly but who even without strict orga‐ nizational authority affect and influence the work of others”, which sounds an awful lot like staff‐plus engineers. I strongly recommend Managing Humans as it shares stories that are easy and fun to read, and also helps generate empathy with managers, which is important as a staff‐plus engineer. The 7 habits of highly effective people is also a book that has a lot of good lessons for staff‐plus engineers.

Accelerate is another great book that helps tie company success to en‐ gineering practices and outcomes in a way that is useful to influence stakeholders, especially at an executive level.

Dmitry Petrashko - Tech Advisor to the Head of Infra at Stripe

May, 2020 presentations, twitter, linkedin

Tell us a little about your current role: where do you work, your title and generally the sort of work do you and your team do. I am a Staff engineer and the Technical Advisor to head of Infrastructure at Stripe.

My current team is all of Stripe Infrastructure, which is responsible for foundational infrastructure services at Stripe ‐ Compute, Networking, Storage, Database, Data Engineering, Performance & Efficiency, Ob‐ servability Services, and Developer Tools. Our work empowers Stripe engineers to focus on product.

The team that I “grew” from was Developer productivity, which builds processes, tools and core libraries used during product development at Stripe, including testing frameworks, linters, typecheckers, build tools, libraries used for gradual rollout, and many others. I started as engineer on that team(while it was still a singular team), eventually becoming a Pillar Tech Lead of that group.

What does a “normal” Staff‐plus engineer do at your company? Does your role look that way or does it differ?

A Staff Engineer at Stripe isn’t a role, rather it’s a level that corresponds to expectation of impact, communication, people and project leader‐ ship skills. Staff engineers fill different roles, mine is a current one is Technical Advisor(TA). In that role I partner closely with the Head of Foundation, Rahul Patil, with the goal of researching critical top‐ ics ahead of time, diving into critical issues (design, code, analytical), brainstorming technical action items, assisting with urgent technical follow‐ups, instrumenting code for data collection, etc. This role is de‐ signed to expand Rahul’s bandwidth and strategic thinking, but does not dirrectly make technical decisions.

As a stepping stone to that role, I was also a Pillar Tech Lead. As we have more PTLs, the expectations are better defined: * PTLs help their teams make technical decisions that will play well with each other and with technical decisions made by other groups at Stripe. Teams at Stripe make most technical decisions themselves, but an experienced PTL can help fine tune those decisions to achieve better outcomes. PTLs also work as arbiters in cases where teams cannot reach an agree‐ ment amongst themselves on technical topics. * PTLs guide the tech‐ nical direction of Stripe, providing input on what are the most impor‐ tant problems to solve and setting the high level technical approaches to solving them. * PTLs help their organization by representing it to other Pillar Tech Leads and also bring technical decisions made else‐ where back to the teams they work with to create alignment. * PTLs create opportunities for other engineers to take on impactful projects and help them succeed.

In the PTL role, I used to partner closely with the Head of Devel‐ oper Productivity and managers of the teams inside the group. We exchanged context and worked towards an agreed goal.

Both of these roles(PTL and TA) are similar in that they partner with engineerign manager and share insight into the needs of our users & tools at our disposal to address them, while the EM has a better un‐ derstanding of Stripe‐wide non‐technical constraints(e.g. resourcing constraints).

How do you spend your time day‐to‐day?

On a perfect week I’d spend Monday, Wednesday and Friday in meet‐ ings or working groups: either 1:1’s or team meetings, collaborating on plans & strategy, both short term and long term. Tuesday and Thursday of my perfect week would be spent coding alone. In reality, depending on team needs at the time, I may end up having more meetings or more time coding. If I’m working to set up a new project, I’ll commonly start by having a week with less meetings: focusing on project briefs, thinking through design, deliverables/milestones and security/reliability implications; followed by a week of socializing the proposal around the company and addressing feedback.

While, from time to time it might seem hard to find time to write code, I believe it’s important as it allows me to maintain a strong connection to engineering and be the bridge between business needs/prioritization and engineering constraints that PTLs need to be.

Where do you feel most impactful as a Staff‐plus Engineer?

Staff Engineers, and Pillar Tech Leads in particular, frequently help set direction for a new project. I feel particularly impactful when I can help improve a proposal that’s well intentioned and solves a real need, but the team that drafted it lacks either experience or context to write a good plan to capture the opportunity. In such cases, having a well structured plan can help substantially reduce the scope while getting to most of the value, and thus demonstrate impact sooner. Or, alternatively, see that the proposal in hand addresses more use cases than the team has originally anticipated and refocusing the project to‐ wards a usecases that was not known by the team would lead to bigger business impact: in both of these cases, I feel impactful by empower‐ ing other engineers.

Can you think of anything you’ve done as a Staff‐plus engineer that you weren’t able to or wouldn’t have done before reaching that title?

No, Stripe intends the Staff‐badge to not be a gate into new opportu‐ nities and I believe we’re good at it. This is also true about the PTL role. We choose enginers for PTL position that are good at represent‐ ing opinions of others. Even before I became a PTL I felt that prior PTL, Paul Tarjan, always made sure my perspective was presented.

Do you spend time advocating for technology, practice, process or ar‐ chitectural change? What’s something you’ve advocated for? Can you

share a story of influencing your organization?

I was hired specifically to introduce typechecking into Ruby at Stripe. This included, together with Nelson and Paul, architecting and imple‐ menting the typechecker, Sorbet, and growing the culture around us‐ ing it.

In the early days of Sorbet, we’ve carefully chosen what features to add based on usecases that Stripe needs the most. I believe we’ve suc‐ ceeded in covering most of usecases that Stripe had with a typesystem and, at the same time, keeping the simplicity: it’s very easy to get to a typesystem and culture that promotes complexity and elitism for sake of it and I’m happy that our efforts avoided swinging from untyped‐ ness to the other end of spectrum.

Today, in my role as Technical Advisor, I advocate for changes that will have outsized impact, most commonly in terms of Reliability, Scalabil‐ ity, Security and Productivity at Stripe. That can be changing the way data is sharded/stored, or changing the way we address change man‐ agement. The big difference though is that unlike in Sorbet where I stayed on project for years, I’d be looking to find/grow a person who’ll take over the project pretty soon ‐ after organization is bought in, and there’s a plan with well articulated milestones and controlled risks. I’ll keep having frequent checkings with people driving these important projects with goal to help mitigate these risks and discover opportuni‐ tites to deliver the project faster, and thus my involvement is visible only in early stages of project.

How do you keep in touch with how things really work as you spend less time on hands‐on development?

While I was a PTL, I had a least a couple of days a week where I got code. I worked closely with other engineers on my teams and we con‐ tinuously learn from each other.

As a Technical Advisor, I wasn’t able to write code as much as I was as a PTL. I mostly wrote code when it was code‐yellow situation. But the success in this role is dependent on having good insignts and deep en‐ gineering understanding. To do this, I speak to our internal customers and stay on top of designs and, notably, failure thresholds and failure modes of systems of teams that I support.

In my role, it’s highly important to understand needs of customers. One helpful resource for that is the Stripe‐wide engineer survey that Developer Productivity group organises, where we are looking to find what are the biggest things keeping our engineers from being produc‐ tive: maybe there’s some tool that became slow since the last survey or some use case that had a user base grow that’s not well supported. While this survey rarely finds things that we weren’t aware of, it’s a great tool for relative prioritization: we can compare how many peo‐ ple complain about things and prioritize them accordingly.

Additionally, before Covid‐19‐induced lockdown, I used to join ran‐ dom tables for dinners at Stripe. I’d ask 3 questions:

• What are you working on?

• What makes it hard?

• How can infrastructure teams help?

This became a great tool in two ways: 1) connecting me to my users, helping discover their needs; 2) helping mitigate unhappiness of teams that aren’t yet supported by having a discussion similar to: “yes, I agree we could help you by doing X, now, lets together look on what we should stop doing to create place for this”, where a person would frequently discover that, while they would like us to address their pain point, they don’t want it addressed at cost of us deprioritizing our current projects.

As I was transitioning away from role of PTL, I’ve created a group that’s currently called DevProd Assembly that gathers leaders of de‐ veloper productivity teams. Each member of this group is expected to build a high trust relationship with 2‐3 product teams, interview them monthly and aggregate feedback with other members of Assembly.

How have you sponsored other engineers? Is sponsoring other engi‐ neers an important aspect of your role?

While sponsoring other engineers isn’t required for a Staff Engineer, I believe it helps to succeed as one, as it helps you deliver more impact by creating opportunities for others and helping them succeed.

And yes, there have been multiple projects that I have helped scope, kick‐off and derisk, while also helping grow a person to take it over from me when I roll off to the next thing.

There’s also a distinction between mentorship and sponsorship and I do both. 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. In working with my teams, I try to help people work on projects somewhat out of their comfort zone, and in that I sponsor them, and then, I could mentor them to help the project succeed.

You first got the title Staff Engineer at your current company. Were you hired as a Staff Engineer? If not, what was the process of getting promoted to Staff?

I wasn’t hired as a Staff Engineer. I had to get uplevelled twice to get to Staff level at Stripe. Both of these uplevels were similar: Stripe up‐ levels after an employee has already been operating on the next level for quite a while and this adjusts expectations that they are expected to continue operating on that level going forward.

What two or three factors were most important in you reaching Staff?

In order of decreasing importance:

1. Focusing on impact on business and company.

2. Being collaborative: by joining meetings/working groups you should help achieve a better outcome.

3. Technical knowledge.

For me personally, the area that I needed to get good at before getting Staff Engineer was the second item. I was already delivering impact and was considered a person to go to for technical advice. I needed to improve my communication skills and collaboration skills so that I could constructively help people who are outside of my team, who might see me for first time ever and who, despite having good inten‐ tions behind their project, may not have the best plan to get it deliv‐ ered.

Technique that helped me in that was asking for feedback in private chat immediately after the meeting, in particular after meetings that didn’t not go perfectly. This has allowed me to learn what I did that might have contributed to other parties not feeling comfortable in these meetings and, in a few cases, the genuinity of asking for how it could have gone better helped fix the outcome of a meeting that has already gone poorly.

How have where you worked and your education impacted your path?

Companies: I appreciate that Stripe has so many opportunities for im‐ pact and this definitely helped me.

Education: I happened to have got a very practical PhD (on how to build fast & maintainable compilers) that almost fully translated to knowledge that’s applicable to my work: helping a company to scale engineering. And, while it served me well, I think there’s a lot of luck involved: I happened to join the right lab at the right time (when conditions for Scala3 being born became material, I’d been at the lab long enough to not be too “green” but still early enough to not have totally set the direction of my research). I’m unsure if I’d advise others to do a PhD: from my perspective, in practical terms, many of my friends would have learned as much by building systems at Stripe/Google/Facebook for the same 4+ years it takes to complete a PhD. If you’d like to learn how databases work ‐ you’d probably learn this not only at the laboratory that does research on databases, but also at the companies that have some of the highest demands for databases and have teams working to improve them. That said, PhD was something that was a good tool for me to change my location.

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 Com‐ puter Science. I came to Russia to join one of the best ex‐USSR uni‐ versities 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. In some of them, I think I wasn’t the prime candidate. By joining the people there and learning from them, I grew a lot. It’s hard for me to tell if US vs EU is a better location career‐wise, but I can definitely tell from my experi‐ ence that changing locations helped me grow a lot.

There is a popular idea that becoming a Staff Engineer requires com‐ pleting a “Staff Project.” Did you have a Staff Project, and if so what was it?

It’s a very hard question for me to answer in retrospect. This is be‐ cause: AFAIK Sorbet was big enough to be my Staff engineer project, BUT with Nelson and Paul being there and us working closely and very fast with each other, it was very hard to attribute success of the project to specific individuals rather than the whole team.

Around the first performance evaluation into the projects, all three of us got feedback that we should have better ways to prescribe which impact was the result of which individual. While I’d love to say that the fact that we didn’t face similar issue on the next performance eval‐ uation was due to intentional actions, I don’t think that is true: I think the project just naturally entered a stage where it was much bigger and thus we didn’t need to “quickly iterate in the same 10 files”, naturally leading to us having clearer and bigger areas of ownership.

I became the “internal architecture/subtyping” person, as well as “talk to users” person, while Paul became the “change the code to make typechecker like it” person. Nelson clearly knew better how other systems at Stripe work and thus helped integrate the tool with them. 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. At this point in the project (stabilization, rollout) all of these became huge areas and thus it became much easier to have a person be a directly responsible individual (DRI) for an area, with others helping occasionally.

After Sorbet I had a couple other impactful projects delivered in short timeframe (6 months), that, I believe, sealed the deal of me getting the Staff Engineer level, but, If I was to choose one, I’d still choose Sorbet due to vast scope of project: both technical and cultural.

Can you remember any piece of advice on reaching Staff that was par‐ ticularly helpful for you?

1. Working with Martin Odersky and Ondrej Lhotak in academia helped me understand how complex systems work together and how to explain that clearly.

2. Brian Goetz helped me understand how much work is behind a simple, yet, robust to withstand widespread adoption, design.

3. Paul Tarjan showed me the importance of adjusting my commu‐ nication style to lead to constructive outcomes for all involved parties.

What about a piece of advice for someone who has just started as a Staff

Engineer?

At least, at Stripe, Staff Engineers work on very different areas. Make sure you agree with your reporting chain on what is the impact you should be achieving and what are the things you’re allowed to compro‐ mise on on the way to that impact. Communicate clearly what compro‐ mises you’re doing and why.

Did you ever consider engineering management, and if so how did you decide to pursue the staff engineer path?

Every time I considered it in the past it was by asking myself and others around me “would it be a way to bring more impact”. So far, every time the answer was “seems like no”.

That said, I’ve found that learning some management skills from great managers(in my case, James Iry, Scott MacVicar, Will Larson, Chris‐ tian Anderson and Shane O’Sullivan) provides huge benefits even in IC role.

Stephen Wan - Staff Engineer at Samsara

September, 2020 github, twitter, linkedin

Tell us a little about your current role: where do you work, your title and generally the sort of work do you and your team do.

I’m a Staff Engineer at Samsara.

I started at the company four years ago when the company had been around for a year and we had fifty or so employees. Nowadays, we have over a thousand folks at the company, with engineering teams in the Bay Area, Atlanta, and London.

When I first started, we had yet to form real teams and our ten or so engineers worked on whatever came up. Nine months in, we had dou‐ bled up and formed product teams around a few core offerings at the time. I did a brief stint leading a product team before switching over to our budding infrastructure group to start our frontend infrastruc‐ ture team. Over the years, I’ve gradually shifted down the stack, also taking stretches on our backend and observability systems.

Today, I work in our Infrastructure & Platform (I&P) group, spending most of my time with the Developer Experience team which builds tools to keep our full‐stack development workflow productive.

What does a “normal” Staff‐plus engineer do at your company? Does your role look that way or does it differ?

Most of our Staff+ engineers are in specialized roles, either in web in‐ frastructure or device firmware. I suppose that puts me in the major‐ ity, but the work our Staff engineers do is varied so it’s a bit hard to claim being “normal” in the role.

When looking at parallels between the IC and management tracks, Staff is considered a director‐equivalent role. Staff engineers have the option to participate in many processes that are typically reserved for managers. We’re invited to the cross‐eng director’s meeting and, at least in I&P, we’re involved in roadmap planning and management syncs. Recently, we’ve brought in Staff engineers to participate in some promotion calibration meetings.

The level of access gives some sense of having a foot planted on both sides. The role is different enough from Senior levels that it’s not quite as much an “individual” software‐contributing role, but it’s also quite different from our more people‐focused management track.

Out of Will’s Staff archetypes, I think my role fits somewhere between the Solver and the Tech Lead. Part of the fun for me has been jumping into a different role every 6‐12 months, diving into a different part of the system with a different group of folks.

How do you spend your time day‐to‐day?

It’s pretty varied by the day. Right now, I try to make Tuesdays and Thursdays meeting days so that I have dedicated focus time in the rest of the week.

My meeting days typically include 1:1s with folks I’m working closely with as well as staff meetings. I’ll also spend some time pairing with individuals on code and design review or more open‐ended design dis‐ cussions.

On other days my focus time is spent in investigation mode, trying to suss out both current issues and paving foundation for future projects. What systems need investment? How have our teams been executing? What upcoming changes should our group prepare for? This time is spent shaping in a broader sense.

Looking back, this focus is distinct from my role prior to Staff. Instead of executing at the individual level working directly on a project or team, the time is centered around a wider lens and over a longer term. Notably, it’s hard for me to guarantee anything longer than a day at a time spent writing code. I don’t get counted when we consider engi‐ neering roadmap bandwidth, though I do try to reserve at least a day a week for writing some code.

At the micro‐level, I keep a document called “what is stephen doing?” that drives my work on the hour‐by‐hour granularity. There’s one main section for the current week and some reminders for future weeks. Every Monday, I start over ‐ unstarted items from the previous week get deleted and few survive to the next week.

That delete‐by‐default intention ends up helping me keep focused and not feel too strewn out. For a long time, I tried to groom a back‐burner list of things to do but it mostly had the effect of stressing me out. Most back‐burner items would end up deleted and incomplete anyways, a month later.

Do you spend time advocating for technology, practice, process or ar‐ chitectural change? What’s something you’ve advocated for? Can you share a story of influencing your organization?

Yes. The specific technology or methodology changes quarter to quarter, but advocacy ends up being a big part of my time. On the smaller end, I’ve helped write culture documents about how we try to approach design documents or code review or code ownership rules. For a bigger example, I spent a couple quarters helping our product teams adopt Service Level Objectives (SLOs).

At the time, we had a fairly established set of features and customer base, but our measurements for uptime were still primitive. In outages, it was hard to get a sense for customer impact because we lacked the distinctions and definitions to communicate (“What percent of customers are affected? Is it both reads and writes? Is this an outage or an existing bug?”), even though we had plenty of metrics and dashboards to look at.

Figure 5: what is stephen doing?

Though introducing SLOs certainly required new engineering work, I’d guess that the majority of my time on the project was spent writing documentation, talking to people, and doing consultancy‐style work with teams. We wanted folks to be able to understand reliability ob‐ jectives end‐to‐end: how to define the objective, how to talk about it in outages, how to measure it in systems, how to keep track of it over time, how to react when it becomes unhealthy. That level of depth ends up needing a lot of messaging and massaging to sink in.

As with most of our big “migrations,” getting many teams to adopt SLOs came iteratively. We first trialed our new tools with a single team with high‐touch support before figuring out the widespread messaging for the rest of the org. I think a key role for me was being able to both talk with engineers about the new tools at a concrete, how‐do‐I‐use‐this level, while also convincing director‐level folks that it would be worth their effort to speak in SLOs.

This same pattern has held true over most of my projects as a Staff engineer. My role ends up being in brokering deals between groups to sell a change across the organization.

How do you keep in touch with how things really work as you spend less time on hands‐on development?

I put in some time programming and doing code review each week, even if it’s just to put up a small bug fix. I try to put in time to partici‐ pate in the same day‐to‐day rituals other ICs go through ‐ code review, navigating docs, outage situations, etc.

Of course, that’s not enough to keep a high‐fidelity model in my head ‐ there’s just too much happening across too many teams to keep track of. The rest is a lot of intentionally seeking out feedback and hearing first‐hand experiences from others.

I’ve also tried to help bake feedback loops into our organization. I helped get us started on doing half‐year dev team surveys with a mix of questions about both our technical systems and engineering culture. The responses from those surveys have been super helpful in keeping a pulse on how the organization is feeling from the ground up.

How have you sponsored other engineers? Is sponsoring other engi‐ neers an important aspect of your role?

Yes. I’ve tried to be intentional about giving away my state, stepping back, and letting others build up expertise.

At the organizational level, I think there are ways to structurally spon‐ sor others, pushing other engineers into taking positions as subject‐ matter experts. As an example, I worked on introducing a new dis‐ tributed tracing system late last year. Our core web application is pow‐ ered by a number of different backend systems and over years, the data flows between these systems became trickier to understand and page performance suffered. We needed a tool to dig ourselves out.

I had worked on early iterations of our performance tools before and knowledge of those systems was largely stuck in my head. In the new project, a concrete goal for me was to bring more folks up to speed. It wasn’t enough to lay a technical foundation in the systems design: my teammates on the project would have to own that area of expertise for years to come.

Practically, that meant spending more of my time discussing and pair‐ ing with the soon‐to‐be tracing owners and much less time directly contributing code or design. When we beta tested with a product team, I’d push another engineer to work on a sales pitch, or figure out the demo, or get the team onboarded.

Today, the tracing system is widely used and fully managed by our SRE and Observability group. The folks I worked with at the time are now the go‐to group for performance questions.

On a more personal level, there are always small spots where I can help nudge other folks into the spotlight. Sponsorship opportunities can start small. Especially if I’m working with someone earlier in their career, I might suggest that they take on more unknown chunks of a new system design, or write a draft for new documentation, or demo our results at our group‐wide meeting.

That small push might be all someone needs to get going, but other times I think it flows nicely into an opportunity to mentor and pair as well. Some things (like building up a slide deck for the first time) can feel intractable until you do them a couple times. There, both the sponsorship and mentorship sides end up feeling impactful.

It also feels like there’s some tension to get to the right spot. We want to grow folks into positions where they can own more and make sys‐ tems decisions, but we also want there to be alignment in how those decisions get made and where we’re trying to go. It’s hard work ‐ it ends up taking a lot of attention to not gatekeep but get to a satisfying result.

You first got the title Staff Engineer at your current company. Were you hired as a Staff Engineer? If not, what was the process of getting promoted to Staff?

When I joined the company, we didn’t have IC titles. I was leveled into the Staff role when we introduced leveling in early 2019.

I think I had a big advantage from being an early engineer on the team. That history was huge in giving me context on our past decisions ‐ knowing what pitfalls we had already run into and helping land new projects into a good place.

At every stage of growth, we would add more layers of people and man‐ agement and there’d be a “relearning” period for how the organization worked. 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 di‐ visions, 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.

What two or three factors were most important in you reaching Staff? How have the companies you joined, your location, or your education impacted your path?

My background is somewhat less traditional ‐ I studied Electrical En‐ gineering instead of Computer Science and dropped out of school be‐ fore completing my degree. That gap forced me to be more self‐taught in my experience, but also left me with a lot of imposter syndrome. I failed a lot of software interviews early on for not having the right credentials. Early in my career, that imposter feeling made me really want to learn as much as I could to cover up for what I feared I didn’t know.

The summer before I dropped out, I interned at Stripe. I remember, perhaps through rose‐tinted glasses, feeling so energized by the en‐ gineering culture there: the hyperfocus on customer experience and excitement about building technology to get there. That experience ended up being quite influential to how I wanted a workplace to feel.

Later when I left school, I started working full‐time at a smaller startup where I really didn’t know what I was doing. The business meandered a bit during my time there, but I was lucky to have worked closely with thoughtful, senior engineers who had a penchant for mentorship. Working there ended up giving me a lot of flexibility on what I wanted to learn which was good for me but probably bad for the company.

As a last bit of background, I worked at a computer camp for a couple summers in high school, teaching school‐aged kids basic computer lit‐ eracy. That teaching mindset certainly left me with more empathy for how folks end up understanding and interacting with computer sys‐

tems.

By the time I joined Samsara, those experiences gave me a clear sense for how I wanted work to feel ‐ being an early employee gave me the influence to shape the way there.

The final piece of the puzzle was my first three years at Samsara. I was fortunate enough to get to work with so many thoughtful collaborators in that time. I can easily trace back many of the working habits, mental models, and mannerisms that I have today to those individuals. I can’t imagine that I’d be in this spot in my career without their influence.

There is a popular idea that becoming a Staff Engineer requires com‐ pleting a “Staff Project.” Did you have a Staff Project, and if so what was it?

No, I didn’t have a designated Staff Project. Looking back, there were projects over the years that perhaps accumulated into the equivalent of a big Staff project, but it’s not something we explicitly talked about in leveling.

As a concept, I’m skeptical of that kind of singularly focused project and worry that they can put folks into a hero mindset when we really want to value engineers that can build the organization, not carry it. I’d be much more excited to see iterative improvement and consistent execution over time: a track record of thoughtful engineering.

I’m happy Samsara seems to agree with that assessment. Our career path document ends up talking much more about that consistent exe‐ cution over a single large‐haul project.

What about a piece of advice for someone who has just started as a Staff Engineer?

A couple things come to mind.

Get comfortable talking a lot. I think a big step‐change between Senior and Staff roles ends up being the focus on people: reconciling compet‐ ing priorities, clearing up miscommunication, aligning folks on the same page. Even though they typically don’t have direct reports, Staff engineers are working in a system of both the technology and the peo‐ ple: the biggest impact is going to come from influencing both.

Do your best to not get exhausted. As I transitioned into a Staff role, it felt easy to slip into a mindset where I was responsible for everything going on and had to timeslice my focus over too many things. It took me a while to recognize that this role didn’t mean I had to work many times harder to be involved in everything, but instead I needed to di‐ rect change through others in the organization. Trust folks, flag issues, and expect them to work it out.

Did you ever consider engineering management, and if so how did you decide to pursue the staff engineer path?

Back in 2016, I remember having an initial conversation with my man‐ ager about pursuing an IC vs management path. At the time, I still felt early into my professional career and wanted to continue investing in my core technical experience.

I reevaluated that decision every year or so and ended up coming to the same conclusion ‐ that I wasn’t done getting my hands dirty on the technical side. Throughout that time, much of the work I was doing was focused around building development experiences for folks at the company. Those efforts ended up pushing me to do more Staff‐like work and I naturally progressed from there.

What are some resources (books, blogs, people, etc) you’ve learned from? Who are your role models in the field?

I tend to prize literature that talks about complicated topics in plain English, both fiction and non‐fiction.

I remember reading about novelist Haruki Murakami writing his first novel in English first, then translating it back to Japanese as a way of shaping the style of his expression. He notes, “I could only write in simple, short [English] sentences. Which meant that, however com‐ plex 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 sen‐ timent 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.

I love reading blogs and papers that really go in depth in a technical area. A few that I’ve come back to over the years include: ‐ Bob Nys‐ trom’s blog posts on programming languages ‐ Vyacheslav Egorov’s blog about compilers and V8 internals (Chrome’s JS engine) ‐ Bran‐ dur’s blog on various systems topics ‐ Nelson Elhage’s Accidentally Quadratic ‐ Vicki Pfau’s Blog on developing a GameBoy Advance emulator ‐ fail0overflow’s blog and talks about console architecture and exploits ‐ Bungie’s engineering publications on building and producing the original Halo games

As an anecdote, early in my career I had a budding interest in pro‐ gramming language internals and picked up a compilers textbook (“the Dragon book”) to learn from. It’s a pretty hard book to get through. Maybe it’s reasonable to get through it with a professor and a few classmates, but it was truly difficult for me to get a working mental model from a reading. Later, I found Bob Nystrom’s Crafting Interpreters which takes a much more practical approach and it felt like a huge breath of fresh air.

I’m also a big fan of reading codebases. Early on in my career, I recall debugging a tricky React problem where some callback wasn’t happen‐ ing in the order I expected. Reading the docs didn’t help. Putting in print statements wasn’t enough. My mentor at the time got me to read some of the source code to better understand what was going on and that really blew my mind a little bit. I got a bug fix in but also a much stronger understanding of how React worked.

That was really a turning point. Being able to quickly dive in and jump through unfamiliar has really felt like a superpower and gives me a larger pattern matching library for different approaches to software design. A recent favorite has been reading through the design and code of esbuild, a super fast javascript bundler.

Finally, some of my favorite recent non‐fiction reads in the last couple years have been on the history of BART, the history of Xerox PARC, and an overview of modern Japanese culture. In each niche, I’ve found the history and context fascinating as seemingly small, independent events and decisions have culminated into ways the world works today.