The Air Traffic Controller Problem: Every Team Needs One

Air traffic controllers don't fly planes. They prevent collisions.

When six planes approach the same runway, the ATC doesn't separate them all into different airspaces. Some planes are grouped in formation. Some share the same approach path. Some need to land simultaneously on parallel runways. The ATC's skill isn't applying one rule. It's knowing which rule fits which situation.

That role doesn't just exist in aviation. It exists in every team, every function, every organization. Most just don't name it. And when it's missing, you don't get crashes. You get something worse: coordination overhead that compounds until everyone is working harder and delivering less.

I used the phrase in the previous article as a management job: seeing across product lines so teams can move without collisions. This piece is about the role itself. Not just in engineering. Every function needs someone doing this, in the work, not above it.

How to Read This Article

• CEO / COO / CFO: The Symptom → The ATC in Every Function → For Executives
• CTO / VP Eng: What the ATC Actually Does → Why the ATC Can't Be a Contractor → For Engineering Leaders
• CPO / CMO: The ATC in Every Function → For Product and Marketing
• CSO / VP Sales / AE / BDR: The ATC in Every Function → For Sales
• Engineer: The 10-Hour Problem → What the ATC Actually Does
• Everyone: The whole thing, about fifteen minutes

The Symptom Everyone Recognizes

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.

I've watched this play out. A team I worked with had one engineer everyone relied on. Not because she wrote the most code, but because she was the only person who understood how the pieces fit together. By the time the org hit 40 people, she wasn't shipping anymore. She was in every planning meeting, every design review, every "quick question" Slack thread, because she was the only one who could see where a change in one system would break another. We had accidentally turned our best builder into a full-time router. The work didn't get harder. The coordination around it did.

DORA's research on loosely coupled teams found that the teams that can test, deploy, and change systems without depending on other teams require little communication to get work done¹. 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."¹ 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.

The 10-Hour Problem

Atlassian's 2025 State of Developer Experience report surveyed 3,500 developers and managers across six countries and found a striking paradox: 68% of developers save 10+ hours per week using AI tools, then 50% lose 10+ hours per week to organizational inefficiencies². Atlassian's own framing is the wash: you save ten hours, you lose ten hours.

Not to coding problems. To finding information, new technology, switching context between tools, and collaborating with other teams².

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, a survey of 50 engineering leaders at companies with 500+ employees, found the same pattern from the management side: "gathering project context" and "waiting on approvals" tied at 26% each as the largest productivity leaks³. When 58% of those 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 ATC³.

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?

The ATC in Every Function

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.

In Engineering

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 live in alignment meetings. New hires take months to become productive because nobody can explain how the pieces fit together.

In Sales

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.

In Marketing

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.

In Product

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.

In Operations / M&A

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 drag because nobody decides what should merge and what should stay separate. Bain's surveys of M&A practitioners who've lived through a failed deal found 83% pointed to integration as a primary cause⁴. Twenty years ago, Bain put the overall failure rate near 70%. The companies that improved those odds got better at the integration work: deciding what to merge, what to leave independent, and how fast. The ATC is often still the missing role.

The ATC at Every Scale

The role doesn't change with size. Who holds it, and how many of them you need, does.

Startup. The founder is the ATC, implicitly. They hold the whole system in their head because they built most of it. Boundaries are informal because everyone can see everyone. This works until it doesn't, usually around the point where no single person can still explain how all the pieces fit.

Mid-market. The implicit role has to become explicit. This is where you name it: a first platform team, a principal engineer, a head of revenue operations. The mistake here is waiting too long, letting coordination overhead compound while insisting the founder can still hold it all.

Enterprise. One ATC can't see everything anymore, so the role federates. You get ATCs who each own a domain and, above them, an ATC whose whole job is designing the boundaries between the boundaries. The risk flips: too many ATCs, each optimizing their own patch, and no one owning the seams between them.

