Every services organisation has a bench — people between projects, waiting on a client start date, rolling off an engagement that ended early, or parked because the skill they have and the skill the market wants have drifted apart. The bench is not a defect. It's the cost of being able to say yes to work you haven't won yet.
What is a defect is not knowing anything useful about the people on it.
The usual state of affairs is a spreadsheet with a name, a skill string, a rate, and a date. That tells you who is unallocated. It tells you nothing about what to do about it. So the conversation in the weekly review becomes a series of individual negotiations, driven by whoever in the room happens to remember something about that person. Decisions don't accumulate. Six weeks later you have the same conversation about the same person, and nobody can reconstruct why the last one went the way it did.
PDR is one way out of that. It's a small idea, and most of the value is in the discipline it forces rather than the taxonomy itself.
The three dispositions
PDR classifies each person on the bench against three questions:
Promotable — is this person ready to move up a level? Not "are they good," but: is there evidence they are already operating above their current band, and would a promotion make them easier to place at a higher billing rate?
Deployable — can this person be put on billable work as-is, right now, with no intervention? This is the most misread of the three. Deployable is not a compliment. It means the skills match live demand and there is nothing blocking a start.
Rotatable — should this person move to a different technology, domain, or vertical? Rotation is the answer when someone is capable but their current specialisation has no pipeline behind it.
The point of three separate axes is that they are not mutually exclusive and they are not a ranking. Someone can be promotable and rotatable — a strong senior engineer in a dying stack. Someone can be deployable but not promotable — solid, well-matched, not ready for the next band. Someone can be none of the three, and that is the most important signal the framework produces, because it means the situation needs a decision that isn't "wait."
The moment you collapse this into a single label — a tier, a grade, an A/B/C — you lose exactly the information you built the system to capture.
The process
1. Intake
Bench entries come from allocation data, not from manual entry. If someone has to remember to add a person, the list will be wrong within a week. The system should derive the bench from the absence of active billable allocation, then let humans annotate.
Intake also needs a start date for the bench period. Aging is the single most predictive field you have, and it only works if the clock starts automatically.
2. Assessment
Someone with actual knowledge of the person marks the three flags. This is usually a delivery lead or a resource manager, not HR and not a tool.
Two design decisions matter more than they sound:
Unassessed must look different from assessed-and-negative. "Not promotable" and "nobody has looked at this yet" are completely different facts, and a UI that renders both as an empty checkbox will quietly destroy your data quality. Blank means unknown. Show it as unfinished.
Every negative or unusual combination needs a justification. Not a dropdown — free text, required, at the point of assessment. This is the gate that turns the framework from a labelling exercise into a decision record. It also slows people down, which is the intended effect. If marking someone as not deployable takes two seconds, it will be done thoughtlessly and often.
3. Action
A classification with no downstream action is theatre. Each disposition should route somewhere concrete:
- Promotable → into the next promotion cycle with the justification attached as evidence
- Deployable → into active matching against open demand
- Rotatable → into a reskilling track with a named target skill and a timeline
- None of the above → escalation, with a review date
The fourth case is the one organisations avoid building. It's also the one that determines whether the whole exercise is honest.
4. Audit
Every assessment change is appended, never overwritten. Who changed what, when, from what to what, and why. Append-only, no edits, no deletes.
This is non-negotiable for two reasons. The obvious one is that these records touch promotion, reassignment, and eventually separation decisions, and you will be asked to explain them. The less obvious one is that the history is where the actual insight lives. A person marked rotatable four quarters running, with four justifications, is telling you something about your reskilling programme, not about the person.
What actually goes wrong
Coverage gets measured instead of accuracy. "94% of the bench is assessed" is a number that goes up when people click things. It says nothing about whether the assessments are right. Coverage is a hygiene metric — worth a single indicator, not a dashboard. If your reporting makes coverage the headline, you have built an incentive to fill in boxes.
Deployable becomes the default. Marking someone deployable is the path of least resistance: it's positive, it needs no justification, it moves the problem to the matching team. Watch the distribution. If deployable is running above 70% of assessed bench while placement rates stay flat, the flag has stopped meaning anything.
Assessments go stale. A three-month-old assessment is a guess. Build in expiry — an assessment older than a defined window reverts to unassessed rather than continuing to display as fact. People will hate this. Do it anyway.
Rotation is recommended without capacity to deliver it. Marking someone rotatable is free. Actually retraining them costs money, bench time, and a mentor. If rotation recommendations exceed reskilling capacity by 5x, the flag is a way of deferring a harder conversation.
The framework gets used as a performance tool. PDR describes market fit and placement readiness. It is not a performance rating, and the two must not be joined. A high performer in a technology with no demand is not deployable, and if your system lets that read as a performance signal, you will lose good people and deserve to.
The honest framing
PDR is a decision-forcing device, not an optimisation engine. It won't tell you what to do with anyone. What it does is make the absence of a decision visible — an unassessed row, a stale assessment, a person marked rotatable for three quarters with no training assigned. That visibility is uncomfortable, which is the entire point, and it's also the reason most implementations quietly drift toward measuring completion rates instead.
If you're building something like this, the test isn't whether the dashboard looks good. It's whether the weekly bench review is shorter and produces fewer repeat conversations than it did before. If a person's situation comes up twice with no change in between, the system failed regardless of how much of the bench is "covered."
One last thing worth saying plainly: these are people, and the labels are blunt. "Not deployable" is a statement about a market, a skills pipeline, and a sales pipeline — three things the individual mostly doesn't control. Build the justification field wide, require it, and read what people write in it. That text is usually a more accurate description of your organisation's problems than of the person's.
