Das typische Org-Chart, das ich in deutschen Mittelständlern sehe, hat drei Data Analysts, einen Lead, und einen hoffnungsvollen Pfeil in Richtung „KI-Initiative". Nach 18 Monaten wundern sich alle, warum das Team fleißig Dashboards baut, aber keine Wirkung zeigt. Der Grund: Du brauchst fünf Rollen, nicht fünf Analysts. In diesem Artikel beschreibe ich jede Rolle inklusive dem Fehlbild, das Stellenanzeigen typischerweise verbreiten.
Warum das Org-Chart eine schlechte Vorlage ist
Der typische Fehler ist, in Titeln zu denken statt in Rollen. Titel definieren Gehälter, Rollen definieren Arbeitsprodukte. Wenn du beim Team-Aufbau fragst „Wie viele Mitarbeiter brauche ich?", fragst du die falsche Frage. Die richtige: Welche Arbeitsprodukte muss das Team liefern — und welche Rollen gehören dazu?
Die fünf Rollen, die ich gleich beschreibe, sind nicht fünf Köpfe. In einem 3-Personen-Team kann eine Person anfangs zwei Rollen halten. Aber nach 12 Monaten brauchst du die meisten Rollen getrennt — weil die Rollen-Erwartungen sonst kollidieren und die Person zerreiben.
Rolle 1 — Data Engineer: das Fundament
Diese Rolle baut und betreibt die Plattform: Pipelines, Warehouse oder Lakehouse, Data Contracts, Monitoring. Ohne Data Engineering keine verlässlichen Daten, ohne verlässliche Daten kein Analytics-Wert.
Das Fehlbild: „Data Engineer = Skripte-Schreiber für Reports". Das ist Analytics Engineer. Wenn deine Stellenanzeige für Data Engineer SQL-Queries als Kern-Arbeit listet, verwechselst du zwei Rollen.
Konkrete Arbeitsprodukte: Pipeline-Architektur, Data-Contract-Management, Qualitäts-Monitoring, Infrastruktur-Kosten-Management.
Wann zuerst besetzen: Fast immer als erste technische Rolle. Ohne Pipeline keine Daten.
Data Products als Arbeitsebene ist das Konzept, in das Data Engineering in reifen Organisationen hineinwächst.
Rolle 2 — Analytics Engineer / Data Scientist: der Hebel
Diese Rolle nimmt, was Data Engineering baut, und macht es analysefähig. Transformations-Logik in dbt, Metriken-Kataloge in einem Semantic Layer, experimentelle Modelle für Business-Fragen.
Die saubere Trennung zu Data Scientist ist eine relativ neue Unterscheidung — seit dbt und der Modern Data Stack etabliert wurde. Analytics Engineer macht die Transformations-Arbeit, Data Scientist baut Modelle und führt Experimente. Beide nutzen die gleiche Plattform, haben aber verschiedene Arbeitsprodukte.
Das Fehlbild: „Data Scientist = macht bunte Dashboards". Nein, das ist Business Analyst. Data Scientist macht Modelle, die Entscheidungen verändern.
Rolle 3 — Data Product Manager: der oft fehlende Link
Diese Rolle entscheidet, was das Data-Team baut, und verantwortet die Wirkung. Discovery, Roadmap, KPI-Ownership, Stakeholder-Management. Wer schon mal Product Management in einer digitalen Organisation gemacht hat, kennt das Profil — hier ist es auf Daten-Produkte übertragen.
Die Rolle fehlt in 80 Prozent aller deutschen Mittelständler, die ich bei mir in der Beratung sehe. Das ist der teuerste Single-Point-of-Failure in jeder Daten-Organisation. Warum? Weil das Team ohne diese Rolle an Problemen vorbeibaut — brillante Dashboards, die niemand braucht.
Abgrenzung zum klassischen Product Manager: Data Products sind interne Produkte, nicht kundenorientierte. Der Data PM muss interne „Kunden" (Fachbereiche) verstehen, nicht Endkunden.
Abgrenzung zum Business Analyst: Der BA analysiert Daten für Business-Fragen. Der Data PM gestaltet, welche Daten-Produkte das Team überhaupt liefert.
<JonasTake number={1}> Die Rolle, die meist zu spät besetzt wird. Ich sehe immer wieder denselben Ablauf: Die ersten 12 Monate baut das Team Plattform und erste Dashboards, der Head of Data macht Product Management nebenbei. Dann kommt Monat 14, das Team ist auf sechs Leute gewachsen, die Nachfrage übersteigt die Kapazität, und keiner priorisiert. Jetzt wird panisch ein PM gesucht — meist ein Jahr zu spät. Der Schmerz dieses einen verlorenen Jahres ist typischerweise der teuerste Fehler im gesamten Team-Aufbau. </JonasTake>
Rolle 4 — Data Translator: die teuerste Rolle, die keiner haben will
Der Data Translator ist die Brücke zwischen Fachbereich und Data-Team. Nicht Assistenz, nicht PowerPoint-Bauer — eine eigenständige Rolle mit eigenem Profil.
Was diese Person tut: Die Fachsprache einer Domäne (Vertrieb, Produktion, Marketing) in Daten-Fragen übersetzen. Und umgekehrt: Erkenntnisse des Data-Teams so übersetzen, dass sie im Fachbereich operationalisiert werden.
Warum schwer zu besetzen: Hybrides Profil. Muss Domänen-Wissen plus Daten-Verständnis plus Stakeholder-Management mitbringen. Solche Menschen sind selten am Markt verfügbar — oft baust du sie intern aus Fachbereichs-Talenten auf, die sich Daten-Kompetenz aneignen wollen.
Hire oder intern aufbauen: In 80 Prozent der Fälle intern. Die Domänen-Kompetenz ist der härtere Teil.
Rolle 5 — Data Governance Lead: der unbeliebte Retter
Diese Rolle hält die Daten-Ordnung: Policies, Datenkatalog, Access-Regeln, Compliance-Übersetzung. In kleinen Teams läuft sie oft nebenbei mit — ab 20 Data-Mitarbeitern oder ab Reifegrad 3 nicht mehr.
Arbeitsprodukte: Governance-Framework (siehe Data Governance Cluster), Data-Owner-Rollen in Fachbereichen, Quality-Metriken, Zugriffsmodelle.
Typisches Fehlbild: „Governance-Rolle als Bremse". Wenn deine Governance als Bremse wahrgenommen wird, hast du einen politischen Governance Lead, keinen produktiven. Die Rolle muss ermöglichen, nicht verhindern.
Hire, Freelance oder Vendor? Eine Daumenregel pro Rolle
| Rolle | Empfehlung | Warum | |---|---|---| | Data Engineer | Hire (Core) | Wissen über deine Datenlandschaft sollte intern bleiben | | Analytics Engineer | Hybrid | Junior intern, Senior als Sparringspartner extern möglich | | Data Product Manager | Hire (strategisch) | Formt die Roadmap — gehört nicht nach außen | | Data Translator | Hire (domänennah) | Muss die Fachsprache deiner Domäne sprechen | | Data Governance Lead | Hire ab Team-Größe 10+ | Extern für Initial-Setup, dann intern | | Tool-Implementierung | Vendor / Freelance | Einmalige Rollouts brauchen keine Dauer-Rolle |
Das Null-Prinzip: Die Rolle, die deine Strategie formt, gehört intern. Alles andere kannst du abwägen.
Der Aufbau-Pfad: welche Rollen zuerst?
Phase 1 — das Fundament (Monate 1–6). Zwei Personen: Data Engineer plus Data Product Manager. Klingt ungewöhnlich, ist aber wichtig. Der DE baut, der PM entscheidet was gebaut wird. Zwei Personen sind das absolute Minimum, um ernsthaft zu starten.
Phase 2 — der Hebel (Monate 7–15). Analytics Engineer oder Data Scientist (je nach Fokus), ein erster Data Translator in der priorisierten Domäne. Jetzt bist du bei vier Köpfen.
Phase 3 — die Stabilisierung (Monate 16–30). Data Governance Lead (fest, nicht nebenbei), zweite Engineer-Welle, und eine Data-Literacy-Rolle — siehe Data Literacy Cluster.
Die Umkehrregel: NIE mit drei Data Analysts starten. Das ist der typische Fehler. Drei Analysts produzieren schöne Dashboards und keine Wirkung, weil sie weder die Plattform bauen noch das Problem kuratieren. Analysts kommen in Phase 2 oder 3, nicht in Phase 1.
Die 3 häufigsten Team-Fehler im Mittelstand
Fehler 1: „Wir nehmen erstmal einen Lead, der macht dann alles." Das funktioniert für drei Monate. In Monat 4 ist die Person überlastet, das Team wächst nicht, die Erwartungen schon.
Fehler 2: „Hiring nach Tools statt nach Problemen." Ich sehe regelmäßig Stellenanzeigen für „Snowflake-Engineer". Das ist ein Data Engineer, der Snowflake kennt — nicht ein eigenes Profil. Du baust dir eine Tool-Abhängigkeit ins Team.
Fehler 3: „Kein Product Manager, weil zu teuer." Der mit Abstand teuerste Fehler. Ein Jahr ohne Data PM kostet dich mehr als drei Jahre Gehalt eines Data PM, weil das Team an Problemen vorbeibaut.
Häufig gestellte Fragen
<FAQ />
Weiterhören im Podcast
<WeiterhoerenBlock topic="Team-Aufbau" categories={["leadership", "data_strategy"]} limit={3} />
<CTA> Unsicher, welche Rolle bei dir zuerst dran ist? 30 Minuten Sparring mit einem aktiven CDO, der die Rollen-Muster in 15 Jahren dreimal durchgespielt hat. Beratung anfragen → </CTA>
Dieser Artikel ist Teil meines Leitfadens zur datengetriebenen Transformation.