The blast radius grows. The mechanics change. The judgment call stays exactly the same: where does independence help, and where is coordination worth its cost.

Why "Decouple Everything" Is Wrong

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."⁵ 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.

Spotify learned the same thing the hard way. A 2023 peer-reviewed study found "surprisingly many" technical dependencies constraining squad autonomy, even after the company tried to decouple by design, across roughly 500 squads⁶. Spotify Engineering has described that same fleet as 10,000+ components⁷. Autonomy was the goal. Coordination overhead was the reality. The answer wasn't more independence. It was better boundary design.

What the ATC Actually Does

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. The best ones do it proactively: they build the train track ahead of the train, laying down the boundary before the collision, so teams never hit the blocker in the first place.

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.

Why the ATC Can't Be a Contractor (Or a Pure Coordinator)

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 the "simple API call" actually requires three teams to coordinate. The salesperson who closes deals knows the "standard integration" actually takes six months. The marketer knows "self-serve" actually requires an engineering ticket.

That ground truth is what makes boundary design relevant. Without it you get architecture astronauts, designing beautiful systems they've never operated, and coordination theater, meetings about alignment that never produce clarity. The ATC feels the pain personally when a boundary that made sense six months ago starts slowing teams down, so they fix it before it calcifies. Contractors optimize for the engagement; employees living inside the system optimize for the outcome. That's why the role can't be outsourced.

Werner Vogels described Amazon's version: the transition "from a two-tier monolith to a fully distributed, decentralized, services platform"⁸ 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"⁹) 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.

The ATC's Failure Mode

There's a way to get this exactly wrong, and it's the mirror image of having no ATC at all.

The ATC who sees everything can start deciding everything. Every boundary runs through them. Every cross-team question waits for their answer. They become the single point of failure they were supposed to design away. Now you don't have accidental coordination overhead; you have deliberate coordination overhead, routed through one person's calendar. The org can't move faster than they can context-switch.

You feel this most clearly when they're gone.

Friday. The ATC is on vacation, or in back-to-backs, or out sick. Slack fills with the same three messages: "who knows how X works?", "who can approve this?", "who remembers why we did it that way?" Work doesn't stop. Context does. You didn't lose a coder for a week. You lost the map.

That's not a staffing gap. That's a weak system. A weak system depends on a hero who holds it all in their head. A strong system uses that hero to build boundaries other people can operate without them. The best ATCs measure themselves by how many decisions they no longer need to be in. They develop other ATCs. They write the interface down so it outlives the conversation. They design themselves out of the critical path on purpose.

If your ATC is indispensable, they haven't finished the job. The goal isn't to be the person who sees the whole system. It's to build a system that doesn't need any one person to see all of it.

Integration as Competitive Moat (For Sales)

Sales feels boundary design as a quote that changes. Without an ATC: "We'll assess your environment, build custom connectors, and scope it with professional services. Typically four to six months." With one: "Most customers are live in two to four 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.

Role-Specific Cheat Sheets

For Executives (CEO, COO, CFO)

For Engineering Leaders (CTO, VP Eng, Directors)

For Sales (CSO, VP Sales, AE, BDR)

For Product and Marketing (CPO, CMO, Product Managers)

Connecting to the Series

The ATC role touches every framework in this series. Without it, teams can't choose Fast/Good/Well independently, because a change in one place cascades into five others. The unknown unknowns stay hidden because nobody sees the whole system well enough to spot them. Accidental boundaries are a form of false certainty: instead of deciding where coordination is worth its cost, the org lets the boundary form on its own and calls the result inevitable. Low-trust environments manufacture coordination through defensive behavior; every approval chain that exists for CYA is a boundary someone should have designed differently. And async management only works if teams can operate independently; otherwise you're just moving the meetings to Slack.

How to Become the ATC

You don't need the title. You need the view and the willingness to use it.

