“Staff Engineer” Read Through, Part 7 (The End!)
Damian Schenkelman through Stephen Wan, Pages 260-293
Damian Schenkelman
At writing. Damian was a Principal Engineer at Auth0. He describes that most Staff+ engineers work in a similar capacity to himself, focusing on the projects for a team they embed with, while also working across an org or the company to have broader scope and influence.
Damian reached Principal at Auth0 through a circuitous route. He joined very early (employee 10, engineer 5), and within 18 months was made a Director of Engineering. After leading the engineering organization in this capacity for ~3 years, he chose to move back to an IC role. I haven’t really evaluated any other folks’ paths in terms of time, but 3 years was about how long my first jaunt through management took. I wonder if there is something to that, like going through performance evaluation a number of times, many promo cycles, planning cycles, and knowing these processes may not be particularly malleable. Damian notes that moving back to an IC role made other engineers more receptive and less defensive when he gives feedback. I had similar experiences, and think this may be that if a manager (or other people manager) is providing technical feedback, it can feel uninformed or an order not a suggestion. As a peer engineer this is a different dynamic, and feels more constructive.
Damian notes that he has chosen a route of scaling influence through alignment and direction across as many engineers as possible. He noted that to scale, impact has to be across many people rather than individual deliverables. He notes that he sometimes codes PoCs, but that’s the exception. I don’t think 1-5% is the right coding time for me now, but 20% feels right. I feel like it needs to be at 60-80% now, and that feels lower impact, but I know it is necessary. One of Damian’s examples of this kind of impact is establishing a repeatable process for reviewing designs/RFCs, including (this is something I love and have *tried* to establish and failed) a decision log to refer to if questions come up or changes are needed in the future.
There are some other interesting bits of Damian’s narrative, but I can’t really put together thoughts cohesively. Maybe a list?
Privilege and luck are a big part of moving up
When there’s not time for a full vision, start with advice that’s least wrong, and least likely to be contradicted when vision is established.
Listen. If there are rumors, squash them as fast as you can and combat with real data.
Make customer connections
—
Dmitry Petrashko
At the time of writing, Dmitry was a Staff Engineer and Technical Advisor to the head of Infrastructure at Stripe. He explains that infrastructure at Stripe intends to empower engineers to focus on product, knowing all of the glue and tools are taken care of. In his role as TA, Dmitry does a lot more research and intelligence gathering on behalf of the executive he supports, versus directly making decisions or building software.
He did explain the Pillar Tech Lead role as a more traditional staff engineer position at Stripe. Those in this role arbitrate technical disagreements (I once asked the incoming CTO during an acquisition who arbitrated in technical disagreements, and she said that wasn’t a problem so the question didn’t have merit), guide tech direction, socialize outside decisions to a pillar, and inside decisions outward. He does note that partnership with people leaders is key in the TA role and PTL role, but there is a different strategic and tactical balance.
Like many others, Dmitry notes that he tries to write some non-blocking code to stay connected to the experience and challenges other engineers face.
Dmitry shares that at his most impactful he is taking good ideas from teams that may lack some key experience or context, and simplify it while retaining the positive impact. I can’t claim that this is something I do frequently, but definitely love to ask important questions at the right time, and save effort and churn. His bottom line, and I think it aligns fairly closely with mine, is that empowering other engineers is what matters most.
An interesting evolution of his approach that Dmitry discussed is that on previous projects he might work on them for years, ensuring successful delivery by staying hands on. Instead of this approach, he explains that he is now very involved at the beginning of a project, but ensures he is finding a person that can grow by leading this, setting them up for success, then stepping back. I definitely love this type of force multiplication. I think a current point of struggle is that I’m… quick to have ideas, but don’t get things to a place that they’ll be taken up and run with. This seems to mostly be a trust and positioning problem, but I think there’s an ownership and follow through problem on my end, too. I’ll need to work on that, amongst so many other things.
The next section I really loved, and is what I crave getting back to: direct connection to engineers. One aspect Dmitry contributed to culture and data gathering via a Stripe-wide engineer survey. I will never stop admiring efforts like this and strive to reproduce them in some way. The Tech Survey at Amazon changed how I looked at scope and understanding of data. Getting high participation, then boiling out action items, and being accountable to them with my teams was a real highlight for me. Leah’s leadership as Voice of the Developer was and remains aspirational to me. The second bit Dmitry notes is having impromptu conversations with engineers gathering details about what they are working on, why it’s hard, and if infra can help. I am desperate for this. I was so close to working on developer tools at Meta when they pulled their L6 req so couldn’t bring me there. I wanted to see my work amplify the work of 1,000s of others, and find out what was delightful and abhorrent about the tools from them.
An interesting tidbit that cropped up in discussing promotion was getting feedback fast, asking privately after meetings. There have been times where I’ve solicited feedback outside regular forums. I did so anonymously to try to get more authentic feedback. It… stung. Maybe a good idea, but I wasn’t mature enough to hear some of it at the time. Another tidbit about his growth was his em/immigration journey. I am incredibly lucky to have the color of skin I have, and to have been born at this time in history, and to be a native English speaker, and naturally born American (and male, and tall, and cis, and…). Dmitry described moving from Ukraine to Russia to Switzerland to the US throughout his education and career. This is a tremendous amount of change, requiring learning in a learned language, cultural acclimation, adapting to new people and places… it is a testament to Dmitry and all immigrants that grind through difficult circumstances to gain opportunities handed to others.
The last thing I wanted to highlight was Dmitry describing working on a hugely impactful project as a collaborator, and the resulting ambiguity of ownership and impact affecting all of their promotions. He noted that when the project got bigger, this got clearer, and made the case easier, but this also highlighted the importance of understanding and enunciating your own impact.
—
Stephen Wan
As of the writing of his narrative, Stephen was a Staff Engineer at Samsara, where he worked in Infrastructure and Platform, working to improve developer experience and tools. This seems right up my alley, and measuring and improving engineer sentiment and productivity (not lines of code or pushes, but more about removing blocks and time wasted on process or wrestling broken tools).
Staff engineers at Samsara are director-level roles, which was surprising to me. At Amazon, Senior engineer was equivalent to a line manager, there was no Staff role, and Principal Engineer was equivalent to senior manager (below Director). Senior principal was Director level. At Meta I believe Director was L8, so two steps above Staff on the IC side (I think that is Principal there, despite them shunning titles). This is the same at Google. I say this to say that I’ve never felt close to director level, so it’s interesting to get the perspective from a different place.
I liked was how Stephen addressed coding: he does it, but can’t promise more than a day at a time of dedication, and isn’t counted in project planning, but still does try to code about a day a week. These guardrails would work really well for me, while trying to be a key part of delivery, especially working solo, feels very antithetical right now.
Another interesting artifact Stephen discussed was an hour by hour accounting of his time, and using that to examine if priorities are right, and drops things quickly that are not getting bandwidth so it’s clear they need another owner or won’t get done. My time management needs a major overhaul, and it’s on my list along with working on focus and rebuilding some endurance.
I appreciated Stephen’s approach to getting a new standard behavior adopted (SLOs). It wasn’t a big-bang, I-said-so effort. Stephen began grassroots understanding engineers’ resistance, and helping them understand tooling, while also working top down to convince directors that spending time understanding and then framing goals around SLOs would be valuable. Through salespersonship, on both ends of the spectrum, Stephen was able to affect a big change without an authoritarian approach.
Stephen ALSO started a dev team survey, and it is now sort of ringing in my ears. Google used to have Googlegeist, an annual survey to capture sentiment across the company. They are doing micro questions now with… well… I consider it lower value and no one has talked about outcomes after months of people answering questions. Maybe it will drive valuable change, but more in-depth, repeated surveys feel better to me. Stephen also leverages ad hoc feedback gathering and coding/reviewing to stay connected to the work engineers are doing.
I loved Stephen’s take on the “Staff Project”, asserting that focusing on one person and their heroics on a project is the opposite of what a more senior IC should do, which is build up a team and divide work up, while giving people tasks that grow them. At Amazon while trying to get to Senior SDE, I kept getting my promo rejected because there wasn’t some big project that I owned. Except I kept a bunch of these projects on-track, sometimes with a lighter approach than others. But not having the most commits or whatever prevented this from being recognized as “mine” OR the right people didn’t see it happen, so it didn’t count.
I talk a lot. My writing isn’t that different from my talking. Sometimes it’s way too much, and I know this. Stephen does call out, though, that you will have to talk, and achieve things with persuasive speech and effective debate as you move up the ladder. Influencing others is a huge part of the job.
Stephen discusses the debate about moving to management, and I had the same perspective. I wanted to be closer to code, while still leading. I folded and moved to management because it was a better path at the time after attempts at promotion as an IC continued to fail, and my team was not I a good situation when it came to management after some key departures.
The last point I liked a lot was that clear communication was a lynch pin. Being able to synthesize information and enunciate it clearly to others is critical, and can be a difficult skill, especially right-sizing detail to various audiences. I got pretty good at this, but I haven’t used that muscle in a while.
—
OK, well… that’s done now. I made the Part 0 post 2 months and 1 day ago. I don’t know what I expected the process to be, but it wasn’t this. This was harder to finish than planned. I also have a creeping feeling I should do more with my learnings but don’t know what. I don’t think I have clear perspective on if this is a good book and if I would recommend it. My experience is greatly colored by tasking myself with these write ups. I loved the perspectives of a diverse set of Staff engineers. Maybe that’s good enough to say it’s worth reading. Heck, maybe just read those first?
Thanks for reading!