An empty square tells you someone is free. It does not tell you they should take the work, or what moving them will disturb.
Watching “The Odyssey” last week, I was reminded of the resource-assignment-failure that caused so many deaths on the Sigeuan shore. Removing Achilles from command, Agamemnon took direct control of the war and had other leaders like Diomedes, Odysseus, and Ajax lead the front-lines (in the Iliad). It took serious damage and the death of Patroclus to bring Achilles back in charge, leading to the Trojans being beaten back after Hector’s death. Like a bad manager abusing authority, Agamemnon’s resource-reassignment had tremendous negative consequences. And the Greeks learnt that the hard way over the following weeks, as the Trojans pushed them back to their own ships. When Achilles finally returned the position reversed almost immediately — and that is the part that makes this a resourcing story rather than a war story, because the Greeks had never been short of soldiers. They were short of one person with a particular set of skills and no quantity of available headcount had covered it.
The modern version of this is quieter (no killings, thankfully) and happens continuously. You have a capacity view that shows who is free; someone reads an empty square on it as an answer and the reassignment that solves this project’s problem creates another one somewhere you will not see until much later.
A good capacity view is genuinely useful, but let’s be clear about what it actually does. It compares demand against assignments, so you can see where work is stacked against people who are already committed. It shows availability, including shifts and PTO, so you are not planning around someone who is out. It surfaces over-allocation and underutilization — the two failures nobody notices until a delivery date moves or an invoice comes in thin.
The challenge is, all of that answers one question — who has room — and the question you actually have is different. You need to know who should take this work, which is not the same thing. An empty square tells you a person is unbooked. It does not tell you they can do the task in question and it does not tell you what happens to everything else if you move them. So a capacity view is an input — a very important one, at that. But turning it into a recommendation takes three additions and each one is a decision your organization has to make before any tool can help with it.
The first gap between availability and viability is qualification. Being unbooked on Thursday is a fact on a calendar. But being able to take over a half-finished integration for a regulated customer is a fact about a person — their role, their skills, the certifications the work requires and whether they have any context on that account at all. Only some of this is recorded when a lot of it is not, which is where staffing decisions can go wrong. Role and availability are almost always in the system. Skills are usually in the system but often stale, because nobody updates a skills record on the day they learn something. Certifications tend to be accurate when the work legally requires them but vague when it does not. And account context — who has spoken to this customer before, who knows why the last change was made the way it was, for example — is frequently in nobody’s system at all. So a recommendation built on those records is only ever as good as the records themselves. A system can compare work against qualifications and flag a missing certification or a skills gap, but it cannot know a skill nobody wrote down. If your skills data is three years old, better tooling will simply help you make the wrong swap faster.
The second addition is the one that gets skipped — maybe call it “the Patroclus problem”: when you assign someone to new work, you are simultaneously removing them from whatever they were doing and the plan almost never shows what that costs. Think about what a reassignment actually disturbs:
None of those show up as a conflict on a calendar. They show up later, as a delivery date that moves for reasons nobody connects back to a staffing decision made three weeks ago. So the useful form of a recommendation is not “Patricia is available” — it is “Patricia can take this — and here is what moving her disturbs.” The second half is what separates a recommendation from a suggestion — a half tools rarely document. And for good reason (if “good” is a word we can use here): producing that second half needs three things a scheduling view usually keeps apart: what the person is currently assigned to, what depends on that work and what those dependencies are worth. Most systems hold all three but never connect them; the dependency graph lives with the project plan, the assignments live with the resource view, the rates live with billing. Join them and the disturbance becomes measurable: which tasks slip, by how long, on whose project and what that costs.
The third addition is organizational rather than technical. Once you can see the trade-off, somebody has to be entitled to accept it — someone with authority AND visibility. This is where a lot of resourcing stalls. A delivery lead can see that moving one person solves their problem and creates a smaller one on a project they do not own. They are not authorized to accept a cost on somebody else’s behalf, so either the decision escalates (slowly) or it happens informally (quickly, and without the affected project finding out until it matters). Agamemnon, for example, had the authority. What he did not have was any account of what the decision would cost, and authority without that is just speed. So it’s critical to state WHO can accept a trade-off that lands on another project — identified by value, by customer tier, whatever makes sense for you — and what the affected owner is entitled to be told. This is the same shape as the ownership rule in our piece on ticket triage: a decision is not really owned until you can name who makes it and what happens when they do not.
With those three decisions documented, automation has real work to do — work that automation is good at. Watching for shortages and overloads before a delivery date starts moving is a weekly discipline that needs automated consistency. Narrowing a whole organization down to the few people genuinely qualified for a piece of work is tedious when done by hand. But presenting a candidate with the basis attached — available hours, current assignments, what the move would affect — turns a name into a proposal you can discuss.
One function that can make a difference is simulation: run the reassignment against the plan before the plan changes. We know the damage choosing the wrong person can do. But even with the right person, seeing the second-order effect until it happens is critical and a simulation puts that effect in front of you while it is still reversible.
There is another capability worth asking for too — one more that the Greeks needed. A system that knows who holds which skill AND which tasks sit on the critical path, can tell you where exactly a specific qualified person stands between now and a delivery date. That is the gap a roster cannot show, because a roster counts people and this is not a shortage of people. You want to find those gaps before someone resigns or books three weeks off, not after. And unlike most of what gets called workforce analytics, this is a plain query over records you already keep.
One caution, whatever mechanism you use: if a system surfaces something like burnout risk, treat it as a signal derived from workload and allocation patterns, useful for prompting a conversation. Not as a prediction about that person.
Here is the boundary that must govern most decisions: proposing a staffing option is not making a staffing change. Simulating a reassignment is not executing one. A shortlist that is wrong costs a delivery lead the two minutes it takes to reject it. But an assignment that is wrong moves a real person off real work and the cost lands on a project that can’t undo it by clicking something. In invoicing we drew the same line between preparing an invoice and sending one and in ticketing, between drafting a reply and sending it. Different process, same principle: between preparing something and committing to it is where a human belongs. In practice, this means that things like proposing, matching, shortlisting and simulating should all be unrestricted, running at great speed. But changing who is assigned to what should not be. That is not a limitation on the automation; it is what lets the automation do everything else at full speed.
Take a staffing change your team made in the last month, and answer these against it.
If question two is hard to answer, that is the gap this article is about: not a tooling gap but a decision that was never documented. And if question five has an uncomfortable answer, that is worth resolving before the next reassignment.
The Greeks finally had it all figured out — after a war, a funeral and about ten years. Not the kind of time or cost we can take on projects, do we now?
Bring one reassignment from the last month, what it disturbed, and who signed it off.