Search documentation

Search for pages in the documentation

Team Structure Patterns

Common team organizational models and when to use them

Learn common team structures and choose the pattern that fits your organization.

Pattern Selection Guide

PatternCompany SizeTeam Access ControlUse Case
Flat< 15ORGANIZATIONEveryone collaborates
Geographic20-100+TEAMRegional teams
Product20-100+TEAM or ORGANIZATIONMultiple products
Hierarchical50-200+TEAMManager/rep structure
Account Tier30-150+TEAMEnterprise vs SMB
Functional20-100+ORGANIZATIONDepartment-based
Matrix50+TEAMMultiple dimensions

Pattern 1: Flat Structure

Best for: Small companies (< 15 people) with full transparency.

Structure

text
Teams:
└─ Default Team (everyone)

Team Access Control: ORGANIZATION

That's it. No additional teams needed.

Characteristics

Team count: 1 (default team only)

Access: Everyone sees all Decision Sites

Membership:

  • All organization members on default team
  • No additional teams

When to Use

Good for:

  • Startups
  • Small teams
  • Full collaboration needed
  • No privacy requirements
  • Flat organizational structure

Example company:

text
Company: 8-person SaaS startup
Structure: Everyone works together
Goal: Full visibility, maximum collaboration

Pros and Cons

Pros:

  • ✅ Simple
  • ✅ No access confusion
  • ✅ Maximum collaboration
  • ✅ Easy to manage

Cons:

  • ❌ No privacy
  • ❌ Doesn't scale past ~15 people
  • ❌ All Decision Sites visible to everyone

Implementation

  1. Set Team Access Control: ORGANIZATION
  2. Use default team for all members
  3. Don't create additional teams
  4. Reassess when company grows past 15 people

Pattern 2: Geographic Teams

Best for: Regional sales organizations with location-based privacy.

Structure

text
Teams:
├─ US-East Sales
├─ US-West Sales
├─ EMEA Sales
├─ APAC Sales
└─ Default Team

Team Access Control: TEAM

Each region has dedicated team, can only see their region's deals.

Characteristics

Team count: One per region (+ default)

Access: Regional privacy enforced

Membership:

  • Reps assigned to home region
  • Regional managers as team OWNERs
  • Possible overlap for cross-regional roles

When to Use

Good for:

  • Multi-region sales
  • Different regions have different customers
  • Regional privacy required
  • Time zone-based teams

Example company:

text
Company: 60-person sales organization
Structure: 4 regional teams
Goal: Regional reps see only their deals

Pros and Cons

Pros:

  • ✅ Clear regional boundaries
  • ✅ Focus on relevant geography
  • ✅ Scales well
  • ✅ Natural structure

Cons:

  • ❌ Cross-regional collaboration requires adding contacts
  • ❌ Global deals need special handling
  • ❌ Reorganization when regions change

Example Setup

US-East Team:

text
OWNER: Regional Sales Director
MEMBERS: 15 account executives (East Coast)
Decision Sites: 200 active deals in US-East region

US-West Team:

text
OWNER: Regional Sales Director
MEMBERS: 12 account executives (West Coast)
Decision Sites: 180 active deals in US-West region

Implementation

  1. Create regional teams (US-East, US-West, EMEA, APAC)
  2. Add regional managers as OWNERs
  3. Add reps as MEMBERs based on territory
  4. Set Team Access Control: TEAM
  5. Assign Decision Sites to appropriate regional team

Pattern 3: Product-Based Teams

Best for: Companies with multiple products or product lines.

Structure

text
Teams:
├─ Product A Team
├─ Product B Team
├─ Product C Team
└─ Default Team

Team Access Control: TEAM or ORGANIZATION

Characteristics

Team count: One per product

Access: Depends on cross-selling needs

  • TEAM if products are independent
  • ORGANIZATION if cross-selling important

Membership:

  • Product specialists
  • Product managers as OWNERs
  • Sales reps can be on multiple teams (selling multiple products)

When to Use

Good for:

  • Multiple products
  • Product specialization
  • Different sales processes per product
  • Product-specific teams

Example company:

text
Company: 40-person product company
Products: 3 distinct products
Goal: Product teams own their deals

Variant A: Siloed Products (TEAM Access)

Use when: Products are independent, no cross-selling.

Setup:

text
Team Access Control: TEAM

Product A Team:
├─ OWNER: Product A Manager
└─ MEMBERS: Product A specialists

Product B Team:
├─ OWNER: Product B Manager
└─ MEMBERS: Product B specialists