Start where you already work. Notice the boundary that keeps generating friction: the handoff that always stalls, the "simple" change that always touches three teams, the approval everyone waits on. That friction is a boundary nobody designed. Name it out loud, name the tradeoff, and propose where it should sit. That's the whole job in miniature.

Then widen the view. Sit in the planning meeting for the team next to yours. Learn what constraint they're actually solving for. The ATC's power comes from carrying more context than anyone else in the room, and context is just accumulated attention.

Stay in the work. The moment you stop shipping, closing, or building, your boundary judgment starts drifting toward theory. Keep one foot in the thing you're designing boundaries around.

And design yourself out. If you become the person every decision routes through, you've recreated the problem. The test is simple: can the team still operate next Friday if you're out? If the answer is a Slack scramble, the view still lives in one head. The goal is boundaries other people can operate without you.

The Air Traffic Controller's Paradox

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.

There's the remaining problem, and it's the one the role can't solve by itself. If the whole-system view lives only in that person's head, the org is one vacation away from flying blind. Designing yourself out only works if the view can live somewhere other than a person.

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.

---

References

Footnotes

1. DORA (DevOps Research and Assessment), "Capabilities: Loosely Coupled Teams." Teams that can test, deploy, and change independently require little communication to get work done. Randy Shoup's Google Datastore quote is on the same page. Forsgren, Humble, and Kim, Accelerate (2018), established loosely coupled architecture as a primary predictor of delivery performance. 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 (Wakefield Research). 68% save 10+ hours per week with AI tools; 50% lose 10+ hours per week to organizational inefficiencies; 90% lose 6+ hours. https://www.atlassian.com/blog/developer/developer-experience-report-2025 ↩ ↩²

3. Cortex, "The 2024 State of Developer Productivity." Survey of 50 engineering leaders at companies with 500+ employees; 58% report 5+ hours per developer per week lost to unproductive work; "gathering project context" and "waiting on approvals" tied at 26% each. https://cortex.io/report/the-2024-state-of-developer-productivity ↩ ↩²

4. Bain & Company, "The 10 Steps to Successful M&A Integration." Among M&A practitioners who experienced a failed deal, 83% pointed to integration as a primary cause. https://www.bain.com/insights/10-steps-to-successful-ma-integration/ Harvard Business Review, "A Better Approach to Mergers and Acquisitions" (May-June 2024), recounting Bain's older finding that roughly 70% of mergers failed, and noting that those odds later inverted as frequent acquirers got better at integration. https://hbr.org/2024/05/a-better-approach-to-mergers-and-acquisitions ↩

5. Ruth Malan, "Conway's Law" (2008). "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 ↩

6. Darja Šmite, Nils Brede Moe, Marcin Floryan, Javier Gonzalez-Huerta, Michael Dorner, and Aivars Sablis, "Decentralized decision-making and scaled autonomy at Spotify," Journal of Systems and Software 200 (2023). Peer-reviewed. ~500 squads as of spring 2020; "surprisingly many" technical dependencies constraining autonomy despite microservice decoupling. https://doi.org/10.1016/j.jss.2023.111649 ↩

7. Spotify Engineering, "Managing Software at Scale" (October 2023). Niklas Gustavsson describing 500+ squads managing 10,000+ software components in production. https://engineering.atspotify.com/2023/10/managing-software-at-scale-googles-kelsey-hightower-talks-with-spotifys-niklas-gustavsson-about-fleet-management ↩

8. Werner Vogels (CTO, Amazon), "A Second Conversation with Werner Vogels," Communications of the ACM (2019). Describes Amazon's transition from a two-tier monolith to a fully distributed, decentralized services platform. https://cacm.acm.org/practice/a-second-conversation-with-werner-vogels/ ↩

9. Steve Yegge, internal Google memo (2011), recounting Jeff Bezos's 2002 API Mandate, including "Anyone who doesn't do this will be fired." Preserved at https://gist.github.com/chitchcock/1281611. Secondary write-up: https://konghq.com/blog/enterprise/api-mandate ↩