John Rogers

about me | github | linkedin

1 October 2023

Book Review: Staff Path

The role of a ‘staff engineer’ is often vague and undefined.

Tanya Reilly’s book, “The Staff Engineer’s Path: A Guide for Individual Contributors Navigating Growth and Change,” brings clarity to this role and offers insights on how to excel within it.

Primarily, the staff engineer role involves leveraging deep technical knowledge and experience in three key areas: big-picture thinking, execution, and organizational development.

While I’ve shouldered some staff-level responsibilities in the past, I’ve never held the official title. In this brief summary, I’ll share my perspective on how the book resonates with my experiences. Mostly, though, I’m here to absorb and learn!

Reflection Time

What’s good

What’s bad

What I’ll Do

Summary

Section 1 - Big Picture Thinking

Understanding the organizational context and maintaining a long-term perspective on projects.

1.1 Defining The Role

The initial step in embracing ‘big picture’ thinking involves introspection about the role itself.

Key insights include:

Archetypes can help in comprehending the role: “tech leads” assist managers; “architects” oversee critical areas; “solvers” tackle complex problems systematically, one at a time; “right hands” provide additional leadership capacity to the organization.

What might be the best option within your team could differ when considered within the broader organizational context. Big picture thinking empowers a staff engineer to optimize not just at a local level but also at the organizational level, with a focus on long-term outcomes.

The chapter also delves into the advantages and disadvantages of reporting higher or lower within the organization structure. It explores the trade-offs between having a ‘too broad’ scope (lack of impact, bottleneck, fatigue) versus a ‘too narrow’ scope (lack of impact, overengineering, overshadowing).

Finally, there’s a practical example of setting annual goals to share with your manager.

I'm already familiar with most of the concepts presented in this section. I'm particularly excited to work on setting my own goals, improving time management, taking the lead on cross-team projects, and gaining a better understanding of the organization's overarching goals.

1.2 “Three Maps”

Where do you fit within the organization? What does the entire organizational landscape look like? And where is your trajectory headed?

Answering these questions can help you address critical inquiries:

These maps also serve as a constant reminder of the bigger picture.

Staff engineers too narrowly focused may:

The Local Map

One of the most significant contributions you can make is by consistently offering an ‘outsider view’ of the situation.

Measuring success through the lens of your customers is an enduring best practice.

To maintain an external perspective, seek to understand how others in the industry have tackled the same problems. Consider these resources to keep that outside view:

The Org Map

Failing to comprehend the organization can lead to various challenges, including difficulties gaining support for good ideas, unexpected obstacles, and protracted decision-making and execution processes.

Culture can be understood on a spectrum, with variables such as secret or open communication, oral or written decisions, top-down or bottom-up initiatives, fast or deliberate change, back channels or front doors, allocated or available capacity, and liquid or crystallized structure.

The critical point is knowing where decisions are being made. If you are part of those decisions, be well-prepared, articulate concisely, and contribute as a collaborative, low-friction team member.

Staff engineers can function as bridges where organizational gaps exist.

The ‘Treasure’ Map

This aspect is about setting clear goals and ensuring alignment across the teams you work with.

The metaphor might be stretched in this section, but it effectively highlights the various forms of big picture thinking that can aid in selecting and achieving meaningful goals. When setting goals, it's worthwhile to revisit this section and explore the recommended resources.

1.3 Creating The Big Picture

This chapter presents a highly relatable example of the initial steps for addressing technical debt in a monolithic application.

This chapter is about a technical vision and a technical strategy. A clear technical vision serves as your north star. While you may not yet know how to reach this vision, it should be both clear and realistic, addressing the organization’s needs.

Valuable resources for crafting a technical vision include:

The technical strategy is the plan of action to achieve the vision. A good strategy is outlined in Good Strategy/Bad Strategy by Richard Rumelt and includes:

These actions may encompass organizational changes, new processes, project modifications, and the initiation of new projects. Be explicit about the strategy’s scope and anticipate that a boring solution will be the best solution.

Some key takeaways:

This is my favorite chapter. I have a feeling this will be immediately relevant to my new role. If I want to establish a technical vision or strategy then I should refer back to the checklist in this chapter. I think coming in as a new staff engineer my primary challenge will be ensuring there's buy-in for my ideas at all levels.

Section 2 - Execution

2.1 Finite Time

At the staff-level, you choose your own work. This autonomy places a premium on your time management and decision-making skills. Ultimately, you are in control of:

Social capital and peer credibility are valuable currencies in this role, so take care when spending them.

The chapter provides strategies for effective time management, including delegation and the practice of blocking off focused work time on your calendar.

When evaluating opportunities, consider the costs and gains in terms of:

To be successful you’ll need to be good at defending your time.

Refer back to this chapter if evaluating an opportunity, or having trouble managing time.

2.2 Driving A Big Project

This is clearly where the author shines.

Mostly though it boils down to:

I'd also argue here that you should be aware of how your project is being perceived. Even if things are going wrong due to factors out of your control (e.g. mutliple competing high-priority projects); you need to clearly communicate that to your stakeholders. Refer back to for details on ways to provide clarity in the project with e.g. pictures and graphs. Also refer here for details on what makes a good RFC.

2.3 The Project Isn’t Going Well

Usually a project gets stuck because it’s blocked by something. This section does a deep dive on what to do when blocked by a variety of obstacle. Each obstacle can be solved by one of: “explaining what needs to happen, reducing what other people need to do, clarifying the organizational support, escalating, or making alternative plans.”

Sometimes though a project isn’t going well because it’s lost its direction, or there isn’t an obvious solution. “Bring clarity to a project that’s adrift by defining your destination, agreeing on roles, and asking for help when you need it.” This section dives into what to do when:

A third category: you might be code complete but the problem isn’t solved. “Don’t declare victory unless the project is truly complete. Code completeness is just one milestone.”

Finally, “whether you’re ready or not, sometimes it’s time for the project to end. Celebrate, retrospect, and clean up.”

These lessons are hard to internalize without experience. The best I can do it to be aware of this guide & refer back to if my project is ever in the weeds.

Section 3 - Execution

3.1 You’re a Role Model!

Being a role model requires a high degree of self-awareness. Choose your words and take actions carefully, since they have more impact now. Improve the quality of your communication & decision making by investing in knowledge building & taking on hard projects. When you don’t know something, don’t ‘fake it until you make it’.

The ultimate metric of success is whether or not people want to work with you:

And as per section 1 - keep the big picture in mind. Be aware of the business, the budgets, the users, and the capabilities of your team. You should also plan ahead.

3.2 Influence at Scale

This section talks about 4 types of influnce you will have:

And each type of influnce can be applied at the:

Where the ‘catalyst’ level means frameworks or community structures that endure after you’re gone.

  1. Advice: Share knowledge and help colleagues by providing advice, from mentoring to group-level sharing.

    • mentoring & peer feedback
    • writing & presenting to groups
    • change the feedback culture

  2. Teaching:

    • teach skills through training and coaching,
    • scaling to group-level education.
    • teaching the teachers, setting curricula, influcing big topics

  3. Guardrails:

    • review and feedback based
    • automation
    • culture change

  4. Opportunities:

    • match individuals with learning opportunities and foster their development.
    • at the group level this just means stepping back.
    • the ‘catalyst’ here are the people that benefit from the opportunities you’ve provided.
This section acts almost like an organization/dev culture health checklist!

3.3 What’s Next

This section provides career advice.

Here’s what you should reflect on when evaluating a job change:

why you might stay:

why you might go:

To that end, consider answering these questions on a scale of 1-5 every month & keeping track of the results:

The bit I liked best was a monthly self-survey of your job. It helps you keep perspective on your work and what you're getting out of it.
tags: