Working With (and Around) Other Teams' Code

Nobody Owns the Whole Stack

Article 1 of this series introduced monorepo culture and code review scrutiny tracking blast radius rather than line count. What that article didn't fully unpack is the organizational side of the same fact: a monorepo makes every team's code technically reachable by every engineer, but "technically reachable" and "yours to change confidently" are very different things. A frontier lab's training stack routinely spans a data infrastructure team, a scheduler/platform team, a distributed training framework team, and multiple model-research teams — and the code you depend on daily is disproportionately likely to have been written by people who don't sit anywhere near you.

Why the Codebase Looks Like the Org Chart

Melvin Conway's 1968 paper, later popularized as "Conway's Law," observed that organizations design systems that mirror their own communication structure — teams that talk to each other easily produce tightly-integrated code, and teams that don't produce code with hard boundaries between them, regardless of what the ideal architecture would look like on a whiteboard. In a frontier lab, this shows up concretely: the scheduler and the training framework tend to have a clean, well-documented interface precisely because the platform team and research teams talk constantly, while two research teams that rarely coordinate often end up with duplicated, subtly incompatible utility code, even when a shared implementation would be objectively better engineering.

Ownership as an Enforced Mechanism, Not a Suggestion

Potvin & Levenberg's Google monorepo paper — already cited in Article 1 of this series — describes exactly how ownership scales inside a single giant repository: per-directory owners files that name who must review a change before it merges, enforced automatically by the code review tooling rather than left to social convention. This is the practical answer to "whose code is it, really" in a monorepo: ownership isn't about who's allowed to read or technically edit a file, it's about whose approval is required before an edit becomes real, and it exists specifically so that the blast-radius-based review scrutiny from Article 1 has someone with real context actually applying it.

A Confident Diff Is Not the Same as a Welcome One

The single most common cross-team friction point is an engineer making a change to someone else's code that is technically correct but organizationally unwelcome — bypassing context the owning team has and you don't, such as a subtle reason a seemingly-dead code path is actually load-bearing for a use case you've never seen. The etiquette that avoids this is simple to state and easy to skip under time pressure: tag the listed owner early, explain the change's motivation rather than just its diff, and be explicit about whether you're proposing a change for them to make, or asking permission to make it yourself. This is the direct organizational counterpart to Article 3's debugging instinct of shrinking scope before acting — here, shrinking your assumption of understanding before touching code outside your usual boundary.

The Cost of Depending on Someone Else's Code

Sculley et al.'s "Hidden Technical Debt in Machine Learning Systems" — cited in Articles 2 and 5 of this series for configuration and kernel maintenance debt — devotes a specific section to what it calls "glue code" and "dependency debt": the tendency for teams to bend their own code around another team's package or API's quirks, accumulating fragile adapter layers that break whenever the upstream team changes something they had every right to change, because it was never a documented contract between the two teams in the first place. Recognizing this pattern is the first step to avoiding it — a clean, minimal, explicitly-versioned interface to another team's code is worth the upfront design cost every time it prevents a break during someone else's unrelated refactor.

Naming How Two Teams Actually Work Together

Skelton & Pais's book Team Topologies names three recurring interaction modes between teams that map cleanly onto frontier-lab reality: collaboration (two teams working closely and temporarily on a shared, evolving problem — common early in a new training framework's life), X-as-a-Service (one team consumes another's clearly-defined API or platform with minimal ongoing coordination — the healthy long-term state for a mature scheduler or data pipeline), and facilitating (one team actively helps another ramp up on a technology, temporarily, with the explicit goal of no longer being needed). Naming which mode a given cross-team relationship is actually in — rather than defaulting to constant ad hoc collaboration — is often the single clearest fix for a chronically friction-heavy team dependency.

Real Scenario Walkthroughs

Readiness Checklist

⚠️ What's Missing or Uncertain

Where This Series Goes Next

Article 8 pulls every prior article in this series together into a single, connected walkthrough: shipping one real experiment from idea to merged PR — writing the training code (Article 2), requesting the compute (Article 4), debugging it when it breaks (Article 3), and navigating review from a team whose code you touched along the way (this article).

🎥 Recommended Videos

🧭 Closing — Ownership Is a Coordination Tool, Not a Fence