paulserban.eu

Writing Edition

Paul Serban

Writing, snippets & book notes

Vol. 2026

Why Cross-Functional Collaboration Fails in Engineering Teams (And How to Fix It)

Uncover the hidden blockers that derail collaboration across teams

Introduction

There is a particular kind of frustration that most senior engineers recognize immediately: the moment a project stalls not because the technology is hard, but because two teams cannot agree on who owns what. A backend service breaks a contract the frontend team didn't know existed. A platform change ships without warning to the three product teams depending on it. A design decision gets made in a Slack thread no one was invited to, and two sprints later, the consequences show up as production incidents.

Cross-functional collaboration - the coordination of engineering, product, design, data, security, and operations toward a shared goal - is one of the most frequently cited challenges in modern software development. It is also one of the most underengineered problems. Teams invest heavily in CI/CD pipelines, observability tooling, and architectural patterns, but the organizational interfaces between teams often receive no formal design at all. They emerge organically, accrete misunderstandings over time, and fail catastrophically at the worst moments.

This article examines why cross-functional collaboration breaks down in engineering organizations. It treats the problem as an engineering challenge - one with identifiable failure modes, concrete root causes, and tractable solutions. Whether you are a senior engineer frustrated by invisible walls between your team and others, or a technical lead trying to understand why a multi-team project keeps slipping, the patterns described here should feel familiar. More importantly, the fixes are practical and deployable without waiting for an organizational restructure.

The Problem: Collaboration Failure Is Structural, Not Personal

A common but mistaken diagnosis of collaboration failures is that they are interpersonal - that the wrong people are in the room, or that individuals are unwilling to cooperate. This framing is almost always wrong, and it leads to interventions (team-building workshops, new Slack channels, better meeting norms) that fail to address the underlying causes. The real failures are structural, and they manifest in predictable ways.

Conway's Law, articulated by Mel Conway in 1968, observes that organizations tend to design systems that mirror their communication structures. The inverse is equally true in practice: when communication structures are dysfunctional, system design suffers correspondingly. An API boundary that is poorly specified often reflects an organizational boundary that is poorly negotiated. A microservice with ambiguous ownership usually maps to a team whose responsibilities were never clearly defined. Recognizing this bidirectional relationship is the first step toward diagnosing collaboration failures correctly.

The structural failure modes tend to cluster around three axes: unclear ownership, misaligned incentives, and inadequate shared context. Each of these is distinct, each manifests differently in daily engineering work, and each requires a different intervention. Teams that conflate them - treating an ownership problem as a communication problem, or an incentive problem as a context problem - spend effort in the wrong places and remain stuck.

Failure Mode 1: Unclear Ownership and the Tragedy of Shared Services

Of all the collaboration failures in engineering organizations, unclear ownership is the most damaging and the most common. When nobody clearly owns a component, a decision, or a domain, work stalls, quality degrades, and accountability becomes impossible to enforce.

The failure mode typically emerges at boundaries: shared libraries, platform infrastructure, data pipelines, integration layers. These are components that multiple teams depend on but that no single team has a mandate to maintain. In practice, they get maintained by whoever has the most urgency at any given moment, which usually means whoever is blocked by a bug. Over time, these components accumulate unreviewed pull requests, inconsistent behavior, and implicit assumptions that only their accidental maintainers understand.

The underlying problem is that shared ownership is not a meaningful concept in software engineering. Shared ownership means that everyone has a right to change something and no one has a responsibility to maintain it. The "everyone owns it" model fails for the same reason that a common resource without governance degrades: individuals optimizing for local goals produce global outcomes that no individual wanted. In software, this manifests as the shared library nobody wants to upgrade, the platform team stretched across forty dependent services, and the integration layer that three teams all modify without coordination.

A more precise model for distributed systems teams is the product ownership model applied at the component level. Each component - including internal platform components, shared libraries, and integration services - should have a named owning team with a published roadmap, an on-call rotation, and a defined API contract. This does not mean other teams cannot contribute; it means one team has final authority and accountability. The distinction between contribution rights and ownership accountability is fundamental.

// Example: A service ownership manifest (stored as code in the repository)
// ownership.yaml or similar, consumed by internal tooling

