From the Preface
This is the book that I wish I’d read before starting my first Engineering executive role, and that I would have reread before starting my second executive role—to reflect on how my beliefs had evolved after doing this expansive, complex work. I hope reading this book serves you well and, more importantly, that it helps you form your own opinions rather than convinces you to take on mine.
My favorite chapter in this book is the third, which discusses creating an Engineering strategy. I also wrote a chapter about Engineering strategy in my last book, Staff Engineer. It’s interesting how different those two chapters are, despite the fact that I wrote both of them, and only three years apart. At first, I wanted to believe this difference reflected some kind of deep insight I’d acquired between writing the two books, but the real difference is more fundamental: being an Engineering executive is a meaningfully different job, and it’s forced me to adopt a different perspective than my previous roles as an engineer and engineering manager.
As an Engineering executive, you will deal with many familiar problems but will have new tools to solve them. For example, the hardest part of developing an Engineering strategy in my previous roles was usually building consensus around the solution. As an executive, the hardest part is building conviction that your strategy is right for your company. There are also new problems that you’ve probably not spent time with before, if you’re new to the executive role. Everyone deals with a planning process, but only executives have to debate the algorithms to attribute platform costs across various business lines.
This book surveys the new challenges, and new tools for old problems, that you’ll encounter as an Engineering executive. There are no universal answers to the most interesting questions, but you’ll come away from this book with an understanding of the problems and at least one recommendation for how to approach each one.
What This Book is Not
If you’re looking for details on how to run one engineering team, this won’t be the most useful book for you. This book does not explore practices for running your weekly team meetings, conducting one-on-ones, or giving feedback effectively. Instead, it focuses on how multiple teams work together effectively across a company’s Engineering function. For those omitted topics, I heartily recommend Camille Fournier’s The Manager’s Path (O’Reilly) and my own An Elegant Puzzle (Stripe Press).
Likewise, this book is focused on the whole Engineering function, which is the intersection of technology-focused and people-focused leadership. There is no meaningful way to talk about leading an Engineering function that doesn’t engage with both those leadership aspects. If you’re looking for a book more focused on technology-focused leadership, consider picking up Tanya Reilly’s The Staff Engineer’s Path (O’Reilly) or my own Staff Engineer.
Finally, this book won’t be helpful if you’re looking for advice on how to build a specific piece of technology. There are a thousand effective ways to build any given product, and this book won’t suggest any of them. Instead, it will discuss the value of standardizing, or not standardizing, your company’s approach to building and maintaining a large portfolio of products and systems. There are simply too many books out there about building technology to recommend any given one, so I’ll leave you to decide what might work better for that focus.
Amazon US
Contact
