The problem: invisible overload until something breaks
Delivery failures often start with silent overload: one engineer on three critical paths, a designer across five launches, a PM accepting work because nobody sees the pile. Spreadsheets update monthly; gut feel says "everyone is busy."
By the time someone says "we're underwater," deadlines slipped, quality dropped, and the fix is overtime — not rebalancing.
AI workload analysis should make load visible early and suggest where to look — not auto-reassign tasks without human judgment.
Why asking in chat does not scale
Social pressure — People say yes in public channels.
Hidden WIP — Off-board tasks, "small favors," and approval waits never total.
No horizon — Busy today ignores next week's committed sprint.
AI guessing names — Generic chat invents assignees; you need open-task data per user.
Workload analysis needs demand mapped to people with remaining estimate and a two-week horizon.
Framework: capacity → demand → heat → conversation
1. Capacity — Realistic hours per week per person. Subtract meetings, support, context-switching — 40 calendar hours ≠ 40 delivery hours.
2. Demand — Open tasks with remaining estimate. Include approvals waiting and carryover — not only board-visible coding tasks.
3. Heat — Map demand against capacity. Green = headroom; amber = watch; red = scheduled beyond the week.
4. Conversation — Heatmap starts rebalance talk; humans decide skill fit, growth goals, and political context.
AI via MCP can summarize: "Who has the most remaining hours this week on Project Atlas?" — citing workload_heatmap output, not inventing names.
| Cell color | Meaning | Manager action |
|---|---|---|
| Green | Headroom | Can absorb small urgent item |
| Amber | Tight | Defer low priority or pair |
| Red | Overloaded | Reassign, cut scope, or escalate staffing |
Where WKFGo fits: workload_heatmap
WKFGo workload_heatmap shows open tasks and remaining estimated hours per user — useful when staffing a sprint or answering "who can take this?" without polling the whole team.
Combine with:
portfolio_overview— cross-project overload for matrixed teamstime_summary— calibrate whether estimates chronically underestimate for a person or work typelist_tasksfilters via MCP — drill into what drives red cells
AI-assisted workload review
Prompt examples (MCP-connected):
- "Summarize workload heatmap for Team Platform — list top three overloaded users with task IDs"
- "Compare remaining hours next week vs last week for release train 12"
Assistant retrieves structured data; manager validates skill and blocker context.
Fixing overload without heroics
Rebalance before re-estimating — Moving one task off a saturated person often beats renegotiating the entire roadmap.
Protect focus blocks — Ten small tasks can destroy throughput despite looking lighter than three epics.
Fix estimates at source — Chronic red on the same person may mean optimistic estimates or ignored dependencies.
Escalate scope, not people — If heatmap stays red after rebalance, cut scope, extend timeline, or add capacity.
Review weekly — Five-minute heatmap scan beats monthly spreadsheet archaeology.
What heatmaps do not do
They do not replace conversation about blockers, learning curves, or waiting on legal.
They do not punish visibility — culture must reward honest WIP.
They do not ignore skills — two people with same hour count are not interchangeable.
Getting started this week
Pick one project that missed a date recently. Open workload_heatmap, list top three people by remaining hours, compare with who was named "blocker" in the postmortem. Mismatch reveals hidden work or bad estimates. Share the chart in next sync — ask who can swap tasks or defer scope. Repeat two weeks before changing roles or hiring.
Matrixed teams: always check portfolio_overview — single-project heatmaps lie when people serve three products.
Anti-patterns
- Auto-assign from AI without facilitator review
- Heatmap as individual performance scorecard
- Ignoring cross-project load in siloed views
- Red cell + new assign anyway — policy without enforcement
Workload analysis once a quarter is too late. Run workload_heatmap before sprint planning and after any unplanned escalation. Compare remaining hours to calendar capacity—AI narrates overload; managers assign_task or defer with stakeholder visibility.
FAQ
Do we need time tracking for workload analysis?
Remaining estimates on open tasks are enough to start; logging improves calibration.
Can AI suggest who should take a task?
AI can list capacity headroom; final assign needs human skill and context judgment — use assign_task after review.
How is this different from Gantt?
Gantt schedules when; heatmap shows who carries how much across time.
Small teams too?
Yes — when one person is the entire backend, overload hits fastest.
Analyze load before the slip
Use workload_heatmap and AI synthesis for honest workload analysis — visibility first, rebalance second, heroics never.
Try it now
Put these patterns on live project data—not slide decks.