Devops and SRE cannot be siloed.

DevOps practicioners know that silos are the thing to be broken by the hands and culture shift. Why but more importantly, how, can business and developers get the results that DevOps promises if they're breaking the most important rule?

When SRE and DevOps became titles the silo gremlin saw this and rubbed its hands together as it saw an opportunity to put walls up and effectively further complicate the value arena. The idea that we're now searching for individuals to fill a role with either of these titles creates a mental and physical seperation between the actor and the subject. Sure, its a little abstract but think about it this way; In SRE, the best SRE is a software engineer with an inclination for performance and availability. On the contrary, there's a lot of staffing for SREs, of which the definition is clearing up of late, but is still quite as nebulous as a DevOps engineer still is. If one was to resource for that position there would be far less speculation on what this person should know how to do and what team they belong to. Instead, its common for SRE teams to exist adjacent software engineers, completely outside of the day to day software engineering effort which ironically yields the most opportunity for them.

Once an team exists, walls comes with it. The classic us vs. them struggle, "throwing over the wall" and communication breakdown potential is greater when these groups of people stay centralized to accomplish a task. The tone should be set immediately that each SRE is a developer or an infra/systems person with an inclination for perfomance and observability. Outcomes, not teams.

When you're looking for success, carefully make choices about how you organize these resources. The velocity of your success depends on it.