Why We Are Writing ‘Scaling Teams’
by Alexander Grosse and David Loftesness
Fast-growing engineering teams face a host of challenges. The leaders of those teams need to anticipate those challenges and adjust appropriately. So, we’re writing a book about it. Scaling Teams will be published by O’Reilly Media next year. Follow the Scaling Teams publication for previews and updates.
Between the two of us, we’ve experienced a range of high-growth scenarios at tech companies large and small. During Alex’s tenure at SoundCloud, he helped build the engineering team from 20 to 100, spanning four offices worldwide. Similarly, Dave started with a team of three at Twitter, eventually managing more than 80 engineers across a dozen teams. We’ve founded small startups, as well as built-out completely new teams within much larger companies (Alex at Nokia, Dave at Amazon/A9).
Each time, we observed processes and patterns break down due to growth; at some point, having more people on the team meant the old way of doing things didn’t work anymore. Although each situation was unique, we learned that, over time, there were some common patterns. We started to be able to anticipate the inflection points in different areas, particularly in recruiting, people management, organizational structure, communication, and culture.
Looking back, we wish we’d had a practical guide to these inflection points, something that could have helped us see the warning signs that come from rapid growth, well before they grew into full-fledged crises. We’d prefer to have made changes proactively, during times of relative stability, rather than pivoting rapidly in search of something workable. We wish we’d had a toolbox of ideas from successful companies that we could apply and adjust to the unique challenges we faced in each situation.
Our goal during the next few months is to write the book we wish we’d had. We’ll distill what we’ve learned through our own experience, as well as through interviews with dozens of former colleagues and industry leaders, into a straightforward, practical guide to managing the rapid growth of engineering teams. We want to write a book that you can read in a weekend if you want, but also something you can use more tactically. We hope it’s a book you’ll want to keep by your desk (or a PDF you’ll keep bookmarked in your browser) for those times when you need a quick solution in a specific problem area. But, you don’t have to wait until the book is finished to read what we’re writing. We’ll be sharing early drafts and updates along the way here on Medium. (You’ll also be able to get the chapters through O’Reilly’s Early Access program once we’ve made some progress.)
In early 2015, Raffi Krikorian (former VP of Platform Engineering at Twitter, and Dave’s former manager) invited us to Armenia to participate in Hive Summit 2015. We were joined by other engineering leaders from Twitter, Reddit, Facebook, and Google to talk to a packed house of Armenian engineers and entrepreneurs about management challenges in high-tech startups. One evening while dining in Yerevan, we discussed how a book about the job of an engineering lead during rapid growth was missing. Everyone agreed, and encouraged us to take on this project.
So, we (Alex and David) started writing an outline. Our fellow Hive Summit attendees gave us some great input, and we contacted O’Reilly to see if they might be interested in the topic. We were lucky to get Laurel Ruma as our key contact and she helped us focus the book and actually suggested the title of Scaling Teams. While discussing the focus areas of the book, we read Tim Howes’ article “What I Learned Scaling Engineering Teams Through Euphoria and Horror,” where he mentioned five dimensions of scaling: People, Hiring, Organization, Communication and Quality. We were inspired by that and decided to also structure our book around various dimensions of scaling. Ours are different in name and (more so) content, but we’re grateful to Tim for the idea. (Thanks, Tim!)
Scaling Teams will cover strategy, tactics, and stories of growth across five dimensions (Hiring, People Management, Organization, Communication, and Culture), reflecting the ever-changing requirements of engineering leaders (e.g., CTOs, VPEs, and directors). We begin with the startup as a single engineering team, either as an independent company or an autonomous group within a larger company, and describe the typical scaling points as the company/department grows.
Because every organization is different, we won’t (and can’t) prescribe a one size fits all solution. There are several factors that can influence decision-making when things break: the number of employees, the growth rate, the number of offices you have (and the number of timezones), the number of remote employees, etc. Sometimes there are approaches that have a very high likelihood of working, which we will describe in more detail. In other cases, we will more broadly cover possible solutions and provide examples of how other companies have solved them.
We don’t claim that we have seen everything. Every time we talk to other engineering leads we discover something new and that’s why we are looking for stories from you! Specifically, stories about your organization when it reached a critical point where what worked in the past did not work anymore. What did you do to try to fix it? Did it work? We’d love to hear from you and add your story to the book (with your permission and attribution, of course) if it points out a useful insight or technique to try. Please add your story in a response post, or contact us directly at firstname.lastname@example.org.
Want to learn more about Scaling Teams, receive updates, and read previews and related work? Follow the Scaling Teams publication, or follow @scalingteams on Twitter.