It's critical to create the correct DevOps team structure

DevOps versus structure

DevOps doesn't advocate for the total erasure of structure. It does, however, strongly encourage developers, admins, quality assurance (QA) teams and everyone else who plays a role in software delivery to collaborate constantly to achieve a harmonious DevOps team structure.

That means that engineers sometimes have to step outside of their official positions. IT ops admins may be asked to take part in a conversation about coding in order to help ensure that developers are aware of the deployment and management needs of admins. The QA team may require developers to learn the basics of Selenium in order to ensure that everyone can interpret testing results.

Breaking down silos doesn't mean erasing hierarchies.

Stepping outside of official roles is a great thing, up to a point. After all, it was organizations realizing they could improve IT processes by dissolving silos that sparked the DevOps revolution a decade ago.

But the collaboration dogma can be taken too far. If you break down the DevOps team structure entirely, your organizational structure will decay, and you will not be able to take full advantage of your engineers' skill sets.

Getting just the right amount of DevOps

How do you know when you're on the verge of crossing the threshold from being an efficient, collaborative, communicative DevOps shop to one that loses all sense of structure and order?

Consider the following signs that you're taking DevOps too far:

• You only hire DevOps engineers. Having some DevOps engineers with broadly defined responsibilities on staff is good. They can float among development, IT ops and other teams and help facilitate healthy collaboration. Yet, if your entire DevOps team structure consists of DevOps engineers with ambiguous job roles, you've gone too far. At the end of the day, you need some people whose main job is coding, others who own IT ops and so on.
• No one is in charge. breaking down silos doesn't mean erasing hierarchies. Those are two different things. Yet, in the rush to embrace DevOps, it can be easy to make the mistake of thinking that all engineers should be treated equally in a DevOps shop. That's not true. You still need a chain of command in your DevOps team structure.
• Your software delivery is getting slower, not faster. It's a problem if you've adopted the tools and processes that are supposed to enable continuous delivery, yet your delivery speed is not actually improving (or is getting worse). A lack of DevOps team structure could be the culprit. When roles become too loosely defined, your engineers' time is not always used in ways most beneficial to the organization because individuals lack strong direction.
• Everyone is blamed when a failure occurs. If you break down silos to the point where no individual or group has ownership of a specific process, your entire IT team ends up being in the line of fire when something goes wrong. That's not healthy. You still need ownership and responsibility, even if you encourage your team members to collaborate and support each other.
• You do one thing better than others. DevOps should help you do all processes equally well. If you instead find that your organization consistently performs strongly in some areas (like development) but is always struggling in others (like deployment), it could be a sign that your organizational balance is off because your ostensible DevOps engineers don't actually have the wide-ranging skill sets that DevOps requires. In that case, you need to ensure that you hire different people with skills in each of the areas that you need to cover. That means giving more priority to engineers who will fill specific roles, rather than serving as general-purpose DevOps folks.

You can and should strive to build an agile, flexible organizational DevOps team structure. Be careful, however, not to go too far. You can't do away with structure entirely. If you do, your organization will end up a big, senseless blob, which is not good for anyone.