Why "Senior Growth Ninja" doesn't have a SOC code
A People Analytics Lead pulls the HRIS export three weeks before a board meeting where a PE-backed CEO wants a role-level view of AI exposure across the company. The export has 340 unique job titles. Some are clean — "Staff Accountant," "Customer Support Representative." Many are not: "Senior Growth Ninja," "Director of People & Culture (Interim)," "Ops/Finance Generalist." None of these strings exist in the O*NET taxonomy, and none of them can be scored against an exposure rubric until they are attached to a real occupational code.
This is the step that happens before any exposure analysis, and it is also the step most teams underestimate. Getting it wrong doesn't just introduce noise — it produces a heatmap that looks precise but rests on guesses nobody can defend in the room. This article walks through a repeatable method for looking up the correct O*NET-SOC code for any job title, including the ones that don't match anything cleanly, and for documenting the lookup so it survives a follow-up question.
The taxonomy you're actually mapping against
Before running any lookup, it helps to know the shape of the system you're mapping into. ONET is built on top of the 2018 Standard Occupational Classification (SOC), maintained by the U.S. Bureau of Labor Statistics, which organizes the U.S. labor market into 23 major groups, 98 minor groups, 459 broad occupations, and 867 detailed occupations. ONET extends that structure with its own detail: the O*NET database currently defines 1,016 occupational titles, of which 923 are data-level occupations carrying full descriptor profiles, collectively representing more than 55,000 job title variants drawn from real postings and surveys. Each occupation is described by roughly 277 descriptors covering tasks, skills, knowledge, abilities, and work context, refreshed on a regular update cycle with the primary annual update typically landing in the third quarter.
That structure matters for a lookup because it tells you two things. First, an ONET-SOC code is more granular than a plain six-digit BLS SOC code — ONET sometimes splits one BLS detailed occupation into multiple O*NET occupations to capture real differences in tasks (for example, splitting a broad "Accountant" category into more specific variants). Second, the 55,000+ alternate titles are your actual lookup surface — your internal title rarely needs to match an occupation name; it needs to match one of the alternate titles attached to that occupation, and this is what makes fuzzy matching viable rather than a losing exercise in name-guessing. For a fuller walkthrough of how the taxonomy fits together, see what O*NET is and how it works.
This site incorporates information from ONET. Used under the CC BY 4.0 license. ONET is a trademark of USDOL/ETA.
A repeatable lookup method
The method below is deliberately linear so it can be run by more than one analyst and still produce consistent results.
Step 1: Normalize the raw title. Strip seniority modifiers ("Senior," "Lead," "Jr."), department suffixes, and internal branding ("Ninja," "Rockstar," "Guru") into a separate field. You want the functional core of the title isolated before you search — "Senior Growth Ninja" becomes "Growth" plus a seniority tag, which is not enough on its own and flags the row for the fallback path below.
Step 2: Search O*NET's alternate title index, not the primary occupation name. Most internal titles will not match a primary O*NET title exactly. They will often match one of the alternate titles indexed under an occupation. Search the normalized core term first, then try close synonyms (e.g., "People & Culture" as a synonym cluster for "Human Resources").
Step 3: Confirm at the task level, not just the title level. A title match is a hypothesis, not a conclusion. Pull the task statements for the candidate occupation and check that a majority of them plausibly describe what the role actually does day to day. A title can match while the task list is wrong — this is common in companies where a title was inherited from an acquisition or a different industry.
Step 4: Record a confidence tier. Every mapped row should carry a tier — direct match, synonym match, or analyst judgment call — not just a code. This single field is what turns a spreadsheet of codes into something a board can trust, because it tells the reader where the analysis is solid and where it is a reasoned estimate.
Step 5: Log overrides with a one-line rationale. When you deviate from the top-ranked candidate — because the task list didn't fit, or because a local title convention is known to mean something specific — write down why in the same row. Six months later, when someone asks "why is the Ops/Finance Generalist role mapped to a business-operations code instead of a financial-clerk code," the rationale should already exist.
A structured, step-by-step version of this — including the exact fields to carry in your working file — is covered in how to map job titles to O*NET occupations.
Handling the titles that don't match cleanly
Most title lists have a long tail that resists a clean lookup. Three patterns show up repeatedly.
Hybrid titles. "Ops/Finance Generalist" is really two functions compressed into one headcount line. The fix is not to force a single code; it's to identify which function consumes the majority of the person's time (from a job description, a manager interview, or a time-allocation estimate) and map to that, with a note that the role is a hybrid and the mapping covers its primary function only.
Branded or internal-only titles. "Growth Ninja," "Happiness Officer," and similar titles carry no external signal at all. These require a manual review of the job description or a short conversation with the hiring manager before any code is assigned — there is no shortcut here, and pretending a fuzzy match solved it is how a mapping loses credibility later.
Titles that map to more than one plausible occupation. Some titles are genuinely ambiguous even after normalization — "Analyst" alone could sit in half a dozen O*NET occupations depending on department. When two or more candidates are equally plausible, don't force a single answer; carry both candidates forward with their confidence tier and resolve the ambiguity using the task-level check in Step 3, or flag it for manual review rather than silently picking one.
Automating the first pass of this process — the normalization and candidate-ranking work — is what a fuzzy-matching approach is built for. It's covered in more depth in fuzzy matching job titles to occupations, including where automated matching is reliable and where it isn't.
Making the mapping defensible, not just complete
A completed lookup and a defensible lookup are different deliverables. A defensible mapping carries, for every title: the assigned O*NET-SOC code, the confidence tier, and — where applicable — an override rationale. That's the difference between a heatmap someone can interrogate in a board meeting and one that collapses under the first "how did you get this number" question.
This is also the exact input layer that any exposure scoring depends on. Once a title is confidently attached to an O*NET occupation, its task list and task-importance weights become the basis for scoring exposure across the four dimensions — cognitive routine, physical routine, social/judgment, and creative — and the resulting flags describe a role as a Monitor, Review, or Redeployment Candidate case for further human judgment, never a verdict on the person in the seat. Get the SOC mapping wrong, and every downstream flag inherits that error silently.
For teams mapping more than a handful of titles, running this by hand in a spreadsheet is workable but slow, and it's easy to lose the confidence-tier discipline under deadline pressure. A structured crosswalk tool that carries normalization, candidate ranking, and override logging in one workflow is covered in the SOC code crosswalk tool guide — worth reading before you commit to doing 340 rows manually.
Getting this right before you score anything
The lookup step rarely gets the attention it deserves because it looks like clerical work sitting in front of the "real" analysis. In practice it's the foundation the entire exposure picture stands on. A rigorous, documented title-to-SOC mapping — with confidence tiers and override rationale — is what lets a People Analytics Lead walk into a board meeting and answer every "how did you get this" question without hesitation.
To make this repeatable across your own title list, download the SOC lookup and confidence-tracking template and see how the full workflow, including automated exposure scoring, is priced on the pricing page.