How to Construct the Ideal DevOps Team Structure

DevOps teams are like houses: There are many ways to go about structuring them, and no approach is necessarily better or worse than the others. The best structure for you depends on your organizational requirements and goals.

Indeed, although the question of how to structure a DevOps team doesn't usually feature prominently in conversations about adopting DevOps, deciding on a team structure that optimizes, rather than hinders, your ability to "do" DevOps can be one of the most challenging parts of building a DevOps organization.

This article unpacks the reasons why structuring a DevOps team can be so difficult, explains the most common DevOps organizational models, and discusses what to consider when devising a DevOps team structure.

What Is a DevOps Team?

A DevOps team is a group of engineers who manage an organization's software delivery process using a CI/CD pipeline.

Note that I'm using the term "DevOps team" loosely here. As noted below, a DevOps team is not necessarily a single stand-alone team. That's one model, but there are other approaches to constructing the organizational structure that undergirds DevOps.

That said, every DevOps team, no matter which form it takes, should include engineers who are skilled in both software development and IT operations. The core purpose of DevOps is to bridge the gap separating these two disciplines. Modern DevOps teams may also include other stakeholders — such as quality assurance engineers or security specialists — who can bring additional expertise to the software delivery process.

Related:How to Move from IT Operations to a Career in DevOps

The Challenge of DevOps Team Structure

There are two main reasons why it's often hard to structure a DevOps team.

The first is that (as we'll see below) there are many ways to go about it, and the DevOps philosophy offers no guidance on which approach is best.

The second is that structuring your DevOps team in the wrong way can cause long-lasting problems. For example, a DevOps team that includes every engineer in your business may be so large that team members cannot communicate effectively, which undercuts the collaboration that is a key goal of DevOps. On the other hand, a DevOps team that is too small may leave your business overly dependent on a handful of key employees to handle DevOps work, creating issues when those employees leave or are temporarily unavailable.

Models for Structuring a DevOps Team

To avoid risks like these, you'll need to select the right DevOps team model for your organization. Here's a look at the most common approaches to structuring DevOps teams, along with their pros and cons.

Embedded DevOps team

Probably the most popular approach to building a DevOps team is to "embed" the DevOps team within a larger team. The larger team is usually either the software development or IT operations team.

The main advantage of this model is that it eliminates the need to hire (and pay for) a totally separate DevOps team. Instead, engineers whose primary role is development or IT ops fill a DevOps role, too. This approach tends to work especially well for smaller organizations, which may lack the resources (or need) for a stand-alone DevOps team.

The drawback is that, if you don't have engineers whose sole focus is DevOps, DevOps can end up becoming a secondary area of focus within your organization. The trick to avoiding this pitfall is to make sure that whomever you assign to your DevOps team-within-a-team gives equal priority to DevOps and the primary team's focus.

Stand-alone DevOps team

The opposite of the embedded DevOps team model is building a stand-alone team of DevOps experts who do nothing but DevOps. This team operates independently from — but closely collaborates with — development and IT operations.

This strategy will cost more and will lead to a larger overall IT organization, which is why it tends to work better for enterprises than for SMBs. The trade-off for the high investment that this model demands is organizations get a team that makes DevOps its sole priority.

The SRE approach

An increasingly popular variant on the stand-alone DevOps team model is to hire a dedicated team of site reliability engineers, or SREs. Although SREs are not quite the same thing as DevOps engineers, they can fill a similar role.

By building an SRE team, then, businesses get something very similar to a stand-alone DevOps team that exists alongside development and IT operations. The main difference from an actual DevOps team is that SREs can bring a broader set of skills to the table; for instance, SREs tend to be more heavily involved in incident response than DevOps engineers.

Collective DevOps ownership

A somewhat radical approach to DevOps team structure is to avoid designating any specific engineers or team as DevOps specialists, and instead make DevOps a collective responsibility of every engineer.

Under this model, the organization as a whole embraces DevOps and CI/CD, with everyone "owning" these responsibilities equally.

The major risk here is that, without assigning primary responsibility for DevOps to anyone in particular, there's a chance that no one will actually do DevOps. But for smaller organizations that enjoy strong cultures of shared responsibility and collaborative models, this approach may be the simplest and most efficient way to implement DevOps.

Outsourced DevOps

A less common strategy for building a DevOps team — but one that may work well for especially small organizations that have minimal in-house development and IT operations resources — is to "hire out" DevOps using something that resembles a managed services model.

In other words, rather than assigning DevOps responsibilities to any of your employees, you would work with an external business to add DevOps techniques and practices to your IT strategy. This approach is sometimes called DevOps-as-a-service.

Leveraging DevOps-as-a-service can be tricky because relatively few businesses offer DevOps on an outsourced basis. But they exist. And if you can't find an agency or MSP that will do DevOps for you, you could experiment with hiring a freelance DevOps engineer.

Conclusion

When deciding how to structure your DevOps team, consider factors like how large your overall IT organization is, how many resources you have to invest in DevOps, and how much of a culture of collaboration already exists within your technical teams. There is no universally right or wrong way to integrate DevOps into your organizational structure, but you'll want to think carefully about your resources and culture before committing to a particular DevOps team structure.