Module 3 — Right Person, Right Work · Lesson 3.1
Assignment Is the Highest-Leverage Decision a Manager Makes
Why who-does-what beats every other lever, and why most teams get it wrong
~11 min
What you'll learn
- Articulate why assignment has higher leverage than direction or feedback
- Recognize the three default failure modes of assignment in fast-moving teams
- Decompose the assignment decision into capability, availability, and choice-of-doer
- Set up the conditions under which capability-aware assignment can actually work
Of the four primitives, allocation is the one most managers under-invest in. Direction gets lots of airtime because it produces strategy decks. Feedback gets airtime because it produces dashboards. Consequence gets airtime because it produces promotions and firings. Allocation — who does what next — produces nothing visible. It just makes everything else work, or quietly fails to.
The compounding cost of bad assignment
Direction errors are usually correctable inside a week. You announce a new outcome, the team pivots, and within five working days everyone is pointed at the new thing. The cost of the misdirected week is real but bounded.
Allocation errors compound. Once a person has been pointed at a problem, they accumulate context that does not transfer cleanly. After two weeks they know things nobody else on the team knows, and pulling them off is no longer a free move — you lose the context, the half-built code, the relationships with the customer they have been talking to. After four weeks the cost of reassignment is high enough that most managers do not pay it, and the wrong assignment becomes permanent.
The compounding cost is why allocation deserves disproportionate care up front. A two-minute conversation about who should pick up a task can save four weeks of accumulated wrong-context debt. A two-second default to 'whoever volunteered first' can create it.
Three default failure modes
Most fast-moving teams default to one of three assignment patterns, all of which produce systematic miscasting.
First is 'whoever spoke last.' The task gets handed to whoever was in the room and seemed willing. This is fast, polite, and approximately wrong: it routes by social fluency, not by capability. The strongest contributors end up with all the work because they cannot bring themselves to refuse.
Second is 'whoever is closest to the problem.' If the bug came up in the support channel, support gets it. If the question came from sales, an SE gets it. This is reasonable for problems that genuinely live close to their reporter and disastrous for problems that have leaked across boundaries — which most interesting problems have.
Third is 'whoever has the bandwidth.' The task lands on whoever has the most empty calendar that week. This is the worst of the three because it optimizes for utilization, which is not a managerial good — it is a side effect of good allocation, not a substitute for it. A high-utilization team mis-matched on capability produces a lot of competent work on the wrong things.
All three default patterns have one thing in common: they do not consult any data about capability. Kavanah's whole assignment system is built on the premise that the data is available, and that consulting it deliberately produces a different (and better) assignment than any of the defaults.
Decomposing the decision
There are exactly three sub-decisions in assignment. The next three lessons take each in turn.
Capability. Of all the people (and AI Employees) who could do this work, who has the right combination of declared skills, demonstrated track record, and access to the context the work requires? This is the question the skills system answers.
Availability. Of those capable, who actually has the time — accounting for current load, scheduled focus blocks, leave, and standing commitments? This is the question the capacity and availability system answers.
Choice of doer. Even among capable, available humans, when should the work go to a human versus an AI Employee? This is the question the persona system asks; it is also the question that has changed the most in the last three years.
The agent's recommend_assignees tool composes all three. The manager's job is to read the recommendation and either accept it or override with reason. The override pattern — what kinds of context cause managers to overrule the recommendation — is itself a useful signal; we cover it as a metric at the end of the module.
What has to be true for the system to work
Capability-aware assignment requires the system to have data about capability. If members have not declared skills, the recommendation engine has nothing to route by, and the recommendation collapses to a noisy proxy (recent throughput, or whoever shipped a similar-looking task last). This is the single most common failure mode of skill-based routing in practice: it is set up, but the inputs are missing, and within a few sprints the team stops trusting it.
The setup discipline is straightforward and was covered in Module 1.4. Every active member declares at least three skills, at least one of which is the skill they want to be known for. The reinforcement loop fills in over time as tasks ship — the system gets smarter the more the team works.
The second precondition is that the workspace tolerates explicit refusal. Members must be able to say 'I am not the right person for this' without social cost. The skill system gives them the language to do it cleanly: 'I am Learning at this skill; X is Proficient.' If the workspace culturally penalizes the refusal, the routing data is correct but the social cost overrides it, and you are back to 'whoever spoke last.'
Audit your current assignment pattern
- 1
Open the Resources tab in /portfolio
Look at the current distribution of tasks-per-member. If it is bimodal — a few people overloaded and a few under-used — your defaults are mis-routing.
- 2
Confirm skill declarations are in
On /people, every active member should have at least three declared skills.
- 3
Pick a recent task and run recommend_assignees
From the AI agent, ask: 'who should own this task?' Compare the recommendation to who actually owns it.
- 4
Notice the deltas
Every delta between the recommendation and the actual owner is a place where your defaults are choosing for you. Some will be right; some will not.
Assignment-system readiness
- Skill-declaration coverage
- Fraction of active workspace members who have declared at least three skills.
- Healthy signal: Above 90%. Below 60% means the recommender has nothing to work with.
- Workload variance
- Coefficient of variation across team members on active task count. High variance = lumpy assignment.
- Healthy signal: Under 0.5. Above 1.0 means a few people are carrying disproportionate load.
- Recommendation acceptance rate
- Fraction of recommend_assignees outputs that get accepted as the actual assignee.
- Healthy signal: 60–80%. Below 40% means the recommender's inputs (skills, history) are stale.
Key takeaways
- ·Allocation errors compound at the highest rate of any primitive.
- ·Default assignment patterns (last to speak, closest to problem, most available) route by social or temporal proximity, not by capability.
- ·The assignment decision decomposes into capability, availability, and human-vs-AI.
- ·Capability-aware assignment requires declared skills and a culture that tolerates explicit refusal.
Capability comes first because it is the input the others depend on. The next lesson is the full picture of how Kavanah models capability — declared, learned, and reinforced — and what that buys you in routing.