GitOps Fish Series — (Rib 2) Culture and Team Collaboration: Harnessing the Potential of DevOps Collaboration Patterns

7 min readSep 7, 2023

The heart of any DevOps initiative within a company should be to amplify value delivery for its clients and the overarching business. It’s not primarily about slashing expenses, ramping up automation, or having configuration management dictate every move. Instead, it’s about optimising workflows, enhancing collaboration, and tailoring processes to fit specific organisational needs and challenges. Recognising these unique demands and dynamics means there isn’t a one-size-fits-all team structure; what works for one organisation in fostering Dev and Ops synergy might not work for another.

Much like designing a system, the structure and organisation of teams play a pivotal role in shaping how they approach DevOps. Conway’s Law posits that organisations are predestined to produce systems that reflect their communication structures. This means that a team’s organisation isn’t just a logistical detail but a determinant of how effectively they can embody the DevOps ethos. As firms embark on their DevOps journey, it’s crucial to understand that cultural change may necessitate rethinking and reshaping team structures. Only by aligning team organisation with the desired operational workflow can a company truly leverage the full potential of DevOps.

The ideal DevOps teams structure for a company isn’t a one-size-fits-all solution and hinges on various factors:

The organisation’s product range: A limited number of products often simplifies collaboration since there are fewer inherent silos, a notion echoed by Conway’s Law.
The depth and efficiency of technical leadership and if Dev and Ops share a unified goal.
The organisation’s readiness to shift its IT Operations from tasks like setting up hardware and tweaking servers towards aligning with the value stream. This also includes how seriously software teams consider operational aspects.
The organisation’s ability and expertise to spearhead operational matters.

DevOps Collaboration Patterns

Consider the below picture where a set of Collaboration Patterns or DevOps Topologies, as the authors of “Team Topologies” book, Matthew Skelton and Manuel Pais, designate them (you can get the details of each pattern here. I strongly recommend that you give it a look)

In DevOps, several anti-patterns, or “anti-types”, hinder collaboration and efficiency between development and operations teams.

Firstly, the Dev and Ops Silos, or “Anti-Type A”, depict a scenario where development teams consider their work done once a feature is complete without accounting for its performance in production. This leads to operational challenges since there isn’t enough context shared.

As DevOps became more popular, some organisations tried to adopt it by creating a separate “DevOps” team (“Anti-Type B”), inadvertently creating a DevOps team silo that became an additional barrier between development and operations. The intent might be good, but the execution can often lead to more complications than solving the root issue of collaboration and integration. This approach is counterproductive unless the DevOps team is temporary with a clear goal of dissolving after bridging the Dev and Ops gap (Type 5).

With the rise of cloud services and Platform-as-a-Service (PaaS) offerings, there’s been a perception in some corners that traditional operations aren’t necessary (see a previous article I wrote about this).

However, this neglects the intricate and essential skills that operations bring, particularly as systems scale and become more complex. “Anti-Type C” reflects this misconception that with the advent of cloud technologies, operational skills and tasks are no longer essential. This negligence results in overlooking crucial operational activities.

Other anti-types include treating DevOps purely as a tooling team, rebranding SysAdmin roles without any genuine organisational shift towards DevOps, misplacing Ops tasks entirely onto Dev teams, isolating database administration tasks, and the “Fake SRE” where, despite the title change, operational challenges remain unsolved.

In contrast, positive DevOps topologies emphasise collaboration, shared responsibilities, and effective operational management across Dev and Ops teams.

DevOps Adoption Pathways

Organisations often tread various paths in their DevOps/GitOps adoption journey, each influenced by distinct driving forces and operational dynamics.

While unique in their approach, these pathways converge towards the common goal of integrating development and operations to enhance delivery speed and quality. Whether led by top management directives, operational necessities, or development-led initiatives, each pathway presents its challenges, pitfalls and rewards. The key to evolving is persistence and resiliency whenever pitfalls or evolution stalls.

The above diagram is an illustration of a potential stages in the evolution:

Administrative Lead (Top Down)

