sec19-stories

Stories: Patterns from 14 Staff Engineers

selt staff-engineering stories career real-world

Status: Notes complete

---

Overview

The final section of Larson’s book is a collection of edited story transcripts from 14 Staff-plus engineers working at companies including Stripe, Mailchimp, Slack, Fastly, Dropbox, Etsy, Squarespace, Uber, Auth0, Split, and Samsara. Larson built staffeng.com expressly to fill a gap: the engineering management track had been extensively documented (The Manager’s Path, High Output Management), but there was almost no first-person literature about what it looks and feels like to operate as a Staff-plus IC. The stories are not case studies in the business-school sense — they are not structured to prove a thesis. They exist to show, through concrete lived experience, that the Staff-plus role is real, varied, and navigable.

The most important thing these stories collectively communicate is that the frameworks in the book’s earlier sections — the archetypes, the promotion mechanics, the operating principles — are not theoretical constructs. They are the distilled patterns that emerge when you listen to enough engineers who have actually lived through the transition.

---

The 14 Engineers — Quick Reference

#	Name	Company	Title	Archetype	Key Story Theme
1	Michelle Bu	Stripe	Payments Products Tech Lead	Tech Lead	Managing scope creep when promoted; staying technical while leading; the identity shift after getting the title
2	Ras Kasa Williams	Mailchimp	Staff Engineer	Solver	Doing Staff work at a company that had no Staff title; retroactive recognition; the value of tenure and institutional knowledge
3	Keavy McMinn	Fastly	Senior Principal Engineer	Architect	Career through multiple companies; architectural influence across org boundaries; being hired directly into senior IC roles
4	Bert Fan	Slack	Senior Staff Engineer	Tech Lead / Solver	Navigating ambiguity in the title transition; the role of peers and colleagues in defining your scope
5	Katie Sylor-Miller	Etsy	Frontend Architect	Architect	Making “glue work” legible as Staff-level impact; web performance as a strategic domain; the promotion packet as a forcing function
6	Ritu Vincent	Dropbox	Staff Engineer	Tech Lead	Being intentional about what kind of Staff work you want to do; choosing technical depth vs. breadth; saying no as a growth skill
7	Rick Boone	Uber	Strategic Advisor to VP of Infrastructure	Right Hand	The Right Hand archetype in practice; how this role differs from all others; the personal cost and reward of operating at executive speed
8	Nelson Elhage	Stripe (formerly)	Staff Engineer	Solver / Architect	Leaving a Staff role; what you learn about the role only after stepping back; security as an organizational challenge, not a technical one
9	Diana Pojar	Slack	Staff Data Engineer	Tech Lead	Data engineering as a Staff domain; bridging data and product; the challenge of cross-functional influence without shipping features
10	Dan Na	Squarespace	Staff Engineer and Team Lead	Tech Lead	Combining Staff IC and team lead responsibilities; when managing people and doing technical work are complementary rather than in conflict
11	Joy Ebertz	Split	Senior Staff Software Engineer	Architect	Navigating Staff work at a smaller, less-structured company; when there is no established pattern for the role; creating the role’s definition yourself
12	Damian Schenkelman	Auth0	Principal Engineer	Architect	Growing into a Principal role through technical writing and external visibility; how blog posts and talks compound influence
13	Dmitry Petrashko	Stripe	Tech Advisor to Head of Infra	Right Hand / Solver	Deep technical expertise as an organizational asset; the compiler and language background applied to infrastructure problems; long-term bets
14	Stephen Wan	Samsara	Staff Engineer	Tech Lead	Hardware-adjacent software infrastructure; domain knowledge as differentiation; Staff work in a less mature engineering organization

---

Cross-Cutting Themes

Theme 1: Paths to Staff Are Diverse

There is no canonical path. Across the 14 stories, engineers reached Staff level through internal promotions after long tenure at one company (Ras Kasa Williams at Mailchimp), by switching companies and being hired directly into a senior IC title (Keavy McMinn’s repeated moves between companies), and through retroactive recognition when a company finally created the title (Williams was effectively doing Staff work years before a Staff title existed at Mailchimp).

Some engineers received the title as a result of a specific Staff project; others received it through accumulated organizational impact that is harder to point to. Some worked for companies where Staff engineering is a well-established function with clear expectations; others had to invent the role’s definition from scratch. The implication for engineers trying to reach the title is that strategy matters: the mechanics that work at a large, well-structured company (promotion packets, sponsors, Staff projects) are not the only mechanics that exist.

Theme 2: The Role Changes After the Title

