Data-Talente einstellen und die Skills Map

2019 veröffentlichte Airbnb eine inzwischen berühmte interne Bestandsaufnahme: Sie hatten rund 100 Data Scientists, aber die Organisation lieferte nicht. Analysten wurden ins PipelinePipelineAlle aktiven Verkaufschancen über die Phasen des Vertriebsprozesses hinweg, zusammen mit ihrem gesamten potenziellen Wert und ihrer Abschlusswahrscheinlichkeit.Vollständige Definition ansehen →-Firefighting gezogen. Promovierte, die gekommen waren, um Modelle für Causal InferenceInferenceDer Moment, in dem ein trainiertes KI-Modell arbeitet: Es nimmt eine neue Eingabe und erzeugt eine Antwort, Vorhersage oder generierte Ausgabe.Vollständige Definition ansehen → zu bauen, schrieben ihre Wochen lang SQLSQLSales Qualified Lead: ein Prospect, den das Sales-Team als bereit für direkte Ansprache und ein Angebot validiert hat, weil er klare Qualifizierungskriterien erfüllt.Vollständige Definition ansehen → für Management-Dashboards. Das Problem war weder Headcount noch Talentdichte, beides war exzellent. Das Problem war, dass Airbnb einen Titel eingestellt hatte („Data Scientist“) statt gegen eine Skills MapMapEinsatz von Software, um wiederkehrende Marketingaufgaben und Kampagnen zu automatisieren und Personalisierung in großem Maßstab über Kanäle wie E-Mail, Web und Social zu ermöglichen.Vollständige Definition ansehen → zu rekrutieren. Alle waren Generalisten, also besaß niemand die spezialisierte Arbeit, die das Geschäft tatsächlich bewegte.

Genau dieses Muster werden Sie wiederholen, wenn Sie Hiring als „wir brauchen mehr Data-Leute“ angehen. Die Aufgabe des CDO ist nicht, Talente zu beschaffen. Sie ist, **die *Form* des Teams präzise genug zu definieren, dass jede Einstellung in ein System passt**, und dann für diese Form zu rekrutieren, ohne auf einen mythischen Fünf-in-Eins-Kandidaten zu warten, den es nicht gibt und der innerhalb eines Jahres kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →ündigen würde, wenn es ihn gäbe.

Die Skills Map: Zerlegen Sie das Team, bevor Sie die Stelle 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. Fangen Sie nicht bei Titeln an. Titel sind nachgelagerte Lügen; sie bedeuten in jedem Unternehmen etwas anderes. Fangen Sie bei der Arbeit an.

Ein modernes Datenteam spannt fünf Capability-Domänen auf. Sie werden sie unterschiedlich gewichten, aber ignorieren können Sie keine:

• Engineering, Daten zuverlässig bewegen, modellieren und bereitstellen. Pipelines, Orchestrierung, Warehouse-/LakehouseLakehouseEine hybride Architektur, die die Flexibilität eines Data Lake mit den analytischen Fähigkeiten eines Data Warehouse auf einer einzigen Storage-Schicht verbindet.Vollständige Definition ansehen →-Design, Data ContractsData ContractsFormale Vereinbarung zwischen dem Team, das Daten erzeugt, und denen, die sie nutzen: legt Struktur, Bedeutung, Qualität und Verantwortung bei Fehlern fest.Vollständige Definition ansehen →, Latenz- und Kosten-SLAs.
• Analytics, Daten in Entscheidungen verwandeln. Metrikdefinition, Experimentation, Business Partnering, die „Warum ist der Umsatz eingebrochen“-Arbeit.
• Science, prädiktive und inferentielle Systeme bauen. ML-Modelle, Causal Inference, Optimierung, Forecasting.
• Governance, Daten vertrauenswürdig und compliant machen *als operative Disziplin*, nicht als Richtlinienordner. Lineage, Quality Monitoring, Umsetzung von Access Control, Privacy Engineering.
• Product, Datenassets und Plattformen als Produkte behandeln, mit Nutzern, Roadmaps und Adoption-Metriken. Diese Domäne besetzen die meisten CDOs zu dünn und bereuen es am meisten.

Jetzt legen Sie die zweite Dimension darüber: Seniorität als Funktion von Ambiguitätstoleranz, nicht von Jahren. Eine erfahrene Person absorbiert Ambiguität und wandelt sie in Struktur für andere um. Eine Junior-Person erledigt klar abgegrenzte Aufgaben. Der Fehler besteht darin, drei Seniors einzustellen, die alle Strategie definieren wollen und von denen keiner die dbt-Modelle schreibt, oder fünf Juniors ohne jemanden, der das System entwirft, 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 angesichts Ihres Reifegrads tatsächlich brauchen. Eine Organisation ohne Plattform, die noch mit Spreadsheets arbeitet, braucht ein starkes Gewicht auf Senior-Engineering und fast keine Science. Ein Unternehmen mit solider Plattform und ungenutzten Entscheidungen braucht Analytics und Product. Bilden Sie Ihre Realität ab, nicht das Organigramm aus dem FAANG-Blogpost, den Sie letzte Woche gelesen haben.

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

