Box: Scaling Cross-Team Architectural Decisions with ITDAG
Problem + constraints
As Box grew, architectural decisions kept happening inside individual team and domain silos — a reasonable default when teams are small enough that "just ask the other team" works informally. At Box's scale, that informal default stopped working: teams could move fast within their own boundary, but nobody had visibility into decisions being made in adjacent systems that their own service depended on. Cross-system dependencies were effectively invisible until they surfaced the hard way — during an incident, when it was already too late to have designed around them. Security, Legal, and Compliance reviews compounded the problem by entering late in the process, at implementation or launch time, turning what should have been early input into a last-minute bottleneck that stalled already-built work instead of shaping it before it existed.
The organizational constraint was that Box couldn't solve this with more process alone — a heavyweight, mandatory review gate risks becoming the thing every team routes around, and a purely voluntary one risks being ignored by exactly the teams whose decisions most need cross-system visibility.
Solution
Box built ITDAG (a cross-domain architecture review and collaboration forum) with a specific design goal: force design alignment to happen before implementation, not after an incident reveals the gap.
- A lightweight, structured review model — not a heavyweight sign-off gate, but a forum where cross-system architectural decisions get surfaced and discussed before teams commit to an implementation path, so dependencies and risks are visible to affected teams while the decision is still cheap to change.
- Deliberate placement of Security/Legal/Compliance earlier in the lifecycle, turning what had been a late-stage bottleneck into upfront input that shapes the design instead of gating the launch.
- Evolution from gate to community of practice. ITDAG didn't stay a checkpoint teams passed through — engineers started actively contributing ideas, challenging assumptions, and shaping architectural standards through it, turning it into an ongoing forum rather than a one-time review step per project.
Box's own framing of the outcome: the cultural shift — engineers treating cross-team architectural alignment as a shared practice rather than a compliance step — has mattered more than any single process improvement the forum introduced.
What to steal
- The failure mode to design against is "the dependency only becomes visible during the incident that it caused." That's a specific, checkable symptom of decisions being made in silos — if the first time a team learns about a cross-system dependency is during an outage retro, the review process (or lack of one) is the root cause, not the specific technical decision that triggered the incident.
- Late-stage compliance review is a symptom of process ordering, not a fact of life. Moving Security/Legal/Compliance input earlier didn't remove the need for their review — it changed when that review shapes the outcome. A review that happens after the system is built can only ever say "redo this"; the same review earlier can say "here's what to avoid" while it's still cheap.
- A review forum has to earn adoption, not mandate it, to avoid becoming a bottleneck itself. Box's own description — "lightweight," evolving into a "community of practice" rather than staying a gate — is the tell that this worked because engineers found it useful, not just because it was required. A mandatory review step that nobody wants to attend just becomes the next thing that slows launches down, which is the exact problem it was meant to solve.
- Watch for the moment a process shifts from gate to community — that's the signal it's actually working, versus merely being tolerated. If a review forum stays purely a checkpoint people pass through as fast as possible, it hasn't achieved what Box describes.
Engineering Lens
This case study is a reminder that not every scaling problem at Principal altitude is a systems problem — some of the highest-leverage architectural work is designing the process by which architectural decisions get made, especially once an org is too large for "just ask around" to reliably surface cross-system risk. The specific failure Box was solving — hidden dependencies surfacing only during incidents — generalizes past any one company: it's what happens whenever the org's decision-making structure hasn't kept pace with its system's actual coupling. In an architecture review, the sharp question this case study suggests isn't about any particular design, it's meta: "how would a team building this even know if it conflicts with something another team is building right now?" If the honest answer is "they wouldn't, until it breaks," that's an architecture-process gap as real as any technical one, and it's squarely Principal-level territory — this is the kind of structural fix a Principal engineer proposes and champions across teams, not something any single team can build for itself, since by definition it has to span the teams whose silos are the problem.