slice icon Context Slice

Content Type Recognition

Match user intent to the appropriate task:

User says Content Type Task
"burnout", "hours", "overtime", "working too much" Burnout Risk taskIdentify Burnout Risk
"workload", "who's overloaded", "task distribution", "capacity" Workload Analysis taskAnalyze Workload Distribution
"team health", "dysfunction", "engagement", "something's wrong" Team Diagnosis taskDiagnose Team Health

Burnout Risk Analysis

Warning Thresholds

These are directional—adjust based on role and context:

Signal Yellow Flag Red Flag
Weekly hours 45+ hrs for 2 weeks 50+ hrs for 2+ weeks
Weekend work Any weekend hours Regular weekend hours
Late night work After 8pm occasionally After 10pm regularly
PTO usage None in 60 days None in 90+ days
Meeting load >25 hrs/week >30 hrs/week

Risk Factors to Weight

  • Role type: Some roles have natural variance (sales quarters, engineering sprints)
  • Tenure: New hires may work more as they ramp
  • Seniority: Senior ICs may have more variance
  • Personal context: Known circumstances (new parent, health issues)

Output Format for Burnout Analysis

# Burnout Risk Assessment: [Team/Period]

## Summary
- **Period analyzed:** [Date range]
- **Team members:** [N]
- **High risk:** [N] people
- **Moderate risk:** [N] people

## Flagged Individuals

### 🔴 High Risk
| Person | Avg Hours | Trend | Key Signals |
|--------|-----------|-------|-------------|
| [Name] | [X] hrs | ↑ Increasing | [Signals] |

### 🟡 Moderate Risk
| Person | Avg Hours | Trend | Key Signals |
|--------|-----------|-------|-------------|
| [Name] | [X] hrs | → Stable | [Signals] |

## Team Patterns
[Observations about team-wide trends]

## Recommended Actions
1. [Action for high-risk individuals]
2. [Action for team-wide patterns]

Workload Distribution Analysis

What to Measure

  • Volume: Task count, story points, tickets assigned
  • Completion time: How long tasks take per person
  • Complexity distribution: Are hard tasks evenly distributed?
  • Load variance: Std deviation across team

Healthy vs. Unhealthy Distribution

  • Healthy: Similar load with natural variance based on capacity/level
  • Unhealthy: One person with 2x+ the load of others
  • Watch for: Single points of failure, knowledge bottlenecks

Output Format for Workload Analysis

# Workload Analysis: [Team/Period]

## Distribution Overview
| Person | Tasks | Completion Time | Load vs. Avg |
|--------|-------|-----------------|--------------|
| [Name] | [N] | [X days avg] | +/- X% |

## Balance Assessment
- **Most loaded:** [Name] at [X]% above average
- **Least loaded:** [Name] at [X]% below average
- **Balance score:** [Good/Moderate/Poor]

## Patterns
[Observations]

## Recommendations
[Actions]

Team Health Diagnosis

Lencioni's 5 Dysfunctions Framework

Use this for qualitative team health assessment:

  1. Absence of Trust: People don't show vulnerability
  2. Fear of Conflict: Artificial harmony, no healthy debate
  3. Lack of Commitment: Ambiguity, hedging, no buy-in
  4. Avoidance of Accountability: Low standards, missed commitments
  5. Inattention to Results: Individual goals over team goals

Symptoms to Listen For

  • "We don't really know what [person] does"
  • "Meetings never decide anything"
  • "No one follows up"
  • "People just do their own thing"
  • "Everyone's in survival mode"

Output Format for Team Diagnosis

# Team Health Diagnosis

## Summary
Based on described symptoms: [Overview of likely issues]

## Likely Dysfunctions

### [Dysfunction 1]: [Confidence: High/Medium]
**Evidence from description:**
- [Symptom 1]
- [Symptom 2]

**What this looks like:**
[Description of this dysfunction in action]

**Intervention ideas:**
1. [Intervention]
2. [Intervention]

### [Dysfunction 2]: [Confidence: Medium]
[Same structure]

## Root Cause Hypothesis
[What might be underlying these symptoms]

## Recommended Next Steps
1. [Immediate action]
2. [Short-term action]
3. [Longer-term action]

Data Validation

Before analysis, check for data quality issues:

Required Checks

  • Empty values: Flag rows with missing employee names or hours. Report: "X rows skipped due to missing [column]"
  • Invalid numbers: Hours must be positive numbers. Flag non-numeric or negative values
  • Impossible values: Hours > 168/week (24x7) are impossible. Hours > 100/week are suspicious—confirm with user
  • Date parsing: If dates don't parse, note the format issue and ask for clarification

Validation Output

If issues found, report them clearly before proceeding:

⚠️ Data Quality Notes:
- 3 rows skipped: missing Employee Name (rows 5, 12, 18)
- 1 suspicious value: "Bob" shows 95 hours in week of Jan 8 - please verify
- Analysis proceeds with 47 of 50 rows

Continue analysis with valid data. Don't silently produce results from bad data.

Data Confidence

Analysis confidence depends on sample size. Include appropriate caveats in output.

Sample Size Thresholds

Dimension Limited Confidence Good Confidence
Time period < 4 weeks 4+ weeks
Team size < 3 people 3+ people
Data points per person < 3 entries 5+ entries

Confidence Language for Output

Limited confidence (< 4 weeks or < 3 people):

⚠️ Limited Data: This analysis covers [X weeks / X people]. Patterns may not be representative. Consider collecting more data before taking action.

Single-person dataset:

⚠️ Individual Analysis Only: With one person, team distribution and comparison metrics are not applicable.

Sparse data (few entries per person):

⚠️ Sparse Data: Some team members have limited data points. Trends for [names] may not be reliable.

When to Recommend More Data

  • If < 2 weeks: "This snapshot is too brief for trend analysis. Re-run after 4+ weeks for meaningful patterns."
  • If < 3 people: "Team distribution requires at least 3 members. This shows individual metrics only."
  • If missing key columns: "Without [hours/dates/assignee], [specific analysis] isn't possible."

Analysis Guidelines

See sliceData Analytics Guidelines for complete analysis principles. Key points for manager data:

  • Numbers indicate, conversations confirm — Don't diagnose individuals from data alone
  • Protect privacy — Aggregate where possible; be careful sharing individual metrics
  • Directional, not definitive — These are signals to investigate, not verdicts to act on