An Elegant Puzzle Systems of Engineering Management
How much do I want to read more? 7/10
An interesting book, with how to set up your team, how many members, how many groups, managers, coachs, what to do for the whole to be effective.
There’s a saying that people don’t leave companies, they leave managers.
challenges of engineering management—from sizing teams to managing technical debt to succession planning.
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.
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 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.
CHAPTER 1 - Introduction
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)
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.
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: to adapt your management for rapidly growing companies, and how to manage when your desired impact is beyond your authority.
“Careers,”: interviewing, hiring, and performance management.
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.
CHAPTER 2 - Organizations
An organization is a collection of people working toward a shared goal.
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.
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?
the fundamental challenge of organizational design is sizing teams.
The guiding principles I use for sizing teams are:
Managers should support six to eight engineers
This gives them enough time for active coaching, coordinating, and furthering their team’s mission by writing strategies, leading change, and so on.
Tech Lead Managers (TLMs):
Managers supporting fewer than four engineers tend to function as TLMs, taking on a share of design and implementation work.
For some folks this role can uniquely leverage their strengths, but it’s a role with limited career opportunities.
o progress as a manager, they’ll want more time to focus on developing their management skills.
Alternatively, to progress toward staff engineering roles, they’ll find it difficult to spend enough time on the technical details.
Managers supporting more than eight or nine engineers typically act as coaches and safety nets for problems.
They are too busy to actively invest in their team or their team’s area of responsibility. It’s reasonable to ask managers to support larger teams during the transition to a more stable configuration, but it is a bad status quo.