← Back to blog
Published

Why internal talent marketplaces do not create mobility

by Skills Intelligence

An internal talent marketplace can recommend the right person for a role in milliseconds and still produce almost no mobility.

The match may be credible. The employee may be interested. The receiving team may have urgent work. Then the current manager refuses to release the person, the salary band does not travel, the project has no funded capacity, or applying quietly marks the employee as disloyal. The marketplace has made the opportunity visible. It has not made the move possible.

This is the category error behind many disappointing implementations:

A talent marketplace is a matching mechanism. Internal mobility is an operating system.

Matching matters, but it is rarely the only constraint. Mobility also depends on opportunity supply, permission, capacity, incentives, employment rules, transition support, and whether employees trust the process enough to participate. A new interface cannot manufacture those conditions. At best, it reveals which of them are missing.

The marketplace solves search, not allocation

In economic terms, a marketplace helps participants discover each other. In organisational terms, that is only the beginning.

An employee is not an unallocated unit of capacity. They already have commitments, a manager, a budget line, a grade, a location, a workload, and a reputation to protect. An opportunity is not a free-standing object either. It needs a sponsor, useful work, funding, a start date, and someone willing to accept the cost of onboarding. Every internal move redistributes capability and pain.

The technology market tends to foreground the elegant part: infer skills, rank opportunities, and recommend a match. The difficult part begins after the recommendation:

  • Who may apply without asking permission?
  • Who pays while someone spends 20% of their time elsewhere?
  • How quickly must a manager release a successful applicant?
  • Who covers the work left behind?
  • Does a temporary project affect performance evaluation or promotion?
  • What happens when the algorithm recommends a move that the employee does not want?
  • Can a worker challenge an incomplete or inaccurate profile?

Without answers, the organisation has built an opportunity catalogue, not an internal labour market.

The seven gates between a match and a move

A useful way to diagnose internal mobility is to treat it as a conversion system. A person must pass through seven gates before a recommendation becomes productive work.

GateThe question that must be trueA common failure
Opportunity supplyIs there real, funded work to join?Managers post aspirational gigs with no protected capacity.
VisibilityCan eligible people safely discover it?Opportunities circulate through private networks before publication.
Credible eligibilityIs the match supported by suitable evidence?A title-derived skill is presented as demonstrated proficiency.
Employee choiceDoes the person want the move on known terms?Recommendation is treated as consent or an obligation.
ReleaseWill the current team let the person go?Approval is discretionary and delay has no consequence.
TransitionCan the move start without creating two full-time jobs?The old workload follows the employee into the new assignment.
OutcomeDid the move help the person and the business?A generated match or accepted invitation is counted as success.

Most platform dashboards begin near the top of this funnel and stop before the bottom. They count searches, recommendations, clicks, applications, or profile completion. Those measures can diagnose friction, but none establishes that capability moved or that a business problem was solved. The wider skills intelligence dashboard guide explains how to connect activity to evidence, action, and outcome.

Talent hoarding is often rational behaviour

It is tempting to describe a manager who blocks a transfer as territorial or culturally resistant. Sometimes that is true. More often, the organisation has designed a locally rational response.

A manager may be measured on quarterly delivery, service levels, utilisation, or team revenue. They receive no credit for exporting a strong employee, but absorb the missed deadline, recruitment effort, and onboarding cost after that employee leaves. The enterprise wants mobility; the manager is paid to prevent disruption. A communications campaign cannot reconcile those two instructions.

This is not merely anecdotal. Ingrid Haegele's study, published in the American Economic Review, uses personnel records, survey evidence, and quasi-random exposure within a large firm. It finds that talent hoarding rises with stronger managerial incentives and deters internal applications. Recent practitioner discussion reaches the same operational issue: the CIPD identifies manager release, backfilling, and talent pipelines as central to making internal mobility work.

The important implication is sharper than “engage managers early”:

A marketplace cannot fix an organisation that rewards managers for retaining talent and asks them to release it voluntarily.

Manager education may help. Incentive compatibility helps more. A serious programme decides how talent stewardship affects objectives, how backfill is funded, which moves can be delayed, and which cannot be vetoed.

Employees also face a mobility risk

The supply side of the marketplace is often treated as abundant: publish opportunities and people will apply. Employees make a more complicated calculation.

They may ask whether their manager can see exploratory searches, whether an unsuccessful application will damage the current relationship, whether a gig adds work without removing any, whether the new team has a record of developing people, or whether a lateral move will slow their next promotion. A recommendation may be relevant and still be unattractive.

That is why employee agency must be part of the system design rather than a sentence in the launch email. At minimum, people need:

  • a private way to explore opportunities;
  • clear terms for time, pay, location, duration, and reporting lines;
  • the ability to decline recommendations without penalty;
  • a route to correct inferred skills and preferences;
  • protection from retaliation for applying;
  • a named human decision owner when eligibility or release is disputed;
  • an explicit definition of what happens when the assignment ends.

The OECD's practical review of skills-first approaches describes internal mobility as an ecosystem involving task-specific and transversal skills, development, and structured opportunities. That is a more useful frame than assuming an algorithmic match is the intervention.

A plausible match is not necessarily an eligible move

Skills intelligence can improve discovery by identifying adjacent capability that job titles hide. But similarity and eligibility are different judgments.

Suppose a model recommends a data analyst for a six-month fraud-engineering assignment. The analyst has SQL, Python, anomaly detection, and relevant domain knowledge. That may justify a conversation. It does not establish production access, regulatory clearance, an appropriate grade, capacity on the required dates, or proficiency in the team's engineering practices.

