Are building a DevOps team in your company agenda or already have one? Considering DevOps continues to gain traction, there’s a high chance you do. If so – you’re not alone — Atlassian’s DevOps Trends survey revealed that 69% of organizations surveyed have a team identified with the title “DevOps”

However, simply introducing new tools or assigning the DevOps label to a team is insufficient to unlock the full potential of DevOps. 

A successful DevOps transformation goes beyond mere reorganizations or adopting the latest technologies; it requires a cultural shift that involves new team structures, management principles, and technology tools. Join us as we explore how to establish the right DevOps team structure tailored to your project needs.

Types of DevOps team structure

Choosing the right DevOps team structure depends on various factors:

• As Conway’s Law explained, fewer product set make fewer natural silos
• Level of technical leadership and the degree of process alignment between development and operations
• A company’s capability and readiness to evolve its IT operations department 
• The organization’s expertise in proactively addressing operational issues

Not all teams share the same goals or utilize the same practices and tools. Hence, even the composition of a team should not be standardized, as different teams require tailored structures based on the broader context of the company and its willingness to embrace change. 

According to Team Topologies, there are 9 common DevOps team approaches that teams can adopt. Keep in mind that the structures outlined below can take various forms depending on a company’s size and maturity. In practice, a hybrid of multiple structures or an evolving structure often yields the best results.

Team structure 1: Devs and Ops 

The ultimate goal of DevOps is to create seamless collaboration between Development (Dev) and Operations (Ops) teams, where both excel in their respective areas while sharing knowledge and responsibilities when necessary. Usually, several separate Dev teams work on distinct or semi-independent product stacks.

Achieving this collaborative model demands significant organizational changes and a highly skilled technical management team. Dev and Ops teams must align around a well-defined, shared objective—such as “Delivering Reliable, Frequent Changes”—that is clearly communicated.

Ops professionals need to be comfortable working closely with Devs and familiarize themselves with practices like test-driven coding and Git. On the other hand, Devs must focus on operational needs, seeking input from Ops for tasks like logging implementations. These changes require a cultural shift away from traditional practices.

Team structure 2: Fully shared Ops responsibilities

In this DevOps team structure, Operations personnel are fully embedded within product development teams, blurring the distinction between Dev and Ops. This integration fosters a strong sense of shared purpose across the entire team. Although this model resembles Type 1 (Dev and Ops Collaboration), it has unique characteristics.

Companies like Netflix and Facebook, which focus primarily on a single web-based product, have successfully implemented this Type 2 topology. However, its applicability is limited outside of narrow product scopes. In organizations with multiple product streams, budget constraints and frequent context-switching often necessitate a clearer separation between Dev and Ops, reverting to a Type 1 model. This topology is sometimes referred to as “NoOps,” as it eliminates a distinct or visible Operations team. It’s worth noting that Netflix’s NoOps model could also be classified as Type 3 (Ops as Infrastructure-as-a-Service, IaaS), depending on specific practices and implementations.

Team structure 3: Ops as Infrastructure-as-a-Service

In organizations where the IT Operations department is either unable or unwilling to undergo rapid transformation, and for those relying on public cloud platforms like Amazon EC2, Rackspace, or Azure, it can be advantageous to view Operations as a team responsible for providing flexible infrastructure for application deployment and management. In this scenario, the internal Operations team essentially functions like an Infrastructure-as-a-Service (IaaS) provider, similar to Amazon EC2.

Within the Dev department, a dedicated or virtual team takes on the role of operational expertise. This team is knowledgeable in areas such as operational features, metrics, monitoring, and server provisioning, and serves as the main point of contact for collaboration with the IaaS team. While primarily a Dev team, they still follow standard practices like Test-Driven Development (TDD), Continuous Integration (CI), iterative development, and coaching as part of their responsibilities.