Multiple engineers describe an adjustment period following the Staff promotion that is uncomfortable in ways they did not anticipate. The work that built the reputation leading to the title — deep technical execution, reliable delivery, close team partnership — does not automatically translate into the work valued at Staff level. Scope expands. Ambiguity increases. The validation loops that existed at Senior (sprint completions, code reviews, feature launches) become less frequent. Several engineers describe a disorienting period of not knowing what “good” looks like anymore and having to consciously recalibrate.

Michelle Bu’s story at Stripe is particularly articulate about this: the transition involves an identity shift, not just a job description change. Engineers who expect the title to feel like a reward — that things will be easier, more clearly defined — are frequently surprised by the opposite. The title creates expectations that the engineer must then grow into.

Theme 3: Sponsorship Was Critical

In nearly every promotion story, a specific person’s advocacy was decisive. The sponsor was not always a formal manager — often it was a senior Staff or Principal engineer who recognized the candidate’s impact before the organization formally codified it, and then made the case to the people who controlled promotion decisions.

Ritu Vincent’s story at Dropbox describes this explicitly: her sponsor created opportunities for her to demonstrate Staff-level impact and then vouched for that impact in the promotion conversation. The relationship required years of trust-building and genuine performance — sponsorship cannot be manufactured, only earned. Several engineers also note the corollary: without a sponsor, promotion stalled regardless of the quality of the work. The technical merit was necessary but not sufficient.

Theme 4: Engineering Strategy and Technical Direction

The practical meaning of “setting technical direction” varies substantially by company type, but the stories consistently illustrate that it involves written artifacts, sustained advocacy, and cross-team coordination — not solo technical work. Keavy McMinn describes architectural influence at Fastly as a process of writing proposals, building consensus across teams that have different incentives, and accepting that the implementation will be shaped by many hands. Diana Pojar’s data engineering work at Slack required creating standards and data models that would be adopted by teams she had no authority over.

What is consistent across the stories is that technical direction is not declared — it is earned through credibility, persistent communication, and visible commitment to the long-term health of systems even when the short-term pressure points elsewhere.

Theme 5: Operating Without Authority

The stories are full of concrete examples of cross-organizational influence without direct reporting relationships: Damian Schenkelman at Auth0 built influence through technical writing that shaped how engineering teams across the company reasoned about distributed systems. Katie Sylor-Miller at Etsy made web performance a first-class concern by combining deep expertise with the ability to translate technical impact into business metrics that product and leadership could act on. Rick Boone at Uber used his proximity to the VP of Infrastructure not as authority delegated from above but as a platform for amplifying and coordinating work that would otherwise fall in the gaps between teams.

The consistent mechanism is: develop enough expertise and enough organizational context that people voluntarily seek your input, then use that position to shape outcomes without requiring formal control.

Theme 6: The Equity and Access Challenge

Several of the engineers from underrepresented groups describe a structural asymmetry that deserves explicit attention: the same quality of work does not always produce the same organizational recognition. Engineers who are not in the default demographic often need to be more explicit about documenting their impact, more deliberate about sponsor relationships, and more vocal about advocating for themselves than their peers with equivalent output. The promotion system, which relies heavily on informal advocacy and visibility, tends to amplify advantages already present in the organization.

Katie Sylor-Miller’s discussion of making “glue work” legible speaks to a related dynamic: the coordination, documentation, and enabling work that keeps teams functional is disproportionately done by engineers from underrepresented groups, and it is systematically undervalued in promotion conversations because it does not produce obvious technical artifacts. The promotion packet becomes a critical tool — not because the work wasn’t done, but because it was invisible until written down.

Theme 7: Company-Specificity of the Role

Perhaps the most striking pattern across the 14 stories is how different the Staff-plus role looks in different organizational contexts. At Stripe, Staff engineers operate in a dense, highly structured engineering culture with strong norms around technical rigor, written communication, and organizational influence. At Mailchimp, the role was less formalized and the work looked more like being the most experienced engineer on a team. At Uber’s infrastructure division, the Right Hand role Rick Boone describes has no real equivalent at a 200-person company. At Samsara, Stephen Wan’s Staff work involves domain knowledge about hardware and physical systems that most software-focused companies would not recognize as central to the role.

The lesson is not that some companies do Staff engineering “correctly.” It is that the title is a container whose contents are defined by the company’s engineering culture, maturity, size, and business model. Engineers evaluating whether a Staff role is real must look at whether the company has the conditions that make Staff-level work possible, not just whether the title exists.

---

Individual Story Highlights

Michelle Bu — Stripe (Tech Lead)

