The Staff Engineer's Path

Introduction

Where do you see yourself in five years? The classic interview question is the adult equivalent of “What do you want to be when you grow up?”: it has some socially acceptable answers and a long enough time horizon that you don’t need to commit.¹ But if you’re a senior software engineer looking to keep growing in your career, the question becomes very real.² Where do you see yourself going?

Two Paths

You may find yourself at a fork in the road (Figure P-1), two distinct paths stretching ahead. On one, you take on direct reports and become a manager. On the other, you become a technical leader without reports, a role often called staff engineer. If you really could see five years ahead on both of these paths, you’d find that they have a lot in common: they lead to many of the same places, and the further you travel, the more you’ll need many of the same skills. But, at the start, they look quite different.

Figure P-1. A fork in the road.

The manager’s path is clear and well traveled. Becoming a manager is a common, and perhaps default, career step for anyone who can communicate clearly, stay calm during a crisis, and help their colleagues do better work. Most likely, you know people who have chosen this path. You’ve probably had managers before, and perhaps you have opinions about what they did right or wrong. Management is a well-studied discipline, too. The words promotion and leadership are often assumed to mean “becoming someone’s boss,” and airport bookshops are full of advice on how to do the job well. So, if you set off down the management path, it won’t be an easy road, but you’ll at least have some idea of what your journey will be like.

The staff engineer’s path is a little less defined. While many companies now allow engineers to keep growing in seniority without taking on reports, this “technical track” is still muddy and poorly signposted. Engineers considering this path may have never worked with a staff engineer before, or might have seen such a narrow set of personalities in the role that it seems like unattainable wizardry. (It’s not. It’s all learnable.) The expectations of the job vary across companies, and, even within a company, the criteria for hiring or promoting staff engineers can be vague and not always actionable.

Often the job doesn’t become clearer once you’re in it. Over the last few years, I’ve spoken with staff engineers across many companies who weren’t quite sure what was expected of them, as well as engineering managers who didn’t know how to work with their staff engineer reports and peers.³ All of this ambiguity can be a source of stress. If your job’s not defined, how can you know whether you’re doing it well? Or doing it at all?

Even when expectations are clear, the road to achieving them might not be. As a new staff engineer, you might have heard that you’re expected to be a technical leader, make good business decisions, and influence without authority—but how? Where do you start?

The Pillars of Staff Engineering

I understand that feeling. Through 20 years in the industry, I’ve stayed on the staff engineer’s path, and I’m now a senior principal engineer, parallel to a senior director on my company’s career ladder. While I’ve considered the manager’s path many times, I’ve always concluded that the “technical track” work is what gives me energy and makes me want to come to work in the morning. I want to have time to dig into new technologies, deeply understand architectures, and learn new technical domains. You get better at whatever you spend time on, and I’ve consistently wanted to keep getting better at technical things.⁴

Earlier in my career, though, I struggled to make sense of this path. As a midlevel engineer, I didn’t understand why we had levels above “senior”—what did those people do all day? I certainly couldn’t see a path to those roles from where I was. Later, as a new staff engineer, I discovered unspoken expectations and missing skills I didn’t know how to describe, much less act on. Over the years, I’ve learned from many projects and experiences—both successes and failures—as well as from phenomenal colleagues and peers in other companies. The job makes sense now, but I wish I’d known then what I know now.

If you’ve taken the staff engineer path, or are considering it, welcome! This book is for you. If you work with a staff engineer, or manage one, and want to know more about this emerging role, there’ll be a lot here for you too. In the next nine chapters I’m going to share what I’ve learned about how to be a great staff engineer. I’ll warn you right now that I’m not going to be prescriptive about every topic or answer every question: a great deal of the ambiguity is inherent to the role, and the answer is very often “it depends on the context.” But I’ll show you how to navigate that ambiguity, understand what’s important, and stay aligned with the other leaders you work with.

I’ll unpack the staff engineer role by looking at what I think of as its three pillars: big-picture thinking, execution of projects, and leveling up the engineers you work with.

Big-picture thinking

Big-picture thinking means being able to step back and take a broader view. It means seeing beyond the immediate details and understanding the context that you’re working in. It also means thinking beyond the current time, whether that means initiating yearlong projects, building software that will be easy to decommission, or predicting what your company will need in three years.⁵

Execution

At the staff level, the projects you take on will become messier and more ambiguous. They’ll involve more people and need more political capital, influence, or culture change to succeed.

Leveling up

Every increase in seniority comes with more responsibility for raising the standards and skills of the engineers within your orbit, whether that’s your local team, colleagues in your organization, or engineers across your whole company or industry. This responsibility will include intentional influence through teaching and mentoring, as well as the accidental influence that comes from being a role model.

We can think of these three pillars as supporting your impact like in Figure P-2.

Figure P-2. Three pillars of staff engineer roles.

