![](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F976e1987-54f1-4c36-966e-09312d9d9b71_890x746.png)
As a product leader, one of the highest leverage ways to spend your time is to design the right org structure. It’s Conway’s law at work: your product will always mirror the team structure and incentives you’ve created with your colleagues.
It’s also insanely hard to get this right. Every organization is different, every product is different, and making the correct call often involves choosing the lesser of two evils. And the position of “executive” makes the challenge even harder: you’re not hearing the scuttlebutt and you’re balancing a lot of different stakeholder’s opinions.
When I “architected” (hah!) my first org as an executive, I entirely lost my head and was an idiot. I did everything counter to my IC-hardened-instincts. It was baffling to me: how I had become the manager that I used to make fun of? To prevent that from happening the next time, I wrote down every obvious “org design rule” that I could think of in an email to myself (subject line: “The Idiot’s Guide to Re-orgs”.)
Here’s that email now, edited for context and clarity.
From: tara@[priorworkplace].com
To: taraseshan@gmail.com
Subj: The Idiot’s Guide to Reorgs
You’ve been working on this re-org over the past couple months. Now that it’s over, it…sucks?! How did we get here? It was particularly galling to realize the obsessed-with-work-youth were critiquing your dumb moves, just like you used to critique your past bosses. You’ve become a monster!
Just kidding. Designing an org is hard, because it’s just like designing a product: it should help differentiate your company and provide value to your users. That said, there are some really clear “basics” that should be mastered so that you can focus your attention on the hard stuff.
Users first: Your org design is your product design. The most important first question to ask yourself is “if the org chart was visible in the product, how would you feel?” The best team splits are across products that never work together, like the iOS and Android apps (who uses both of those?) so that users never feel the “seam” in the product experience.
Anti-fragile org: Everyone one of us is replaceable. People come and go over the course of their careers. It’s easy to rationalize building a team around a star performer, and even putting a team in an inappropriate geography to accommodate that star. In retrospect, this was a terrible idea. The star left three months later and the team was doomed to fail. A person’s career decision should not make or break your org chart.
Optimize for compounding: Keep people in the same general zone so that their expertise can build over time. In this particular re-org, you swapped team missions so that the Reporting team ended up working on Reductions and vice versa. This was not a great idea. People benefit from compounding expertise. The Reporting team had gained a lot of expertise over the two quarters they had been doing Reporting — when they handed off the product, the new owners had to spend two quarters re-learning what the previous team had done and refactoring (lol.) You cost the company and the users two quarters of progress, if not more.
Speed is critical. Org structures are not trap doors. We will have to do this again. Leaving people in limbo has real costs. Instead, move quickly and decisively knowing that you can unwind it as needed. Bring people along, recognizing that most people’s instinct while nervous is to go slow and proceed with caution. That’s the wrong instinct here! You need to be the person to drive speed.
Lean into strengths: It is tempting to try to eliminate pain with the org structure and get “creative” to solve issues. You tried to divide teams by user segment and then layer in the stack, created “experience” versus “platform” teams, and made an awkward grab bag team whose responsibility was to solve others’ pain. This is a trap. Use process to eliminate pain (process is an opiate!) and use org structure/incentives to focus on strengths.
Clarity over nuance: Teams need clear swim lanes where they feel empowered and have a sense of ownership. Do not create a team mission that is mired in complexity, mixed structures and nuance. This will lead to confusion, conflict, and wasted energy. If you feel yourself getting too complicated and cute, back up.
Avoid homogeneity: Teams do not have to be perfect 7 person teams. It is ok to have 3 person teams and 14 person teams. Fund the important stuff the way it should be funded, and make the teams around “new bets” as small as possible (3 people, ideally.) If the existence of a team seems questionable, now is the time to cut it. In this specific re-org, you did not aggressively fund the important stuff or cut teams. You felt uncomfortable! You wanted to think the company could do it all! But that’s usually wishful thinking, and sets the org up to fail. Fund teams heterogeneously, and cut teams whenever you can.
Make transitions faster: When teams must merge, change managers, or wind down, people often ask for a couple months to transition. However, any sort of delay is usually borne from an emotional need for stability rather than what is best for the teams in the long term. More often than not, you should rip off the Band-Aid! The new joint team can handle spinning down old projects and learning new things together.
Beware of inadvertent promotions or demotions: A shifting org structure sometimes creates inadvertent “promotions” by adding or eliminating layers. Some managers and teams (PMs, gah) are extra-sensitive to these dynamics. In the case where a promotion is an “interim” elevation, make that “interim” state extremely clear to the point of over-communication. In the case where the movement is an demotion of sorts, make sure it’s very thoughtful. There should always be a good reason that you can explain to the person in question. If possible, give them a (real) choice: “When we merged the teams, we chose Joe as the new leader. He is a meaningfully more experienced manager than you are, and I think you can learn from him. You can choose to report to Joe and stay on the newly merged team, or you can still report to me and switch teams.”
Keep the “in” group small and eliminate grumbling: The best person to help you design the right org is an engineering tech lead1 who has both on-the-ground context and “leader” visibility. Unlike most managers and directors who want to build territory, the tech lead knows their job is about growing the product. Once you have a reasonable default structure with the TL and the senior team, run the actual re-org process as a tight turnaround, ideally a week before you communicate with ICs. This should involve: getting feedback from the managers and cross functional leadership, incorporating that feedback, running edge cases by HR, and then communicating to the org. Constructive feedback from this manager group deserves real consideration and responses, but grumbles are unacceptable. Re-orgs are the ultimate moment to “disagree and commit” for any leaders in the organization. The best people to culturally discourage grumbles are the founders.
[bonus] Test your comms with a focus group: Patrick Collison would send important organizational messages to a small group of trusted but “ordinary” (no special leadership position or privilege) people as a way to get feedback and gauge the greater org’s reaction. You can create an opportunity to do this by following the Stripe re-org comms schedule:
Day 0:
Tell everyone affected in 1:1s, give talking points for managers
Do a “gut-check” of the mass communications with a trusted group of ICs. Make sure to specify that the feedback is being asked about the communication, not the re-org itself.
Get any feedback from managers, based on their 1:1s.
Day 1:
Send out the comms to everyone in the org! Always, always, include an updated diagram of the org chart.
Reinforce the message in key team meetings where needed (managers should have reported hot spots to you after their 1:1s.)
Managers should support individuals having a hard time and escalate issues with HR (or you, if there’s no HR.)
Follow up:
Shift to talking about the actual reason for the re-org (product substance) as soon as possible. For example, something like: “We re-orged so that we can move faster on our top priority, building a better measurement product. This is why that is important. These are the three things we have to do in that area, and why they are challenging.”
This is my comfort zone (product substance! strategy!) but actually is one of the best ways to run the re-org because it leans on strengths. If you’re not a gifted empath, take the rational route. It becomes clear to the people involved that you’re being a good steward of the company and product, not just taking care of individuals.
Or any similar function outside of engineering — think “senior IC in the details who doesn’t have an incentive to power grab via the org lines”