Best Practices

Proven strategies for effective team management

Follow these proven strategies to manage teams effectively and avoid common pitfalls.

Team OWNER Selection

Choose the Right People

Good OWNER candidates:

Team managers or leads
People who will stay long-term
Reliable, trustworthy employees
People who understand team structure
Those who already manage the team

Poor OWNER candidates:

Temporary employees or contractors
Brand new hires
People unfamiliar with the team
Those leaving the company soon
Individual contributors without management responsibility

Always Have Multiple OWNERs

Recommended: 2-3 OWNERs per team

Why multiple OWNERs?

Continuity:

If one OWNER leaves, others can manage
No orphaned teams requiring admin intervention
Smooth transitions during departures

Coverage:

Backup when primary OWNER unavailable
Distributed workload for large teams
Time zone coverage for global teams

Failure scenarios:

Single OWNER:

text

Problem: Sarah is the only OWNER of Enterprise Team
Sarah leaves the company
Result: No one can add/remove members
Solution: Organization ADMIN must fix manually

Multiple OWNERs:

text

Enterprise Team OWNERs: Sarah, John
Sarah leaves the company
Result: John continues managing team
No disruption

OWNER Count Guidelines

Too few (1 OWNER):

Single point of failure
Vacation coverage issues
Risk if OWNER leaves

Sweet spot (2-3 OWNERs):

Continuity without confusion
Clear ownership
Manageable coordination

Too many (5+ OWNERs):

Unclear responsibility
"Someone else will do it" syndrome
Coordination overhead

Team Size Guidelines

Recommended Team Sizes

Small teams: 5-15 members

Easy to manage
Clear communication
Strong cohesion

Medium teams: 15-30 members

Consider multiple OWNERs
May need sub-organization
Still manageable

Large teams: 30-50 members

Definitely need 2-3 OWNERs
Consider splitting into smaller teams
Naming conventions help organization

Very large teams: 50+ members

Usually indicates need to split
Consider regional or functional sub-teams
May be better as multiple teams

When to Split Teams

Signs you should split:

Team has 50+ members
Natural sub-groups exist (regions, products)
Members only work with subset of team
Managing membership becomes difficult
Team doesn't feel cohesive

Example split:

text

Before:
Sales Team (80 members, unwieldy)

After:
├─ US-East Sales (25 members)
├─ US-West Sales (25 members)
├─ EMEA Sales (20 members)
└─ APAC Sales (10 members)

Team Naming Conventions

Clear, Consistent Names

Good team names:

Enterprise Sales Team
US-East Region
Product A Specialists
Customer Success
Strategic Accounts

Poor team names:

Team 1
Sarah's Team
The A-Team
New Team
Miscellaneous

Naming Patterns for Scale

Geographic pattern:

Sales - US-East
Sales - US-West
Sales - EMEA
Sales - APAC

Product pattern:

Product A - Sales
Product A - Engineering
Product B - Sales
Product B - Engineering

Tier pattern:

Enterprise - East
Enterprise - West
SMB - East
SMB - West

Benefits:

Alphabetical grouping in lists
Clear hierarchy
Easy to find teams
Scales well

Membership Management

Regular Audits

Quarterly team audits:

Check:

Are all current members still with company?
Are new employees on appropriate teams?
Do team OWNERs still manage the team?
Are there employees not on any team?
Has team structure changed?

Update:

Remove departed employees
Add new hires to appropriate teams
Adjust team OWNERs if needed
Fix missing memberships

Onboarding Process

When someone joins:

Identify appropriate team (region, product, function)
Add to team with correct role (usually MEMBER)
Document membership in onboarding checklist
Verify access to team Decision Sites

Example onboarding:

text

New hire: Alex
Role: Account Executive
Region: US-East
Product: Enterprise

Actions:
├─ Add to US-East Sales Team (MEMBER)
├─ Add to Enterprise Team (MEMBER)
├─ Verify access to regional Decision Sites
└─ Document in HR onboarding checklist

Offboarding Process

When someone leaves:

Remove from all teams they were on
Transfer team OWNER role if they were OWNER
Reassign their Decision Sites if needed
Document removal in offboarding checklist

Warning: Don't forget to remove from teams. Departed employees with access create security risk.

Access Control Setting

Choose Carefully

Team Access Control is hard to change later.

ORGANIZATION access:

Small companies (< 20 people)
Full transparency cultures
Cross-selling critical
Flat structures

TEAM access:

Medium/large companies (20+ people)
Regional privacy needed
Structured access required
Clear team boundaries

OWN access:

Individual contributor model
Maximum confidentiality
Consulting/law firms
Minimal collaboration

Pilot Before Full Rollout

Test with small group first:

Create 1-2 pilot teams
Assign subset of Decision Sites
Test access patterns (can people access what they should?)
Gather feedback from team members
Fix issues before full deployment
Roll out to all teams

Example pilot:

text

Week 1-2: Create Enterprise Team pilot
Week 3-4: Test access, gather feedback
Week 5: Fix issues identified
Week 6: Create all remaining teams

