As you’re hiring people to help piece together your organization’s unique DevOps puzzle, where do you put them? How do you structure your teams to facilitate a DevOps-centric approach?

The idea of creating a delivery engineering team (aka a “tooling team”) seems to be gaining traction. We at Bitlancer are big fans of this approach because it inherently defines and limits the amount of work being done by a separate team in a DevOps context/culture. Development leaders like Netflix are apparently onboard with this approach as well.

The job of a delivery engineering team is basically to build and maintain the automation that enables everybody else in the company to build, test and ship their code into production-whether it’s product code or infrastructure code. For example, a delivery engineering team might help move software from a legacy platform to the cloud by creating the required tools and practices. That’s a relatively small but obviously critical piece of anybody’s DevOps puzzle, which provides the foundation necessary to allow everybody else to own their own material in the DevOps context.

It really makes sense, at least for organizations that have multiple product teams, to separate out a delivery engineering function. That way you don’t have a bunch of your engineers messing with the automation that’s supporting all your code delivery.

What you don’t want to do, as we’ve stated all over this blog in the past, is create a “DevOps team.” Just as DevOps shouldn’t be in anyone’s job title, there can’t be just one team that controls DevOps. All your engineers, whatever their roles, should be involved in the DevOps process.