• Describes the title transition as an identity challenge, not just a role expansion: the work she was rewarded for at Senior — deep individual execution, reliable delivery — suddenly mattered less, and she had to build new skills (broader influence, written communication, organizational navigation) quickly.
• Was explicit about the scope creep problem: after promotion, the number of things she could have an opinion on vastly exceeded what she could actually engage with meaningfully. Learning to scope her involvement deliberately was a post-promotion skill she had not needed before.
• Found that technical depth remained important at Stripe even in a Tech Lead role — the company’s culture rewards engineers who can credibly engage with implementation details, not just architectural abstractions.
• The Stripe context mattered: a payment infrastructure company with high reliability requirements meant that Staff-level technical judgment had real consequences measured in financial and regulatory risk, not just code quality.

Ras Kasa Williams — Mailchimp (Staff Engineer)

• Spent years doing Staff-level work before the title existed at Mailchimp — a common situation at companies that added Staff titles retroactively as the engineering org matured.
• His story is an argument for long tenure as a compounding advantage: the institutional knowledge, the trust network, and the systems-level mental model that comes from years at one company are genuinely hard to replicate through external hiring or rapid promotion.
• Describes a quieter variant of the Staff role: not architecting massive cross-company initiatives, but being the person who has seen everything and can reliably identify which problems are new and which are old problems in new clothes.
• The Mailchimp engineering culture at the time was less formal than Stripe; the Staff title brought recognition more than it changed the actual work, which distinguishes his story from the “identity shift” narratives at more structured companies.

Keavy McMinn — Fastly (Senior Principal Engineer)

• Built a Staff-plus career by moving companies deliberately rather than grinding for promotion at one place — each move brought a title upgrade and a new technical domain.
• Her technical focus — APIs, developer experience, and systems interoperability — is a domain that requires cross-organizational influence by definition: the value of a well-designed API is visible only when other teams actually use it.
• At Fastly, Principal Engineering involves genuine architectural authority over large portions of the technical platform, which requires both technical depth and the political skill to get architecture proposals accepted across teams with different priorities.
• Notes that being hired directly into senior IC roles (rather than promoted internally) requires demonstrating in the interview process not just technical capability but organizational judgment — interviewers want to know whether you can operate effectively without the institutional context a long-term employee would have.

Bert Fan — Slack (Senior Staff Engineer)

• Describes a gradual recognition of scope — he was operating at Staff level before he and his manager had an explicit conversation about it, and the title came as a formalization of existing practice rather than a signal to change behavior.
• The peer environment at Slack was important to his story: being surrounded by other strong engineers who operated at the same level created both pressure and support; he learned what Staff-level operating looked like by watching colleagues who were doing it.
• Navigated the ambiguity of scope definition: at Slack, Staff engineers are not handed a charter — they negotiate their scope through demonstrated impact and organizational trust.
• His story reinforces that sponsorship at Slack operated through peer advocacy, not just top-down advocacy from managers — senior engineers vouching for each other was a meaningful part of the promotion process.

Katie Sylor-Miller — Etsy (Frontend Architect)

• Her story is the most detailed account in the book of making invisible work legible: she documented the web performance work she and others had done (coordination, standard-setting, tooling, knowledge transfer) in a promotion packet that made the organizational impact of that work visible for the first time.
• Web performance as a Staff domain is a concrete example of an Architect archetype: she owned a technical area that cut across every product team, required both deep technical expertise and cross-functional communication, and produced business-measurable outcomes (conversion, Core Web Vitals, revenue).
• Addresses the frontend bias in Staff conversations directly: her story counters the assumption that Staff-plus titles are primarily for backend, infrastructure, or platform engineers. Frontend architecture at scale is a legitimate Staff domain.
• The promotion packet in her story was not merely administrative — it was a forcing function that required her to articulate the scope and impact of her work in a way she had never done before, and the articulation itself changed how she and her manager understood what she had built.

Ritu Vincent — Dropbox (Staff Engineer)

• Her most distinctive contribution to the collective story is a clear articulation of intentional career design at Staff level: after reaching the title, she was deliberate about which kind of Staff work she wanted — deep technical execution in a focused domain rather than broad organizational coordination.
• Describes the post-promotion choice explicitly: many Staff engineers drift toward whatever the organization needs without asking what they personally want from the role. Vincent made an active decision and communicated it to her manager.
• Her sponsor at Dropbox gave her access to high-visibility projects specifically to create promotion opportunities — the sponsor-as-door-opener pattern is clearest in her story.
• Notes that saying no — to scope expansions, to lateral requests that would dilute her focus — became a more important skill after the title than before it, because the organizational pull to be involved in everything was stronger.

