+180 XP

Data-Talente einstellen und die Skills Map

# Data-Talente einstellen und die Skills Map

2019 veröffentlichte Airbnb eine inzwischen berühmte interne Bilanz: Rund 100 Data Scientists, aber die Organisation lieferte nicht. Analysten wurden ins Pipeline-Firefighting gezogen. Promovierte, die für Causal-Inference-Modelle angetreten waren, schrieben wochenlang SQL für Exec-Dashboards. Das Problem war nicht Headcount oder Talentdichte, beides war exzellent. Das Problem war, dass Airbnb einen Titel eingestellt hatte („Data Scientist“) statt gegen eine Skills Map zu rekrutieren. Alle waren Generalisten, also übernahm niemand die spezialisierte Arbeit, die das Geschäft tatsächlich bewegte.

Dieses Fehlermuster wiederholen Sie, wenn Sie Hiring als „wir brauchen mehr Data-Leute“ angehen. Der Job des CDO ist nicht, Talente zu beschaffen. Er besteht darin, die *Form* des Teams präzise genug zu definieren, dass jeder Hire in ein System passt, und dann für diese Form zu rekrutieren, ohne auf einen mythischen Fünf-in-eins-Kandidaten zu warten, der nicht existiert und innerhalb eines Jahres kündigen würde, wenn es ihn gäbe.

Die Skills Map: Zerlegen Sie das Team, bevor Sie die Stellenausschreibung zerlegen

Bevor Sie eine einzige Stellenbeschreibung schreiben, brauchen Sie eine Skills Map, ein zweidimensionales Modell dessen, was Ihre Datenfunktion *tun* muss und welche Fähigkeiten das erfordert. Beginnen Sie nicht mit Titeln. Titel sind nachgelagerte Lügen; sie bedeuten in jedem Unternehmen etwas anderes. Beginnen Sie mit der Arbeit.

Es gibt fünf Capability-Domänen, die ein modernes Data-Team abdeckt. Sie werden sie unterschiedlich gewichten, aber ignorieren können Sie keine davon:

  • Engineering, Daten zuverlässig bewegen, modellieren und bereitstellen. Pipelines, Orchestrierung, Warehouse-/Lakehouse-Design, Data Contracts, Latenz- und Kosten-SLAs.
  • Analytics, Daten in Entscheidungen verwandeln. Metrikdefinition, Experimentation, Business Partnering, die „warum ist der Umsatz eingebrochen“-Arbeit.
  • Science, prädiktive und inferenzielle Systeme bauen. ML-Modelle, Causal Inference, Optimierung, Forecasting.
  • Governance, Daten vertrauenswürdig und compliant machen *als operative Disziplin*, nicht als Policy-Ordner. Lineage, Quality Monitoring, Umsetzung von Access Control, Privacy Engineering.
  • Product, Datenassets und Plattformen als Produkte mit Nutzern, Roadmaps und Adoption-Metriken behandeln. Diese Domäne wird von den meisten CDOs unterbesetzt und am meisten bedauert.

Legen Sie nun die zweite Dimension darüber: Seniorität als Funktion von Ambiguitätstoleranz, nicht von Jahren. Eine Senior-Person absorbiert Ambiguität und wandelt sie in Struktur für andere um. Eine Junior-Person führt klar abgegrenzte Aufgaben aus. Der Fehler ist, drei Seniors einzustellen, die alle Strategie definieren wollen und von denen keiner die dbt-Modelle schreibt, oder fünf Juniors, für die niemand das System architekturiert, in dem sie arbeiten.

Das Ergebnis dieser Übung ist ein Raster. Auf der einen Achse: Ihre fünf Domänen. Auf der anderen: der Seniority-Mix, den Sie in Ihrer Reifestufe tatsächlich brauchen. Eine Organisation ohne Plattform, die noch mit Spreadsheets arbeitet, braucht eine starke Engineering-Senior-Gewichtung und fast keine Science. Ein Unternehmen mit solider Plattform und unausgeschöpften Entscheidungen braucht Analytics und Product. Mappen Sie Ihre Realität, nicht das Org-Chart aus dem FAANG-Blogpost, den Sie letzte Woche gelesen haben.

Von der Map zu Rollen: das Anti-Unicorn-Prinzip

