Steven Sinofsky — former Microsoft Windows executive, now a16z board partner — wrote a really in-depth article about organizing teams within companies:
Functional versus Unit Organizations
For the uninitiated, functional organization is grouping people by discipline: marketers as a team, software engineers as a team, etc. Unit organization is grouping by business or product, where each unit contains its own “full stack” of people which can autonomously run that area of the company. Those who’ve stayed for a while at a company know that there’s no “right way” to organize teams, and that executives bounce between the two structure types to optimize for evolving business needs.
At least, that’s been my learnings as a people manager, and I’ve had to execute a few minor re-orgs to move my teams closer to the company’s immediate goals1. I liked that Sinofsky not only looks at what reorgs bring about in immediate impact, but that he takes a longer view of its ramifications: the skillsets that unit leaders will develop over time, and how that will affect product development down the line. Of course, since Microsoft Windows is one of the biggest software projects in history and employs thousands of developers, this sense of scale and long-term organization vision is more applicable than with smaller shops.
At a high-enough level, though, planning a re-org is more about drawing out an org chart that caters to areas of focus, and then slotting people into open positions and shuffling till everything kinda fits. Most re-orgs I’ve experienced are of this type, and there’s a feeling of cold, scalable methodology to the entire ordeal. It’s not surprising that people are stressed during these events; they can be accompanied by layoffs, and even in situations where people are simply shuffled around, teams which were humming along are broken apart without a care for cohesion or culture. In the eyes of an org chart, people are fungible.
That said, the best reorganization I’ve ever been a part of was executed by Gokul Rajaram upon joining Square. It’s an unwritten rule that senior executives, when taking on a new job, will look to hire and/or reorganize their team soon after starting, both as a way to leave their imprint and to demonstrate that they can take immediate action. Gokul followed the same blueprint, but made an effort to gather input from everyone under his management tree individually2.
When it came time to execute the move, he identified a bunch of product areas — continuation of core products plus a handful of “bold bet” new initiatives — to focus on, and left it up to the individuals to self-select onto the new teams. Now, this may be standard practice at some companies, but to introduce this to a team of 80+ folks that did not start with this type of culture, and to continue the thread on shipping products by putting enough people in the right place is still an impressive accomplishment. I’ve had people tell me, years later, that it was a “relatively easy” re-org to execute, but I’m not sure if they’ve ever been in the driver’s seat and were speaking from experience3.
As with most people-centric matters, it’s helpful to have a rough template and playbook, but the devil will always lie within the details. Organizing teams, when done correctly, feel like setting up a table for dinner. There’ll be cooks who actually prepare the food, servers to take care of the operations, and diners to enjoy the meal; the table simply sets the stage, and if it does its job, you don’t even realize its importance.
I’ve heard one executive humbly claim that her only real power as an exec was the re-org.↩
He also gave some great advice on how to do this; listen and take notes and synthesize, don’t argue or get defensive on negative feedback.↩
It comes from the same place where individual contributors think management is pretty easy since they’ve been (poorly) managed throughout their careers.↩