The system should preserve at least four separate states:

  1. Potential match — the profile contains signals worth investigating.
  2. Validated eligibility — required evidence and constraints have been checked.
  3. Agreed availability — the employee and both sides have accepted the terms.
  4. Activated assignment — the person has started with access, capacity, and an accountable owner.

Collapsing those states into one match score creates two problems. Weak candidates are presented with false precision, and strong non-traditional candidates can be rejected because the model lacks the right evidence. The discipline described in AI skills intelligence applies here directly: an inferred skill is a hypothesis to investigate, not a personnel decision.

The minimum viable mobility contract

Before configuring a marketplace, write the rules of movement. They need not be perfect, but they must be explicit enough to test.

Opportunity rules

Define what may be posted, who sponsors it, whether it is funded, the expected output, required time, location constraints, and the evidence genuinely necessary to start. Remove “development opportunities” that are actually unfunded overtime.

Application rules

Decide whether employees can explore and apply privately, when a current manager is notified, which criteria are mandatory, and which are preferences. A manager should not be able to convert a desirable attribute into a hidden gate after applicants appear.

Release rules

Set a response time, limited grounds for delay, a maximum deferral, and an escalation owner. If every move remains subject to an indefinite veto, mobility is a slogan.

Capacity and cost rules

Specify how partial assignments are recorded, which cost centre pays, how utilisation targets change, and who funds backfill. Fractional work cannot survive if time is counted twice.

Career and reward rules

State how project performance enters reviews, whether temporary responsibility changes pay, what happens to bonus attribution, and how a successful assignment affects progression. Employees should not have to reverse-engineer the career consequences.

Evidence and appeal rules

Publish how matching works at a useful level, distinguish observed from inferred claims, and provide a route to correct data or challenge an eligibility decision. For consequential uses, apply the stronger governance described in the platform evaluation guide.

These rules form the real product. The platform encodes and scales them.

A fictional funnel exposes the bottleneck

Consider an illustrative enterprise launching a cloud-controls programme. Its marketplace reports 420 recommended employees and celebrates the reach of the matching engine.

The operational funnel tells a different story:

  • 420 people receive a recommendation;
  • 96 open the opportunity;
  • 31 apply;
  • 18 pass evidence-based eligibility review;
  • 7 receive manager release;
  • 5 begin the assignment;
  • 4 complete it;
  • 3 subsequently fill recurring capability needs.

These numbers are fictional, but the diagnostic logic is real. Improving semantic matching at the top of this funnel may have little value if eleven eligible applicants are lost at the release gate. The next investment should then be a release policy, backfill mechanism, or manager incentive—not a more advanced recommendation model.

This is why aggregate adoption can mislead. A marketplace with fewer recommendations but a reliable path from application to completed assignment may create more capability than one with spectacular traffic and no movement.

Measure liquidity, friction, and consequences

The right measures follow the gates rather than the interface. A pilot should examine:

  • opportunity liquidity: funded opportunities per eligible population, by function and level;
  • evidence-qualified application rate: applications that meet the published threshold;
  • release conversion: eligible applicants released within the agreed service level;
  • release latency: time between selection and confirmed availability;
  • transition overload: participants whose prior workload was not reduced as agreed;
  • assignment start and completion: accepted moves that become and finish real work;
  • capability transfer: whether the receiving team reduced a defined gap or dependency;
  • career consequence: progression, retention, pay, and future opportunity after participation;
  • distribution: who sees, applies for, receives, and completes opportunities;
  • manager flow balance: capability imported, exported, developed, and blocked by team.

Not every metric belongs on an executive dashboard. Together, however, they show where the internal market stops functioning. They also prevent a vendor, HR team, or sponsor from declaring success at the easiest stage to count.

A pilot should test movement, not matching

A useful pilot needs enough organisational friction to be informative. Choosing only volunteers with spare capacity may produce a smooth demonstration and teach little about enterprise mobility.

Start with one bounded capability problem involving two or three teams. Establish a baseline for how the work is staffed today. Agree the mobility contract, identify a small opportunity supply, and use the marketplace to support discovery. Then record every conversion and loss through the seven gates.

The decision at the end is not simply whether users liked the experience. It is whether the new system:

  1. moved qualified capacity faster than the existing process;
  2. did so without hidden workload or unacceptable employee risk;
  3. improved a defined delivery, development, or retention outcome;
  4. exposed a constraint the organisation is willing and able to change;
  5. produced evidence strong enough to justify the next expansion.

The latest OECD guidance recommends beginning skills-first adoption with targeted roles and stakeholder participation. That principle is especially important for mobility: a small real market is more instructive than an enterprise-wide catalogue of theoretical opportunities.

The operating model is the marketplace

Internal talent marketplaces are useful. They can widen discovery, make career paths legible, expose transferable capability, and reduce dependence on informal networks. Research and implementation guides have long stressed that their value depends on manager engagement, opportunity supply, and incentives; Deloitte's early field guide, for example, treats manager behaviour and iterative operating-model design as core conditions rather than optional change management.

The mistake is asking the platform to create a market the organisation has not authorised.

A matching engine can tell you that two sides might benefit from a move. Only an operating model can decide whether the employee may move, who bears the cost, how evidence is checked, and what happens next. If those rules remain implicit, the marketplace will digitise the existing politics. If they are made explicit and testable, technology can finally help them scale.

If you need to diagnose mobility friction, define the mobility contract, or design a pilot that measures completed movement rather than recommendations, get in touch to discuss the implementation.

Continue exploring