HEAT Framework

Appearance

The Three Views ​

"One data source. Three perspectives. Complete visibility."

HEAT generates three complementary views from a single tagging system, each optimized for different stakeholders and use cases.

View 1: Developer View (Personal Board) ​

Audience: Individual contributors Purpose: Self-awareness and personal capacity planning Update frequency: Real-time

What You See ​

  • Personal heatmap calendar — Your effort distribution over time
  • Streak tracker — 🔥 indicators when you're grinding too long
  • Tag history — What you actually worked on (vs. what you planned)
  • Intensity trends — Are you overloading consistently?

Sample Interface ​

Your Week (Nov 25 - Dec 1):
┌────────┬─────────┬────────────┬──────────────┐
│  Day   │ Intensity│  Color    │ Streaks      │
├────────┼─────────┼────────────┼──────────────┤
│ Monday │   14    │ 🟩 Normal  │ -            │
│ Tuesday│   28    │ 🟨 Heavy   │ 🔥 Day 2 (SQL) │
│ Wed    │   36    │ 🟥 Critical│ 🔥 Day 3 (SQL) │
│ Thursday│  12    │ 🟩 Normal  │ -            │
│ Friday │   18    │ 🟩 Normal  │ -            │
└────────┴─────────┴────────────┴──────────────┘

Tag Breakdown:
├── Blocker (SQL): 72 intensity units (65%)
├── Feature (API): 18 intensity units (16%)
├── Support: 10 intensity units (9%)
└── Config: 11 intensity units (10%)

Insight: You spent 65% of your week stuck on SQL blockers.
Recommendation: Consider asking for help if blocker persists.

Use Cases ​

  1. Self-assessment: "Am I taking on too much?"
  2. Planning: "I'm at 40 intensity mid-week — pace myself tomorrow"
  3. Communication: "I can't take new work — my heatmap shows I'm critical"

View 2: Manager View (Team Heatmap) ​

Audience: Team leads, engineering managers Purpose: Proactive intervention and load balancing Update frequency: Daily snapshots, weekly aggregates

What You See ​

  • Team heatmap matrix — Effort concentration across all team members
  • 🔥 Burnout alerts — Streak warnings requiring intervention
  • Bus factor indicators — Knowledge concentration risks
  • Project filters — Isolate by billing code, epic, or module

Sample Interface ​

Team Heatmap (This Week):
┌─────────┬────────────┬────────┬───────────┬──────────────┐
│ Developer│ Total Int. │ Color  │ Streaks   │ Bus Factor   │
├─────────┼────────────┼────────┼───────────┼──────────────┤
│ Alice   │    48      │ 🟥 Crit│ 🔥 Day 5  │ Payment (95%)│
│ Bob     │    12      │ 🟩 Norm│ -         │ Balanced     │
│ Carol   │    24      │ 🟨 Heavy│ 🔥 Day 2 │ Auth (80%)   │
│ Dave    │    38      │ 🟥 Crit│ -         │ UI (70%)     │
└─────────┴────────────┴────────┴───────────┴──────────────┘

Alerts:
├── 🔴 Alice: 5-day streak on Payment module (intervention required)
├── 🟡 Carol: 2-day streak on Auth service (monitor)
├── 🟠 Dave: High intensity, no streak (check for overload)
└── 🔴 Bus Factor: Payment module has single owner (Alice)

Recommended Actions:
1. Pair Bob (low load) with Alice on Payment (immediate)
2. Assign senior dev to help Carol with Auth blocker
3. Redistribute Dave's upcoming tasks
4. Schedule Payment module knowledge transfer session next sprint

Use Cases ​

  1. Burnout prevention: Intervene at 🔥 Streak: 3 days (not Day 10)
  2. Load balancing: "Bob is at 12, Alice is at 48 — redistribute"
  3. Knowledge risk: "Only Alice touches Payments — cross-train now"
  4. Capacity planning: "Team baseline is 15/day — we're at 22 this week"

View 3: Tag Analysis (Strategic Trends) ​

Audience: Engineering leadership, architects, product owners Purpose: Identify systemic issues and strategic patterns Update frequency: Weekly or monthly aggregates

What You See ​

  • Global tag aggregation — What is the team actually doing?
  • Daily vs Weekly toggle — Operational (daily) vs strategic (weekly) view
  • Drill-down capability — Click tag → see every task/developer contributing
  • Trend analysis — How has tag distribution changed over time?