You’ll notice that these pillars sit on a solid foundation of technical knowledge and experience. This foundation is critical. Your big-picture perspective includes understanding what’s possible and having good judgment. When executing on projects, your solutions will need to actually solve the problems they set out to solve. When acting as a role model, your review comments should make code and designs better, and your opinions need to be well thought out—you need to be right! Technical skills are the foundation of every staff engineer role, and you’ll keep exercising them.

But technical knowledge is not enough. Success and growth at this level means doing more than you can do with technical skills alone. To become adept at big-picture thinking, execute on bigger projects, and level up everyone around you, you’re going to need “humaning” skills, like:

• Communication and leadership

• Navigating complexity

• Putting your work in perspective

• Mentorship, sponsorship, and delegation

• Framing a problem so that other people care about it

• Acting like a leader whether you feel like one or not⁶

Think of these skills like the flying buttresses you see on gothic cathedrals (as in Figure P-3): they don’t replace the walls—or your technical judgment—but they allow the architect to build taller, grander, more awe-inspiring buildings.

Figure P-3. Leadership skills are like the flying buttresses that let us keep massive buildings stable.

Each of the three pillars has a set of required skills, and your aptitude for each of them will vary. Some of us may be in our element when leading and finishing big projects, but find it intimidating to choose between two strategic directions. Others may have strong instincts for understanding where the company and industry are going, but lose control of the room quickly when managing an incident. Still others may boost the skills of everyone they work with, but struggle to build consensus around a technical decision. The good news is that all of these skills are learnable, and you can become adept at all three pillars.

This book is divided into three parts.

Part I: The Big Picture

In Part I, we’ll look at how to take a broad, strategic view when thinking about your work. Chapter 1 will begin by asking big questions about your role. What’s expected of you? What are staff engineers for? In Chapter 2, we’ll zoom out further and get some perspective. We’ll look at your work in context, navigate your organization, and uncover what your goals are. Finally, in Chapter 3, we’ll look at adding to the big picture by creating a technical vision or strategy.

Part II: Execution

Part II gets tactical and moves on to the practicalities of leading projects and solving problems. In Chapter 4, we’ll look at choosing what to work on: I’ll share techniques for how to decide what to spend time on, how to manage your energy, and how to “spend” your credibility and social capital in a way that doesn’t diminish it. In Chapter 5 I’ll discuss how to lead projects that stretch across teams and organizations: setting them up for success, making the right decisions, and keeping information flowing. Chapter 6 will look at navigating the obstacles you’ll meet along the way, celebrating a project that finishes successfully, and retrospecting (but still celebrating!) if it’s canceled and cleanly shut down.

Part III: Leveling Up

Part III is about leveling up your organization. Chapter 7 will look at raising everyone’s game by modeling what a great engineer acts like, how to learn out loud, and how to build a psychologically safe culture. We’ll look at how to be the “adult in the room” during an incident or a technical disagreement. Chapter 8 is about more intentional forms of raising your colleagues’ skills, like teaching and coaching, design review, code review, and making cultural change. Finally, Chapter 9 will explore how to level up yourself: how to keep growing and how to think about your career. Where do you go after your current role? I’ll discuss some options.

One warning before we go further: this is a book about staying on the technical track. It is not a technical book. As I’ve said, you need a solid technical foundation to become a staff engineer. This book won’t help you get that. Technical skills are domain-specific, and if you’re here, I’m assuming that you already have—or are setting out to learn—whatever specialized skills you need in order to be one of the most senior engineers in your domain. Whether “technical” for you means coding, architecture, UX design, data modeling, production operations, vulnerability analysis, or anything else, almost every domain has a plethora of books, websites, and courses that will support you.

If you’re someone who thinks that technical skills are the only ones that matter, you’re unlikely to find what you’re looking for in here. But, ironically, you might also be the person who’ll get the most from this book. No matter how deep or arcane your technical knowledge, you’ll find that work gets less annoying when you can persuade other people to adopt your ideas, level up the engineers around you, and breeze through the organizational gridlock that slows everyone down. Those skills aren’t easy to learn, but I promise they’re all learnable, and I’ll do my best in this book to show the way.

Do you want to be a staff engineer? It’s fine not to aspire to more senior engineering roles. It’s also fine to move to the manager track (or go back and forth!), or to stay at the senior level, doing work you enjoy. But if you like the idea of helping achieve your organization’s goals and continuing to build technical muscle while making the engineers around you better at their craft, then read on.

O’Reilly Online Learning

Note

For more than 40 years, O’Reilly Media has provided technology and business training, knowledge, and insight to help companies succeed.

Our unique network of experts and innovators share their knowledge and expertise through books, articles, and our online learning platform. O’Reilly’s online learning platform gives you on-demand access to live training courses, in-depth learning paths, interactive coding environments, and a vast collection of text and video from O’Reilly and 200+ other publishers. For more information, visit https://oreilly.com.

How to Contact Us

Please address comments and questions concerning this book to the publisher:

• O’Reilly Media, Inc.
• 1005 Gravenstein Highway North
• Sebastopol, CA 95472
• 800-998-9938 (in the United States or Canada)
• 707-829-0515 (international or local)
• 707-829-0104 (fax)

