What you say makes a lot of sense, and on paper, standardization across teams looks like the perfect solution. In fact, I used to think exactly the same way - I even remember feeling skeptical about approaches like micro-frontends that allowed teams to choose different frameworks. You raise valid concerns about ending up with "a dozen similar and dissimilar approaches" and team transition challenges. But experience has shown me that this approach is overlooking some key aspects.
When we force teams to standardize everything upfront, we create what I call the "cookie-cutter problem" - where every technical decision requires massive coordination across the entire organization. And you're absolutely right - this isn't about saying "Screw it. Y'all do what you want." The goal isn't to have dozens of different approaches, but rather to protect against premature standardization that creates rigid coupling between teams.
When we have hundreds of people working together, every forced dependency becomes a potential bottleneck. You mention "if your teams have communication issues then focus on the communication issues" - and that's exactly what this approach does, but from a different angle. Rather than forcing teams to constantly communicate about every shared implementation detail —becoming one gigantic team—, we establish clear interfaces that define what needs to be communicated while giving teams autonomy over how they implement their solutions. This actually improves communication by making it more focused and meaningful.
And this isn't just my opinion - it's backed by decades of research and industry experience. Conway's Law has shown how system design mirrors communication structures. Amazon's success with "two-pizza teams" and their API-first approach demonstrates the power of team autonomy with clear interfaces. The DORA research program consistently shows that team independence correlates with higher delivery performance. All these point to the same conclusion: trying to enforce complete standardization across large organizations often creates more problems than it solves.
So, what do you think about focusing on clear interfaces between teams rather than enforcing identical implementations across the board?