export interface ServiceOwnership {
  name: string;
  owningTeam: string;
  oncallRotation: string; // Link to PagerDuty / OpsGenie rotation
  slackChannel: string;
  apiContract: string; // Link to OpenAPI spec or equivalent
  consumers: string[]; // Explicit list of consuming teams
  deprecationPolicy: string; // How long before a breaking change goes live
}

const paymentServiceOwnership: ServiceOwnership = {
  name: "payment-service",
  owningTeam: "payments-platform",
  oncallRotation: "https://opsgenie.example.com/teams/payments-platform",
  slackChannel: "#payments-platform-support",
  apiContract: "https://schema.internal.example.com/payment-service/v2",
  consumers: ["checkout-team", "subscriptions-team", "billing-team"],
  deprecationPolicy:
    "Breaking changes require 30-day notice to all consumers via #payments-platform-support and direct async review",
};

Encoding ownership as machine-readable metadata, rather than wiki pages nobody maintains, allows tooling to enforce it. Pull request automation can notify owning teams when their contracts are modified. Dependency graphs become auditable. The invisible becomes visible.

Failure Mode 2: Misaligned Incentives and Local Optimization

Even when ownership is clear, collaboration fails when teams are incentivized to optimize for local metrics that conflict with system-level outcomes. This is not a failure of character - it is a predictable response to how performance is measured and rewarded.

A classic pattern: a product team is measured on feature velocity. A platform team is measured on infrastructure reliability. A security team is measured on vulnerability closure rate. Each team behaves rationally relative to its own metrics. The product team ships fast and introduces technical debt. The platform team gates deployments on stability reviews that slow feature delivery. The security team mandates remediation timelines that conflict with product roadmaps. Every team is "doing its job." The system as a whole moves slowly, and nobody feels responsible for the slowness because their individual metrics look fine.

This is the classic failure mode of local optimization in complex systems, well-described in Eliyahu Goldratt's The Goal and applied to software development in The Phoenix Project by Gene Kim, Kevin Behr, and George Spafford. The theory of constraints predicts exactly this outcome: optimizing individual steps in a process does not optimize the whole process. In software organizations, the constraints are almost always at the handoff points between teams - which is precisely where cross-functional collaboration is most demanding.

The fix requires designing incentive structures that create shared accountability at those handoff points. This does not require eliminating team-level metrics; it requires adding joint metrics that cut across organizational boundaries. A product team and a platform team co-owning a shared deployment frequency metric, for example, creates a natural forcing function for early negotiation instead of late-stage conflict. A security team measured partly on time-to-unblock-engineering alongside vulnerability closure rate changes the conversation from adversarial to collaborative.

One structural pattern that works well at scale is the embedded model combined with explicit service-level objectives (SLOs) that span team boundaries. Rather than having a security team that reviews completed work as a gate, embedding a security-oriented engineer on a product team - or establishing a shared SLO for "time from code to compliant production" - changes the incentive dynamics at the source. The collaboration becomes continuous rather than adversarial.

Failure Mode 3: Missing Shared Context and the Cost of Knowledge Asymmetry

The third failure mode is subtler and harder to see until it causes a serious incident. It arises when teams operate with fundamentally different models of the system they are jointly building and maintaining. Knowledge asymmetry - where one team has deep context about a domain that other teams lack - is inevitable in large engineering organizations. The failure occurs when that asymmetry is not managed deliberately.

A backend team makes an optimization to a shared data model, reasoning correctly within their local context that the change reduces query latency by 40%. The analytics team, whose pipeline depends on the previous schema semantics, is not consulted. The optimization ships. Dashboards go silent. An incident occurs. Post-mortem analysis reveals that neither team was negligent - they simply had no visibility into each other's dependencies. The schema change was not captured in a changelog. The analytics pipeline's dependency was not documented. Nobody knew what nobody knew.

Knowledge asymmetry compounds over time. In young organizations it is manageable; engineers tend to have broad context because the system is small. As organizations scale, specialization increases, domains deepen, and the gap between what any individual team knows and what the full system requires grows rapidly. Without deliberate mechanisms for shared context creation, teams develop inconsistent mental models of the same system. Decisions that look locally rational cause globally incoherent outcomes.

