Unlocking DevOps Success — Flow at Scale

Author: David Kleinmann (Specialist Lead at Deloitte | Technology & Transformation | Engineering, AI & Data)

DevOps and Team Topologies, Generated by AI

Over the past decade, DevOps has become a standard approach for modern software delivery. Organizations have invested heavily in pipelines for continuous integration and continuous delivery, cloud platforms and automation tools. Yet many transformation initiatives still fail to achieve the expected improvements in speed, stability and developer experience.

A recent interaction with one of our consulting clients in the public sector illustrated this pattern again. The organization had invested substantially in modern DevOps tooling. CI/CD pipelines were established, cloud infrastructure was standardized and engineering teams had access to a broad set of automation and platform services. From a technical standpoint, most requirements for fast delivery appeared to be fulfilled.

Despite this, delivery speed remained below expectations. Features still required multiple handovers before reaching production, and dependencies between teams resulted in long lead times. Engineers spent a significant part of their time aligning with other teams rather than developing and improving their own systems. The increasing coordination overhead led to frustration, even for relatively small changes.

Explanations for this situation can be found in research like Accelerate (1) and the State of DevOps Reports (2) which show that elite technical practices alone don’t result in high performance. Instead, outcomes are also strongly correlated with social and organizational factors such as trust, psychological safety and clarity of responsibility. High-performing teams are not simply better at automation and other technical capabilities. They are better at organizing work and decision-making.

This article argues that the main challenge of DevOps at scale is organizational, not technical. It explores how organizational structure influences flow and how one exemplary approach can help facilitate a discussion on the topic — if used correctly.

When Structure Limits Flow

If technical maturity alone does not explain performance differences, the question becomes: what does?. A growing body of research points toward organizational structure, team boundaries and interaction patterns as important factors influencing how effectively teams deliver software.

Conway’s Law, Generated by AI

Conway’s Law (3) provides an early conceptual idea for this perspective. It suggests that systems mirror the communication structures of the organizations that build them. In practice, architecture often reflects organizational structure. When work must cross multiple organizational boundaries, coordination becomes part of the delivery process itself. Automation can accelerate handovers, but it can’t eliminate the need for them.

Research on DevOps adoption has repeatedly emphasized that organizational and cultural factors play a central role in determining whether DevOps practices succeed. Leite et al. (4) for example built a conceptual map based on reviewing DevOps challenges presented in literature and identified many barriers to DevOps adoption that are not primarily technical but organizational. They point to challenges such as overcoming collaboration and communication barriers and the need for small and loosely coupled teams as playing a key role.

The importance of coordination becomes more visible in large-scale agile development environments. Bjørnson et al. (5) analyse such environments as multi-team systems in which multiple feature teams pursue a shared objective while remaining interdependent. In these settings, work across team boundaries becomes as important as work within individual teams. Their study shows that effective coordination depends on mechanisms such as shared mental models, closed-loop communication and trust between teams.

More recent research has examined how DevOps teams are structured in practice. López-Fernández et al. (6) identify recurring team structures, including different collaboration models between departments and cross-functional DevOps teams. These arrangements differ in how responsibilities and coordination are distributed, which directly affects how effectively organizations can deliver software measured by indicators such as lead time and mean time to recovery.

Further empirical research also suggests that DevOps team formation influences performance outcomes. Korkmaz and Aydin (7) compare DevOps team formations and identify measurable differences in delivery performance and operational reliability. Their findings indicate that most team formations benefit from DevOps adoption but that formations with stronger collaboration and alignment between development and operations roles generally show stronger improvements.

The diversity of these organizational models has also led researchers to examine how DevOps structures can be categorized. Díaz et al. (8) argue that organizations often lack a consistent taxonomy for describing DevOps organizational models, which makes DevOps transformations harder to reason about and compare. Without a shared vocabulary for team structures and collaboration patterns, organizations struggle to systematically design or evolve their team structures.

All things considered, this research suggests that DevOps performance is constrained not only by low maturity of tools but also by inadequate structure. Automation can only amplify the system it operates within. If team boundaries, ownership models, and interaction patterns are misaligned with value delivery, technical improvements will produce diminishing returns over time.

If structure shapes flow, then team design becomes a central variable in DevOps performance. DevOps is often described in terms of CI/CD, automation and other technical practices. At its core, however, it is about reducing handovers, shortening feedback loops, and enabling teams to deliver value autonomously. These goals are not purely technical. They are organizational.

