At the large US technology company, no single team controls the entire system. A feature that touches payments, identity, and platform teams requires coordination across three codebases, three on-call rotations, and three sets of priorities. Getting technical alignment across teams without creating bureaucratic overhead is an active engineering problem.
Why Cross-Team Alignment Fails
The common failure modes, in order of frequency:
Misaligned interfaces. Team A implements an API that Team B needs to consume. Team A’s API design reflects Team A’s data model; Team B’s consumption patterns don’t fit naturally. The integration works, but it’s awkward — too many calls, wrong granularity, missing context. This could have been avoided if both teams reviewed the API design before implementation.
Duplicate solutions. Two teams independently build caching layers, notification services, or configuration systems. Both work. Neither team knows the other is doing it until someone proposes standardising on one. Now there’s a migration project.
Implicit dependencies. Team A relies on a behaviour of Team B’s system that isn’t documented as a contract — a side effect, a timing guarantee, an undocumented API field. Team B changes the behaviour; Team A’s system breaks. Nobody was at fault except the lack of a documented contract.
The architecture tax. Decisions made by early teams become constraints on later teams. The service mesh was set up by the platform team; all services are expected to use it. The event schema was established for the first three services; the tenth service fits awkwardly. Without active architectural governance, early decisions accrete as implicit mandates.
What Works: Lightweight Coordination
Heavy governance — architectural review boards, mandatory approval chains, multi-week RFC processes — creates its own problems: slow decisions, teams routing around the process, resentment of overhead.
The approaches that work at scale are lightweight by design.
Architecture Decision Records (ADRs) are a log of significant technical decisions with their context, options considered, and rationale. The format is simple:
| |
ADRs serve two purposes: they capture the reasoning at decision time (so future readers understand why, not just what), and they reduce re-litigation of settled questions. “We decided this in ADR-042” is a faster conversation than re-running the analysis from scratch.
Working groups for cross-cutting problems. A working group is a temporary, time-bounded group of engineers from affected teams that owns a specific decision. Not a committee, not a standing body — a group that forms to answer one question and dissolves when the answer is documented.
The secret to effective working groups: they produce a specific artifact (an ADR, a design document, a prototype, an RFC), not ongoing meetings. A working group that meets forever without producing a decision is a committee. A working group that produces a decision and closes is useful.
Architecture forums for visibility and review. A recurring forum (biweekly worked well at one company) where teams share significant technical decisions before they’re finalised. Not approval-gated — teams aren’t blocked on presenting here. But sharing designs widely before implementation catches duplicate solutions, surfaces API consumers with opinions, and distributes architectural knowledge.
The key design choice: the forum is advisory, not mandatory. Teams can proceed without presenting if the change is minor or urgent. But teams that consistently skip the forum lose access to the peer review that makes their systems better.
The API Contract Problem
The most common source of integration failures: teams don’t document what is and isn’t part of their API contract.
An API contract includes:
- The fields that are guaranteed stable (removing them is a breaking change)
- The fields that are provisional (consumers shouldn’t rely on them)
- The behaviours that are guaranteed (idempotency, ordering, retry-safety)
- The performance guarantees (SLA, rate limits)
An API contract does not include:
- Internal implementation details
- Undocumented fields that happen to be useful
- Timing behaviours that aren’t explicitly promised
Getting teams to maintain explicit contracts is harder than it sounds. The overhead is real. The approach that worked: consumer-driven contract testing. Consumers write tests against their expectations of the API; providers run those tests as part of their CI. If a provider change breaks a consumer’s test, the provider knows before shipping.
This creates a contractual relationship backed by automation rather than documentation alone. Teams can change their implementations freely as long as the consumer tests pass.
When Alignment Breaks Down
Sometimes alignment fails despite good processes. The failure points to look for:
Incentive misalignment. Team A is measured on their system’s availability; the integration with Team B creates reliability risk. Team A avoids deep integration to protect their metrics. The fix is organizational, not technical: shared SLOs for cross-team dependencies, or product-level metrics that span team boundaries.
Priority divergence. Team A needs a feature from Team B’s API; Team B has three quarters of work ahead of them with no room. Team A builds around the gap; Team B never ships the feature; the workaround becomes permanent. The fix: escalation path for cross-team dependencies that are blocking product delivery. These shouldn’t sit invisible in team backlogs.
Architecture drift. Teams converge on different solutions for the same problem class — one team’s retry strategy, another team’s completely different approach. Neither team knew the other was solving it. The fix: architecture forum visibility for cross-cutting decisions before implementation.
The Thing That Doesn’t Scale
The one coordination mechanism that doesn’t scale: a single person (the “chief architect,” the “platform lead”) as the synchronisation point for all technical decisions.
At small scale (< 30 engineers), this can work because the person is reachable and has context. At larger scale, they become a bottleneck, decisions queue up waiting for their review, and teams route around them out of frustration.
Distribute architectural authority. Create forums and processes that let teams coordinate laterally, without routing through a central authority. The role of architectural leadership at scale is to maintain the forum, curate the ADR log, and resolve genuine conflicts — not to approve every technical decision.
Cross-team technical alignment is a communication and incentive problem as much as it’s a technical one. The practices that help — ADRs, working groups, contract testing, architecture forums — succeed because they distribute information and reduce the cost of coordination, not because they increase oversight. Lightweight coordination that teams actually use beats heavy governance that teams route around.