Hier sabotieren sich die meisten CDOs selbst. Sie bauen eine reiche Skills Map und klappen sie dann in eine einzige Stellenbeschreibung zusammen, die alles fordert. Die inzwischen klassische Parodie einer Ausschreibung: „Suchen Data Scientist mit Statistik auf PhD-Niveau, Produktionserfahrung mit Spark, dbt-Meisterschaft, Stakeholder Management und Kubernetes.“ Diese Person existiert in Ihrem Comp-Band etwa im Verhältnis 1 zu 5.000, und sie einzustellen erzeugt eine Bus-Factor-of-one-Abhängigkeit, die Sie über Jahre wieder auflösen.

Das Anti-Unicorn-Prinzip: Eine Rolle sollte tiefe Stärke in einer Domäne, Arbeitskompetenz in einer angrenzenden Domäne und Literacy im Rest verlangen. Deep-adjacent-literate, das „T-Shape“, das alle zitieren und wenige durchsetzen.

Konkret heißt das: Ein Analytics Engineer ist *deep* in Modeling/Transformation, *competent* in Analytics (er versteht die Fragen) und *literate* in Governance (er weiß, warum Lineage zählt). Sie verlangen von ihm nicht, ML-Modelle zu bauen. Wenn Ihre Ausschreibung drei „deep“-Anforderungen enthält, haben Sie einen Job für zwei Personen geschrieben, und der Markt bestraft Sie mit einer sechsmonatigen Vakanz.

Der Test vor dem Posten: Fragen Sie bei jedem „Must-have“, ob ein starker Kandidat es in 90 Tagen im Job lernen könnte. Wenn ja, ist es ein Nice-to-have. Verschieben Sie es. Die meisten Ausschreibungen sterben an Must-have-Fettleibigkeit, jeder Stakeholder fügt seinen Lieblings-Skill hinzu, und der zusammengesetzte Kandidat wird imaginär.

Die Rollen tatsächlich gestalten

Mit der Map und dem Anti-Unicorn-Prinzip lösen sich die meisten modernen Teams in einen kleinen Satz dauerhafter Rollen-Archetypen auf. Ihre Aufgabe ist zu entscheiden, welche Sie *jetzt* brauchen und in welchem Verhältnis.

Analytics Engineer, wohl der Hire mit dem höchsten Leverage der letzten fünf Jahre und derjenige, der Airbnbs Krise löste. Sitzt zwischen Rohdaten und Analysten, verantwortet den Transformation Layer (dbt, semantische Modelle) und verwandelt chaotische Warehouse-Tabellen in vertrauenswürdige, dokumentierte, getestete Datenprodukte. Diese Rolle befreit Ihre Scientists von SQL-Hausmeisterarbeit und Ihre Engineers von BI-Anfragen. Wenn Ihre Data Scientists produktive Transformationslogik schreiben, ist das Ihr erster Hire.

Data Engineer, verantwortet Ingestion, Orchestrierung und Plattformzuverlässigkeit. Deep in Systemen, competent bei Kosten-/Performance-Tradeoffs. Das ist Ihr Infrastruktur-Rückgrat; unterbesetzen Sie hier und alles Nachgelagerte ist unzuverlässig.

Analyst / Analytics-Partner, deep in der Business-Domäne und in Experimentation, eingebettet in eine Funktion (Growth, Finance, Ops). Der Unterschied zwischen einem guten und einem großartigen Analysten ist nicht das Tooling; es ist die Fähigkeit, eine vage Executive-Frage in eine bearbeitbare, beantwortbare Frage umzuformulieren.

Data Scientist / ML Engineer, stellen Sie *eng* ein. Seien Sie ehrlich, ob Sie Inferenz brauchen (causal, Design von Experimenten) oder Produktions-ML (Modelle im Serving-Pfad). Das sind verschiedene Menschen. Diese Vermischung ist der Grund, warum so viele „Data Scientists“ unglücklich sind, sie wurden für Statistik eingestellt und sollten MLOps machen.

Data Product Manager, verantwortet die Plattform und zentrale Datenassets als Produkte. Definiert Adoption-Metriken, priorisiert die Roadmap, managt die Beziehung zum internen Kunden. In einer reifen Organisation verhindert diese Rolle, dass Ihre Plattform zum Friedhof ungenutzter Tabellen wird.

Governance / Data Quality Engineer, operationalisiert Vertrauen. Verantwortet Quality Monitoring, Lineage-Tooling, Umsetzung von Zugriffsrechten. Kein Compliance Officer, ein Engineer, der Governance automatisch laufen lässt.

