Chapter 38: Further Reading

Essential Sources

1. Will Larson, Staff Engineer: Leadership Beyond the Management Track (2021)

The definitive book on what staff-level individual contributors actually do. Larson interviewed dozens of staff and principal engineers at companies including Stripe, Slack, Auth0, LaunchDarkly, and Fastly, synthesizing their experiences into a framework for technical leadership without management authority. The book introduced the four archetypes (tech lead, architect, solver, right hand) used in Section 38.1 and remains the most practical guide to the staff IC role.

Reading guidance: Part 1 (Staff Engineer Archetypes) provides the conceptual framework used throughout this chapter — read it first. Chapter 3 (Writing Engineering Strategy) describes the design document and RFC processes adapted for data science in Sections 38.2-38.3. The key insight is Larson's distinction between a design document (proposes a specific solution) and an engineering strategy (a collection of documents forming a coherent direction), which maps to the distinction between a project-level design review and the organizational-level technical roadmap (Section 38.7). Chapter 5 (Being Visible) addresses the personal brand question from Section 38.8 with pragmatic advice on when to write, when to present, and how to build credibility through communication rather than self-promotion. Chapter 6 (Operating at Staff) describes the daily activities — design review, code review, mentoring, project leadership, cross-team coordination — that constitute the job. Part 2 collects interviews with practicing staff engineers, offering diverse perspectives on how the role manifests at different companies. For data scientists specifically, the sections on influence without authority and managing technical quality are the most transferable — though the examples are from software engineering, the organizational dynamics are identical.

2. Will Larson, An Elegant Puzzle: Systems of Engineering Management (2019)

While nominally a management book, An Elegant Puzzle is essential reading for staff ICs because it explains the system within which they operate. Larson covers organizational design, team sizing, managing technical debt, succession planning, and the relationship between engineering and product management — all topics that a staff data scientist must understand even if they are not personally responsible for them.

Reading guidance: Chapter 3 (Organizations) describes the dynamics of team growth, the challenge of maintaining technical culture at scale, and the tension between specialization and generalism — all of which affect how the staff DS structures the technical roadmap and team gap analysis (Sections 38.7, 38.11). Chapter 5 (Culture) covers writing culture, decision-making frameworks, and the role of process in engineering organizations. Larson's treatment of "process as culture" is particularly relevant: the design review process, RFC process, and brown bag schedule described in this chapter are not bureaucratic overhead — they are cultural artifacts that encode the organization's values (rigor, transparency, knowledge sharing). Chapter 7 (Careers) provides the management perspective on IC career progression, including how promotion committees evaluate staff candidates — useful context for Section 38.9's discussion of the senior-to-staff transition. For staff ICs, the most valuable insight is that managers are operating under constraints (headcount limits, competing priorities, organizational politics) that are invisible from the IC perspective — and understanding these constraints makes influence without authority more effective.

3. Eugene Yan, "What We Look for in a Resume" and "Unpopular Opinion — Data Scientists Should Be More End-to-End" (eugeneyan.com, 2020-2023)

Eugene Yan's blog is the most consistently thoughtful source on data science career development, technical leadership, and production ML practice. Yan, a senior applied scientist at Amazon, writes from the intersection of technical depth and organizational awareness that characterizes staff-level work. His posts on career development, writing, and the gap between research and production are particularly relevant to this chapter.

Reading guidance: "Unpopular Opinion — Data Scientists Should Be More End-to-End" argues that data scientists who can deploy, monitor, and maintain their own models create more value than those who hand off to engineering — a perspective that aligns with Theme 3 (Production ML = Software Engineering) and informs the staff DS's emphasis on production readiness in design reviews. "What We Look for in a Resume" provides a hiring manager's perspective on what signals technical depth, production experience, and leadership potential — useful for understanding how staff candidates are evaluated (Section 38.9). "Writing is Thinking" makes the case that writing is not just a communication tool but a reasoning tool — the act of writing forces clarity that cannot be achieved through thinking alone. This aligns with Section 38.8's argument that writing is the most scalable form of technical leadership. Yan's posts on system design, including analyses of recommendation systems at various companies, provide real-world context for the build vs. buy decisions (Section 38.6) and platform bets discussed in this chapter.

4. Tanya Reilly, The Staff Engineer's Path: A Guide for Individual Contributors Navigating Growth and Change (O'Reilly, 2022)

A complementary perspective to Larson's Staff Engineer, with deeper treatment of the day-to-day mechanics of staff-level work. Reilly, a principal engineer with experience at Squarespace and Google, focuses on the practical skills: how to lead without managing, how to navigate ambiguity, how to choose what to work on, and how to maintain technical depth while operating at organizational scope.

Reading guidance: Part 1 (The Big Picture) covers the question "what does a staff engineer actually do?" with more operational detail than Larson's treatment. Reilly's concept of "being a map" — understanding the technical landscape well enough to help others navigate it — is particularly apt for the staff data scientist, who must connect causal inference expertise with production engineering, fairness requirements with business objectives, and research advances with practical applications. Part 2 (Execution) covers project management, prioritization, and the mechanics of getting things done without direct reports — skills that Section 38.5 (stakeholder management) and Section 38.7 (roadmap) address in a data science context. Part 3 (Leveling Up) covers the personal sustainability of the role: avoiding burnout, managing scope, and maintaining the technical depth that grounds your credibility. This last topic is underaddressed in most leadership books and is particularly relevant for staff data scientists, who face constant pressure to become full-time meeting attendees at the expense of technical currency.

5. Laszlo Sragner, "The Data Science IC Career Framework" (Medium/Towards Data Science, 2023) and Monica Rogati, "The AI Hierarchy of Needs" (2017)

Two influential frameworks for thinking about data science careers and organizational maturity. Sragner's career framework maps the progression from junior through distinguished data scientist with specific behavioral expectations at each level — providing concrete content for the promotion criteria discussed in Section 38.9. Rogati's hierarchy (data collection, data storage, data exploration, data aggregation, optimization/experimentation, AI/deep learning) argues that organizations should build capabilities from the bottom up rather than jumping to sophisticated ML — a perspective that aligns with Theme 6 (Simplest Model That Works) applied at the organizational level.

Reading guidance: Sragner's framework is useful as a supplement to Section 38.9's three criteria (judgment, scope, impact). His behavioral descriptions for each level — what "good" looks like at senior vs. staff vs. principal — provide concrete examples that managers and ICs can use for calibration. The framework's emphasis on "multiplier effects" at higher levels (how much your work increases the output of others) aligns with the mentoring and knowledge-sharing emphasis of Section 38.4. Rogati's hierarchy is essential context for Section 38.6 (build vs. buy) and Section 38.7 (roadmap): a staff DS who proposes building sophisticated ML systems before the organization has reliable data infrastructure is building on sand. The hierarchy also informs the "saying no" skill from Section 38.5 — sometimes the right answer to "can we use deep learning for this?" is "not until we fix our data pipeline." Both frameworks are short reads (blog posts/articles) that repay multiple readings as your perspective evolves with career progression.