Result: Product A team cannot see Product B deals.

Variant B: Cross-Selling Products (ORGANIZATION Access)

Use when: Cross-selling is critical.

Setup:

text
Team Access Control: ORGANIZATION

Teams used for organization only
Everyone can see all product deals

Result: Product A team can see Product B deals (cross-selling opportunities).

Pros and Cons

Pros:

  • ✅ Product specialization
  • ✅ Clear product ownership
  • ✅ Product-specific processes

Cons:

  • ❌ Reps selling multiple products need multiple team memberships
  • ❌ Cross-selling harder with TEAM access
  • ❌ Product reorganization affects teams

Implementation

  1. Create teams per product
  2. Add product managers as OWNERs
  3. Add specialists as MEMBERs
  4. Decide: TEAM (siloed) or ORGANIZATION (cross-selling)
  5. Assign Decision Sites to appropriate product team

Pattern 4: Hierarchical Structure

Best for: Traditional sales hierarchy with managers and reps.

Structure

text
Teams:
├─ Sales Leadership
│  └─ OWNERs: VPs and Directors
├─ Enterprise Team
│  ├─ OWNER: Enterprise Manager
│  └─ MEMBERS: Enterprise reps
├─ Mid-Market Team
│  ├─ OWNER: Mid-Market Manager
│  └─ MEMBERS: Mid-Market reps
└─ Default Team

Team Access Control: TEAM

Characteristics

Team count: One per manager (+ leadership team)

Access: Hierarchical visibility

  • Reps see their team
  • Managers see their team
  • Leaders see everything (via ADMIN or multiple OWNER roles)

Membership:

  • Managers as team OWNERs
  • Reps as team MEMBERs
  • Leaders as organization ADMINs (bypass all restrictions)

When to Use

Good for:

  • Traditional hierarchies
  • Manager/rep structure
  • Clear reporting lines
  • Need manager visibility

Example company:

text
Company: 100-person sales organization
Structure: VP → Directors → Managers → Reps
Goal: Managers see their team, VPs see everything

Pros and Cons

Pros:

  • ✅ Matches org chart
  • ✅ Manager visibility
  • ✅ Clear ownership
  • ✅ Familiar structure

Cons:

  • ❌ VP/Director access requires ADMIN role (or being on all teams)
  • ❌ Reorganization requires team changes
  • ❌ Matrix reporting complicated

Implementation

  1. Create team per manager
  2. Add managers as OWNERs
  3. Add reps as MEMBERs reporting to that manager
  4. Make VPs/Directors organization ADMINs (for full visibility)
  5. Set Team Access Control: TEAM

Pattern 5: Account Tier Teams

Best for: Enterprise vs Mid-Market vs SMB segmentation.

Structure

text
Teams:
├─ Enterprise Accounts
├─ Mid-Market Accounts
├─ SMB Accounts
└─ Default Team

Team Access Control: TEAM

Characteristics

Team count: One per tier

Access: Tier-based privacy

Membership:

  • Account executives assigned by tier
  • Tier-specific managers as OWNERs

When to Use

Good for:

  • Different processes per tier
  • Account size specialization
  • Tier-based compensation
  • Different sales motions

Example company:

text
Company: 50-person sales organization
Tiers: Enterprise (>$100K), Mid-Market ($25K-$100K), SMB (<$25K)
Goal: Specialists focus on their tier

Tier Definitions

Enterprise Accounts Team:

text
Accounts: >$100K ARR
Sales cycle: 6-12 months
Team size: 10 specialized AEs
Decision Sites: 50 active deals

Mid-Market Accounts Team:

text
Accounts: $25K-$100K ARR
Sales cycle: 3-6 months
Team size: 15 AEs
Decision Sites: 150 active deals

SMB Accounts Team:

text
Accounts: <$25K ARR
Sales cycle: 1-3 months
Team size: 20 AEs (high velocity)
Decision Sites: 400 active deals

Pros and Cons

Pros:

  • ✅ Tier specialization
  • ✅ Appropriate sales motions
  • ✅ Clear account ownership
  • ✅ Compensation aligned

Cons:

  • ❌ Account tier changes require team reassignment
  • ❌ Expansion plays (SMB → Enterprise) complicated
  • ❌ Tier boundaries can be fuzzy

Implementation

  1. Define tier boundaries (revenue, size, complexity)
  2. Create teams per tier
  3. Add tier managers as OWNERs
  4. Assign reps by specialization
  5. Set Team Access Control: TEAM

Pattern 6: Functional Teams

