Availability and Capacity

Capacity vs. availability

Capacity is a structural number: how much work a person could absorb in a given week if everything else were ideal. It is roughly constant for a given role and tenure. It does not change much from one week to the next.

Availability is a situational number: how much work this person can absorb this specific week, given what is already in flight, scheduled focus blocks, leave, and standing commitments. It changes constantly.

Most organizational pain comes from using capacity as if it were availability. A team member has the capacity to take on another project; that does not mean they are available. The lesson Kavanah enforces is that availability — not capacity — is the input to assignment.

Availability requests — the leader-initiated flow

When you (the leader) need to know who is free for a new initiative, you create an availability request. The request can be workspace-wide ('who has 20% of their week free for the new auth project?') or project-scoped ('Mobile App v2 — who can take on a 3-day spec sprint?').

The request goes to the relevant members and asks them to respond. Each response has a structured answer — available, partial, unavailable — and an optional note. Responses land in the Resources tab on /portfolio, where you can see who said what and decide.

This flow exists for one reason: it is honest. Asking 'who has bandwidth this week?' in a chat thread produces social answers — the strongest contributors say yes because they cannot bring themselves to refuse. A structured availability request gives the same people permission to say 'partial' or 'unavailable' without it sounding like a refusal of help. The structure removes the social cost.

Standing availability entries — the member-initiated flow

Members can also create standing entries — patterns that hold over time, not tied to a specific request. 'I am head-down on the platform migration through the end of the month.' 'I am on parental leave from May 12.' 'I do focus work on Mondays and Tuesdays; ad-hoc work is fine Wed–Fri.'

Standing entries are visible to leaders in the same Resources view and are used by the recommend_assignees tool to filter the candidate pool. A member with a 'no new work this month' standing entry will appear in the recommendation with a clear flag — not invisible, because the leader might still need to know who is the best capability match, but not at the top of the rank.

Standing entries are also what make availability sustainable. Without them, members re-explain their situation every time a request comes in. With them, the system already knows.

Active load — the metric that does the work

The most useful single signal in the availability model is not 'is this person available' but 'what is their current active load?' — the count of tasks they have in progress, weighted by estimated remaining time.

Active load is computed continuously. The recommend_assignees tool uses it as a soft cap: candidates above a threshold are deprioritized in the ranking unless the leader explicitly overrides. The threshold is configurable per workspace; a healthy default for a small team is two to three active tasks per person, with the explicit understanding that three is the upper bound, not the target.

Why is the upper bound three? Because beyond three active tasks the cost of context-switching exceeds the value of additional work in flight. The team's measured throughput goes up if you keep most members at one to two active tasks at a time and let them complete-and-pull instead of accumulating partial work.

The workload variance metric — the coefficient of variation of active task count across the team — is the workspace-level version of this. High variance means a few people are carrying disproportionate load. The fix is not to add more variance ('let them keep going, they're crushing it') — it is to redistribute, even at the cost of some short-term context-loss, because the alternative is burnout plus a brittle bus number.

How capability and availability compose

The recommend_assignees tool produces a single ranked list. The ranking is, simplifying slightly, capability_score × availability_modifier.

Capability_score is the max of declared and learned strength on the relevant skills, with a small bonus for recent work in the same project.

Availability_modifier is the multiplier from active load and standing entries — 1.0 for a member who is fully available, 0.5 for someone with two active tasks of similar size, 0.0 for someone with an explicit 'unavailable' standing entry covering the current date.

The leader sees the score, the reasons, and an explicit availability flag. If the top capability match is unavailable, the recommendation surfaces both — 'top capability: Sarah Chen, unavailable; recommended: Marcus Johnson' — so the leader can decide whether to wait for Sarah or proceed with Marcus.

This composition is also the basis for the override metric: when the leader picks someone other than the recommendation, the system asks (quietly, in the audit log) what factor drove the override. The most common factors — coaching reasons, project continuity, client preference — are useful patterns to surface and discuss in retros.