We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at https://oreil.ly/staff-eng-path.

Email [e-mail] to comment or ask technical questions about this book.

For news and information about our books and courses, visit https://oreilly.com.

Find us on LinkedIn: https://linkedin.com/company/oreilly-media.

Follow us on Twitter: https://twitter.com/oreillymedia.

Watch us on YouTube: https://youtube.com/oreillymedia.

Acknowledgments

Thank you to the many, many people who helped make this book a reality.

Thank you to Sarah Grey, best of all possible development editors, and all of the other phenomenal folks at O’Reilly, including acquisitions editor, Melissa Duffield; production editor, Liz Faerm; copy editor, Josh Olejarz; Susan Thompson, who created the incredible cover; and illustrator, Kate Dullea, who translated my pencil scrawls into gorgeous art. This was my first time writing a book, and you all took the terror out of it.

My thanks to Will Larson for his encouragement and support, and for helping the staff engineering community find each other for the first time. Also thanks to Lara Hogan for enthusiasm and introductions when I turned up in her DMs all “but could I write a book??” Thank you both for showing what sponsorship looks like.

I was lucky enough to have two of the wisest and most insightful engineers I know along on this journey. Cian Synnott and Katrina Sostek, this book is infinitely better for your review and feedback over the last year. In particular, I am indebted for your thoughtful suggestions around the parts that didn’t work. Constructive criticism is always harder, and I’m grateful for your time and energy.

Many people generously shared their time to discuss ideas, offer feedback, or teach me something. I want to particularly thank Franklin Angulo, Jackie Benowitz, Kristina Bennett, Silvia Botros, Mohit Cheppudira, John Colton, Trish Craine, Juniper Cross, Stepan Davidovic, Tiarnán de Burca, Ross Donaldson, Tess Donnelly, Tom Drapeau, Dale Embry, Liz Fong-Jones, Camille Fournier, Stacey Gammon, Carla Geisser, Polina Giralt, Tali Gutman, Liz Hetherston, Mojtaba Hosseini, Cate Huston, Jody Knower, Robert Konigsberg, Randal Koutnik, Lerh Low, Kevin Lynch, Jennifer Mace, Glen Mailer, Keavy McMinn, Daniel Micol, Zach Millman, Sarah Milstein, Isaac Perez Moncho, Dan Na, Katrina Owen, Eva Parish, Yvette Pasqua, Steve Primerano, Sean Rees, John Reese, Max Schubert, Christina Schulman, Patrick Shields, Joan Smith, Beata Strack, Carl Sutherland, Katie Sylor-Miller, Izar Tarandach, Fabianna Tassini, Elizabeth Votaw, Amanda Walker, and Sarah Wells. Also, thanks to the many (so many!) other people I spoke with via DMs, email, hallway conversation, or in spirited Slack threads. You made this book better, and I appreciate you.

Thank you to the people who drink afternoon tea: you demonstrate the power of community every day. Thanks to everyone on the #staff-principal-engineering channel on Rands Leadership Slack for being relentlessly supportive and for sharing your experiences with humility. Huge appreciation to my colleagues at Squarespace and to the Google SRE diaspora. I’ve learned a ton from you all. And I want to thank Ruth Yarnit, Rob Smith, Mariana Valette, and the whole Lead Dev crew for the incredible technical leadership content they’ve shared with the world. Thanks for what you do.

Thank you to the Hillfolks, including that very good dog. I’m lucky and privileged to have you as friends. Thanks for letting me write in your caravan (and quarantine there when I had COVID!) I look forward to decades more of friendship and watching your baby oak trees grow.

Finally, to my whole family—my parents, Danny and Kathleen, and the whole extended clan—thank you for being patient over the last year while I fell off the planet.

And of course, Joel and Ms 9! I look forward to seeing you on Saturdays again. To Joel (who came up with the idea that humaning skills are “flying buttresses”), thank you for great conversations about engineering organizations and making good software. And thank you for all the sandwiches. And to Ms 9 (who was Ms 6 when I wrote the first draft of this book!): thank you for your excellent ideas, drawings, and hugs. I appreciate you lummoxes.

¹ Although you’re not supposed to reply “a zookeeper who is also an astronaut” to the interview question. Adult life is very limiting.

² For the sake of brevity, I’m going to say “software engineer” throughout this book; however, if you’re a systems engineer, data scientist, or any other practitioner of tech, I think you’ll find it relevant, too. All are welcome here!

³ This is changing. Will Larson, LeadDev, and others have been doing phenomenal work in paving the road. I’ll link to resources throughout this book.

⁴ I reserve the right to change my mind later on.

⁵ Throughout this book I’m going to use the term “company” when talking about employers, but of course you could be at a nonprofit, government agency, academic institution, or other type of organization. Swap in whatever makes sense for you.

⁶ And a lot more. Check out Camille Fournier’s article “An Incomplete List of Skills Senior Engineers Need, Beyond Coding”.