Top management decides to adopt DevOps, but they do it without a deep understanding of the processes, culture, and collaboration required. It’s seen more as a trend or buzzword than a strategic choice. This approach might quickly devolve into the “DevOps Team Silo” anti-pattern where a separate DevOps team is created without integrating it into the broader organisation, or, very commonly in tandem with Cloud adoption, a “Dev Don’t Need Ops”.

More conscious management may lead to adopting a “DevOps as an External Service”.
Using DevOps as an External Service allows organisations to swiftly tap into expert DevOps professionals and best practices, typically in a more cost-effective solution. This approach enables companies to centre on their primary products or services while experts manage DevOps, granting them access to the latest tools and technologies. As organisational needs expand, external providers offer more effortless scalability compared to internal hiring and onboarding challenges.

It’s common to see this as a variant of “DevOps Team with an Expiry Date”, acting like a ‘bridge’ to bring Dev and Ops closer. By setting up a temporary team, the organisation can test the waters without committing fully. It can be a way to evangelise and demonstrate the value of DevOps practices internally. If successful, it can pave the way for more integrated collaboration models like Type 1 or 2, although this pattern does not address your “global” cultural challenges as you are only covering team-wide. If you are starting (see previous article)

Development Lead (Dev-Driven)

In this pathway, the push for DevOps comes from the development side, emphasising their role in driving the change. Typically arises with Public Cloud adoption (“Dev Don’t Need Ops”), followed by the recognition that some additional tools/processes are required for Day 2, and start stalling with velocity slowdown and cost ramp up without synergies and skills for operations/day 2.

In the best scenario, you usually get a specific workload (or group of workloads) that are covered by the Type 1 or Type 2 pattern. This comes at the cost of synergies and financial efficiency (with the remaining environment)..

Operations Lead (Ops First)

This signifies that the push for DevOps comes from the operations side, emphasising their role in driving the change, often as a reaction where infrastructure/operations attempt to recover some relevance and importance in the organisation.

Besides the premature/early stages anti-patterns (Fake SRE, Rebranded Sysadmin or Dev and DBA Silos), positives outcomes start to be achieved when Ops as Infrastructure as a Service pattern is adopted, where a team who provides the infrastructure on which applications are deployed and run. This will require some responsibilities and skills transition to the Dev Team (or ensured by Traditional Ops teams), like monitoring, provisioning base configuration (under the provided guardrails), etc. While sacrificing the communication aspects, this is the most accessible way to get some velocity.

With the rising popularity of containers and technologies like Docker and Kubernetes, many organisations see containers as a way to bridge the Dev and Ops divide. Containers provide a clear contract between what developers build and what gets deployed, allowing consistency across environments.

Conclusion

DevOps is not merely a set of tools or processes; it’s a philosophy that emphasises collaboration, agility, and continuous improvement. As highlighted in this article, understanding the nuances of DevOps collaboration patterns and anti-patterns is crucial for successful implementation. The right approach can amplify value delivery, optimise workflows, and bridge the traditional Dev and Ops divide. While there is no one-size-fits-all solution, with the right mindset and commitment, organisations can harness the true potential of DevOps, setting them on a path to more significant innovation, efficiency, and success.

Within the DevOps space, due to the increasing importance of data privacy and protection, ‘DevSecOps’ gained more traction, integrating security considerations right from the development phase, even if sometimes not completely integrated (parallel checks in CI/CD pipelines, for example), GItOps to achieve require a higher level of collaboration/integration as you will see in the Fishbone Ribs dedicated to Architecture and Practices.

As automation tools become more sophisticated, and with the right design tailored for such evolution, we might witness a transition towards ‘NoOps’ or ‘Reduced Ops’. Here, many operational tasks could be automated so that a dedicated operations team may become redundant. However, in my perspective, achieving this state remains a distant aspiration.

Please note that the opinions and views expressed in this article are solely my own and do not represent my employer’s official position or policies. This is a personal commentary based on my experiences and thoughts, and although I aim for accuracy, there may be errors or omissions in the content.

Articles in this series: