I've read a lot on how other orgs have grown and gone through DevOps transformations, and all of this is echoed in those stories, but it also leaves out other strategies. Would like to see more of a matrix of what strategies are useful in what context and aren't in others.<p>In SRE/Ops, it seems to work better with two single-disciplinary teams (Builders and Runners) in one department. One team builds systems, another team runs systems. This is because experience leads to efficiency. Scaling a single-disciplinary team <i>(in this context)</i> you get efficiency combined with ability to respond to organizational change. Think of a cabinetmaker versus a chair maker. Or in comparing SW Developer / SRE-Builder / SRE-Runner, an auto engineer, an auto mechanic, and a racecar driver. They are each efficient at a particular thing because of their experience.<p>But for building and running a product as a whole, you want a multi-disciplinary team to manage the wide range of experience needed to build and run that product. You still rely on outside single-disciplinary teams for things that can be done more efficiently that way. But you can change the product faster/better if a core group has a lot of general knowledge about it.<p>The trick is to create feedback loops where these different teams feed information and work streams back into each other constantly. You do this to fight silo-ism, and to reduce friction in the value chain.<p>I think "reporting" is highly overrated. The principle of a self-organizing team is that they will figure out what they need to do. If you start dissolving the "lines" between teams, the organization as a whole will start figuring out what it needs to do. If you think about ecology, this is how natural systems work: there are always boundaries in different parts of an organism, but many of its parts self-determine their actions. Coordination becomes a ballet, not a machine.<p>And what's often overlooked is how the larger organization affects the value chain. The higher levels of the organization often set the tone for how work gets done for <i>everyone</i>. But different parts of the org may benefit from radically different working models. Are there proven ways to run different parts of the business in drastically different ways, yet still provide clear workflows for them to operate together efficiently?