During my years as both VP of SaaS Operations and Engineering, I had the experience of going through different transformations at an organizational level. I've worked and moved from distributed agile teams to centralized factory-like process-type organizations to stream-aligned teams and successful teams that eventually ended up being a 50+ people area.
In a big organization with sub-organizations composed of multiple teams, one theme that occasionally comes up is the question of which sub-organization a team should be part of.
For example, at some point, we funded a new platform team called Release Engineering. Its goal was to take ownership of the existing CICD infrastructure, maintain it, and improve and reduce the cognitive load for other engineers. But to which area would this team belong? To the Product Development area (where their users are) or to the Cloud Services area (where the teams that provided them with services are)?
To answer this question, my friend and colleague asked another interesting question: What's an area? If we're one company, one team, why would this matter? And damn, he's right, but ... there's always a but.
Like Conway's law and reverse Conway maneuver, deciding which org to put the team in is an arbitrary organizational design decision. When the team belongs to an area, it will likely have a higher communication bandwidth (and, eventually, coupling) with the other teams in the same area. There's no right/wrong; instead, it is a decision of what you want to incentivize.