This IaaS topology trades direct collaboration with Ops for simpler implementation, enabling organizations to realize value more quickly than with a Type 1 Dev and Ops collaboration model. It offers the potential for rapid deployment, with the option to explore Type 1 collaboration later.

Team Structure 4: DevOps as an external service

Some companies, particularly smaller ones, may lack the financial resources, expertise, or personnel to manage the operational aspects of their software independently. In such instances, the Dev team may turn to service providers like LARION for support. These providers can assist with creating test environments, automating infrastructure and monitoring, and advising on which operational features to incorporate throughout the software development cycle.

This DevOps team structure offers a practical and valuable way for smaller teams to build knowledge and skills in automation, monitoring, and configuration management. As the company grows, they can gradually move towards a Type 3 model (Ops as IaaS) or even a Type 1 model (Dev and Ops Collaboration) by expanding their team and bringing in more operational specialists.

Team Structure 5: Limited-term DevOps team

The main goal of a temporary team is to enhance collaboration between Development (Dev) and Operations (Ops), ideally moving towards a Type 1 (Dev and Ops Collaboration) or Type 2 (Fully Shared Ops Responsibilities) model before rendering itself unnecessary.

Members of this team serve as intermediaries, bridging the divide between Dev and Ops by implementing innovative practices such as stand-ups and Kanban for Ops teams. They also tackle operational concerns for Dev teams, including load balancers, management NICs, and SSL offloading.

If enough individuals start to see the advantages of integrating Dev and Ops functions, the temporary team has a real chance of achieving its objective. However, it’s essential not to overload the temporary team with long-term responsibilities related to deployments and production diagnostics. Assigning such tasks to the temporary team could risk creating a DevOps silo, undermining the collaborative objectives.

Team Structure 6: DevOps advocacy team

In organizations where there is a substantial divide between Development (Dev) and Operations (Ops) or a tendency for such a divide to develop, creating a “facilitating” DevOps team can be a highly effective strategy. This model is a variation of Type 5 (DevOps Team with an Expiry Date), with the key difference being that the DevOps team operates continuously and is dedicated specifically to enhancing collaboration and cooperation between the Dev and Ops teams. Members of this team are often referred to as “DevOps Advocates,” as they play a vital role in raising awareness of DevOps practices.

Team structure 7: SRE Team (Google Model)

While DevOps often encourages Development (Dev) teams to participate in on-call rotations, this is not a requirement. In fact, some organizations, such as Google, follow a different approach known as Site Reliability Engineering (SRE), which involves a clear transition of responsibility from Dev to the SRE team that manages the software’s operations.

Here’s how SRE team operates:

• Developers create products incorporating the features outlined in the product strategy.

These releases are handed over to an SRE team. It’s important to note that these teams have the authority to approve or deny launches but must adhere to a structured mathematical framework.

• SRE teams establish a service level agreement (SLA), which often includes a targeted uptime benchmark (typically around 99%), leading to the creation of an “error budget.” If the product is functioning smoothly with minimal errors, it can be launched. However, if the error budget is exceeded and the SLA is not met, the launch will be halted.
• The SRE team is composed of expert-level developers who can not only identify problems but also resolve them. These engineers are encouraged to actively engage in hands-on work, with the stipulation that SREs can spend only 50% of their time on operational tasks.

Collaboration between the Dev and SRE teams primarily focuses on operational aspects. Once the SRE team approves the code, they take on the responsibility for supporting it in the Production environment, relieving the Dev team of that obligation.

Team structure 8: Container-driven collaboration

Containers reduce the need for specific types of collaboration between Development (Dev) and Operations (Ops) by encapsulating an application’s deployment and runtime requirements within a container. This encapsulation creates a clear boundary that defines the responsibilities of both Dev and Ops. The Container-Driven Collaboration model works well when backed by a strong engineering culture. However, if the Dev team overlooks operational concerns, this model can deteriorate into an adversarial “us versus them” mentality.

Team Structure 9: Dev and DBA collaboration