Sample Interface ​

Team Tag Analysis (Last 30 Days):
┌──────────┬─────────────┬────────────┬──────────────┐
│ Tag Type │ Intensity   │ % of Total │ Trend        │
├──────────┼─────────────┼────────────┼──────────────┤
│ Feature  │    840      │    35%     │ ↓ Down 10%   │
│ Blocker  │    720      │    30%     │ ↑ Up 45%     │
│ Support  │    480      │    20%     │ → Stable     │
│ Config   │    240      │    10%     │ ↑ Up 120%    │
│ Research │    120      │     5%     │ ↓ Down 60%   │
└──────────┴─────────────┴────────────┴──────────────┘

Alerts:
├── 🔴 Blocker intensity up 45% (systemic issue — recent deployment?)
├── 🔴 Config intensity up 120% (environment breaking frequently?)
├── 🟡 Feature work down 10% (innovation capacity shrinking)
└── 🟠 Research down 60% (team in reactive mode)

Insight: Team shifted from 40% Feature work to 30% Blocker work.
Root Cause Hypothesis: Recent microservice migration introduced instability.
Recommended Action: Halt new features, stabilize platform first.

Use Cases ​

  1. Systemic diagnosis: "Config spiked 500% → environment is broken"
  2. Innovation capacity: "Only 30% Feature work — rest is firefighting"
  3. KTLO ratio: "Support + Config = 60% → automation needed"
  4. Strategic planning: "Blocker work increasing trend → tech debt sprint"

How the Views Work Together ​

Example Scenario: Payment Bug Crisis ​

Day 1 (Monday) ​

  • Developer View (Alice): Tags "Payment bug" as Blocker, SQL, x7
  • Manager View: No alert yet (first occurrence)
  • Tag Analysis: Blocker intensity within normal range

Day 3 (Wednesday) ​

  • Developer View (Alice): Still working on Payment bug, now x9
  • Manager View: 🔥 Alert: Alice Streak: 3 days (intervention threshold)
  • Tag Analysis: Blocker intensity ticking up slightly

Manager Action (Wednesday afternoon) ​

  • Reviews Alice's streak in Manager View
  • Clicks Alice's name → sees she's been stuck on "Payment SQL deadlock"
  • Pairs Bob (currently low load) with Alice
  • Result: Bug resolved by Thursday

Day 7 (End of week) ​

  • Developer View (Alice): Streak ended Day 4, intensity back to normal
  • Manager View: Alice recovered, Bob learned Payment module (Bus Factor: 2 now)
  • Tag Analysis: Blocker intensity spike resolved, back to baseline

Without HEAT: Alice grinds for 10 days, burns out, considers quitting. With HEAT: Intervention on Day 3, crisis averted.

Customization by Role ​

For Developers ​

Default view: Personal board only (privacy-first) Optional: Share heatmap with manager (opt-in) Privacy: Only you see your streaks unless you choose to share

For Managers ​

Default view: Team heatmap + alerts Filters: By project, team, time range Drill-down: Click developer → see their tag distribution Reports: Weekly summary emails with 🔥 streak count

For Leadership ​

Default view: Tag Analysis (strategic trends) Aggregation: Roll-up by department, product area Metrics: Feature vs KTLO ratio, Blocker trends, Research investment Alerts: Systemic issues (Config spike, Blocker surge)

Technical Implementation ​

All three views are generated from the same data model:

typescript
interface WorkItem {
  id: string;
  taskId: string;      // From existing PM system
  taskTitle: string;
  projectId: string;
  timestamp: string;
  userId: string;
  tags: Tag[];         // Work type + intensity
}

// Developer View query
const personalHeatmap = aggregateByDay(
  workItems.filter(item => item.userId === currentUser)
);

// Manager View query
const teamHeatmap = aggregateByUser(
  workItems.filter(item => item.teamId === currentTeam)
);

// Tag Analysis View query
const tagTrends = aggregateByTag(
  workItems.filter(item => item.timestamp > last30Days)
);

No separate systems. One source of truth. Three perspectives.

Next Steps ​

🔥 Pain Streak Algorithm — How burnout detection works

👁️ Observable Signals — What to tag and when

🏗️ Integration Architecture — How HEAT connects to your PM system

🎮 Try the Interactive Demo — Experience all three views with sample data

"One tagging system. Three complementary views. Complete visibility from individual to strategic." 🔥