by Will Larson
Summary
There’s a saying that people don’t leave companies, they leave managers. Management is a key part of any organization, yet the discipline is often self-taught and unstructured. Getting to good solutions for complex management challenges can make the difference between fulfillment and frustration for teams, and, ultimately, between the success or failure of companies.
Will Larson’s An Elegant Puzzle orients around the particular challenges of engineering management—from sizing teams to managing technical debt to succession planning—and provides a path to the good solutions. Drawing from his experience at Digg, Uber, and Stripe, Will Larson has developed a thoughtful approach to engineering management that leaders of all levels at companies of all sizes can apply. An Elegant Puzzle balances structured principles and human-centric thinking to help any leader create more effective and rewarding organizations for engineers to thrive in.
Bio
Will Larson has been an engineering leader and software engineer at technology companies of many shapes and sizes, including Yahoo!, Digg, SocialCode, Uber, and, since 2016, Stripe.
He grew up in North Carolina, studied Computer Science at Centre College in Kentucky, spent a year in Japan for the JET Program teaching English, and has been living in San Francisco since 2009.
An Elegant Puzzle draws from the writing in his blog, Irrational Exuberance!, that he has been updating since graduating from college. It is currently, and will always be, a work in progress.
@lethain
www.lethain.com
An Elegant Puzzle: Systems of Engineering Management
© 2019 Will Larson
All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or any other information storage and retrieval system, without prior permission in writing from the publisher.
First published in 2019 in hardcover
in the United States of America
by Stripe Press/Stripe Matter Inc.
Stripe Press
Ideas for progress
San Francisco, California
press.stripe.com
Printed in Canada
ISBN: 978-1-7322651-8-9
Ebook by Bright Wing Books (brightwing.ca)
First Edition
Contents
Preface
Acknowledgments
1 Introduction
2 Organizations 2.1 Sizing teams
2.2 Staying on the path to high-performing teams 2.2.1 Four states of a team
2.2.2 System fixes and tactical support
2.2.3 Consolidate your efforts
2.2.4 Durable excellence
2.3 A case against top-down global optimization 2.3.1 Team first
2.3.2 Fixed costs
2.3.3 Slack
2.3.4 Shift scope; rotate
2.4 Productivity in the age of hypergrowth 2.4.1 More engineers, more problems
2.4.2 Systems survive one magnitude of growth
2.4.3 Ways to manage entropy
2.4.4 Closing thoughts
2.5 Where to stash your organizational risk?
2.6 Succession planning 2.6.1 What do you do?
2.6.2 Close the gaps
3 Tools 3.1 Introduction to systems thinking 3.1.1 Stocks and flows
3.1.2 Developer velocity
3.1.3 Model away
3.2 Product management: exploration, selection, validation 3.2.1 Problem discovery
3.2.2 Problem selection
3.2.3 Solution validation
3.3 Visions and strategies 3.3.1 Strategies and visions
3.3.2 Strategy
3.3.3 Vision
3.4 Metrics and baselines
3.5 Guiding broad organizational change with metrics
3.6 Migrations: the sole scalable fix to tech debt 3.6.1 Why migrations matter
3.6.2 Running good migrations
3.7 Running an engineering reorg 3.7.1 Is a reorg the right tool?
3.7.2 Project head count a year out
3.7.3 Manager-to-engineer ratio
3.7.4 Defining teams and groups
3.7.5 Staffing the teams and groups
3.7.6 Commit to moving forward
3.7.7 Roll out the change
3.8 Identify your controls
3.9 Career narratives 3.9.1 Artificial competition
3.9.2 Translating goals
3.10 The briefest of media trainings
3.11 Model, document, and share 3.11.1 How it works
3.11.2 Where it works
3.12 Scaling consistency: designing centralized decision-making groups 3.12.1 Positive and negative freedoms
3.12.2 Group design
3.12.3 Failure modes
3.13 Presenting to senior leadership
3.14 Time management
3.15 Communities of learning
4 Approaches 4.1 Work the policy, not the exceptions 4.1.1 Good policy is opinionated
4.1.2 Exception debt
4.1.3 Work the policy
4.2 Saying no 4.2.1 Constraints
4.2.2 Velocity
4.2.3 Priorities
4.2.4 Relationships
4.3 Your philosophy of management 4.3.1 An ethical profession
4.3.2 Strong relationships > any problem
4.3.3 People over process
4.3.4 Do the hard thing now
4.3.5 Your company, your team, yourself
4.3.6 Think for yourself
4.4 Managing in the growth plates 4.4.1 In the growth plates
4.4.2 Outside the growth plates
4.4.3 Aligning with values
4.5 Ways engineering managers get stuck
4.6 Partnering with your manager
4.7 Finding managerial scope
4.8 Setting organizational direction 4.8.1 Scarce feedback, vague direction
4.8.2 Mining for direction
4.9 Close out, solve, or delegate
5 Culture 5.1 Opportunity and membership 5.1.1 Opportunity
5.1.2 Membership
5.1.3 Keep going
5.2 Select project leads
5.3 Make your peers your first team
5.4 Consider the team you have for senior positions
5.5 Company culture and managing freedoms
5.6 Kill your heroes, stop doing it harder 5.6.1 The fall and rise of a hero
5.6.2 Kill the hero programmer
5.6.3 A long time coming, a long time going
5.6.4 Resetting broken systems
6 Careers 6.1 Roles over rocket ships, and why hypergrowth is a weak predictor of personal growth 6.1.1 Your new career narrative
6.1.2 Opportunities for growth
6.2 Running a humane interview process 6.2.1 Be kind
6.2.2 What role is this, anyway?
6.2.3 Finding signal
6.2.4 Be prepared
6.2.5 Deliberately express interest
6.2.6 Feedback loops
6.2.7 Optimize the funnel
6.3 Cold sourcing: hire someone you don’t know 6.3.1 Moving beyond your personal networks
6.3.2 Your first cold sourcing recipe
6.3.3 Is this high-leverage work?
6.4 Hiring funnel 6.4.1 Funnel fundamentals
6.4.2 Instrument and optimize
6.4.3 Extending the funnel
6.5 Performance management systems 6.5.1 Career ladders
6.5.2 Performance designations
6.5.3 Performance cycles
6.6 Career levels, designation momentum, level splits, etc.
6.7 Creating specialized roles, like SRE or
TPMs 6.7.1 Challenges
6.7.2 Facilitating success
6.7.3 Advantages
6.7.4 What to do?
6.8 Designing an interview loop
7 Appendix 7.1 Tools for operating a growing organization 7.1.1 Line management
7.1.2 Middle management
7.1.3 Managing an organization
7.2 Books I’ve found very useful
7.3 Papers I’ve found very useful
Landmarks
Cover
Title Page
Table of Contents
Start of Content
Preface
The first blog post that I ever wrote was on April 7, 2007, and was titled “Finding Our Programming Flow.” It was not very good. That year I wrote 69 posts, the last being “Miyajima and Hiroshima,” a collection of pictures from a trip I took while teaching English in Japan. The next year, 2008, I wrote 192 posts. The writing still left much to be desired.
It took 200 more posts and another decade to cobble together a written voice and to make enough mistakes that my experience might become worth reading. I’m fortunate that that moment coincided with my time at Stripe, an environment where folks routinely do things that might in other contexts seem out of reach: things like starting a technology magazine or publishing a book.
This book is the lucky alignment of that happy moment at Stripe, a decade of writing and a decade of learning about both leadership and management, and the good fortune to work with colleagues who suggested collecting my writing into this book.
I hope that everyone who picks up this book gets something useful out of it. Your comments and thoughts are appreciated at:
[email protected].
Acknowledgments
A few particular thanks are in order. This book came together in the months preceding my wedding, and I’m grateful to Laurel for her thoughts and partnership. Thank you to Brianna Wolfson and Tyler Thompson, without whom this book would not exist. Finally, thanks to my sister, Hope, who has long been the talented sibling, showing that the path to authorship is attainable.
1
Chapter 1
Introduction
1.1 Introduction
Some people go into management out of a desire to be of service. Others become managers in a cynical pact, exchanging excitement in their current role for the prospect of continued salary bumps and promotions. There are even folks who initially go into management because they’re entirely fed up with their own manager and are convinced that they could do better.
I won’t say which of those, if any, describes me.
Regardless of what motivation first brings you into management, it can feel as if you’ve entered a troubled profession. Skilled practitioners are scarce, and only the exceptional company is willing to invest in growing its managers.
If training programs are peculiarly uncommon, concerns that today’s managers are ill-prepared are not. I was lucky early in my management career to have a coworker describe me as the best leader they had worked with. It took several additional years of practice for another to declare me their worst.
While David’s cloak is increasingly suspicious draped from the shoulders of Silicon Valley’s Goliaths, the vast majority of technology companies are well-meaning chrysalises that hope to one day birth a successful business, and they are guided by managers who are learning to lead, one unexpected lesson at a time. For many such people, the entry into engineering management begins with a crisis, and their training is a series of hard knocks.
This was certainly my experience: my path into management began at Digg, paved by a pair of layoffs in 2010. The three one-on-ones I’d had at my previous job had not, surprisingly, culminated in a rigorous framework for management, and I had absolutely no idea what I was doing.
In the years since, I’ve worked to educate myself on the topic, reading anything that seemed even distantly relevant. There are some wonderful resources out there (many of which I’ve listed in the “Books I’ve found very useful” appendix), but the rare answers I uncovered continued to be drowned out by my ever-increasing sea of questions.
It was only when I got the opportunity to work at Uber, which was growing its engineering team from 200 to 2,000 over two years, and then at Stripe, which was experiencing similar rapid growth, that I had to opportunity to truly refine my approach to management through exposure to an endless variety of challenges. There are few things peaceful about managing in rapidly growing companies, but I’ve never found anywhere better to learn and to grow.
As I’ve become more experienced, my appreciation for management, and engineering management in particular, has grown, and I’ve come to view the field as a series of elegant, rewarding, and important puzzles. This book is a collection of those puzzles, which I’ve had the good fortune to struggle with and learn from. It starts with the most important tool in my kit, “Organizations.” Organizational design gets the right people in the right places, empowers them to make decisions, and then holds them accountable for their results. Maintained consistently and changed sparingly, nothing else will help you scale more. Next, we’ll review a handful of fundamental “Tools” of management that I’ve found useful across a wide variety of scenarios. These range from systems thinking to vision documents, from metrics to migrations, from reorgs to career narratives. Perhaps the easiest way to use this chapter is to skim over the ideas quickly, and then reread them when it seems as if they might be useful.
The third chapter, “Approaches,” works through circumstances in which you might need to adjust how you manage. It digs into how to adapt your management for rapidly growing companies, and how to manage when your desired impact is beyond your authority. It will hopefully help you find alternative paths to approach some of the areas where you’re not feeling as successful as you’d like.
That chapter is followed by an exploration of “Culture.” This section is focused on practical things you can do to nurture an inclusive team or organization. It also digs into a few particular culture topics on the conflict of “freedom to” and “freedom from,” and deals with hero culture.
Finally, the book ends with an exploration of “Careers,” with a focus on interviewing, hiring, and performance management. Many managers come up thinking of recruiting as something run by recruiters, and performance management as something designed by human resources, but these are powerful tools that you should be using frequently.
If you finish the entire book, you won’t walk into your office the next day as a perfect manager (I remain grateful for the days I walk into the office feeling like a marginally competent one), but I hope that it’ll stimulate questions about how you’re approaching management, provide a few new approaches for you to experiment with, and help you take a few steps further down the path of engineering management.
2
Chapter 2
Organizations
Figure 2.1
Sizing teams and groups of teams using sizing rules.
Organizations
An organization is a collection of people working toward a shared goal. Each organization is an exploration of the possible, undertaken together by the ten, the hundred, or the thousand. Initially, I was tempted to glibly write that sometimes organizations work, but the truly extraordinary thing is that all organizations work.
Some do indeed work better than others, and organizational design is the attempt to understand why some create such energy and others create mostly heat: friction, frustration, and politics. I believe that excellent organizations grow from consistently applying a straightforward process.
When I have a problem that I want to solve quickly and cheaply, I start thinking about process design. A problem I want to solve permanently and we have time to go slow? That’s a good time to evolve your culture. However, if process is too weak a force, and culture too slow, then organizational design lives between those two.
This chapter covers the approaches to organizational design and evolution that I’ve found eff
ective. If you’re reading through and find yourself thinking that this sounds easy, I agree! The hard bit is keeping your courage up when circumstances get challenging.
2.1 Sizing teams
When I transitioned from supporting a team to supporting an organization, I started to encounter a new category of problems that I had never thought about. How many teams should we have? Should we create a new team for this initiative, or ask an existing team to take it on? What is the boundary between these two teams?
These questions were the gateway to the obscure art of organizational design. As I’ve gotten more exposure, I’ve come to believe that the fundamental challenge of organizational design is sizing teams. You’ll find yourself sizing teams during reorganizations,1 to accommodate growth from hiring, and when considering how to support new projects. It’ll be an unusual month that you won’t consider some aspect of team design.
While I’m skeptical that there exists a unified law of team sizing, I have iterated my requirements onto a useful framework that solves the majority of cases I encounter. That framework has in turn led to a standard playbook. Both are short, opinionated, and hopefully useful!