To bridge the gap between Development (Dev) and Database Administration (DBA) teams, some organizations have adopted a model similar to Type 9. In this approach, the DBA team’s database expertise is complemented by a corresponding capability or specialization within the Dev team. This arrangement helps reconcile the Dev-centric view of databases as simple persistence stores for applications with the DBA-centric perspective of databases as intelligent and valuable sources of business insights.

DevOps team roles & skills 

DevOps engineer

One of the key roles for implementing a DevOps restructuring is a DevOps engineer

Responsibilities:

• Build and deploy application code
• Design and implement CI/CD pipelines.
• Deploy and maintain the storage, servers and networking resources
• Monitor system performance and troubleshoot issues.

Skills:

• Familiar with coding & scripting (e.g. Python, JavaScript, Go)
• Configuration management (e.g. Chef, Puppet or Ansible)
• Communication & collaboration 
• Containers and container orchestration (e.g Docker or Kubernetes)
• System architecture and provisioning (e.g AWWS, Terraform
• Monitoring and logging tools (e.g. Prometheus, ELK Stack)

In addition to the primary role of a DevOps engineer, there are various sub-roles within a DevOps team:

Security engineer

Organizations that have not fully integrated security and compliance considerations into their planning and development processes typically assign an individual or a team to handle security. However, this approach can lead to an antipattern, as it relegates security to an afterthought. It is far more challenging to secure software after it has been designed, built, and deployed than to incorporate security measures from the outset.

Responsibilities: 

• Applying security best practices and utilizing tools to safeguard the company’s software and systems against potential threats.

Skills: 

• Security protocols and technologies (e.g Nessus, Metasploit, and Burp Suite) 
• Knowledge of compliance standards (e.g PCI-DSS, HIPAA, and SOC 2)

Test automation engineer

Responsibilities: 

• Implement automated testing to ensure high-quality releases.
• Working closely with development to identify and prioritize areas suitable for automated testing.
• Conducting regression testing and validating bug fixes.
• Analyzing and reporting test results 
• Continuously enhancing and maintaining the test automation infrastructure.

Skills: 

• Test automation tools (Selenium, Appium, Cucumber) 
• Testing methodologies (Agile, Scrum, TDD)
• Programming skills (Java, Python, JavaScript).
• Excellent analytical and problem-solving abilities.
• Experience with CI/CD pipelines.
• Cloud-based testing and test automation in environments like AWS or Azure

Product Owner/Manager

Responsibilities: 

• Define the product vision and strategy.
• Prioritize the product backlog and manage feature requests.
• Collaborate with stakeholders to gather requirements and feedback.
• Ensure the development team delivers value aligned with business goals.

Skills:

• Strong communication, leadership and problem-solving skills
• Understanding of the market, customer needs, and competitive landscape
•  Proficiency in prioritizing the product backlog
• Familiarity with Agile principles and practices
• Technical understanding

DevOps project management best practices

Once you define your DevOps team structure and member roles, it’s time to think about project management to facilitate faster software delivery and effective team collaboration. Familiarity with Agile principles and practices 

In a DevOps management approach, project managers act as coordinators among various contributors while monitoring timelines and dependencies. However, it is crucial for project managers to closely align with the DevOps team and possess a deep understanding of the development process and the skills necessary to deliver the final product. To effectively integrate into the DevOps pipeline, project managers should adhere to several best practices.

Embrace MVP mindset

In software development, the minimum viable product (MVP) refers to a version of application with minimal features that effectively meets the project’s essential requirements. DevOps adopts the MVP philosophy to ensure that there is always a deliverable at the end of each sprint, avoiding delays caused by an overly broad scope. 

This approach marks a significant departure from traditional project management methods, which tend to focus on delivering a complete, monolithic product. Instead, DevOps is seen as an ongoing process of continuous improvement rather than a linear sequence with defined start and end points. 

The MVP mindset offers several benefits: customers receive a deliverable more quickly, allowing their feedback to guide adjustments earlier in the development cycle. In contrast, teams following a waterfall approach may complete a final product only to find that it does not fully meet users’ needs, forcing them to restart the entire process.

Navigating dependencies

Even in a system architecture that employs a microservices approach—where small applications are built to perform specific tasks—dependencies still exist between these applications, the underlying systems they operate on, the data they manage, and more. 

Tracking these dependencies extends beyond mere configuration management; it necessitates maintaining visibility into all the dynamic components of the IT environment and the tasks of the DevOps team to effectively define sprint objectives. Each deliverable should be fully functional within the existing environment and ready for deployment by the end of each DevOps cycle. If progress is hindered by a backlog of tasks or unmet system requirements, then enhanced dependency tracking becomes essential.

Leverage project management tools

Automation is a key focus within DevOps to enhance team effectiveness and this is equally true for DevOps project management. Project management tools serve as a central repository, providing a clear overview of task assignments, project progress, and any issues encountered throughout the process. 

Ideally, these applications should integrate seamlessly with the tools the DevOps team utilizes daily, ensuring that both project managers and developers are aligned. Dashboards can display real-time metrics regarding team performance relative to their goals, allowing project managers to identify potential issues and address them earlier in the development cycle. 

Let’s explore some of the tools available to help implement effective DevOps project management strategies: 

• Jira: Developed by Atlassian, Jira is a project management and issue tracking platform designed specifically for software teams. It allows teams to assign tasks, monitor issues, and report on resolutions for each sprint. Additionally, Jira seamlessly integrates with other products in the Atlassian suite, such as Bitbucket, Confluence, and Pipelines, as well as various developer tools, providing enhanced insights and functionality.
• Azure Boards: A project management tool that is part of the broader Azure DevOps suite, covering the entire DevOps lifecycle, including Pipelines, Repos, and Test Plans. It features Kanban boards, team dashboards, and custom reporting to monitor every phase of development, along with advanced analytics to keep you informed about your project’s status. Additionally, Azure Boards offers both pre-built and customizable workflows to ensure that every task is effectively captured.
• AWS DevOps: An extensive suite of tools designed to manage pipelines and develop software within a unified stack. This software project management solution is categorized under Infrastructure as a Service (IaaS) cloud computing. The integrated tools, including CodePipeline, CodeBuild, CodeDeploy, and CodeStar, support the entire DevOps lifecycle and can be deployed in the cloud or on local machines. Furthermore, AWS Marketplace offers access to thousands of additional tools to enhance project management and development capabilities.
• GitLab: GitLab is an application designed to support the entire DevOps lifecycle, emphasizing the management of team member assignments and project organization. It utilizes issues to track tasks, employing labels, milestones, and iterations to categorize these issues for improved coordination. Additionally, the platform provides visualizations to quickly assess progress toward goals and integrates with code merge requests, allowing for real-time correlation between issues, milestones, and developers’ work.
• Asana: A DevOps management platform designed to streamline and automate the process of capturing tasks and activities within a team. It provides various views for tasks, including timelines and boards, offering the context necessary to prioritize work effectively. Project managers can implement approvals and customize workflows using forms, templates, and rules to align with the team’s needs. Additionally, Asana integrates with over 200 productivity tools, including GitHub and GitLab. For a comprehensive overview of the technologies your organization will require to establish a DevOps pipeline beyond project management, be sure to explore our complete list of DevOps tools.

Summary

By carefully selecting the right DevOps team structure, defining member roles, and implementing effective project management principles, you can enhance coordination between individual team members and the overall goals of each sprint. However, navigating the right approach and model can be challenging for enterprises as there is no one-size-fits-all solution.

At LARION, we have successfully assisted organizations of all sizes across various industries in identifying their project needs, establishing effective team structures, assigning roles, and selecting the right tools for DevOps operations and project management. Contact our team today to transform your operations and achieve meaningful results with DevOps