Architecture/CaseStudies/box-itdag-architectural-decision-making

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.

Principal Engineer 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.

Reel Script

Setup: As Box grew, architectural decisions were made team-by-team in silos — fast for each individual team, but nobody had visibility into decisions being made in systems they depended on, and Security/Legal/Compliance review only entered the picture late, at launch time.

Concept walkthrough: Walk through the actual failure pattern this created: cross-system dependencies staying invisible until an incident forced them into view, at which point it was too late to have designed around them cheaply. Then introduce ITDAG as the structural fix — a lightweight forum designed to surface those decisions and get compliance input while a design is still cheap to change, not after it's built.

Real example / case study tie-in: Trace how ITDAG's role changed over time — starting as a review checkpoint, evolving into a community of practice where engineers proactively bring ideas and shape shared architectural standards, rather than just clearing a gate to ship. That evolution is the evidence the forum solved the actual problem rather than just relocating the bottleneck.

Tradeoffs & alternatives: Contrast a heavyweight, mandatory architecture review board (thorough, but the kind of gate teams learn to route around or rubber-stamp through) against a purely voluntary "ask around" culture (fast, but exactly the failure mode Box started with) — ITDAG's lightweight-but-structured middle path is a deliberate bet that a forum has to be useful enough to attract voluntary engagement, not just mandatory enough to force it.