Traditional organizational models separate responsibilities along functional lines. Architecture, development, operations and security capabilities are distributed across distinct units. While this may provide clarity within units, it frequently introduces friction across them and limits delivery speed. Each additional boundary creates delay, and each shared responsibility increases coordination effort.

This is where the structural argument becomes practical. If a team does not have clear end-to-end responsibility for its product within a value stream, it must rely on others to complete its work. The results are longer delivery cycles and diluted accountability. Ownership becomes shared, and shared ownership often translates into unclear ownership. Over time, teams adapt through informal coordination channels, escalation paths or centralized approvals. These adaptations stabilize the system in the short term but increase complexity in the long term.

DevOps, when understood as a capability of the whole organization and not just individual teams, therefore requires teams aligned with value creation rather than technical capabilities alone. It requires boundaries that minimize unnecessary dependencies and interaction patterns that support autonomy instead of constant synchronization. Understanding this relationship between structure and flow reframes the transformation challenge. The core challenge at scale is not whether pipelines are sufficiently mature, but whether teams are designed to support autonomous, value-oriented delivery. This is where deliberate organizational design becomes essential and where approaches can provide a structured way of reasoning about team boundaries, interaction modes, and cognitive load.

Team Topologies as a Design Approach

To help foster a discussion with our client we used a structured approach to team design offered by Team Topologies (9). Rather than prescribing a fixed organizational chart, the approach provides a way to reason about how teams should be shaped and how they should interact to support fast flow and manageable cognitive load.

TeamTopologies fundamental team types (Source: GitHub Team Topologies Team Shape Templates)

The central idea is that teams should be organized around streams of value and that their responsibilities should be bounded in a way that enables autonomy. Team Topologies differentiates between stream-aligned, enabling, complicated subsystem and platform teams. A stream-aligned team is expected to deliver value end-to-end within a clearly defined domain. The remaining supporting team types exist not to fragment ownership, but to reduce complexity. Enabling teams help others to acquire new capabilities. Complicated subsystem teams isolate areas of deep technical specialization. Platform teams provide internal services that reduce duplication and cognitive burden across the organization.

TeamTopologies fundamental interaction modes (Source: GitHub Team Topologies Team Shape Templates)

Equally important are the interaction modes between these teams. The approach differentiates between collaboration, facilitation, and X-as-a-Service interactions. Through collaboration teams can discover new things by working together for a defined period of time. In facilitation, one team helps and mentors another team in order to enable new capabilities or overcome a certain obstacle. Through X-as-a-Service one team consumes something “as a Service” from another team with minimal interaction. The approach emphasizes that unmanaged interaction patterns often become hidden bottlenecks. On the other hand, intentional interaction design allows organizations to balance autonomy with necessary coordination.

The appeal of Team Topologies lies in its explicit focus on flow and cognitive load. It recognizes that teams can’t optimize for everything at once. By clarifying boundaries and expected interaction modes, the approach aims to reduce structural friction and align organizational design with the realities of modern software development.

However, using such an approach does not automatically solve structural problems. Its effectiveness depends on how thoughtfully it is applied and how well it is adapted to the specific organizational context, especially when transformations move beyond isolated teams and attempt to scale. Team Topologies does not just change labels or reporting structures. It changes how work flows through the organization. The most visible impact is often a reduction in coordination overhead. Stream-aligned teams with clearly defined value domains can make more decisions independently and deliver changes faster with fewer handovers or approvals. Platform teams provide reusable capabilities, enabling teams support skill development and collaboration becomes deliberate instead of reactive.

As a result, lead times decrease, feedback loops shorten and incident resolution improves when accountability is clear. Cognitive load also becomes more manageable when teams are not responsible for unrelated components or support tasks and developer experience improves when interaction patterns are intentional. These changes also increase transparency. Clear boundaries make bottlenecks and ownership gaps easier to identify, allowing organizations to address structural issues more directly.

However, Team Topologies is not a blueprint. It requires continuous adaptation to value streams, architecture, and context. The goal is not perfect usage, but improved flow through deliberate and iterative design.

Common Pitfalls in Applying Team Topologies

