1/3+180 XP

Hiring data talent and the skills map

# Hiring data talent and the skills map

In 2019, Airbnb published a now-famous internal reckoning: they had roughly 100 data scientists, but the org couldn't ship. Analysts were pulled into pipeline firefighting. PhDs who joined to build causal inference models spent their weeks writing SQL for exec dashboards. The problem wasn't headcount or talent density, both were excellent. The problem was that Airbnb had hired a title ("data scientist") instead of hiring against a skills map. Everyone was a generalist, so no one owned the specialized work that actually moved the business.

That failure mode is the one you will repeat if you approach hiring as "we need more data people." The CDO's job is not to acquire talent. It's to define the *shape* of the team precisely enough that every hire slots into a system, and then to hire for that shape without waiting for a mythical five-in-one candidate who does not exist and would quit within a year if they did.

The skills map: decompose the team before you decompose the req

Before you write a single job description, you need a skills map, a two-dimensional model of what your data function must *do* and what capabilities that requires. Do not start from titles. Titles are downstream lies; they mean different things at every company. Start from the work.

There are five capability domains a modern data team spans. You will weight them differently, but you cannot ignore any of them:

Engineering, moving, modeling, and serving data reliably. Pipelines, orchestration, warehouse/lakehouse design, data contracts, latency and cost SLAs.
Analytics, turning data into decisions. Metric definition, experimentation, business partnering, the "why did revenue drop" work.
Science, building predictive and inferential systems. ML models, causal inference, optimization, forecasting.
Governance, making data trustworthy and compliant *as an operational discipline*, not a policy binder. Lineage, quality monitoring, access control implementation, privacy engineering.
Product, treating data assets and platforms as products with users, roadmaps, and adoption metrics. This is the domain most CDOs under-hire and most regret.

Now overlay the second dimension: seniority as a function of ambiguity tolerance, not years. A senior person absorbs ambiguity and converts it into structure for others. A junior person executes well-scoped tasks. The mistake is hiring three seniors who all want to define strategy and none of whom will write the dbt models, or hiring five juniors with no one to architect the system they operate in.

The output of this exercise is a grid. Down one axis: your five domains. Across the other: the seniority mix you actually need given your maturity stage. A pre-platform org that's still on spreadsheets needs a heavy engineering-senior weighting and almost no science. A company with a solid platform and untapped decisions needs analytics and product. Map your reality, not the org chart of the FAANG blog post you read last week.

From map to roles: the anti-unicorn principle

Here is where most CDOs sabotage themselves. Having built a rich skills map, they collapse it back into one job description that demands all of it. The now-classic parody req: "Seeking data scientist with PhD-level statistics, production Spark experience, dbt mastery, stakeholder management, and Kubernetes." That person exists at a rate of maybe 1 in 5,000 in your comp band, and hiring them creates a bus-factor-of-one dependency you'll spend years unwinding.

The anti-unicorn principle: a role should require deep strength in one domain, working competence in one adjacent domain, and literacy across the rest. Deep-adjacent-literate, the "T-shape" everyone quotes but few enforce.

Concretely, that means an analytics engineer is *deep* in modeling/transformation, *competent* in analytics (they understand the questions), and *literate* in governance (they know why lineage matters). You do not require them to build ML models. If your req has three "deep" requirements, you have written a job for two people, and the market will punish you with a six-month vacancy.

The test to apply before posting: for every "must-have," ask whether a strong candidate could learn it in 90 days on the job. If yes, it's a nice-to-have. Move it. Most reqs die of must-have obesity, every stakeholder adds their pet skill, and the composite candidate becomes imaginary.

Designing the actual roles

With the map and the anti-unicorn principle in hand, most modern teams resolve into a small set of durable role archetypes. Your job is to decide which ones you need *now* and in what ratio.

Analytics Engineer, arguably the highest-leverage hire of the last five years and the one that resolved Airbnb's crisis. Sits between raw data and analysts, owns the transformation layer (dbt, semantic models), and turns chaotic warehouse tables into trustworthy, documented, tested data products. Hiring this role frees your scientists from SQL janitorial work and your engineers from BI requests. If you have data scientists writing production transformation logic, this is your first hire.

Data Engineer, owns ingestion, orchestration, and platform reliability. Deep in systems, competent in cost/performance tradeoffs. This is your infrastructure backbone; under-hire here and everything downstream is unreliable.

Analyst / Analytics partner, deep in the business domain and experimentation, embedded with a function (growth, finance, ops). The differentiator between a good and great analyst is not tooling; it's the ability to reframe a vague executive question into a tractable, answerable one.

Data Scientist / ML Engineer, hire *narrowly*. Be honest about whether you need inference (causal, experimentation design) or production ML (models in the serving path). These are different people. Conflating them is why so many "data scientists" are miserable, they were hired to do stats and asked to do MLOps.

Data Product Manager, owns the platform and key data assets as products. Defines adoption metrics, prioritizes the roadmap, manages the internal customer relationship. In a mature org this role is what prevents your platform from becoming a graveyard of unused tables.

Governance / Data Quality Engineer, operationalizes trust. Owns quality monitoring, lineage tooling, access implementation. Not a compliance officer, an engineer who makes governance run automatically.