The solution space here is well-established, though infrequently applied with rigor. Architecture Decision Records (ADRs), proposed by Michael Nygard, provide a lightweight mechanism for capturing not just what was decided but why - including the alternatives considered and the forces that drove the decision. When ADRs are stored alongside code, searchable, and referenced in pull requests and incident post-mortems, they create a durable institutional memory that survives team reorganizations and engineer turnover.

# ADR-0042: Adopt Event Sourcing for Order State Management

## Status
Accepted - 2024-11-15

## Context
The orders domain currently uses a mutable state model where order records are
updated in-place. Three teams (fulfillment, billing, analytics) read order state
through different query patterns, and race conditions have caused billing discrepancies
in 12 incidents over the past quarter. The analytics team requires a full audit trail
that the current model cannot provide without expensive CDC (change data capture) setup.

## Decision
We will adopt event sourcing for the orders aggregate. All state transitions will be
represented as immutable events in an append-only event store. Projections will
serve each team's query patterns independently.

## Consequences
- Fulfillment, billing, and analytics teams each own their own projection
- Breaking changes to event schemas require cross-team review via RFC process
- Eventual consistency must be accepted for read models (analytics team confirmed acceptable)
- Onboarding cost increases - new engineers must understand event sourcing patterns

## Alternatives Considered
- CDC with Debezium: rejected due to operational complexity and coupling to DB internals
- Shared read model: rejected - teams have conflicting consistency requirements

The RFC (Request for Comments) process - adapted from its origins in internet standards development and popularized in engineering organizations by companies including Rust, React, and numerous engineering-first organizations - provides a complementary mechanism for cross-team context alignment before decisions are made. Unlike ADRs, which document decisions already taken, RFCs solicit input during the design phase. When an RFC is required for any change that affects more than one team's interface, it creates a forcing function for early coordination.

Failure Mode 4: Inadequate Interface Contracts Between Teams

Beyond ownership, incentives, and context, there is a fourth failure mode that is particularly common in service-oriented architectures: poorly specified interfaces between team-owned systems. Teams that operate through well-specified contracts - API schemas, event formats, SLAs - can work independently with minimal coordination overhead. Teams that operate through implicit, underdocumented interfaces must coordinate constantly, because any change anywhere can break anything else.

This is the core insight behind consumer-driven contract testing, a practice formalized in tools like Pact. Rather than having a provider team guess at what their consumers need, consumer teams define their expectations explicitly as executable contracts. The provider runs these contracts as part of their test suite. When the provider changes its API in a way that violates a consumer's contract, the test fails before anything ships to production. The interface agreement is encoded in executable form, not in documentation that goes stale.

// Consumer-side Pact contract example (simplified)
// The checkout-team defines what they expect from the payment-service

import { Pact, Matchers } from "@pact-foundation/pact";
const { like, term } = Matchers;

const provider = new Pact({
  consumer: "checkout-service",
  provider: "payment-service",
});

describe("Payment Service Contract", () => {
  before(() => provider.setup());
  after(() => provider.finalize());

  it("returns a payment intent for a valid order", async () => {
    await provider.addInteraction({
      state: "a valid order exists with id order-123",
      uponReceiving: "a request to create a payment intent",
      withRequest: {
        method: "POST",
        path: "/v1/payment-intents",
        body: {
          orderId: like("order-123"),
          amount: like(4999),
          currency: term({ generate: "USD", matcher: "^[A-Z]{3}$" }),
        },
      },
      willRespondWith: {
        status: 201,
        body: {
          id: like("pi_abc123"),
          status: term({ generate: "requires_payment_method", matcher: "^requires_" }),
          clientSecret: like("pi_abc123_secret_xyz"),
        },
      },
    });

    // Exercise the consumer client against the mock
    const client = new PaymentServiceClient(provider.mockService.baseUrl);
    const result = await client.createPaymentIntent({
      orderId: "order-123",
      amount: 4999,
      currency: "USD",
    });

    expect(result.status).to.match(/^requires_/);
  });
});

Consumer-driven contract testing shifts the communication burden from synchronous coordination (meetings, Slack threads, design reviews) to asynchronous, executable specification. Teams can move independently with confidence that their interface expectations are verified continuously. Breaking changes surface immediately, before they cause production incidents, and they surface with enough specificity to enable targeted remediation rather than wide-scale investigation.

