Critical-path hire
Rejecting the entire shortlist
A regulated milestone depended on one rare engineering skill. Everyone available was a comfortable yes, so I said no to all of them and re-sourced against a single weighted axis.
- The whole interviewed shortlist, including the internally preferred option
- 3 rejectedThe whole interviewed shortlist, including the internally preferred option
- A fresh pool screened on one deliberately weighted skill
- 13 re-sourcedA fresh pool screened on one deliberately weighted skill
- Candidates whose rare skill was genuinely evidenced
- 1 verifiedCandidates whose rare skill was genuinely evidenced
The client
A regulated device-adjacent product build inside a distributed software organisation. The delivery date was fixed by a regulatory milestone, and the specialist skill it required is rare in the general market and easy to fake on a CV.
The engagement
A staffing decision taken inside live delivery, with the risk escalated on the register until an offer was signed.
The problem
The plan rested on a senior engineer who could do genuinely low-level work in a specialist domain — not the framework-level version most CVs claim. The one person in-house who had it was only available a fraction of the week, and every interviewed candidate came back with a flag: gaps in the fundamentals, a team-fit warning, or a habit of writing code before clarifying the requirement.
What I did
I treated the rare skill as a screening axis with double weight rather than one line on a balanced scorecard, because a balanced scorecard is how you hire a pleasant generalist for a specialist seat. That meant rejecting the entire interviewed shortlist, including the internally preferred option, and telling account leadership the resourcing risk was escalated and unresolved rather than reporting a green plan. The nearest milestone was re-planned so it did not depend on the rare skill at all, which bought the time to source properly, and the finalist went to a paid trial task rather than a fourth conversation — at that level interviews mostly measure interviewing.
What was built
A hiring approach built around one deliberately double-weighted screening axis, evidence of the specific low-level skill rather than keyword matches, a re-planned milestone that removed the skill from the critical path, and a paid trial task in place of a fourth interview — with the residual specialist gap carried openly on the risk register.
On the table at the end
- Written rejection rationale per candidate
- Re-planned milestone removing the rare skill from the critical path
- Screening rubric with the weighted axis
- Escalated risk entry held open until an offer was signed
What it changed
Avoided filling a specialist seat on a regulated critical path with a pleasant generalist, re-planned the near-term milestone so it no longer depended on the hire, and replaced interview impressions with paid trial work as the basis for the decision.
How it ran
- 01
Name the skill precisely
Not the domain in general but the specific low-level path it required, so keyword matches stopped counting as evidence.
- 02
Reject the comfortable yes
All three interviewed candidates declined with written reasons, and the risk escalated rather than quietly held at amber.
- 03
Take the skill off the critical path
The nearest milestone re-planned around people already on the team, so sourcing pressure stopped driving the hiring decision.
- 04
Re-source against one axis
A pool of thirteen screened on evidenced low-level work first, seniority and communication second.
- 05
Paid trial, not another interview
The finalist tested on real work before an offer, with the remaining specialist gap logged as an open risk for an external adviser to close.
Other work
All case studies →- Health tech
The estimate that covered a third of what the client thought they were buying
Two documents described two different products and both carried our logo. I stopped the contract, wrote the discrepancy register, and split the release into a fundraising build and a regulated one.
- Software services
What the projects actually earned, once someone put cost next to revenue
Margin was assumed to be about half. Reading revenue, cost and hours together showed a spread from a third to three quarters — and one project that had quietly overrun its ceiling without a change request.
- Professional services
A project office that lives in a git repository
Project knowledge lived in people's heads and chat threads, and AI tools were producing confident documents with no provenance. I made the repository the single source of truth and gave every project management role a written protocol.
Something similar on your plate?
Thirty minutes, no deck. I will tell you whether it is worth doing at all.