The ratio matters more than the roster. A useful starting heuristic for a mid-maturity org: for every 4-5 people who *produce* insight (analysts, scientists), you need roughly 2-3 who *enable* it (engineers, analytics engineers) and at least 1 who *productizes and governs* it. Teams that skew all-producer collapse under their own technical debt within 18 months.

How to Build a Data Team from Scratch

Watch on YouTube

Writing reqs and screening that actually predict performance

Once roles are defined, the job description becomes a filter, and most are terrible filters. Strip yours to three sections: the *problem this person owns* (not "responsibilities", the actual outcome they're accountable for), the *deep skill* required, and the *literacy* expected. Kill the laundry list. A job description that reads like a system requirements doc signals a team that doesn't know what it wants.

For screening, abandon whiteboard algorithm puzzles for data roles, they predict nothing. Use work-sample tests that mirror the actual job. For an analytics engineer, give them a messy schema and ask them to design and document a model. For an analyst, hand them a real (anonymized) ambiguous business question and a dataset, and evaluate how they frame it, not just the answer. The signal you want is *judgment under ambiguity*, which is precisely what a puzzle strips out.

A clean way to encode the skills expectation for a role, which also forces you to be honest about depth vs. literacy:

yaml

role: analytics_engineer
owns: "trusted, tested transformation layer feeding all BI"
skills:
  data_modeling:      deep       # non-negotiable
  sql:                deep
  testing_ci:         competent
  business_context:   competent
  governance_lineage: literate
  ml:                 none       # explicitly not required

Writing it this way, per role, does two things: it kills must-have obesity, and it becomes the exact rubric your interviewers score against. When every interviewer rates the same dimensions on the same scale, you eliminate the "I just liked them" bias that produces homogeneous teams.

Vérification des acquis

1. According to the lesson, what was the root cause of the data team's inability to ship, despite excellent headcount and talent density?

2. The lesson argues that seniority should be defined primarily as a function of what?

3. Why does the lesson insist you start a skills map from 'the work' rather than from job titles?

CHOIX MULTIPLES

4. Select ALL statements that accurately reflect the lesson's view of the CDO's role in building a data team.

Sélectionnez toutes les réponses correctes.

CHOIX MULTIPLES

5. Select ALL correct descriptions of the five capability domains a modern data team spans, as defined in the lesson.

Sélectionnez toutes les réponses correctes.

Buying, building, and the market reality

Even a perfect skills map runs into a labor market. The senior data engineer you've specced costs $220K+ in competitive markets and turns over in 2-3 years. So the map is also a build-vs-buy decision tool.

For each cell in your grid, ask: is this skill *rare and durable* (buy senior, pay up, retain hard) or *learnable and abundant* (buy junior, grow internally)? Analytics engineering competence, for example, is highly learnable by a strong analyst with SQL, so it's often cheaper and stickier to grow than to buy. Deep ML infrastructure is rare and expensive to develop internally, buy it. Mapping every domain against this rare/learnable axis turns your hiring plan into a *portfolio*: a few expensive senior anchors who create structure, surrounded by developable talent who will stay because you're the place that grew them.

This reframes the unicorn problem entirely. You don't need one person who has everything. You need a *team* whose skills map, in aggregate, covers everything, with deliberate redundancy on the load-bearing skills so no single departure cripples you. The unit of completeness is the team, never the individual.

Sourcing beyond the obvious pool

The candidates who match your req perfectly are the ones every other CDO is also chasing. Two moves widen the pool without lowering the bar.

Hire for the deep skill and the trajectory, and screen out on the literacy gaps that are genuinely unteachable. Domain context (understanding your business) is teachable. Statistical intuition is hard to teach. So a brilliant scientist from a different industry is a better bet than a mediocre one from yours, the reverse of most hiring instincts.

Second, build the pipeline from adjacent roles you already employ. Your best analytics engineers are often your frustrated analysts who taught themselves dbt. Your best data PMs are often analysts who kept naturally gravitating toward the "who's actually using this?" question. Naming these paths explicitly, and funding the transitions, is cheaper, faster, and produces higher retention than any external req. It also sends a signal to your whole team that growth is possible here, which does more for retention than any comp adjustment.

The CDO who treats hiring as an isolated transaction will always be behind. The one who treats it as portfolio construction against a living skills map, buying the rare anchors, growing the learnable core, and sourcing from adjacencies, builds a team that compounds rather than churns.

Key Takeaways

Build the skills map before the org chart. Decompose the work into five domains (engineering, analytics, science, governance, product) crossed with real seniority needs, and weight it to *your* maturity stage, not a blog post's.
Enforce deep-adjacent-literate on every role. One deep skill, one competent adjacency, literacy elsewhere. Apply the 90-day test to every "must-have" and delete the ones a strong hire could learn on the job.
Hire the analytics engineer early. If scientists and analysts are doing transformation janitorial work, this single role unlocks the productivity you thought you needed more headcount for.
Treat hiring as portfolio construction. Map each skill as rare-and-durable (buy senior, retain hard) or learnable-and-abundant (grow internal). The unit of completeness is the team, never the unicorn individual.
Screen with work samples, not puzzles, and score everyone on the same role rubric. Judgment under ambiguity is the signal; a shared rubric is your defense against homogeneous, bias-driven teams.

À faire, tiré de cette leçon

Ces actions sont compilées dans le plan d'action du rôle.

Build a skills map and hire an analytics engineer early

Voir le plan d'action complet →

Career paths & upskilling