However, as with everything, Team Topologies can be misapplied and in the discussion with our client we had to navigate some possible pitfalls. It’s easy to adopt its terminology without addressing the structural and cultural conditions required for it to function effectively. As a result, transformational efforts may reinforce the very problems they intend to solve. The approach provides a language and a set of design principles, but it does not replace the need for deliberate organizational change. Without aligning incentives, governance and leadership behavior, structural redesign remains superficial.

One common pitfall is over-engineering the approach. Some organizations attempt to classify every team precisely into one of the defined types and try to document interaction modes exhaustively. Usage of the approach focuses more on taxonomy than on flow. The effort invested in assigning categories outweighs the attention given to reducing dependencies or clarifying ownership. Treating the approach as a rigid blueprint introduces just another form of rigidity and in reality teams can have traits of more than one type and interactions between teams can be short-lived. The purpose of Team Topologies is to guide organizational reasoning, not to enforce a rigid template.

A second pitfall lies in imposing a modern team model onto a historically grown organization without adjusting leadership behavior, decision rights and accountability mechanisms. When approval structures remain unchanged and escalation paths remain centralized, simply renaming teams as stream-aligned or platform-oriented does not change how decisions are made. Informal coordination channels continue to dominate daily work. The visible structure changes, but the operating model does not. In such cases, the organization experiences structural changes without achieving structural improvement. Teams may appear autonomous on paper while still being constrained by legacy governance models, leading to frustration and poor delivery performance. Over time, this gap between formal structure and actual behavior can erode trust in the transformation itself.

A third pitfall is freezing interaction patterns. In reality, organizations are dynamic systems. Teams evolve, domains shift and technical capabilities mature. Collaboration, facilitation and service-oriented interactions are intended as deliberate and often temporary patterns for specific outcomes. They don’t need to be permanent states. Continuous collaboration can reduce team autonomy and increase coordination overhead. Delivery teams may begin to rely on constant cross-team interaction rather than building internal capability. When enabling teams remain embedded indefinitely, knowledge transfers never fully complete and dependencies persist. When platform teams become mandatory intermediaries for all changes, they evolve into centralized gatekeepers. What was intended to reduce friction can unintentionally reintroduce bottlenecks if interaction modes are not periodically reassessed. Over time, these patterns can recreate the same coordination problems that the approach was meant to resolve.

Another significant pitfall emerges when team types are defined without clear boundaries for products and skills. Declaring a team stream-aligned does not automatically define its stream. Without a clearly articulated value domain and the skills required to support it, end-to-end responsibility only exists on paper. Teams remain dependent on external specialists for architectural decisions, security approvals or operational changes. The label suggests autonomy, but the structure does not enable it. Similarly, platform teams without a clearly scoped internal product risk expanding into general support units. They become ticket-processing units rather than product-oriented service providers, increasing cognitive load for both sides and reducing focus. Clear product thinking is essential to prevent platform teams from becoming another form of centralized dependency.

A different pitfall can be to underestimate cognitive load as a constraint. When responsibilities are consolidated without carefully considering complexity, teams become overloaded. They may be stream-aligned on paper but responsible for legacy systems, new feature development, compliance requirements and deep infrastructure concerns simultaneously. The result is not autonomy but exhaustion. The overload can drastically reduce flow because teams can’t realistically manage the breadth of responsibility assigned to them. Without explicit attention to cognitive load, structural redesign may shift bottlenecks rather than eliminate them. In practice, reducing cognitive load often requires simplifying architectures as much as reorganizing teams.

A further pitfall arises when organizations treat Team Topologies as a one-time transformation. The redesign is framed as a project with a defined end date. Once new team charts are published, the organization assumes the work is complete. In practice, organizational design requires continuous calibration. Value streams evolve, architectures change and external constraints shift. If the structure remains static while the system evolves, misalignment gradually reappears. The approach only delivers sustained benefits when it becomes part of an ongoing design discipline.

Underlying all these pitfalls is a shared misunderstanding. Team Topologies is often treated as an organizational restructuring exercise rather than a mechanism for continuously improving flow. The approach does not guarantee performance improvements simply by being used. Its effectiveness depends on whether team boundaries truly reduce unnecessary dependencies, whether ownership is clarified rather than redistributed ambiguously and whether cognitive load is actively managed. Avoiding these pitfalls requires careful considerations. Organizations must continuously evaluate whether their team design aligns with value delivery and architectural reality. Success should not be measured by how accurately teams match predefined categories, but by whether coordination decreases, accountability becomes clearer, and flow improves across the system. Only then organizational design begins to unlock the full potential of the technical capabilities that DevOps initiatives have already established.