Hier sabotieren sich die meisten CDOs selbst. Nachdem sie eine reichhaltige Skills Map gebaut haben, falten sie sie zurück in eine einzige Stellenbeschreibung, die alles verlangt. Die inzwischen klassische Parodie einer Ausschreibung: „Gesucht: Data Scientist mit Statistik auf PhD-Niveau, Produktionserfahrung mit Spark, dbt-Meisterschaft, Stakeholder Management und Kubernetes.“ Diese Person existiert in Ihrer Comp-Band vielleicht einmal unter 5.000, und sie einzustellen erzeugt eine Bus-Faktor-1-Abhängigkeit, die Sie jahrelang wieder auflösen.

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

Konkret heißt das: Ein Analytics Engineer ist *deep* in Modellierung/Transformation, *competent* in Analytics (ererDas Verhältnis von Interaktionen (Likes, Kommentare, Shares) zur Reichweite eines Inhalts. Zeigt, wie stark die Zielgruppe reagiert, gemessen an der Zahl der Personen, die den Inhalt gesehen haben.Vollständige Definition ansehen → 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 eine Stelle für zwei Personen geschrieben, und der Markt bestraft Sie mit sechs Monaten Vakanz.

Der Test vor dem Veröffentlichen: 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 ergänzt seinen Lieblingsskill, und der zusammengesetzte Kandidat wird imaginär.

Die Rollen tatsächlich entwerfen

Mit der Map und dem Anti-Unicorn-Prinzip in der Hand lösen sich die meisten modernen Teams in eine kleine Zahl dauerhafter Rollenarchetypen auf. **Ihre Aufgabe ist zu entscheiden, welche Sie *jetzt* brauchen und in welchem Verhältnis.**

Analytics Engineer, wohl die hebelstärkste Einstellung der letzten fünf Jahre und diejenige, die Airbnbs Krise gelöst hat. Sitzt zwischen Rohdaten und Analysten, besitzt den Transformation Layer (dbt, Semantic Models) und macht aus chaotischen Warehouse-Tabellen vertrauenswürdige, dokumentierte, getestete Datenprodukte. Diese Rolle zu besetzen befreit Ihre Scientists von SQL-Hausmeisterarbeit und Ihre Engineers von BI-Anfragen. Wenn bei Ihnen Data Scientists Transformationslogik für die Produktion schreiben, ist das Ihre erste Einstellung.

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

Analyst / Analytics Partner, deep in der Geschäftsdomäne und in Experimentation, eingebettet in eine Funktion (Growth, Finance, Ops). Der Unterschied zwischen einem guten und einem großartigen Analysten liegt nicht im Tooling; er liegt in der Fähigkeit, eine vage Management-Frage in eine bearbeitbare, beantwortbare umzuformulieren.

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

Data Product Manager, besitzt die Plattform und zentrale Datenassets als Produkte. Definiert Adoption-Metriken, priorisiert die Roadmap, steuert die interne Kundenbeziehung. In einer reifen Organisation verhindert diese Rolle, dass Ihre Plattform zum Friedhof ungenutzter Tabellen wird.

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

Das Verhältnis zählt mehr als die Aufstellung. Eine brauchbare Ausgangsheuristik für eine Organisation mittlerer Reife: **Auf je 4-5 Personen, die Insight *produzieren* (Analysten, Scientists), brauchen Sie ungefähr 2-3, die ihn *ermöglichen*** (Engineers, Analytics Engineers) und mindestens 1, der ihn *produktisiert und governt*. Teams, die ganz auf Produzenten setzen, brechen innerhalb von 18 Monaten unter ihrer eigenen technischen Schuld zusammen.

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 besitzt* (nicht „Aufgaben“, sondern das Ergebnis, für das sie verantwortlich ist)**, den erforderlichen *Deep Skill* und die erwartete *Literacy*. Streichen Sie die Wunschliste. Eine Stellenbeschreibung, die sich wie ein Systemanforderungsdokument liest, signalisiert ein Team, das nicht weiß, was es will.

Verzichten Sie beim Screening für Data-Rollen auf Whiteboard-Algorithmusrätsel, sie sagen nichts vorher. Nutzen Sie Work-Sample-Tests, die die tatsächliche Arbeit spiegeln. Geben Sie einem Analytics Engineer ein unsauberes Schema und lassen Sie ihn ein Modell entwerfen und dokumentieren. Geben Sie einem Analysten eine echte (anonymisierte) mehrdeutige Geschäftsfrage und einen Datensatz und bewerten Sie, wie er sie rahmt, nicht nur die Antwort. **Das Signal, das Sie wollen, ist *Urteilsvermögen unter Ambiguität*, und genau das nimmt ein Rätsel heraus**.

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

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 pro Rolle so zu schreiben bewirkt zweierlei: Es tötet die Must-have-Fettleibigkeit, und es wird zur exakten Bewertungsmatrix, gegen die Ihre Interviewer bewerten. Wenn jeder Interviewer dieselben Dimensionen auf derselben Skala bewertet, eliminieren Sie den „Ich mochte sie einfach“-Bias, der homogene Teams hervorbringt.

Buy, Build und die Marktrealität

Auch eine perfekte Skills Map trifft auf einen Arbeitsmarkt. Der Senior Data Engineer, den Sie spezifiziert haben, kostet in kompetitiven Märkten über 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 *selten und dauerhaft* (senior einkaufen, gut bezahlen, hart binden) oder *erlernbar und reichlich vorhanden* (junior einstellen, intern entwickeln)? Kompetenz im Analytics Engineering etwa ist für einen starken Analysten mit SQL gut erlernbar, deshalb ist es oft günstiger und stabiler, sie aufzubauen statt einzukaufen. Tiefe ML-Infrastruktur ist selten und intern teuer zu entwickeln, kaufen Sie sie ein. Jede Domäne gegen diese Selten/Erlernbar-Achse abzubilden 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 aufgebaut hat.

Das rahmt das Unicorn-Problem komplett neu. Sie brauchen keine Person, die alles hat. Sie brauchen ein *Team*, dessen Skills Map in Summe alles abdeckt, mit bewusster Redundanz bei den tragenden Skills, damit kein einzelner Abgang Sie lahmlegt. Die Einheit der Vollständigkeit ist das Team, nie das Individuum.

Sourcing jenseits des offensichtlichen Pools

Die Kandidaten, die perfekt auf Ihre Ausschreibung passen, sind dieselben, hinter denen jeder andere CDO her ist. Zwei Schritte erweitern den Pool, ohne die Messlatte zu senken.

Stellen Sie auf den Deep Skill und die Entwicklungsrichtung hin ein 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 bereits 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 zur Frage „Wer nutzt das eigentlich?“ gravitierten. Diese Pfade ausdrücklich zu benennen und die Übergänge zu finanzieren ist günstiger, schneller und bringt höhere Retention als jede externe Ausschreibung. Es sendet außerdem an Ihr ganzes Team das Signal, dass Entwicklung hier möglich ist, was für Retention mehr tut als jede Gehaltsanpassung.

Der CDO, der Hiring als isolierte Transaktion behandelt, wird immer hinterherlaufen. Wer es als Portfolioaufbau gegen eine lebende Skills Map behandelt, die seltenen Anker einkauft, den erlernbaren Kern aufbaut und aus Nachbarrollen sourct, baut ein Team, das sich aufbaut statt zu verschleißen.

Wichtigste Erkenntnisse

• Bauen Sie die Skills Map vor dem Organigramm. Zerlegen Sie die Arbeit in fünf Domänen (Engineering, Analytics, Science, Governance, Product), kreuzen Sie sie mit dem realen Seniority-Bedarf und gewichten Sie nach *Ihrem* Reifegrad, nicht nach dem eines Blogposts.
• Setzen Sie Deep-adjacent-literate für jede Rolle durch. Ein Deep Skill, eine kompetente Nachbardomäne, Literacy im Rest. Wenden Sie den 90-Tage-Test auf jedes „Must-have“ an und streichen Sie, was eine starke Einstellung im Job lernen könnte.
• Stellen Sie den Analytics Engineer früh ein. Wenn Scientists und Analysten Transformations-Hausmeisterarbeit machen, schaltet diese eine Rolle die Produktivität frei, für die Sie mehr Headcount zu brauchen glaubten.
• Behandeln Sie Hiring als Portfolioaufbau. Kartieren Sie jeden Skill als selten-und-dauerhaft (senior einkaufen, hart binden) oder erlernbar-und-reichlich (intern aufbauen). Die Einheit der Vollständigkeit ist das Team, nie das Einhorn-Individuum.
• Screenen Sie mit Work Samples statt Rätseln und bewerten Sie alle nach derselben Rollen-Rubrik. Urteilsvermögen unter Ambiguität ist das Signal; eine gemeinsame Rubrik ist Ihr Schutz vor homogenen, bias-getriebenen Teams.