The practice does require investment: teams must write and maintain contracts, provider builds must run consumer contracts, and the tooling infrastructure must be maintained. The investment pays off rapidly in organizations where interface breakage is a recurring incident pattern - which is most organizations with more than three independently deployed services.

The Collaboration Tax: What Unresolved Failures Actually Cost

Before discussing solutions comprehensively, it is worth being specific about the cost of unresolved collaboration failures. Engineering leaders sometimes treat these problems as chronic low-level friction rather than as acute performance issues. That framing underestimates the cost.

The most visible cost is lead time: the time from a feature's conception to its delivery in production. When collaboration failures require repeated synchronization cycles - a design is reviewed, returned for changes, re-reviewed, escalated because a dependency was missed - lead time increases non-linearly. A feature that would take two weeks in a well-coordinated system takes eight weeks in a fragmented one, not because the engineering work is harder, but because the coordination overhead compounds.

Less visible but equally important is the cognitive cost borne by individual engineers. Context switching between coordination work and technical work is expensive. An engineer who spends two hours per day on alignment - Slack threads, status updates, cross-team meetings, dependency negotiations - loses not two hours of productive time but significantly more, because deep engineering work requires sustained focus that fragmentary interruptions prevent. Research in cognitive psychology consistently demonstrates that task-switching imposes a reorientation cost that accumulates through a workday. Engineering managers who have optimized their teams' codebases while leaving coordination overhead unaddressed have optimized the wrong bottleneck.

The least visible cost is attrition. Experienced engineers who have built mental models of good engineering environments recognize friction caused by organizational dysfunction. When the source of daily frustration is clearly structural rather than technical, senior engineers leave - and they leave for organizations where the structural problems have been solved. The talent cost of chronic collaboration failure is real, and it is borne disproportionately at the senior levels where it is most expensive.

Practical Solutions: Engineering the Organizational Interface

With the failure modes clearly articulated, the solutions follow logically. The goal is to treat team interfaces as first-class engineering artifacts - subject to the same design discipline, versioning, and testing rigor applied to technical systems.

Define team topologies explicitly. Matthew Skelton and Manuel Pais's Team Topologies framework provides a practical vocabulary for this. Their model distinguishes stream-aligned teams (delivering value in a specific domain), platform teams (reducing cognitive load for stream-aligned teams), enabling teams (helping stream-aligned teams adopt new practices), and complicated-subsystem teams (owning components requiring deep specialist knowledge). Naming the topology of each team clarifies expected interaction modes. A platform team should minimize the cognitive load it places on stream-aligned teams; an enabling team should work itself out of a job by building capability. Unclear topology produces unclear collaboration expectations.

Establish interface contracts and version them like APIs. Every inter-team dependency - API, event schema, data contract, platform capability - should have a published contract, a versioning scheme, and a deprecation policy. Changes to contracts should follow the same review process as public API changes. The deprecation policy should be designed to give consuming teams enough lead time to adapt without blocking the providing team's roadmap.

Run cross-functional incident reviews with blameless post-mortems. The post-mortem process, when practiced rigorously and consistently, is one of the most effective mechanisms for surfacing coordination failures. A blameless post-mortem asks what in the system - technical or organizational - allowed the incident to occur, and what changes would prevent recurrence. When post-mortems consistently surface "team X wasn't notified of change Y" or "the dependency on service Z wasn't visible," they build an empirical record of coordination failures that can inform structural investment. The SRE book published by Google (Beyer et al., 2016) remains the canonical reference for this practice.

Make dependencies visible at the organizational level. Most engineering organizations have detailed dependency graphs at the service level and almost no visibility at the team level. Tooling that maps which teams depend on which services, how those dependencies have evolved over time, and which teams are most central in the dependency graph provides organizational intelligence that informs staffing decisions, platform investment priorities, and risk management. Building this visibility from existing data (deployment manifests, service mesh telemetry, CODEOWNERS files) is tractable with modest engineering investment.

Invest in asynchronous coordination mechanisms. Much collaboration overhead comes from synchronous coordination - meetings and real-time discussions - being used as the primary mechanism for alignment on decisions that do not require real-time interaction. RFCs, ADRs, design documents, and asynchronous comment threads on proposals move the alignment work out of calendars and into durable, searchable artifacts. This is not an argument against meetings; some alignment genuinely requires real-time discussion. It is an argument for reserving synchronous time for genuinely synchronous work, and for designing default-async processes for the majority of coordination events.