Das Verhältnis zählt mehr als die Besetzungsliste. Eine brauchbare Startheuristik für eine Organisation mittlerer Reife: Auf jeweils 4-5 Personen, die Insight *produzieren* (Analysten, Scientists), brauchen Sie etwa 2-3, die ihn *ermöglichen* (Engineers, Analytics Engineers), und mindestens 1, die ihn *produktisiert und governt*. Teams, die reine Produzenten sind, kollabieren innerhalb von 18 Monaten unter ihren eigenen technischen Schulden.

How to Build a Data Team from Scratch

Watch on YouTube

Ausschreibungen schreiben und Screening, das Performance wirklich vorhersagt

Sind die Rollen definiert, wird die Stellenbeschreibung zum Filter, und die meisten sind schlechte Filter. Reduzieren Sie Ihre auf drei Abschnitte: das *Problem, das diese Person verantwortet* (nicht „Aufgaben“, das tatsächliche Ergebnis, für das sie einsteht), die erforderliche *Deep Skill* und die erwartete *Literacy*. Streichen Sie die Wunschliste. Eine Stellenbeschreibung, die wie ein Systemanforderungsdokument liest, signalisiert ein Team, das nicht weiß, was es will.

Verzichten Sie beim Screening für Data-Rollen auf Whiteboard-Algorithmus-Puzzles, sie sagen nichts vorher. Nutzen Sie Work-Sample-Tests, die den echten Job spiegeln. Geben Sie einem Analytics Engineer ein unordentliches Schema und lassen Sie ihn ein Modell entwerfen und dokumentieren. Geben Sie einem Analysten eine echte (anonymisierte) ambivalente Business-Frage und einen Datensatz, und bewerten Sie, wie er sie rahmt, nicht nur die Antwort. Das Signal, das Sie wollen, ist *Urteilsfähigkeit unter Ambiguität*, und genau die entfernt ein Puzzle.

Ein saubere Weg, die Skill-Erwartung für eine Rolle zu kodieren, der Sie auch zwingt, bei Tiefe vs. Literacy ehrlich zu sein:

yaml
role: analytics_engineer
owns: "trusted, tested transformation layer feeding all BI"
skills:
  data_modeling:      deep       # nicht verhandelbar
  sql:                deep
  testing_ci:         competent
  business_context:   competent
  governance_lineage: literate
  ml:                 none       # ausdrücklich nicht erforderlich

Das so zu schreiben, pro Rolle, bewirkt zwei Dinge: Es beendet die Must-have-Fettleibigkeit, und es wird genau das Rubric, gegen das Ihre Interviewer bewerten. Wenn jeder Interviewer dieselben Dimensionen auf derselben Skala bewertet, eliminieren Sie den „ich fand sie einfach sympathisch“-Bias, der homogene Teams produziert.

Wissenscheck

1. Was war laut Lektion die Grundursache dafür, dass das Data-Team trotz exzellentem Headcount und exzellenter Talentdichte nicht lieferte?

2. Die Lektion argumentiert, dass Seniorität vor allem als Funktion von was definiert werden sollte?

3. Warum bestehen die Lektion darauf, eine Skills Map von „der Arbeit“ aus zu beginnen statt von Jobtiteln?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE Aussagen, die die Sicht der Lektion auf die Rolle des CDO beim Aufbau eines Data-Teams korrekt wiedergeben.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE korrekten Beschreibungen der fünf Capability-Domänen eines modernen Data-Teams, wie sie in der Lektion definiert werden.

Wählen Sie alle richtigen Antworten aus.

Buy, Build und die Marktrealität

Auch eine perfekte Skills Map stößt auf einen Arbeitsmarkt. Der Senior Data Engineer, den Sie spezifiziert haben, kostet in kompetitiven Märkten 220.000 $+ und wechselt nach 2-3 Jahren. Die Map ist also auch ein Werkzeug für Build-vs-Buy-Entscheidungen.

Fragen Sie für jede Zelle Ihres Rasters: Ist dieser Skill *rar und dauerhaft* (senior kaufen, gut zahlen, hart binden) oder *erlernbar und reichlich vorhanden* (junior kaufen, intern entwickeln)? Analytics-Engineering-Kompetenz etwa ist für einen starken Analysten mit SQL sehr gut erlernbar, deshalb ist es oft günstiger und stabiler, sie aufzubauen statt zu kaufen. Tiefe ML-Infrastruktur ist rar und intern teuer zu entwickeln, kaufen Sie sie. Jede Domäne gegen diese Rar/Erlernbar-Achse zu mappen, macht aus Ihrem Hiring-Plan ein *Portfolio*: einige teure Senior-Anker, die Struktur schaffen, umgeben von entwickelbaren Talenten, die bleiben, weil Sie der Ort sind, der sie entwickelt hat.