Don't Change Frequently

Changing Team Access Control affects ALL Decision Sites immediately.

Impact:

ORGANIZATION → TEAM: People suddenly lose access
TEAM → ORGANIZATION: Everyone suddenly sees everything
Any → OWN: Massive access restriction

Best practice: Decide setting early, stick with it.

Team Structure

Keep It Simple

Start minimal:

Default team + 2-5 additional teams
Grow teams as needed
Don't create teams "just in case"

Avoid over-organization:

Too many teams creates confusion
Teams should serve clear purpose
Empty teams should be deleted

Document Your Structure

Team documentation template:

text

Team Name: Enterprise Sales Team
Purpose: Manage enterprise accounts (>$100K ARR)
OWNERs:
├─ Sarah Johnson (Sales Manager) - primary
└─ John Smith (Regional Director) - backup
Members: 15 account executives
Team Access Control: TEAM (regional privacy)
Decision Sites: ~50 active enterprise deals

Benefits:

Clarity for new members
Onboarding reference
Troubleshooting aid
Audit documentation

Review Structure Quarterly

Questions to ask:

Does team structure still match organization?
Have any teams grown too large?
Are there orphaned/empty teams?
Do team names still make sense?
Has company structure changed?

Update as needed:

Split large teams
Merge small teams
Rename teams for clarity
Delete unused teams

Decision Site Assignment

Assign at Creation

When creating Decision Site:

Choose appropriate team immediately
Don't leave unassigned (harder to organize later)
Use team that matches the deal

Example:

text

Creating Decision Site: Acme Corp Deal
Region: US-East
Account Size: Enterprise

Assign to: US-East Enterprise Team

Regular Cleanup

Audit Decision Site assignments:

Quarterly check:

Are Decision Sites on correct teams?
Any unassigned Decision Sites?
Have team assignments become outdated?
Are there Decision Sites on deleted teams? (should be on default team)

Fix:

Reassign misplaced Decision Sites
Assign unassigned Decision Sites
Update assignments when ownership changes

Common Pitfalls to Avoid

Pitfall 1: Too Many Teams

Problem:

text

Organization with 20 people creates 15 teams
Result: Confusion, empty teams, hard to find anything

Better approach:

Start with 3-5 teams maximum
Add teams only when clear need exists
Delete unused teams

Pitfall 2: Single OWNER Per Team

Problem:

text

Each team has exactly 1 OWNER
OWNERs go on vacation or leave
Teams become unmanageable

Better approach:

Always have 2-3 OWNERs
Plan for continuity
Promote backup OWNERs

Pitfall 3: Changing Access Control Frequently

Problem:

text

Week 1: ORGANIZATION access
Week 5: Switch to TEAM access (people lose access)
Week 10: Back to ORGANIZATION (privacy lost)
Users confused and frustrated

Better approach:

Choose carefully at start
Pilot test before committing
Stick with choice long-term

Pitfall 4: Ignoring Default Team

Problem:

text

Default team has 0 members
New employees don't get added to any team
Orphaned Decision Sites pile up on default team
No one manages default team

Better approach:

Assign OWNERs to default team
Use default team intentionally (holding area or company-wide)
Add new employees to default team until assigned elsewhere
Monitor default team's Decision Sites

Pitfall 5: Forgetting to Remove Departed Employees

Problem:

text

Employees leave but stay on teams for months
Security risk
Inaccurate team rosters
Confusion about who's actually on team

Better approach:

Remove from teams during offboarding
Quarterly team audits
Automated offboarding checklist

Pitfall 6: Unclear Team Purpose

Problem:

text

Team created but purpose unclear
Members don't know why they're on team
Duplicate teams created
Assignments inconsistent

Better approach:

Document team purpose
Clear naming conventions
Regular communication
Delete teams without clear purpose

Permission Management

Understand Role Independence

Organization roles and team roles are separate:

Example:

text

User: Sarah
Organization Role: COLLABORATOR (can't create Decision Sites)
Team Role: OWNER (can manage Enterprise Team)

Result:
✅ Can add/remove team members
✅ Can manage team settings
❌ Cannot create Decision Sites (needs CREATOR org role)

Key point: Team OWNER doesn't grant Decision Site creation permission.

ADMIN Override

Organization ADMINs bypass all team restrictions:

Use cases:

Emergency access to Decision Sites
Team management when all OWNERs gone
Auditing all Decision Sites
Fixing access issues

Don't overuse:

Give team OWNERs authority to manage
ADMIN for escalation only
Not for day-to-day team management

Communication

Announce Team Changes

When creating teams:

Notify affected members
Explain team purpose
Clarify what changes
Provide documentation

Example announcement:

text

Subject: New Regional Sales Teams

We're creating regional teams to improve focus:
- US-East Sales Team
- US-West Sales Team

What this means for you:
- You'll be added to your regional team
- You'll see only your region's Decision Sites
- Cross-regional collaboration: add contacts

Questions? Contact your manager or IT admin.