Aug 14, 2026
Rules of thumb for reorgs/org design:
- this is all stage dependent
- in early stages splitting different classes of work across teams is a nightmare (product, infra, sre, etc)
- thus when starting smtg new, spin up a team and dedicate it to the new project e2e
- in scaled products/later stages it's the opposite: one team handling multiple distinct classes of work is a nightmare
- thus when scaling split teams by class of work. Product teams build features, infra teams run infra, sre teams handle reliability
- ppl will make compelling arguments for not doing this. E.g. engineers should feel the pain of bugs or they have no incentive to care about reliability, etc etc. Generally speaking the arguments are wrong. Trading these concerns off to make teams single threaded is worth it many times over. And if problems do crop up, there are better ways to fix them anyway. (There are always exceptions of course ymmv)
- if a good team's performance is lagging, check if they're doing multiple classes of work. High likelihood this is the problem, in which case you should split the team
- if a team is responsible for two areas but never manages to get to one of them it's a good sign you should either (a) spin up a dedicated team or (b) abandon the underserved area
- if you’re doing smtg new/big that slices across the org, spin up a virtual team for it. Pull ppl from all the relevant parts of the org into this project. Make it their primary (and ideally only) objective. Depending on the project the team can later become permanent or disband
- try to keep team structure and code structure eventually consistent (people don't really do this anymore, but I still maintain you should try)
- try to maintain knowledge continuity/don't leave behind orphan components. Knowledge is easy to lose and hard to recover
- you ship the org chart; product coherence will degrade across team boundaries. E.g. Azure/AWS/gcloud portal experience across services.
- you can (and should) resist this through force of will, but eventually org structure wins
- thus you must explicitly decide where in the product you are willing to trade off coherence. You can then select team boundaries around this affordance
- a corollary is that if you have product surfaces that have become incoherent and you want to fix that, you have to eliminate team boundaries and thus have to merge the teams
- reorgs that fix smtg important may stress ppl in the short term but energize them in the long term
- reorgs reshuffle people's status and relationship ties. So you’ve got to pace reorgs and weigh their utility against the costs of disgruntled managers and ppl feeling estranged
- everyone has different chaos tolerance. Frequent reorgs are like a centrifuge that stratifies ppl by how much chaos they can withstand. (The top stratum typically makes for very good leaders)