Conclusion — Designing for Flow at Scale

As organizations grow, the challenge of DevOps shifts from optimizing individual teams to optimizing the system as a whole. High-performing isolated teams don’t automatically translate into high-performing organizations. At scale, the primary constraint is rarely within teams, but between them.

DevOps has matured as a set of technical practices. Continuous integration, automation and cloud platforms are widely adopted. Yet performance differences between organizations persist. Research and experience converge on a central insight: structure shapes outcomes. If responsibilities are fragmented, ownership is unclear, and interaction patterns are unmanaged -, technical excellence alone will not produce sustainable improvements as automation only amplifies the system it operates in.

DevOps Bridge, Generated by AI

Dependencies accumulate when multiple value streams intersect. Shared platforms, compliance requirements, legacy systems and architectural constraints create interactions that can either enable or inhibit flow. Without deliberate design, these interactions can become sources of delay. Teams may optimize locally while overall lead time across the organization remains unchanged. Designing for flow at scale requires continuous structural alignment, it is not a one-time transformation milestone. It involves clarifying which dependencies are essential and which are accidental, deciding where capabilities should reside and revisiting team boundaries and interactions as products and architectures evolve. The objective is not to eliminate interaction, but to ensure that interaction is intentional, proportional and supportive of value delivery.

Therefore, the essential question for organizations at scale is not whether their pipelines are fast enough, but whether their teams are designed for the way they want to build and operate software today.

About the Author

David studied Industrial Engineering and Management and worked as a software developer in the tourism industry. Before he joined Deloitte in 2017, he helped various clients modernize their approach to software development and operations. His main focus areas include DevOps and SRE.

References/Additional Resources

1. Forsgren, N., Humble, J. and Kim, G. (2018) Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations [Book]. IT Revolution Press.
2. DevOps Research and Assessment (DORA) (2014–2024) State of DevOps / Accelerate State of DevOps Reports [Research report, 2014–2024]. Puppet; Google Cloud.
3. Conway, M. E. (1968) How do committees invent? [Journal article, 1968]. Datamation, 14(4), pp. 28–31.
4. Leite, L., Rocha, C., Kon, F., Milojicic, D. and Meirelles, P. (2019) A survey of DevOps concepts and challenges [Journal article, 2019]. ACM Computing Surveys, 52(6), Article 127. Available at: https://doi.org/10.1145/3359981 (Accessed: 16 February 2026).
5. Bjørnson, F. O., Wijnmaalen, J., Stettina, C. J. and Dingsøyr, T. (2018) Inter-team coordination in large-scale agile development: A case study of three enabling mechanisms [Conference paper, XP 2018]. In: Garbajosa, J., Wang, X. and Aguiar, A. (eds.) Agile Processes in Software Engineering and Extreme Programming (Lecture Notes in Business Information Processing, vol. 314, pp. 216–231). Springer. Available at: https://doi.org/10.1007/978-3-319-91602-6_15 (Accessed: 20 February 2026).
6. López-Fernández, D., Díaz, J., García, J., Pérez, J. and González-Prieto, Á. (2022) DevOps team structures: Characterization and implications [Journal article, 2022]. IEEE Transactions on Software Engineering, 48(10), pp. 3716–3736. Available at: https://doi.org/10.1109/TSE.2021.3102982 (Accessed: 06 March 2026).
7. Korkmaz, H. E. and Aydin, M. N. (2025) An empirical study on performance comparisons of different types of DevOps team formations [Journal article, 2025]. Frontiers in Computer Science, 7, 1554299. Available at: https://doi.org/10.3389/fcomp.2025.1554299 (Accessed: 05 February 2026).
8. Díaz, J., Pérez, J., Alves, I., Kon, F., Leite, L., Meirelles, P. and Rocha, C. (2024) Harmonizing DevOps taxonomies — A grounded theory study [Journal article, 2024]. The Journal of Systems and Software, 208, 111908. Available at: https://doi.org/10.1016/j.jss.2023.111908 (Accessed: 05 February 2026).
9. Skelton, M. and Pais, M. (2019) Team topologies: Organizing business and technology teams for fast flow [Book]. IT Revolution.