I’m frequently asked about the ideal team structure for DevOps. A common sentiment suggests that the only “proper” way to do DevOps is by having developers and operations people on the same team. Otherwise, the thinking goes, you have the old dev and ops separation that DevOps is specifically intended to eliminate.

While this comes from a good place, it’s not actually the only valid way to do DevOps. Let me offer two models for successful DevOps. These are not meant to be taken too rigidly. I’ve seen both work successfully within the same organization, sometimes transitioning from one to the other, or sometimes employing both simultaneously.

Let’s remember that a core goal of DevOps is cooperation between Dev and Ops. Specifically, in some traditional teams, development’s goal is faster change, and operation’s goal is stability (i.e. no change); DevOps seeks to align these teams with a shared goal.

1. The combined DevOps team

   This is the model I eluded to above, and is the model most likely to be considered the “only” model by hard-core “cross-functional” advocates. A common approach is to have an Operations Engineer embedded on each development team. This Ops engineer may (or may not) be part of a larger Operations team, tribe or guild, with other operations engineers in the organization.

   This approach seeks a shared goal by virtue of Devs and Ops being on the same team, with the same team objectives.

2. The Operations-as-a-service team

   Another approach to DevOps is to keep Operations Engineers on their own team, but with a redefined purpose. In this model, the Operations team exists primarily to serve the development organization by providing the tools that allow developers to deploy and manage their own services.

   In this model, the responsibility for application stability is shifted from Ops (where it puts Devs and Ops at odds with each other), back to the Dev team. If the Dev team ships unstable code to production, it’s no longer the Ops team’s responsibility to bail them out. The Ops team’s responsibility is simply to give Devs the minimal operations platform necessary for Dev to do their own debugging and service restoration.