Functional vs Divisional Structure

Organize by expertise (design, engineering) not by product area (guest team, host team) to prevent fragmentation

Brian Chesky
Brian Chesky's new playbook

Functional vs Divisional Structure

"We went to a functional model. We went back to a startup. So we said, we're not going to have divisional leaders. We're going to have design, engineering, product which turned to product marketing and marketing and communications and sales and operations, all the functions of a startup." - Brian Chesky

What It Is

Functional vs Divisional Structure is an organizational design choice that has profound implications for how a company operates. Divisional structures organize around product areas or business units (guest team, host team, experiences team), while functional structures organize around expertise (design, engineering, marketing).

Brian Chesky discovered that divisional structures, despite being commonly recommended for scaling companies, can create significant dysfunction: politics, bureaucracy, dependencies, and fragmentation. After nearly losing Airbnb during COVID, he restructured the company from 10 divisions back to a functional model—essentially returning to how a startup operates.

The key insight is that divisions tend to become separate empires that go in different directions, accumulate their own resources, and require political advocacy to get things done. Functional structures force collaboration and maintain coherence.

How It Works

Divisional Structure (common at scale)

  • Teams organized around product areas: Guest Team, Host Team, Experiences Team
  • Each division has its own designers, engineers, PMs, marketers
  • Divisions have their own roadmaps, priorities, success metrics
  • Leaders become "general managers" of their division

The Dysfunction Pattern:

  1. Teams run on slightly different technical stacks → Technical debt
  2. Dependencies create backlogs (everyone needs payments platform) → Bottlenecks
  3. Frustrated teams build their own capabilities → Duplication
  4. Divisions advocate for their own interests → Politics
  5. Coordination requires relationship-building → Bureaucracy
  6. Hard to know who's doing what → Lack of accountability
  7. Individual contribution feels disconnected → Complacency

Functional Structure (startup-like)

  • Teams organized around expertise: Design, Engineering, Marketing
  • Designers report to design leaders who do design work
  • Single roadmap across the company
  • Leaders are experts in their function, not general managers

Why Functional Works:

  • One roadmap means everyone rows the same direction
  • No division advocacy—the company decides priorities
  • Experts lead experts (design leaders actually design)
  • Features can span "areas" without org chart battles
  • Eliminates the need for influence-building

How to Apply It

  1. Audit your current structure - Map out how teams are organized and what they own

  2. Identify dysfunction signals:

    • Do teams have separate technical stacks?
    • Are there significant dependency backlogs?
    • Do teams build duplicate capabilities?
    • Does getting things done require relationship-building?
    • Is it hard to know what everyone is doing?

  3. Consider functional conversion:

    • Collapse division leaders into functional leaders
    • Create one company roadmap, not divisional roadmaps
    • Ensure leaders are experts in what they lead
    • Remove "general manager" roles that don't do the work

  4. Maintain domain knowledge through roles, not structure:

    • Airbnb has product marketers focused on guests/hosts
    • But designers and engineers are fungible across areas
    • Domain expertise lives in people, not org boxes

  5. Create one shared consciousness:

    • Top 30-40 people in continuous conversation
    • Single roadmap updated regularly
    • CEO reviews all work (see Founder Mode)

When to Use It

  • When your company has fragmented into separate empires
  • When getting things done requires political navigation
  • When teams are building duplicate capabilities
  • When coordination costs exceed the benefits of specialization
  • When products feel incoherent or inconsistent
  • When you want "1000 people to work but it looks like 10 did it"

When NOT to Use It

  • When you're running genuinely separate businesses with no integration
  • When regulatory or market requirements demand separation
  • When scale is so large that functional structure becomes unwieldy
  • Note: Even Apple, at massive scale, remained largely functional under Jobs

Historical Context

Chesky studied the history of divisional organizations:

"I studied Alfred Sloan at General Motors that MIT Sloan is named after. And actually the founding of divisional companies, which I believe was DuPont. They were making powder for gunpowder. The war ends. What do we do with powder? Turns out powder can be used for paint, but the way you sell gunpowder and paint are different sales channels so they created what we now know as the divisional structure."

The divisional structure was invented for companies with genuinely different products requiring different go-to-market approaches. It's been over-applied to tech companies building integrated products.

Source

Primary Source:

  • Guest: Brian Chesky
  • Episode: "Brian Chesky's new playbook"
  • Key Discussion: (00:22:57) - Moving from 10 divisions to functional; (00:10:34) - How divisions create dysfunction
  • YouTube: Watch on YouTube

Additional Source:

  • Guest: Dhanji R. Prasanna
  • Episode: "How Block is becoming the most AI-native enterprise in the world"
  • Key Discussion: (00:09:23) - Block's transformation from GM structure to functional; how it enabled AI-native transformation
  • YouTube: Watch on YouTube

Dhanji's perspective adds: Block had operated as a portfolio of independent companies (Square, Cash App, Afterpay, TIDAL) with separate engineering practices, design teams, and strategies. Moving to functional structure—all engineers reporting to one team, all designers to another—enabled unified technical strategy and faster AI adoption. "When you really want to go deep in technology... you need a singular focus."

Related Frameworks

Back to Team Building