97 Things Every Engineering Manager Should Know

Chapter 28. The Five Whys of Organizational Design

Kellan Elliott McCrea

Recently, I wrote about sizing engineering organizations and how you can think about it as an exercise in managing concurrency. In understanding organization size, I talk about the mental exercise of thinking about how the number of concurrent work streams you’re taking on as a team applies upward pressure on the needs of your organization (e.g., you need more managers, who need more directors, who need a more senior CTO, etc.) The inverse exercise is also useful.

As is so often the case with conversations about organizational design, the problem statement usually starts like this: “We need a new engineering leader. Should we hire a new vice president of engineering and move all our managers there (except, of course, for that one team)? Should we hire a CTO to own architectural conversations but maybe not have anyone report to them? Maybe this half of our team could report to the CPO?”

I spend a lot of time trying to convince teams that this is the wrong way to think about organizational design. You can’t solve questions of organizational design by shuffling responsibilities around the board like so many chips on the roulette table (or memorably, once, like so many stacks of Starburst candy on the floor of the CEO’s office). And you can’t solve your team’s problems by slicing more thinly the responsibilities at the top, no matter how often someone tells you the hoary distinction that the vice president ...