When Airbus wound down its Beluga transport division, Laura built the matching engine that answered it, job profile by job profile.
Illustrative rebuild of the tool. The interface, columns and formula follow the original; all profiles, competencies and figures shown are synthetic sample data.
Roughly 1,000 people had to move into other parts of the group without losing skills it had taken years to build. Nobody can hold that in their head, and nobody wants to defend a placement they cannot explain. The question underneath it was narrower than it looked: for every job profile being retired, which other profiles in the catalogue sit close enough that its people can step across?
The whole engine is five ideas: read the catalogue, intersect the competencies, measure the gap, read the level honestly, and survive a six-minute execution limit.
Every job profile in the group is one block of rows: one row per competency, each with the target level it demands. The level arrives as text, “4 – Expert”, and the script reads the number off the front of the string. The comparison needs nothing else about a profile, which is exactly why it held up under scrutiny.
For each profile being retired, the script walks every other profile in the catalogue and intersects the two competency lists. The shared competencies are written out one per row, not counted and summarised. A works council or a line manager can see precisely why two roles were called neighbours, and argue with the single line they disagree with.
Two things make a move hard: competencies the new profile demands that the old one never taught, and a shift in seniority band. The script combines them as a straight-line distance, √(competency gap² + level shift²), so every candidate profile gets one comparable index. Sorting that column is the shortlist: the nearest profile is the one where retraining is smallest and the band barely moves.
A profile’s level is the most common level across its competencies, not the mean. Average one expert competency against a handful of basics and you get a fraction that describes no real role; the mode keeps the profile in the band people actually recognise, so the level term in the index compares like with like.
Every run writes one summary row per candidate profile: how many competencies it demands, how many it shares with the retired one, the gap between them, its level band and its index. Sorted by that last column, the sheet is the shortlist, and it is also the source the report in the dashboard above is built on. One table, so the number in a scorecard and the number in a review meeting cannot disagree.
Apps Script stops after six minutes, and a catalogue this size does not finish in six. So the run keeps a worklist: three profiles per pass, a flag written back per profile the moment it completes, and a dialogue on the next start asking whether to resume what is pending or begin again. The catalogue processes as a sequence of short, restartable runs: a crash costs three profiles, not the afternoon.
The tool is Apps Script inside the workbook the HR organisation was already using. That was the decision that made it usable: nothing to procure, no access to grant, no training. People opened the file they had open anyway and read a sheet, and because the output is a sheet, they could sort it, filter it, and hand it on with a link.
A retired profile and every possible destination for it, ranked by a single number combining retraining distance and seniority shift. The shortlist is a sort, not a meeting.
Each match arrives with the shared competencies written out line by line, so a placement can be defended, or contested, on the specific competency someone disagrees with.
The engine ran inside the spreadsheet the organisation already used. Nothing to procure, no accounts to hand out, and every result one link away from the next person who needed it.
We build the matching, scoring and reporting that turn a catalogue of data into a shortlist somebody can act on, inside the tools your organisation already runs.
Talk to us