Rick Boone — Uber (Right Hand)

• The only story in the collection that centers the Right Hand archetype, making his account uniquely valuable for understanding what that role looks like in practice.
• The Right Hand role at Uber’s infrastructure VP level involves filling gaps at executive speed: when the VP needs a problem investigated, a decision accelerated, or a team coordination unblocked, Boone was the person who made it happen. The work is defined by the executive’s priorities, not by a fixed technical domain.
• Describes the personal cost: operating at executive speed means context-switching constantly, rarely finishing anything you start, and deriving satisfaction from organizational outcomes rather than technical deliverables. Engineers who find meaning in deep technical execution often find this role draining.
• The leverage is unique: one person operating at this level can have more organizational impact than a team of engineers working on well-defined problems, because the bottlenecks addressed are structural rather than technical.

Nelson Elhage — Stripe (formerly, Staff Engineer)

• His story is unusual: it is told from the perspective of having left a Staff role, which gives him distance to articulate what the role actually required that was not visible from inside it.
• His work at Stripe focused on security — specifically, making security a first-class organizational concern rather than a team that reviewed PRs. His framing: security is an organizational architecture problem, not primarily a technical one.
• Describes the challenge of working on problems that are structurally invisible until they fail: security debt, like other forms of technical debt, accumulates silently and the organizational incentive to address it is weaker than the incentive to ship features.
• Reflects on what it means to leave a Staff role voluntarily — for him, it was about intellectual freedom and the opportunity to work on problems he found more interesting. The Staff title is valuable but is not the only measure of meaningful technical work.

Diana Pojar — Slack (Staff Data Engineer)

• One of the few data engineering stories in the Staff literature, making her account particularly valuable for engineers in analytics engineering, data platform, and ML infrastructure roles that often have unclear Staff pathways.
• Her Staff work centered on data modeling and data platform standards — creating canonical data structures and pipelines that could be relied upon by product, analytics, and ML teams. The impact was real but diffuse, which created promotion challenges.
• Describes bridging data and product as the core challenge: data engineers often operate in a supporting role relative to product engineering, and asserting Staff-level influence requires demonstrating that data infrastructure decisions have product-level consequences.
• The absence of feature-shipping deliverables in data engineering work made her Staff-level impact harder to document and advocate for — her promotion story involved explicitly making that impact legible in the language that engineering leadership used to evaluate Staff work.

Dan Na — Squarespace (Staff Engineer and Team Lead)

• His story directly challenges the assumption that managing people and doing Staff IC work are in conflict: at Squarespace, he combined both, and found them complementary rather than competing.
• The combination worked because his people management scope was small (one team), while his technical scope was broader. The managerial work gave him direct organizational context that made his technical leadership more effective, not less.
• Describes Staff work in a less mature engineering organization as an opportunity: the absence of established patterns meant more latitude to shape technical direction, but also required more effort to build the organizational infrastructure (process, standards, documentation) that more mature companies have already developed.
• His dual role is more common than the book’s framework suggests — the Tech Lead archetype often exists in this hybrid form, especially at mid-sized companies where the engineering management and IC tracks have not fully separated.

Joy Ebertz — Split (Senior Staff Software Engineer)

• Working at a smaller, less-structured company (Split), her story is the clearest account of creating the Staff role’s definition from scratch — there were no existing Staff engineers to emulate, no established charter, no standard set of expectations.
• She describes the freedom and the disorientation of this situation: the latitude to define her own scope was real, but so was the absence of feedback loops. Knowing whether she was doing the job well required building her own evaluation framework.
• Her technical work focused on distributed systems and data consistency — problems that are invisible to users when working and catastrophic when not, which maps cleanly to the “unglamorous but essential” pattern common to Staff-level technical work.
• Notes the leverage asymmetry at small companies: a Staff engineer at a 200-person company can shape engineering culture and technical standards in ways that are simply not possible at larger companies where culture is more established and change moves more slowly.

Damian Schenkelman — Auth0 (Principal Engineer)

• His story is the clearest account of external visibility as a compounding career investment: he wrote technical blog posts and gave conference talks that built a reputation outside Auth0, which fed back into organizational credibility inside Auth0.
• The mechanism: engineers who read his posts would join Auth0 and already have context on his thinking; outside engineers would reference his writing in discussions; leadership saw external validation of his technical judgment.
• Describes Principal engineering at Auth0 as deeply tied to technical writing — the expectation was that a Principal engineer produced written artifacts (proposals, standards, architecture docs) that shaped how the entire engineering org reasoned about problems.
• His path to Principal involved no single Staff project — it was an accumulation of writing, talks, internal proposals, and technical leadership that together demonstrated the scope required for the title.

