Air traffic controllers don't fly planes. They prevent collisions. Every team needs someone who sees the whole system and decides where independence helps and where coordination is necessary. This role exists everywhere, not just in engineering.
Christian Battaglia
February 20, 2026
18 min read
This isn't just an engineering problem. But engineering makes it visible first.
Year 1: 10 engineers. Features ship independently. Velocity is high.
Year 2: 20 engineers. Features require coordination. Velocity plateaus. "We need better process," someone says.
Year 3: 40 engineers. Every change cascades across teams. Your best people are coordinating, not building.
Output went up 30%. Headcount went up 300%. Where did the rest go?
Coordination overhead. And it happens in every function.
DORA's research program, the longest-running academically rigorous investigation of software delivery performance (six years, 31,000+ professionals), found that the teams that can test, deploy, and change systems without dependencies on other teams require little communication to get work done1. The teams that can't spend their weeks coordinating instead of building.
Randy Shoup, formerly Engineering Director at Google, put it concretely: Google's Datastore service is "one of the largest NoSQL services in the world, and yet it is supported by a team of only about eight people, largely because it is based on layers upon layers of dependable services built upon each other."1 Eight people running one of the largest services on the planet. Not because they're 10x engineers. Because someone designed the boundaries so they could operate independently.
That someone is the ATC.
Atlassian's 2025 State of Developer Experience report surveyed 3,500 developers across six countries and found a striking paradox: developers save roughly 10 hours per week using AI tools, then lose 10 hours per week to organizational inefficiencies2.
Not to coding problems. To finding information, adapting to unfamiliar systems, context switching between tools, and collaborating with other teams2.
Notice what's absent from the top friction points: the actual work. The work itself isn't the bottleneck. The coordination around the work is.
Cortex's 2024 State of Developer Productivity report found the same pattern from the management side: "gathering project context" and "waiting on approvals" tied at 26% each as the largest productivity leaks3. When 58% of engineering leaders report losing 5+ hours per developer per week to unproductive work, and the top causes are context-gathering and approval-waiting, you're looking at a missing ATC3.
Someone should have designed the system so that context is findable and approvals aren't bottlenecks. Someone should be looking at the whole picture and asking: why does this team need to wait on that team?
Here's the thesis: the ATC role isn't an engineering role. It's a universal role that every function needs.
The ATC is the person who sees the whole system and makes judgment calls about where independence helps and where coordination is necessary. In engineering, we've started naming it: platform engineering, technical leadership, architecture. In other functions, the role usually exists informally or doesn't exist at all.
The tradeoff: Shared infrastructure (consistency, less duplication) vs team independence (speed, autonomy).
What the ATC does: Decides which services share a database and which own their data. Chooses where to centralize authentication and where to let teams deploy independently. Designs interfaces so teams don't wait on each other.
When the ATC is missing: "Simple" changes cascade across 6 systems. Engineers spend 40% of their time in alignment meetings. New hires take months to become productive because nobody can explain how the pieces fit together.
The tradeoff: Standardized playbook (consistency, training efficiency) vs territory-specific approaches (relevance, speed).
What the ATC does: Decides which parts of the sales motion are standardized (pricing, contracts, demo flow) and which are customized per territory or segment. Ensures AEs aren't competing on the same accounts. Designs handoffs between BDR → AE → SE → implementation so deals don't stall.
When the ATC is missing: Territory conflicts. Competing discounts on the same prospect. Deals stalling in handoffs because nobody designed the interface between roles. Implementation surprises because sales promised something engineering can't deliver.
The tradeoff: Unified brand (consistency, recognition) vs regional/campaign autonomy (speed, relevance).
What the ATC does: Decides which brand elements are centralized (identity, messaging framework, compliance) and which campaigns run independently (regional promotions, channel-specific content). Designs systems so marketing teams can launch without waiting on engineering.
When the ATC is missing: Campaigns wait 12 weeks for a landing page because marketing can't configure without engineering. Brand inconsistency across regions. Competing campaigns cannibalizing each other's audience.
The tradeoff: Shared roadmap (alignment, cross-product coherence) vs independent shipping (speed, team ownership).
What the ATC does: Decides which product features share infrastructure and which ship independently. Makes dependencies explicit during planning instead of discovering them mid-cycle. Ensures Product A's roadmap doesn't silently depend on Product B's timeline.
When the ATC is missing: Planning cycles become negotiation theater. Product teams block each other without knowing it. The roadmap looks clean but execution reveals invisible dependencies everywhere.
The tradeoff: Unified operating model (efficiency, standards) vs business unit autonomy (speed, context-specific decisions).
What the ATC does: Decides which processes are standardized across the organization (compliance, reporting, HR) and which business units run independently. During acquisitions, determines what integrates immediately (auth, SSO) and what stays independent (product features, team structure).
When the ATC is missing: Acquisitions take 18-24 months to integrate because nobody decides what should merge and what should stay separate. Academic studies consistently show approximately 70% of M&A deals fail to achieve their intended strategic goals, and 83% of practitioners who've experienced failed acquisitions cite integration as the primary cause4. The ATC is often the missing role.
Every pattern for increasing independence creates new problems.
Event-driven architecture? Duplicate data. Dropped events. Microservices? 47 services, nobody knows what talks to what. Regional marketing autonomy? Brand inconsistency. Territory-specific sales? Pricing conflicts and account overlap. Independent P&Ls? Duplicated infrastructure, missed cross-sell.
The ATC doesn't pick "independent" or "coordinated." They pick the right tradeoff for each boundary.
Ruth Malan put it sharply: "If the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins."5 That applies to every system, not just software. Your org chart, reporting structure, and approval chains determine how fast things move. The ATC designs those boundaries intentionally.
Team Topologies research found that teams managing cognitive load effectively achieved a 25% reduction in context switching and a 20% increase in productivity6. One 400-engineer organization saved €8 million annually by eliminating just one hour of daily blocking per engineer6. Spotify learned the same thing: a 2023 peer-reviewed study found "surprisingly many" technical dependencies constraining squad autonomy across 10,000+ components and 500+ squads7. The answer wasn't more independence. It was better boundary design.
Across every function, the ATC does five things:
1. Sees the whole system. They carry context from every team. They know the CMO's market window, the CSO's integration timeline, the engineer's deployment constraint, and the CEO's acquisition strategy; all at the same time. No single team has this view.
2. Designs boundaries. They decide where teams operate independently and where they coordinate. These aren't technical decisions. They're organizational decisions with technical, commercial, and strategic implications.
3. Makes tradeoffs explicit. Instead of letting dependencies form accidentally, the ATC names them. "This requires coordination; here's the cost. This can be independent; here's the risk." Every team benefits from that clarity.
4. Prevents collisions. When two teams are about to build conflicting things, the ATC spots it early. When a sales commitment conflicts with an engineering constraint, the ATC surfaces it before it becomes a crisis.
5. Does the actual work. This is the one most organizations get wrong. The ATC isn't a coordinator. They're a practitioner who coordinates because they're in the work, not above it.
Here's where organizations make the most expensive mistake: they hire a consultant to "design the architecture," bring in a contractor to "set up the platform," or create a dedicated "coordination role" whose sole job is connecting teams.
All three fail for the same reason: the ATC's judgment comes from doing the work, not observing it.
A contractor designs boundaries and leaves. They don't live with the consequences when the event bus starts dropping messages at 2 AM. They don't feel the pain when the "clean" API design creates three extra handoffs for every feature. They optimize for elegance because they won't be around for maintenance.
A pure coordinator (program manager, scrum master, architecture review board) sits in meetings and draws diagrams. Their understanding of the system is secondhand. They know what teams told them in status updates, not what actually happens when code ships. Their boundary design becomes theoretical because it's disconnected from ground truth.
The ATC has to be someone doing the work. The VP Engineering who still reviews database migrations and writes infrastructure code. The VP Sales who still closes deals, not just reviews pipeline. The CMO who still runs campaigns, not just approves them. The CPO who still talks to customers, not just reads NPS dashboards.
Why? Because the work is where you learn which boundaries are real and which are imaginary. The engineer who ships code knows that the "simple API call" actually requires 3 teams to coordinate. The salesperson who closes deals knows that the "standard integration" actually takes 6 months. The marketer who runs campaigns knows that "self-serve" actually requires an engineering ticket.
That ground truth is what makes the ATC's boundary design relevant. Without it, you get architecture astronauts: people who design beautiful systems they've never operated. You get coordination theater: meetings about alignment that don't produce clarity.
The ATC's coordination stays relevant because it's informed by today's reality, not last quarter's architecture diagram. They notice when a boundary that made sense six months ago is now creating friction because the product evolved. They feel the pain personally when their own design choices slow teams down.
This is also why the role can't be outsourced. The ATC needs to be invested in the long-term health of the system because they're living inside it. Contractors optimize for the engagement. Employees optimize for the outcome.
Werner Vogels described Amazon's version: the transition "from a two-tier monolith to a fully distributed, decentralized, services platform"8 wasn't just an architecture decision. It was an organizational design decision made by people who were building the system, not advising on it. The Bezos API Mandate of 2002; six rules, the last being "Anyone who doesn't do this will be fired"9; forced every team to communicate through designed interfaces. The people who designed those interfaces were the same people who operated the services. That's what made it work.
Forrester found that 68% of enterprise software purchases cite "ease of integration" as a top-3 buying criterion10. The ATC designs boundaries that make integration fast. Sales benefits directly.
When your prospect asks "how fast can you integrate?":
Without an ATC: "We'll assess your environment, build custom connectors, and scope it with professional services. Typically 4-6 months."
With an ATC: "Standard REST APIs with OpenAPI specs. Most customers integrate core systems in 2-4 weeks. You can start during the trial."
The difference isn't engineering talent. It's whether someone designed the interfaces so integration is composable by default.
| Question | Why It Matters |
|---|---|
| "Do we have someone who sees across all functions and designs boundaries?" | Tests whether the ATC role exists |
| "Can we add products without existing products changing?" | Tests boundary design quality |
| "What percentage of time is coordination vs actual work?" | Quantifies the cost of missing an ATC |
| "If we acquire a company, how long until integration unlocks value?" | Tests M&A readiness |
| "Where are teams waiting on each other, and has anyone designed that away?" | Surfaces accidental dependencies |
| Decision | Centralize When | Distribute When | Watch Out For |
|---|---|---|---|
| Data | Single source of truth matters (auth, billing) | Teams need independent schemas (features) | Distributed data + event bus = consistency risk |
| Communication | Low latency required; simple request/response | Teams need independence; fire-and-forget | Event-driven creates invisible side effects |
| Deployment | Tightly integrated components (shared release) | Independent features (separate pipelines) | Version drift between independently deployed services |
| APIs | Internal APIs with few consumers | External APIs or many consumers (version them) | Versioning adds complexity; don't version prematurely |
| Testing | Shared infrastructure (integration tests) | Independent services (contract tests) | Contract tests only work if contracts are enforced |
| Discovery Question | What You Learn |
|---|---|
| "How long do integrations take with your current vendor?" | Current pain; sets up contrast |
| "When your vendor ships updates, do your integrations break?" | Reveals poor boundary design |
| "How many teams coordinate for a typical new feature?" | Quantifies their coordination overhead |
| "Have you acquired companies? How long was tech integration?" | M&A pain is expensive and memorable |
| Prospect Says | You Say |
|---|---|
| "How fast can you integrate?" | "Standard integrations take 2-4 weeks. We have customers live in 8 days." |
| "We need customization." | "Custom features ship without affecting core functionality. No 6-month projects." |
| "We've been burned by breaking changes." | "API versioning and independent deployment. You control upgrade timing." |
| "This looks complex." | "More services, but they change independently. That's why we ship daily without breaking integrations." |
| Scenario | Without ATC | With ATC |
|---|---|---|
| New campaign feature | 8-12 weeks (requires engineering) | 1-3 days (self-serve, pre-designed) |
| A/B test variant | 4-6 weeks per variant | Hours (config-driven) |
| Add product to platform | 12-18 months (integration trauma) | 4-8 weeks (designed for composability) |
| Respond to competitor | Months (roadmap locked by dependencies) | Weeks (independent shipping) |
The ATC role touches every framework in this series. Without it, teams can't choose Fast/Good/Well independently because changes cascade (Article 1). Unknown unknowns stay hidden because nobody sees the whole system (Article 2). Low-trust environments create artificial coordination through defensive behavior; every approval chain that exists for CYA is a boundary someone should have designed differently (Article 4). And async management systems only work if teams can operate independently; otherwise you're just moving meetings to Slack threads (Article 5).
The best ATCs are invisible. Planes land on time. No collisions. No drama. Nobody thanks them because the system just works.
The best organizational ATC looks the same. Teams ship independently. Integrations are smooth. Acquisitions plug in. Sales quotes timelines with confidence. Marketing launches without waiting on engineering. Nobody notices the boundary design because it feels natural.
That's the paradox: the better the ATC does their job, the less visible it is.
Every function has the same "centralize vs distribute" tradeoff. Most organizations let it resolve accidentally: whoever pushes hardest wins, dependencies form without design, coordination overhead compounds until everyone's drowning in meetings.
The organizations that scale? They staff the role. Not always with a title. Sometimes it's a VP Engineering who sees across product lines. Sometimes it's a COO who designs operating models. Sometimes it's a sales leader who designs territory boundaries and handoff protocols.
But someone is doing it. Deliberately. With the whole system in their head.
The constraint isn't talent, capital, or technology.
It's whether someone sees the whole system clearly enough to design the boundaries that let everyone else move independently.
Every team needs an air traffic controller. Most just don't know it yet.
DORA (DevOps Research and Assessment), "Capabilities: Loosely Coupled Teams" and Accelerate by Forsgren, Humble, Kim (2018). Six years of research across 31,000+ professionals; loosely coupled teams identified as primary predictor of high software delivery performance. Randy Shoup quote on Google Datastore from DORA capability documentation. https://dora.dev/capabilities/loosely-coupled-teams/ ↩ ↩2
Atlassian, "State of Developer Experience Report 2025." Survey of 3,500 developers and managers across six countries; 50% lose 10+ hours per week to organizational inefficiencies; 90% lose 6+ hours; top friction points are finding information, context switching, and cross-team collaboration. https://www.atlassian.com/blog/developer/developer-experience-report-2025 ↩ ↩2
Cortex, "The 2024 State of Developer Productivity." Survey finding 58% of engineering leaders report 5+ hours per developer per week lost to unproductive work; "gathering project context" and "waiting on approvals" tied at 26% each as largest productivity leaks. https://cortex.io/report/the-2024-state-of-developer-productivity ↩ ↩2
Harvard Business Review, "A Better Approach to Mergers and Acquisitions" (May-June 2024), citing academic research: approximately 70% of M&A deals fail to achieve strategic goals; 83% of practitioners who experienced failed acquisitions cite integration as primary cause. IS integration research: Journal of Information and Software Technology (2023), 47 peer-reviewed studies. https://hbr.org/2024/05/a-better-approach-to-mergers-and-acquisitions ↩
Ruth Malan, "Conway's Law" (traceinthesand.com). Extended analysis of organizational structure and architecture alignment: "If the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins." https://ruthmalan.com/traceinthesand/conwayslaw.htm ↩
Team Topologies, "Mastering Team Effectiveness: The Power of Managing Cognitive Load" (2024). Research on domain-based team structures showing 25% reduction in context switching, 20% increase in productivity; one 400-engineer organization saved €8 million annually by eliminating one hour of daily blocking per engineer. https://teamtopologies.com/news-blogs-newsletters/2024/7/23/newsletter-july-mastering-team-effectiveness-the-power-of-managing-cognitive-load ↩ ↩2
Spotify Engineering / Journal of Systems and Software, "Decentralized decision-making and scaled autonomy at Spotify" (2023). Peer-reviewed research finding "surprisingly many" technical dependencies constraining squad autonomy; analysis of 10,000+ components across 500+ squads. https://www.sciencedirect.com/science/article/pii/S0164121223000444 ↩
Werner Vogels (CTO, Amazon), "A Second Conversation with Werner Vogels," ACM Communications (2019). Describes Amazon's transition from two-tier monolith to fully distributed services platform; S3 evolved from 8 services (2006) to 262 services (2019). https://cacm.acm.org/practice/a-second-conversation-with-werner-vogels/ ↩
Jeff Bezos, "The API Mandate" (2002). Internal memo requiring all Amazon teams to expose data through service interfaces. Publicly surfaced in 2011 by Google engineer Steve Yegge. https://konghq.com/blog/enterprise/api-mandate ↩
Forrester, "The Total Economic Impact of Microservices and API-First Architecture" (2023). 68% of enterprise software purchases cite "ease of integration" as top-3 buying criterion. https://www.forrester.com/research ↩