Workload management: distributing work without burning people out

Workload management is how work is distributed across a team so that nobody is quietly drowning and nothing important is unstaffed. It differs from capacity planning, which asks whether the team as a whole can take on more; workload management asks who specifically is carrying what, this week, and whether that is sustainable.

The reason it fails is rarely bad intent. It is that load is invisible: a manager sees the tasks assigned, not the ones absorbed informally, not the support requests, not the person who is the unofficial reviewer for everyone else. The first job is making the real distribution visible, and the second is being willing to change it.

What makes workload visible

• One place where all work in progress is shown, per person. Work tracked in three tools is work that is not tracked.
• A limit on how many things one person has in progress at once. Three is a lot; five is a person who finishes nothing.
• Size or effort on each item, even roughly — small, medium, large. Counting tasks treats a two-hour fix as equal to a two-week build.
• Blocked items marked as blocked, because a blocked task occupies attention without producing progress.
• The invisible work named: support rotas, reviews, interviews, mentoring, incident response. This is often a third of someone's week and appears nowhere.
• Due dates only where they are real. Every item having a date is the same as none having one.
• A weekly moment where the distribution is actually looked at, rather than assumed.

Work-in-progress limits do more for workload than any amount of prioritisation. A person with three open items finishes them; a person with eight switches between them, finishes none this week, and reports being extremely busy — which is true and also the problem. Cap the in-progress column and the queue becomes visible instead of hidden inside individuals.

Running it weekly

1. Get everything onto one board with an owner and a rough size. Work not on the board is invisible by definition.
2. Set a work-in-progress limit per person and hold it. New work waits in the queue rather than starting.
3. Look at the board by person once a week, not by project. Project views hide individual overload perfectly.
4. Ask about the unassigned load explicitly — support, reviews, meetings — rather than assuming the board is complete.
5. Move blocked items out of in-progress so they stop counting as capacity being used.
6. Rebalance actively: reassign, sequence, or drop. A review that identifies overload and changes nothing teaches people not to raise it.
7. Watch for the person who never says they are overloaded. They are usually the one who is.
8. Look at trends monthly — if the same person is at the limit every week, that is a staffing or scope problem, not a scheduling one.

Overload is a system signal

When one person is consistently overloaded, the instinct is to help them prioritise. Sometimes that is right. More often it means the work is not distributed because only they can do it — a skills concentration — or because the team has taken on more than it can carry and the overflow lands on whoever is least able to refuse. Both are decisions for the manager rather than problems for the individual, and treating them as time-management coaching is how good people leave.

Ettex Board makes the distribution visible: columns and cards with drag-and-drop, assignees and avatars so a per-person view is a filter rather than an exercise, colour labels and priority flags, due dates, checklists inside cards, lists and swimlanes for larger boards, and WIP limits to keep flow honest — the single most useful feature here. Every move and edit is logged per card and the board updates live for everyone. Effort estimates and the trend over weeks fit Ettex Sheets, recurring commitments like support rotas belong in Ettex Calendar so they stop being invisible, and the one-to-one where overload is actually raised is best kept in Ettex Notes.

Said plainly: Ettex has no workload analytics. There is no automatic capacity calculation per person, no burndown or velocity, no time tracking to measure real load, no alerts when someone is over a threshold, and no resource-levelling. The board shows what is assigned; whether that is too much is a judgement made in a weekly conversation. For a small team that conversation beats the metric anyway.

Sharing desks needs tooling once capacity is contested. Hot desk software shows what is free on a floor plan, releases no-shows and reports occupancy by day, which is what makes a flexible office workable rather than a daily search.

Capacity is only half the question; the other half is sequence. Ticket triage decides what gets looked at first, and arrival order carries no information about which problem is expensive.

Signals workload is unmanaged

• Everything in progress and little finishing — the classic signature of no WIP limit.
• Work tracked in several places, so no view is complete.
• Tasks counted rather than sized, making a full plate indistinguishable from a light one.
• Support, reviews and meetings absent from the board while consuming half the week.
• The same person late repeatedly, treated as an individual performance issue.
• Overload raised in a review and nothing reassigned afterwards.
• Blocked items sitting in progress for weeks, occupying attention and hiding real capacity.
• Rebalancing that only happens when someone finally says they cannot cope.

Workload management needs one board, a WIP limit, sizes rather than counts, and a weekly look by person. When the same name is at the limit every week, that is a staffing decision — not a prioritisation lesson.