Stranger Things: Why Engineering Teams Slow as They Grow
Originally published by Robert Hatta on November 15, 2017
I just finished watching (binging) Stranger Things 2. For the uninitiated, it’s thatgood. The story follows several groups of tweens, teens and adults as they separately piece together what’s behind paranormal activity in their sleepy town. When each group figures out what’s going on, they set about battling the menace through various means. These parallel narratives are part of what makes the series so fun to watch. However, it can be frustrating as hell. A single post to the Hawkins Facebook page or Slack group would have sorted the problem in one episode. But it’s set in the 80s. So we’re forced to agonize as the different groups struggle to share information (juvenile Demogorgons like nougat) and coordinate their efforts without the benefits of cell phones, Amber Alerts or Twitter. Season 2 takes the agony further, by adding several new characters to the mix. Many critics of the second installment have noted that it feels slower than the first season.
This reminds me of what I often see at startups, especially engineering teams. In the early days, teams are small and the objectives are clear. Work is easily distributed and coordinated across this tight group of individual contributors (ICs). Everyone is coding and everyone knows his or her part. Shit gets done.
It seems logical that adding more IC engineers will add capacity and increase velocity. But a funny thing happens after team reaches eight or nine engineers. Things don’t speed up. They slow down. Shit does not get done.
Selina Tobaccowala has seen this problem across multiple startups at every stage of growth. She co-founded Evite from her Stanford dorm room. After selling Evite to TicketMaster, she went on to lead a 200-person engineering team there. She was later the President and CTO of SurveyMonkey as it grew from two to 150 engineers. She has observed that eight engineers seem to be the breaking point because, “one person can only handle six to eight direct reports.”
[Selina Tobaccowala, co-founder of fitness app Gixo]
Selina blames other factors that slow velocity as engineering teams grow. The product becomes more complex and work might be split across multiple teams. This makes it harder to keep everyone aligned on priorities (it’s not just about survival anymore) or to share best practices. Early engineers start to question how they’ll move up through the organization or grow their skills. And someone needs to find, interview and hire more engineers. All of these factors add up and, if unchecked, lead to frustration and missed deadlines.
Startup CTOs often make the problem worse. Selina adds, “Many CTOs can have allergic reaction to engineers that aren’t coding 100% of the time. They view the management function as a waste of a good engineer.” But recruiting, one-on-one meetings, best practice sharing and resource allocation are each critical and require full-time attention. She has three tips for inserting management into engineering teams effectively.
Create and celebrate management and IC growth equally
One common mistake she sees is where companies create compensation frameworks that view management roles as superior to IC roles. Selina recommends creating parallel career tracks for both ICs and managers that are equally compensated. For example, a level-2 engineer should get the same pay as a level-1 manager. Share these pay scales across the team so it’s clear that ICs and managers are separate but equally important roles. Selina adds, “celebrate people moving between tracks. Going from manager to IC shouldn’t be viewed as a demotion.”
Hire or promote managers who want to be managers (for the right reasons)
Many startups do (and should) promote ICs into management roles. However, many simply choose the best engineer and make them a manager. The truth is that many ICs love being ICs. They get energy from shipping code, not sitting in meetings and interviewing candidates. Promoting these ICs to management has two negative outcomes: you get a shitty manager and you’ve lost a great IC.
Lots of factors play into being a good manager, but Selina focuses on one, critical question: why do you want to be a manager? “ People whose answers reflect a genuine love of seeing others succeed are the ones you want… answers around wanting more decision-making authority or influence are red flags for me.”
Selina also suggests giving new managers a three-month trial period. Tell the team about the promotion, but don’t make a big, company-wide announcement. Don’t even change their job title on LinkedIn. After 90 days, check in with them as well as their team to see if it’s working. If it is, make the announcement. If it isn’t working, allow the manager to transition gracefully back to being an IC.
Let managers manage
Many engineering managers still commit code or are active in code reviews. This is not a bad thing. However, management is a separate job from coding and CTOs should assess managers based on the performance of their team, not the number of lines they commit individually.
Selina also reminds CTOs that managers of managers will also become a thing. “Again, most people top out at six to eight direct reports. You can scale without adding a new layer of management by splicing off teams around product or feature sets. But eventually, these too will grow beyond what one person can manage.”
In the end, the writers at Stranger Things 2 wake up to the need for management. In the final episode, three teams finally come together to plan a coordinated attack, sharing duties and appointing managers over each team. No spoilers here, but startup CTOs would benefit from finding the Steve Harringtons among their ICs and give them the resources they need to manage successful, fast teams.