Sourcing with adjacent job titles and skills

Search for one job title and you reach only the people who happen to use that exact label, which for most roles is a minority of the qualified market. Employers name the same work differently, candidates describe themselves in their last employer’s vocabulary, and titles lag the actual job by a year or more. The fix is to source against a map instead of a keyword: the cluster of alternative titles for the role plus the skills that reliably travel with it. This post builds that map for one role, site reliability engineer, then gives you the method to build it for any role.

Why does one job title miss most of the market?

Job titles are set by employers, not by a standards body. The same person, same laptop, same pager, can be a DevOps engineer at a 40-person startup, get relabeled site reliability engineer after a new VP arrives, and end up platform engineer when the team splits in two. None of those renames changed what they can do for you.

Candidates compound the problem. Profiles get updated late or not at all, people keep the title of their best-sounding past job, and plenty of strong engineers describe themselves in their team’s internal vocabulary rather than anything a recruiter would type. Meanwhile every recruiter searching the exact title converges on the same overexposed slice of the market: people who adopted the fashionable label and keep their profiles polished, which correlates strongly with already being flooded with recruiter messages.

The deeper pool, people doing the work under a different name and not thinking about recruiters at all, only becomes visible when you search for the work itself. That means alternative titles and, more importantly, skills.

A worked example: mapping the SRE role

Suppose the brief is a site reliability engineer. Searching that title alone gets you the people who currently call themselves SREs. Here is who it misses:

Then the skill layer. Four signals travel with this role almost everywhere:

• Kubernetes (often written K8s) for running production workloads
• Terraform, or infrastructure as code generally, for provisioning
• An observability stack: Prometheus, Grafana, Datadog or similar
• On-call and incident response, the clearest marker that someone operates systems rather than only building them

A skill-led search such as (Kubernetes OR K8s) AND (Terraform OR “infrastructure as code”) AND (“on-call” OR SLO OR incident) finds the platform engineer who is functionally an SRE and has never used the title. If your operators are rusty, there is a working reference in boolean search strings for recruiters.

How do you build this map for any role?

The SRE example generalizes into a five-step method. Budget about an hour per role; the map gets reused in every search, message and screen afterwards.

1. Start from known-good people, not keywords. Collect three to five profiles everyone agrees are strong: current team members, the best past hire, the person the hiring manager wishes they could clone. These are your ground truth.
2. Harvest their titles, current and previous. The previous titles matter most. They show what this kind of person was called two jobs ago, which is exactly what the hidden part of the market still calls itself.
3. Harvest recurring skills, then split anchors from decoration. List every tool and responsibility that appears on most of the ground-truth profiles. Some are anchors (Kubernetes, for an SRE), some are decoration that appears on every profile and filters nothing. The discipline for separating them is the same one we use for requirements in must-have versus nice-to-have skills.
4. Mine other companies’ job ads. Read five postings from companies hiring the same role. Their titles and requirement lists tell you what the market calls this work right now, including labels you would not have guessed.
5. Turn the map into searches, and run them in more than one place. Title-led strings for precision, skill-led strings for coverage. And not only on LinkedIn: GitHub, technical communities and niche boards expose skills far better than headline titles do, as covered in where to find candidates beyond LinkedIn.

What goes wrong when you widen the net?

Two failure modes, both manageable.

First, noise. A wider net pulls in platform engineers who have never carried a pager and infrastructure engineers who are sysadmins with a new headline. The map has to cut both ways: adjacent titles get people into the pool, then anchor skills plus one role-defining signal (for SRE, on-call ownership) decide who stays. This is also where scoring people against the actual job description beats scanning titles by eye, and it is worth understanding how candidate matching works before trusting any tool to do it for you.

Second, seniority drift. Adjacent titles do not carry consistent seniority: a senior DevOps engineer at a 30-person company and a mid-level SRE at a large platform business may have swapped scopes entirely. Calibrate on what they ran, what broke, and what they owned, not on years spent under a particular label.

One cheap win before sourcing anywhere external: run the finished map across your own ATS first. Past applicants who did well in process for an adjacent role are the warmest pool you have, and talent rediscovery is exactly this search pointed inward.

Where does Recruitifly fit?

A title and skill map only pays off if your tooling can act on it. In Recruitifly, the assistant Fly searches the talent pool on skills rather than headline titles, scores and ranks candidates against the actual job, builds shortlists from the result, and drafts outreach in the candidate’s own language. Every one of those steps is propose then confirm: Fly prepares the work, you approve each change before it happens, which is how a sourcing assistant should behave around real candidates. We are in private beta; if you want to try the SRE map above against a live role, talk to us.