Das rahmt das Unicorn-Problem vollständig neu. Sie brauchen nicht eine Person, die alles hat. Sie brauchen ein *Team*, dessen Skills Map in der Summe alles abdeckt, mit bewusster Redundanz bei den tragenden Skills, sodass kein einzelner Abgang Sie lahmlegt. Die Einheit der Vollständigkeit ist das Team, niemals die Einzelperson.

Sourcing jenseits des offensichtlichen Pools

Die Kandidaten, die perfekt auf Ihre Ausschreibung passen, sind die, die jeder andere CDO auch jagt. Zwei Bewegungen verbreitern den Pool, ohne die Messlatte zu senken.

Rekrutieren Sie für die Deep Skill und die Entwicklungskurve, und sortieren Sie bei den Literacy-Lücken aus, die wirklich nicht vermittelbar sind. Domänenkontext (Ihr Geschäft verstehen) ist vermittelbar. Statistische Intuition ist schwer zu vermitteln. Ein brillanter Scientist aus einer anderen Branche ist also die bessere Wette als ein mittelmäßiger aus Ihrer, das Gegenteil der meisten Hiring-Instinkte.

Zweitens: Bauen Sie die Pipeline aus angrenzenden Rollen, die Sie schon beschäftigen. Ihre besten Analytics Engineers sind oft Ihre frustrierten Analysten, die sich dbt selbst beigebracht haben. Ihre besten Data PMs sind oft Analysten, die immer wieder natürlich zur Frage „wer nutzt das eigentlich?“ gezogen wurden. Diese Wege explizit zu benennen und die Übergänge zu finanzieren, ist günstiger, schneller und bringt höhere Retention als jede externe Ausschreibung. Es signalisiert außerdem dem ganzen Team, dass Wachstum hier möglich ist, und das tut für Retention mehr als jede Comp-Anpassung.

Der CDO, der Hiring als isolierte Transaktion behandelt, wird immer hinterherlaufen. Wer es als Portfoliokonstruktion gegen eine lebende Skills Map behandelt, die raren Anker kauft, den erlernbaren Kern entwickelt und aus Angrenzendem sourct, baut ein Team, das sich verzinst statt zu churnen.

Key Takeaways

  • Bauen Sie die Skills Map vor dem Org-Chart. Zerlegen Sie die Arbeit in fünf Domänen (Engineering, Analytics, Science, Governance, Product), kreuzen Sie sie mit dem echten Seniority-Bedarf und gewichten Sie nach *Ihrer* Reifestufe, nicht nach der eines Blogposts.
  • Setzen Sie deep-adjacent-literate bei jeder Rolle durch. Eine Deep Skill, eine kompetente Angrenzung, Literacy im Rest. Wenden Sie den 90-Tage-Test auf jedes „Must-have“ an und löschen Sie die, die ein starker Hire im Job lernen könnte.
  • Stellen Sie den Analytics Engineer früh ein. Wenn Scientists und Analysten Transformations-Hausmeisterarbeit machen, setzt diese eine Rolle die Produktivität frei, für die Sie mehr Headcount zu brauchen glaubten.
  • Behandeln Sie Hiring als Portfoliokonstruktion. Mappen Sie jeden Skill als rar-und-dauerhaft (senior kaufen, hart binden) oder erlernbar-und-reichlich (intern entwickeln). Die Einheit der Vollständigkeit ist das Team, niemals das Unicorn-Individuum.
  • Screenen Sie mit Work Samples, nicht mit Puzzles, und bewerten Sie alle mit demselben Rollen-Rubric. Urteilsfähigkeit unter Ambiguität ist das Signal; ein gemeinsames Rubric ist Ihr Schutz vor homogenen, bias-getriebenen Teams.

Was Sie aus dieser Lektion umsetzen

Diese Maßnahmen sind im Playbook der Rolle zusammengefasst.

  • Erstellen Sie eine Skills-Map und stellen Sie früh einen Analytics Engineer ein
Vollständiges Action Playbook ansehen