Dmitry Petrashko — Stripe (Tech Advisor to Head of Infrastructure)

• Like Rick Boone, his role is a variant of the Right Hand archetype, but grounded in deep compiler and programming language theory expertise rather than in organizational coordination skills.
• His story illustrates how rare deep technical expertise becomes an organizational asset that is difficult to replicate through hiring: his knowledge of type systems, compiler optimization, and formal reasoning was directly applicable to Stripe’s infrastructure challenges in ways that a generalist could not provide.
• Operating as a technical advisor at the VP level required translating between the highest level of technical depth and the organizational language of infrastructure investment, reliability, and engineering velocity — a translation skill that is not automatic even for technically excellent engineers.
• His story is a case for staying deeply technical at senior levels rather than broadening into organizational generalism — the value of the role depended entirely on the depth remaining real.

Stephen Wan — Samsara (Staff Engineer)

• Samsara is a hardware-software company building IoT devices for physical operations (fleet management, industrial monitoring), making his story the most distinct from the pure software companies that dominate the rest of the collection.
• Staff engineering at Samsara involves deep domain knowledge about physical systems — firmware, hardware constraints, real-time data pipelines from embedded devices — that is not transferable from a pure software background and creates a natural moat for engineers who develop it.
• Describes Staff work in an organization that is still growing into engineering maturity: Samsara at the time of the interview was scaling rapidly, which meant Staff engineers were simultaneously doing the work and building the organizational capacity to sustain that work.
• His story is a reminder that the Staff engineer’s domain is defined by where the company creates value, not by what is conventionally considered “core software engineering” — in hardware-adjacent companies, the highest-leverage technical problems are often at the boundary between software and physical systems.

---

Key Takeaways

1. No single path exists to Staff: internal promotion after long tenure, company-switching, retroactive title recognition, and direct hire are all legitimate mechanics — and the right strategy depends on the company you are at.

2. The title creates expectations, not comfort: multiple engineers describe the post-promotion period as disorienting — the work that earned the title is not exactly the work valued at the level, and building new operating patterns takes time.

3. Sponsorship is the decisive variable in most promotions: technical merit is necessary but not sufficient. The promotion stories almost universally involve a specific person who opened doors, created opportunities, and vouched for the candidate’s impact with their own credibility.

4. “Setting technical direction” means writing, advocating, and coordinating — not solo technical work. Across every company in the stories, technical influence at Staff level operates through written artifacts and cross-organizational relationships.

5. Operating without authority is the core skill of the role: the stories collectively illustrate that the Staff engineer’s influence is primarily informal — earned through expertise, credibility, and persistent communication, not through reporting structures.

6. The work is company-specific to a degree that makes cross-company generalization dangerous: what counts as Staff-level impact at Stripe, Mailchimp, Uber, and Samsara is substantially different. Engineers must evaluate the specific conditions of the company, not just the title.

7. Invisible work must be made legible: the promotion packet, technical writing, and explicit scope documentation are tools for translating genuine impact into the language that promotion processes can evaluate. Especially for engineers whose work is coordination-heavy or infrastructure-focused.

8. External visibility compounds internal influence: Schenkelman’s story in particular demonstrates that technical writing and conference talks build organizational credibility recursively — the reputation accrued outside the company flows back in.

9. The equity gap is structural: underrepresented engineers face a systematic asymmetry in which the same quality of work requires more deliberate self-advocacy and sponsor cultivation to produce the same organizational recognition.

10. Staying deeply technical is a legitimate Staff strategy: the Petrashko and Elhage stories counter the implicit assumption that Staff engineers must move toward organizational generalism. Deep technical expertise that addresses real organizational problems is itself a Staff-level contribution.

---

Related Resources

• sec01-overview — The four archetypes (which archetype each story exemplifies); the Stories section is the empirical grounding for the archetype framework
• sec12-find-your-sponsor — Sponsorship patterns visible across the stories; the sponsor relationship is the most consistently decisive variable
• sec13-staff-projects — What Staff projects look like in practice; the stories complicate the “single defining project” model with accumulation-based paths
• sec15-being-visible — How Schenkelman’s external visibility strategy exemplifies the visibility principles in this section
• sec08-create-space-for-others — Multiple story subjects explicitly discuss creating space for others as a component of their Staff work
• ch03-leading-big-projects — Complementary view from “The Staff Engineer’s Path” on the same themes

---

Last Updated: 2026-05-30