Trade-offs and Pitfalls of Collaboration Tooling

Process improvements and collaboration tooling are not universally beneficial. Like any engineering intervention, they introduce trade-offs and can fail in predictable ways if applied without judgment.

The most common failure mode of formal collaboration processes is bureaucratic overhead without corresponding value. An RFC process that requires a thirty-page template for every cross-team change will be ignored or gamed. A contract testing setup that takes two days to bootstrap and an hour to maintain per change will be abandoned when schedules tighten. The overhead of coordination tooling must be proportional to the cost of the coordination failures it prevents. For a small organization with five teams and low interface churn, lightweight mechanisms (a shared design doc template, a weekly cross-team sync) may be entirely sufficient. For a large organization with fifty teams and high interface volatility, more structural investment is justified.

Tooling can also create a false sense of coordination. Teams that maintain elaborate ownership manifests and API contracts can still fail to collaborate effectively if those artifacts are not actually consulted during decision-making. Process documentation and tooling are inputs to collaboration, not substitutes for it. The goal is not compliance with a process; it is actual alignment between teams on shared concerns. This distinction matters because it implies that any collaboration process must be designed around how engineers actually work, not around how a process designer thinks they should work.

Finally, some coordination overhead is genuinely necessary and should not be engineered away. When teams share high-stakes infrastructure, when changes are irreversible, or when the blast radius of a mistake is large, synchronous review and explicit sign-off from stakeholders is appropriate. The goal is not frictionless coordination but correctly calibrated friction - enough to prevent costly mistakes, not so much that it prevents forward movement.

Best Practices: A Framework for Durable Cross-Functional Collaboration

The following practices reflect the combined lessons of the failure modes and solutions discussed above. They are presented in rough order of impact, though context matters and the right starting point depends on which failure mode is most acute in a given organization.

Make ownership legible and machine-readable. Define a canonical ownership model for all components and publish it in a format that tooling can consume. GitHub's CODEOWNERS file is a minimal starting point; richer formats allow encoding on-call rotation, API contracts, and consumer lists. Automate notifications and routing based on this data.

Establish API contracts between teams and enforce them in CI. For every inter-team service dependency, define a consumer contract and run it in both the consumer's and provider's CI pipeline. Treat a contract violation as a build failure. This shifts interface negotiation from incident response to design time.

Adopt the RFC process for cross-team changes. Define a threshold - any change that affects the public interface, SLA, or data model of a service used by more than one team - above which an RFC is required. Publish RFCs in a shared, searchable location. Archive decisions with their rationale.

Instrument inter-team handoffs explicitly. Treat team boundaries as observable system boundaries. Instrument them with the same care applied to service boundaries in production systems - latency, error rate, and throughput at the interface level make coordination failures visible in data rather than only discoverable through incident post-mortems.

Run regular cross-team architecture reviews. A monthly or quarterly cross-team architecture review, focused on the evolution of inter-team interfaces and shared infrastructure, provides a structured venue for surfacing concerns before they become incidents. The goal is not to gatekeep changes but to ensure that teams with relevant context have visibility into what is changing.

Align incentive structures to cross-team outcomes. Identify two or three joint metrics that matter to teams with the most significant dependencies. Make those metrics visible on shared dashboards. Include them in planning discussions. Over time, shared metrics create shared accountability that changes the collaboration dynamic from adversarial to cooperative.

Analogies and Mental Models

Cross-functional collaboration in engineering organizations is structurally similar to distributed systems coordination. The teams are the nodes; the interfaces between them are the communication channels; the collaboration failures are the network partitions, message loss, and semantic mismatches that distributed systems engineers spend their careers managing.

This analogy is useful because it borrows a mature mental model. In distributed systems, engineers do not expect coordination to be free or failure-free. They design for graceful degradation. They define explicit consistency guarantees. They build observability into communication channels. They treat interface contracts as first-class artifacts. Applied to organizational design, the same principles hold: design for graceful degradation (what happens when a team is unavailable?), define explicit consistency guarantees (how quickly will consumers be notified of breaking changes?), build observability into handoffs, and treat team interfaces as first-class artifacts.

