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
| Pattern | Company Size | Team Access Control | Use Case |
|---|---|---|---|
| Flat | < 15 | ORGANIZATION | Everyone collaborates |
| Geographic | 20-100+ | TEAM | Regional teams |
| Product | 20-100+ | TEAM or ORGANIZATION | Multiple products |
| Hierarchical | 50-200+ | TEAM | Manager/rep structure |
| Account Tier | 30-150+ | TEAM | Enterprise vs SMB |
| Functional | 20-100+ | ORGANIZATION | Department-based |
| Matrix | 50+ | TEAM | Multiple dimensions |
Pattern 1: Flat Structure
Best for: Small companies (< 15 people) with full transparency.
Structure
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:
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
- Set Team Access Control: ORGANIZATION
- Use default team for all members
- Don't create additional teams
- Reassess when company grows past 15 people
Pattern 2: Geographic Teams
Best for: Regional sales organizations with location-based privacy.
Structure
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:
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:
OWNER: Regional Sales Director
MEMBERS: 15 account executives (East Coast)
Decision Sites: 200 active deals in US-East region
US-West Team:
OWNER: Regional Sales Director
MEMBERS: 12 account executives (West Coast)
Decision Sites: 180 active deals in US-West region
Implementation
- Create regional teams (US-East, US-West, EMEA, APAC)
- Add regional managers as OWNERs
- Add reps as MEMBERs based on territory
- Set Team Access Control: TEAM
- Assign Decision Sites to appropriate regional team
Pattern 3: Product-Based Teams
Best for: Companies with multiple products or product lines.
Structure
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:
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:
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:
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
- Create teams per product
- Add product managers as OWNERs
- Add specialists as MEMBERs
- Decide: TEAM (siloed) or ORGANIZATION (cross-selling)
- Assign Decision Sites to appropriate product team
Pattern 4: Hierarchical Structure
Best for: Traditional sales hierarchy with managers and reps.
Structure
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:
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
- Create team per manager
- Add managers as OWNERs
- Add reps as MEMBERs reporting to that manager
- Make VPs/Directors organization ADMINs (for full visibility)
- Set Team Access Control: TEAM
Pattern 5: Account Tier Teams
Best for: Enterprise vs Mid-Market vs SMB segmentation.
Structure
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:
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:
Accounts: >$100K ARR
Sales cycle: 6-12 months
Team size: 10 specialized AEs
Decision Sites: 50 active deals
Mid-Market Accounts Team:
Accounts: $25K-$100K ARR
Sales cycle: 3-6 months
Team size: 15 AEs
Decision Sites: 150 active deals
SMB Accounts Team:
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
- Define tier boundaries (revenue, size, complexity)
- Create teams per tier
- Add tier managers as OWNERs
- Assign reps by specialization
- Set Team Access Control: TEAM
Pattern 6: Functional Teams
Best for: Department-based organization with cross-functional visibility.
Structure
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:
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
- Create teams per department
- Add department heads as OWNERs
- Add team members by department
- Set Team Access Control: ORGANIZATION
- Use teams for labeling only
Pattern 7: Matrix Organization
Best for: Complex organizations with multiple dimensions.
Structure
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
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:
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
- Identify dimensions (region, tier, product, etc.)
- Create teams per dimension
- Add users to multiple teams based on their dimensions
- Document who should be on which teams
- Set Team Access Control: TEAM
Hybrid Patterns
You can combine patterns:
Geographic + Tier Hybrid
Teams:
├─ US-East Enterprise
├─ US-East SMB
├─ US-West Enterprise
├─ US-West SMB
└─ Default Team
Product + Geographic Hybrid
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):
Teams: Default Team only
Access Control: ORGANIZATION
After (50 people):
Teams:
├─ US-East
├─ US-West
├─ EMEA
└─ Default Team
Access Control: TEAM
Migration:
- Create regional teams
- Assign members by region
- Reassign Decision Sites to regional teams
- Change Team Access Control: ORGANIZATION → TEAM
- Communicate change
From Geographic to Matrix (Scaling Complexity)
Before:
Teams: Regional only
After:
Teams: Regional + Tier
Users on multiple teams
Migration:
- Add tier teams
- Add users to tier teams (in addition to regional)
- Assign Decision Sites to primary dimension (region or tier)
- Document access patterns
Choosing Your Pattern
Decision Tree
-
Company size?
- < 15: Flat
- 15-50: Geographic or Product
- 50-150: Geographic + Tier
- 150+: Matrix
-
Natural divisions?
- Geography: Geographic pattern
- Product: Product pattern
- Both: Hybrid or Matrix
-
Privacy needs?
- High: TEAM access control
- Low: ORGANIZATION access control
-
Complexity tolerance?
- Low: Flat or Geographic
- Medium: Product or Tier
- High: Matrix
Next Steps
- Implement your pattern: Quick Start
- Follow best practices: Best Practices
- Configure access: Team Access Control
- Understand roles: Team Roles