You are paying to hire people you already employ
A canonical skills graph makes the payroll a queryable pipeline

Introduction
"I think we keep hiring skills we already have." A founder said this to us about her 300-person company, in the tone of someone confessing a superstition. Then she pulled the example that had planted it: a $28,000 recruiting spend for a datavisualization contractor, signed the same quarter an internal platform engineer, two floors down, had shipped a full Grafana observability suite as a side project. Nobody knew. His title said "Platform Engineer." The req said "Data Visualization Specialist." No system in the building could connect those two facts.
Her superstition was arithmetic. Every skills-adjacent hire carries the recruiting fee, the ramp months, the salary premium of the open market, while some fraction of those skills sit on the current payroll, invisible, because the only skill records the company keeps are job titles, and job titles are free text written by whoever drafted the posting.
A job title is not a skills record. It is a compression artifact
The vocabulary problem wearing an org chart
Look at how the data actually exists. "Growth hacker," "demand generation manager," and "performance marketer" are, in most companies, the same competence wearing three costumes. "Platform engineer" might mean Kubernetes, might mean CI tooling, might mean the person who quietly knows Grafana cold. Titles vary by hiring manager, by era, by negotiation; the skills underneath vary on entirely different axes. Any matching built on this vocabulary, internal mobility, project staffing, the build-vs-hire call, inherits the noise. So companies do the honest thing available to them: they stop matching internally and go to market, where at least the vocabulary problem is the recruiter's job.
The remedy is not a better org chart. It is a canonical vocabulary, the same move catalog teams make when three suppliers spell "Medium" three ways, applied to human capability.
Build the skills graph before the matching
The method has three layers, and the order matters.
First, the canonical taxonomy: a controlled vocabulary of skills, drawn from an established framework such as ESCO or O*NET and pruned hard to what your business actually uses, a few hundred nodes, not ten thousand, with relationships between them: Grafana is-a observability tool, adjacent to Prometheus, parent skill monitoring.
Second, normalization into that vocabulary. Titles, job descriptions, project histories, internal wikis, engineering repos, all of it maps to canonical skills. This mapping is exactly what language models are now good at, with the same discipline any classifier deserves: model proposes, human confirms, especially early. The output is a skills profile per person built from evidence of work, not from the title someone negotiated. (Self-reported skill surveys, the traditional tool here, mostly measure self-confidence; the repo history does not exaggerate.)
Third, and only now, matching: when a need arises, it is expressed in the same vocabulary and run against the graph first. The req for a "Data Visualization Specialist" decomposes into canonical skills, and the platform engineer two floors down surfaces before the recruiting fee does. Adjacency makes it smarter than lookup: no exact match, but two people one trainable skill away is an answer worth more than a shortlist of external strangers.
We built this pipeline for an organization in the founder's size class: taxonomy pruned to roughly 400 skills, profiles inferred from work artifacts and confirmed by managers in a one-off review sprint, matching wired into the req-approval flow, so "did we check inside" stopped depending on hallway memory. In the first two quarters, roughly one approved req in five was filled or shrunk internally, and the recruiting line moved accordingly.
The cheapest candidate pipeline is the payroll, and almost nobody can query it.
The counterargument is cultural and real: skills inference can read as surveillance, and a graph used to deny people opportunities will be gamed or resented into uselessness. The deployments that work run it in the open, profiles visible to their owners, correctable, and used first for offering growth paths rather than auditing gaps. The same graph that fills a req also tells an engineer what one skill separates them from the role they want, and that is the version people update voluntarily.
TensorLabs builds this class of system, taxonomy, inference, matching, for companies whose founders have started having the superstition. Hers, at 300 heads, was costing six figures a year. The Grafana engineer, for what it is worth, was delighted to be found.
You might also like
Keep reading from the journal.
January 8, 2026JavaScript
Building “TagTamer” — A Chrome Extension with Manifest V3
Learn how to build a Chrome extension using Manifest V3 by creating TagTamer—a simple tool that highlights HTML heading tags on any webpage. This hands-on guide covers popup UI, background scripts, content scripts, and modern extension architecture.
July 13, 2026Engineering
A third of your ad spend reports to nobody
Server-side first-party collection makes the budget follow real numbers
July 13, 2026Extensions
The customer your cloud bill is hiding
Per-tenant metering turns pricing from a bet into arithmetic