A second useful mental model comes from urban planning. A city whose road network was never planned - where streets grew organically from foot paths - is navigable but inefficient. Adding new roads is expensive because existing infrastructure is entangled. In contrast, a city with a planned grid can extend its infrastructure predictably. Software organizations that grow their collaboration structure organically accumulate the organizational equivalent of spaghetti roads. Redesigning them is painful but ultimately cheaper than continuing to navigate the maze.

The 80/20 Insight

If forced to identify the single intervention that resolves the majority of cross-functional collaboration failures, it is this: make team interfaces explicit and machine-readable. Most collaboration failures trace back to interface ambiguity - somebody changed something they didn't know someone else depended on, or nobody was sure who owned a decision, or a contract change was undiscussed because the contract was never written down.

When team interfaces are explicitly specified - ownership manifests, API contracts, deprecation policies, consumer lists - the coordination failures that depend on ambiguity cannot occur. What remains is the harder class of failures: misaligned incentives and missing context. These require the more involved interventions described above. But the majority of recurring, day-to-day collaboration friction in most engineering organizations is directly traceable to interface ambiguity, and that problem is tractable with modest, systematic investment in tooling and process.

Key Takeaways

  1. Diagnose before intervening. Cross-functional collaboration fails along three distinct axes - unclear ownership, misaligned incentives, and missing shared context. Identify which failure mode is dominant before choosing a solution.

  2. Encode ownership as code, not wiki. Machine-readable ownership manifests, enforced by CI tooling and PR automation, are durable. Wiki pages go stale. Automate the visibility of who owns what.

  3. Adopt consumer-driven contract testing for high-value service interfaces. For interfaces that cross team boundaries and have a history of breakage, executable contracts in CI provide continuous, low-overhead alignment.

  4. Use RFC and ADR processes for cross-team decisions. Asynchronous, structured decision documentation reduces meeting load, creates institutional memory, and ensures teams with relevant context are consulted before consequential changes ship.

  5. Instrument team boundaries as observability surfaces. Treat inter-team handoff points as observable system boundaries. Latency and error rates at team interfaces make collaboration failures visible in data, enabling systemic improvement rather than one-off incident response.

Conclusion

Cross-functional collaboration fails because teams are asked to coordinate at scale without the structures that make coordination tractable. The failures are structural, predictable, and - critically - fixable. They do not require organizational restructuring, personality changes, or new culture initiatives. They require the same discipline applied to technical systems: explicit interfaces, observable behaviors, clear ownership, and incentive structures aligned to system-level outcomes.

The engineering organizations that have solved this problem at scale share a common approach. They treat team interfaces as first-class artifacts, subject to the same design rigor as public APIs. They invest in tooling that makes ownership, dependencies, and contracts visible and machine-readable. They design coordination processes that are proportional to the cost of coordination failures. And they measure outcomes at the system level, not just the team level.

None of this is technically difficult. Most of it can be started by a single team, without waiting for organizational consensus. The practices described in this article are composable and incrementally deployable. Begin with the most acute failure mode, apply the corresponding fix, and measure the outcome. The compounding effect of well-designed team interfaces, like the compounding effect of well-designed technical interfaces, is significant and durable.

References

  1. Conway, M. E. (1968). "How Do Committees Invent?" Datamation, 14(5), 28-31.
  2. Skelton, M. & Pais, M. (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press.
  3. Kim, G., Behr, K., & Spafford, G. (2013). The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win. IT Revolution Press.
  4. Goldratt, E. M. & Cox, J. (1984). The Goal: A Process of Ongoing Improvement. North River Press.
  5. Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (Eds.) (2016). Site Reliability Engineering: How Google Runs Production Systems. O'Reilly Media. Available at: https://sre.google/sre-book/table-of-contents/
  6. Nygard, M. (2011). "Documenting Architecture Decisions." Blog post. https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions
  7. Pact Foundation. Pact Documentation. https://docs.pact.io/
  8. Richardson, C. (2018). Microservices Patterns: With Examples in Java. Manning Publications. (Chapter on service collaboration patterns.)
  9. Newman, S. (2021). Building Microservices: Designing Fine-Grained Systems (2nd ed.). O'Reilly Media. (Chapters on inter-service communication and team organization.)
  10. Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press. (Evidence-based analysis of how organizational structure affects software delivery performance.)