Best for: Department-based organization with cross-functional visibility.

Structure

text
Teams:
├─ Sales Team
├─ Engineering Team
├─ Support Team
├─ Marketing Team
└─ Default Team

Team Access Control: ORGANIZATION

Characteristics

Team count: One per function/department

Access: Everyone sees everything (ORGANIZATION access)

Membership: By department

Purpose: Organizational labeling, not access control

When to Use

Good for:

  • Cross-functional collaboration
  • Department tracking
  • Full transparency needed
  • Small-to-medium companies

Example company:

text
Company: 30-person company
Departments: Sales, Engineering, Support, Marketing
Goal: Organize by function, full visibility

Pros and Cons

Pros:

  • ✅ Clear functional boundaries
  • ✅ Full cross-functional visibility
  • ✅ Collaboration enabled
  • ✅ Simple to understand

Cons:

  • ❌ No access control
  • ❌ Teams don't restrict
  • ❌ Purely organizational

Implementation

  1. Create teams per department
  2. Add department heads as OWNERs
  3. Add team members by department
  4. Set Team Access Control: ORGANIZATION
  5. Use teams for labeling only

Pattern 7: Matrix Organization

Best for: Complex organizations with multiple dimensions.

Structure

text
Teams:
├─ US-East Region
├─ US-West Region
├─ Enterprise Tier
├─ Mid-Market Tier
├─ Product A
├─ Product B
└─ Default Team

Team Access Control: TEAM

Users are on multiple teams based on region, tier, and product.

Characteristics

Team count: Multiple dimensions

Access: Combined access from all team memberships

Membership: Users on 2-4 teams

Example User

text
User: Sarah
Teams:
├─ US-East Region (MEMBER)
├─ Enterprise Tier (MEMBER)
└─ Product A (OWNER)

Can access Decision Sites from:
- US-East region
- Enterprise tier
- Product A
- Plus any she owns

When to Use

Good for:

  • Large, complex organizations
  • Multiple organizational dimensions
  • Matrix reporting
  • Need flexibility

Example company:

text
Company: 150-person sales organization
Dimensions: Region, Tier, Product
Goal: Reps see deals matching their dimensions

Pros and Cons

Pros:

  • ✅ Flexible
  • ✅ Matches complex orgs
  • ✅ Multiple access paths
  • ✅ Scales well

Cons:

  • ❌ Complex to manage
  • ❌ Users on many teams
  • ❌ Access troubleshooting harder
  • ❌ Requires clear documentation

Implementation

  1. Identify dimensions (region, tier, product, etc.)
  2. Create teams per dimension
  3. Add users to multiple teams based on their dimensions
  4. Document who should be on which teams
  5. Set Team Access Control: TEAM

Hybrid Patterns

You can combine patterns:

Geographic + Tier Hybrid

text
Teams:
├─ US-East Enterprise
├─ US-East SMB
├─ US-West Enterprise
├─ US-West SMB
└─ Default Team

Product + Geographic Hybrid

text
Teams:
├─ Product A - US
├─ Product A - EMEA
├─ Product B - US
├─ Product B - EMEA
└─ Default Team

Migration Patterns

From Flat to Geographic (Growing Company)

Before (15 people):

text
Teams: Default Team only
Access Control: ORGANIZATION

After (50 people):

text
Teams:
├─ US-East
├─ US-West
├─ EMEA
└─ Default Team

Access Control: TEAM

Migration:

  1. Create regional teams
  2. Assign members by region
  3. Reassign Decision Sites to regional teams
  4. Change Team Access Control: ORGANIZATION → TEAM
  5. Communicate change

From Geographic to Matrix (Scaling Complexity)

Before:

text
Teams: Regional only

After:

text
Teams: Regional + Tier
Users on multiple teams

Migration:

  1. Add tier teams
  2. Add users to tier teams (in addition to regional)
  3. Assign Decision Sites to primary dimension (region or tier)
  4. Document access patterns

Choosing Your Pattern

Decision Tree

  1. Company size?

    • < 15: Flat
    • 15-50: Geographic or Product
    • 50-150: Geographic + Tier
    • 150+: Matrix
  2. Natural divisions?

    • Geography: Geographic pattern
    • Product: Product pattern
    • Both: Hybrid or Matrix
  3. Privacy needs?

    • High: TEAM access control
    • Low: ORGANIZATION access control
  4. Complexity tolerance?

    • Low: Flat or Geographic
    • Medium: Product or Tier
    • High: Matrix

Next Steps