Depending on needs and priorities, companies need different team structures to ensure active Dev, Ops, and QA collaboration. How you build your DevOps team may depend on your company structure and available talent.
Regardless of your company’s structure, DevOps needs collaboration across different functions. The team shares duties to ensure the best possible outcomes. Here are 10 different structures to build highly effective DevOps teams.
The smooth collaboration model offers a seamless and continuous collaboration between the Dev and Ops teams. Each team specializes as needed while also sharing where applicable.
In most smooth collaboration scenarios, there will be multiple Dev teams working on separate product stacks. To be successful, a smooth collaboration model needs thorough planning. The leadership needs a high level of technical competence. Leaders may benefit from negotiation classes to organize teams into functional units.
Both the Dev and Ops teams need to have clear, shared goals. The Dev team needs to be comfortable seeking Ops input in the implementation of business goals. The Ops team should be comfortable with Git and test-driven coding while pairing with Dev.
In a NoOps team, the product development and operations functions appear fully embedded. There is no clear distinction between Dev and Ops teams. Everyone’s focus is on a single, shared purpose.
A NoOps team works most effectively if the company has a single web-based product. This is likely because the team structure operates best on a narrow focus. The model may not work so well with multiproduct companies due to frequent context-switching.
Negotiating shared focus between one product and others leads to team members eventually grouping into Devs and Ops teams. Facebook and Netflix have had great success with the NoOps team model.
Most new companies work on cloud-based infrastructure. However, there are still many companies operating in traditional IT infrastructure. Infrastructure as a Service (IaaS) is the most effective DevOps team model for companies that rely on a traditional IT department. The IaaS model also works best for firms that run their applications on public cloud resources such as Microsoft’s Azure or Amazon’s EC2.
In an IaaS setup, management negotiates with an external firm to handle operation elements. The outsourced Ops team has limited functions. Typical Ops functions include providing elastic infrastructure for the DevOps team to deploy and run applications.
Other Ops functions transfer to the Dev team or a virtual team. The virtual team may conduct server positioning, provide monitoring, and analyze metrics, and will mainly be a Dev team. However, the virtual team will follow standard practices such as:
The IaaS team structure increases effectiveness due to how easy it is to implement compared to the smooth collaboration model.
Smaller businesses may lack the experience, expertise, or finances to handle the operational aspects of software development. Such teams may negotiate with an external service provider to outsource operations. The service provider may be in charge of building test environments, automating infrastructure, and handling monitoring. The service provider may also advise on operational features to install at each stage of the software development cycle.
DevOps as a Service can provide a small and growing team with training opportunities. Team members learn how to customize automation and configuration management for their software. As the group expands, the company could later adopt a smooth collaboration or IaaS model.
A temporary DevOps team structure starts as a DevOps silo, but with an expiry date. The team is typically created to last less than 18 months. The team’s purpose is to bring the Dev and Ops teams closer together through negotiation and collaboration. The entire team works towards morphing into a smooth collaboration or an IaaS structure.
The temporary DevOps team usually experiments with new designs and workflows. The Ops team works with the primary goal of creating more customer value without increasing costs. The Dev team’s primary goal is to deploy iterations faster with minimal increase in effort.
The temporary DevOps team is a test-drive for the company to determine whether they need a full-scale DevOps team. If setting up a permanent team makes sense, the company may negotiate to merge the Dev and Ops teams.
In the meantime, the temporary team shouldn’t handle long-term DevOps functions. In particular, the team should not be responsible for long-term production diagnostics or software deployment. The temporary DevOps structure is most useful for multiproduct businesses that experience regular conflicts between their Dev and Ops teams.
Companies with a high degree of systemic maturity and technical expertise may encounter difficulties running traditional DevOps models. The solution, in some cases, is to introduce a site reliability engineering (SRE) team.
SRE teams work to negotiate workflows between Dev and Ops teams. The SRE team structure removes incentives for local optimization and dismantles structures that encourage the “siloization” of knowledge. SRE structures also focus on monitoring and speeding up recovery from errors.
In the SRE model, the Dev team hands over to the SRE team. The Dev team provides metrics, logs, and other test evidence proving the viability of their software. The SRE can either accept or reject the Dev team’s code. If SRE accept, it’s the SRE team, rather than the Dev team, that then works with the Ops team to support production.
The SRE team breaks down Dev and testing functions to small changes for continuous change management. SRE teams usually use continuous integration and continuous delivery management standards. One of the best known examples of a company that uses SRE teams is Google.
Over 75% of businesses that use container strategies report an up to 10% decrease in software deployment time. Containers provide a hand-over system that removes the need for constant negotiation between the Dev and Ops teams.
Containers improve efficiency by encapsulating the deployment and runtime requirements of the software. The container then acts as a boundary separating Dev and Ops tasks and functions.
Container-driven collaborations increase effectiveness in companies with a sound engineering culture. However, in less developed business, the container-driven approach my degenerate into an adversarial “Us vs. Them” relationship between Dev and Ops. Conflicts usually arise when Dev team members ignore Ops considerations.
Some firms find it useful to pair their database administration (DBA) teams with the development team. The Dev-DBA structure proves useful in improving database capabilities as sources of business value.
The Dev-DBA structure is a favorite for companies with large central databases connected to multiple applications. Such companies find it more efficient to have at least one database administrator support the application development effort right from planning to deployment. Having a DBA alleviates data management problems, anticipates issues before they occur, and reduces delays.
DBA negotiates support structures for smooth database management. Without DBA support, the Dev team would likely spend more time resolving issues with the data interface, security frameworks, and compatibility issues. Often, the DBA will act as a coordinator between the Dev and Ops teams.
Companies with a strong engineering base have lots of technical talent at their disposal. Software engineers typically have untested ideas on how to improve their work. In self-selecting teams, the company encourages members to put a team together and pursue an idea. Management tends to step in during the later development stages.
Self-selected teams are more flexible and often share a willingness to break down barriers. Members find it easier to negotiate roles with familiar faces. Most of the team’s work revolves around trial and error approaches, leading to innovative systems and products.
Self-selected teams usually work to break down silos as members feel they are jointly pursuing mutual objectives. One company that has a self-selection culture, to great advantage, is New Relic.
One way to find the best upcoming talent is by recruiting from academic institutions. Most engineering class leaders are glad to host a recruiter and point out promising students. However, one challenge you should be ready to face is intense competition for young talent.
Building a team by recruiting students and recent graduates has the following advantages:
In most DevOps environments, it’s almost impossible to build a perfect team. Nonetheless, managers can structure their team to deliver software better and faster, depending on the company’s needs.
How you build your DevOps team can affect your productivity and profitability. For optimal effectiveness, structure your team, and define your goals according to business priorities. While building a great team is essential, set up systems to engage members in continuous skill training. Staff retention motivates members and improves team effectiveness.
If you want to learn more on the topic, here is one article we strongly recommend: When Implementing DevOps Make Sure to Avoid These 6 Mistakes.