Deutsch

Die ersten 30/60/90 Tage als neuer Data Scientist

Es ist 9:47 Uhr an Tag drei. Sie haben gerade so herausgefunden, welche Slack-Kanäle relevant sind. Ihr Kaffee ist noch heiß. Eine Nachricht kommt von jemandem, den Sie einmal beim Onboarding getroffen haben: „Hey, könntest du dir das Churn-Modell anschauen? Es läuft schon eine Weile nicht mehr richtig."

Herzlichen Glückwunsch. Sie haben gerade 18 Monate an Entscheidungen anderer Menschen geerbt. Zwei frühere Owner, keine Dokumentation, die das Lesen wert wäre, ein Feature-Set, das niemand vollständig versteht, und ein CFO, der seit sechs Wochen fragt, wann „die AI-Investition" sich auszahlt. Das Modell wurde seit August nicht mehr neu trainiert. Ihr Laptop ist noch nicht mal vollständig eingerichtet.

Das ist die tatsächliche Erfahrung an Tag drei für die meisten neuen Data Scientists in B2B SaaS, und die Versuchung ist brutal: schnell irgendetwas liefern, um zu zeigen, dass man seinen Platz verdient. Tun Sie das nicht. Die ersten 90 Tage sind der Zeitraum, in dem Sie die Grundlage dafür legen, ob das Leadership Sie als Umsatzhebel oder als nächste Position betrachtet, die gestrichen wird, wenn der Vorstand nach aufgeblähtem Headcount fragt. Und Data-Science-Rollen werden schneller gestrichen als jede andere technische Funktion, wenn die Geschichte über den Geschäftswert unklar ist.

Hier ist ein 90-Tage-Plan, der keine Heldentaten erfordert, nicht davon abhängt, dass Sie ein Genie sind, und nicht damit endet, dass Sie das kaputte Churn-Modell von jemandem anderem als Ihren KPI übernehmen.

Warum Prüfen besser ist als Bauen (und warum die meisten neuen DS-Einstellungen das falsch machen)

Der größte Fehler, den ein neuer Data Scientist macht, ist das Ausliefern eines neuen Modells in Woche zwei, um produktiv zu wirken. Es fühlt sich gut an. Es bedeutet aber auch, dass Sie jetzt etwas besitzen, dessen Geschäftskontext Sie noch nicht verstehen, dass Sie Stakeholdern signalisiert haben, dass „Modelle ausliefern" Ihr Wertversprechen ist (das ist es nicht), und dass Sie das einzige Zeitfenster übersprungen haben, in dem Sie dumme Fragen stellen dürfen, ohne dafür bewertet zu werden.

Sie haben genau eine Honeymoon-Phase. Nutzen Sie sie zum Zuhören, nicht zum Bauen. Die gute Nachricht: Zuhören produziert greifbare Artefakte (ein Audit-Memo, eine Stakeholder-Karte, ein Data-Warehouse-Spickzettel), die für Ihre Führungskraft genauso produktiv aussehen wie ein halbfertiges Modell, und sie erzeugen keine technischen Schulden.

Tage 1 bis 30: Prüfen und Zuhören

Die ersten 30 Tage haben ein Ziel: eine verteidigbare Karte davon erstellen, was existiert, was kaputt ist und was die Menschen tatsächlich wollen. Keine neuen Modelle. Keine „schnellen Experimente." Keine Versprechen.

Jedes Modell in der Produktion inventarisieren

Erstellen Sie eine Tabelle. Eine Zeile pro Modell, das irgendwo läuft: in der Produktion, als geplantes Notebook, als das Ding in Airflow, das niemand als Modell bezeichnet. Füllen Sie für jedes Modell drei Spalten aus:

  • Leistung versus behauptete Leistung. Was steht in der Modellkarte oder der letzten Quartalsüberprüfung (AUC, Precision im Top-Dezil, MAPE oder was auch immer)? Was tut es tatsächlich auf den letzten 90 Tagen an Daten? Sie werden mindestens ein Modell finden, bei dem der Unterschied peinlich ist. Das Churn-Modell ist meistens der schlimmste Kandidat. Datendrift von 15 bis 25 Prozent bei wichtigen Features ist normal in B2B SaaS, wo sich der Kunden-Mix jedes Quartal verschiebt.
  • Fairness und Drift. Liegt die Eingabeverteilung noch nahe an dem, womit das Modell trainiert wurde? Für tabellarische Modelle gibt Ihnen eine schnelle Prüfung des Population Stability Index (PSI) bei den fünf wichtigsten Features meistens alles, was Sie wissen müssen. PSI über 0,25 bedeutet, dass das Modell außerhalb seiner Trainingsverteilung operiert und die Vorhersagen Rauschen sind, das als Signal verkleidet ist.
  • Tatsächlicher Geschäftswert. Wer nutzt den Output? Welche Entscheidung treibt er an? Was würde passieren, wenn das Modell morgen einen konstanten Wert zurückgäbe? Wenn die Antwort lautet: „Ehrlich gesagt, wahrscheinlich nichts," schreiben Sie das auf. Sie werden es später brauchen.

Drei bis fünf Modelle sind normal. Acht oder mehr bedeutet, dass jemand gebaut hat, um beschäftigt zu wirken, und Sie haben einen Friedhof geerbt.

An fünf Stakeholder-Syncs teilnehmen

Nicht fünf Gespräche. Fünf wiederkehrende Syncs, denen Sie in den ersten zwei oder drei Treffen als stiller Beobachter beitreten, bevor Sie beginnen, etwas beizutragen. Wählen Sie je einen aus:

  • Sales Ops (Forecast-Genauigkeit, Pipeline Coverage, Beschwerden über Lead Scoring)
  • Customer Success (Churn-Signale, Expansion Plays, Verbindungen von NPS zu Umsatz)
  • Product (Feature-Adoption, Aktivierung, was sie schlecht A/B-testen)
  • Finance (Umsatzprognosen, Unit Economics, das tatsächliche Modell des CFO vom Unternehmen)
  • Engineering / Data Platform (Warehouse-Kosten, Pipeline-Zuverlässigkeit, was gerade brennt)

Sie achten auf zwei Dinge: welche Entscheidungen aus dem Bauchgefühl heraus getroffen werden, die auf Datenbasis getroffen werden könnten, und welche Entscheidungen auf Daten basieren, die eigentlich falsch sind. Das Zweite ist häufiger, als man zugeben möchte. Sales Ops, der Pipeline-Forecasts auf der Grundlage eines Salesforce-Berichts erstellt, der Verlängerungen doppelt zählt, ist ein Klassiker in den meisten B2B-SaaS-Unternehmen.

Herausfinden, wo die Fehler im Warehouse stecken

Jedes Data Warehouse hat eine Schicht kleiner, übler Wahrheiten. Drei Mal umbenannte Spalten. Soft-gelöschte Zeilen, die das BI-Tool stillschweigend einbezieht. Zeitzonen-Bugs, durch die Montage in Singapur als Sonntage erscheinen. Ein revenue_usd-Feld, das in einer Tabelle vor dem Rabatt und in der danebenstehenden Tabelle nach dem Rabatt angegeben ist.

Verbringen Sie eine Woche mit derjenigen Person, die die Analytics-Schicht verantwortet. Nehmen Sie ein Notizbuch mit. Fragen Sie: „Was wünschen Sie sich, dass die Menschen wüssten, bevor sie diese Tabelle abfragen?" Sie werden aus dieser einen Frage mehr Wert ziehen als aus drei Wochen dbt-Dokumentation lesen.

Bis Tag 30 sollten Sie haben: eine Audit-Tabelle, Notizen aus fünf Stakeholder-Syncs, ein einseitiges „Data-Warehouse-Fallstricke"-Dokument und null neue Modelle in Arbeit.

Tage 31 bis 60: Einstellen, Liefern, Vorschlagen

Jetzt beginnen Sie, sichtbare Arbeit zu produzieren. Drei Deliverables, in dieser Reihenfolge.

Ein kaputtes Modell einstellen, öffentlich, mit einem Memo

Das klingt karrieregefährdend. Es ist das Gegenteil. Ein kaputtes Modell einzustellen ist das Einzige mit dem höchsten Hebel, das Sie als neuer DS tun können, weil:

  1. Es Rechenkapazität, Aufmerksamkeit des Headcounts und Stakeholder-Bandbreite freisetzt.
  2. Es zeigt, dass Sie Urteilsvermögen haben, nicht nur Durchsatz.
  3. Es stellt fest, dass „ein Modell ausliefern" keine Tugend ist, wenn das Modell falsch ist.

Wählen Sie den schlimmsten Kandidaten aus Ihrem Audit. Der klassische Kandidat ist das Churn-Modell, das in 18 Monaten zweimal neu trainiert wurde, 22 Prozent Feature-Drift aufweist, keine tatsächliche Retention-Maßnahme antreibt (CS-Reps ignorieren den Score) und 400 USD pro Monat an Rechenkosten kostet. Schreiben Sie ein einseitiges Memo: was das Modell behauptet hat, was es tatsächlich getan hat, was es gekostet hat, welche Entscheidung es antreiben sollte, was Sie als Ersatz vorschlagen (oft: „ein einfacher Kohortenreport, wöchentlich aktualisiert").

Schicken Sie das Memo an Ihre Führungskraft und den ursprünglichen Stakeholder. Lassen Sie sie antworten. Neun von zehn Mal werden sie sagen: „Ja, wir haben schon vor Monaten aufgehört, es anzuschauen." Jetzt ist es weg, mit einer Papierspur, und Sie haben dem Leadership gezeigt, dass Sie Ihre eigene Arbeit kürzen, wenn sie sich nicht rentiert.

Eine kurze Vorlage, die funktioniert:

Memo: Einstellung des Modells [Modellname]
Autor: [Sie]
Datum: [Datum]

Was es heute tut: [ein Satz]
Was es beim Launch beanspruchte: [Kennzahl und Wert]
Was es tatsächlich auf den letzten 90 Tagen tut: [Kennzahl und Wert]
Rechenkosten: [USD/Monat]
Entscheidungen, die es antreibt: [Liste, ehrlich wenn die Antwort "keine" ist]
Empfehlung: Einstellung bis [Datum]. Ersatz durch [einfachere Lösung oder nichts].
Risiko bei Nicht-Einstellung: [fortlaufende Wartung und falsches Vertrauen in veraltete Vorhersagen]

Das war es. Eine Seite. Keine Anhänge.

Eine Quick-Win-Analyse liefern, die ein Stakeholder tatsächlich angefragt hat

Kehren Sie zu Ihren Stakeholder-Sync-Notizen zurück. Finden Sie die kleinste, konkreteste Anfrage, diejenige, die die Person beiläufig erwähnt hat, mit einer klaren Entscheidung dahinter. Nicht „Wir sollten AI für X nutzen." Sondern etwas wie: „Ich würde gerne wissen, welcher Onboarding-Schritt in den ersten 14 Tagen am meisten zum Abbruch führt."

Lösen Sie genau das. Slack-freundliche Zusammenfassung. Maximal drei Diagramme. Empfehlung im ersten Absatz. Beziehen Sie die anfragende Person und deren Führungskraft mit ein. Sie versuchen nicht, eine Kaggle-Competition zu gewinnen. Sie beweisen, dass Sie eine echte Frage in eine echte Antwort umwandeln können, innerhalb von unter zehn Arbeitstagen.

Eine 6-Monats-ML-Roadmap vorschlagen, die an 2 bis 3 Geschäftskennzahlen geknüpft ist

Bis Tag 60 sollten Sie genug Kontext haben, um eine Roadmap zu entwerfen. Maximal zwei bis drei Geschäftskennzahlen. Für jede eine 1- bis 2-seitige Hypothese, einen Modell- oder Analyseansatz, eine Aufwandsschätzung (klein / mittel / groß) und vor allem ein Kill-Kriterium (was Sie dazu bringen würde, die Arbeit daran einzustellen).

Kill-Kriterien sind das, was eine Roadmap von einer Wunschliste unterscheidet. „Wenn der Basis-Lift bis Woche 8 unter 5 Prozent liegt, stoppen wir und verteilen um" ist eine Roadmap-Zeile. „Ein Churn-Modell bauen" ist keine.

Teilen Sie die Roadmap mit der Führungskraft, die Sie eingestellt hat. Nehmen Sie Gegenstimmen entgegen. Überarbeiten Sie. Das Ziel ist, dass sie Ihre nächsten zwei Quartale gegenüber jedem in der C-Suite in einem Satz beschreiben können.

Tage 61 bis 90: Eine Kennzahl übernehmen, präsentieren und H2 planen

Die letzten 30 Tage dienen dem Übergang von „der neue DS" zu „der Person, die X verantwortet."

Eine Geschäftskennzahl übernehmen, die an ein Modell geknüpft ist

Entscheidende Formulierung: Sie verantworten die Kennzahl, nicht das Modell. Wenn Sie das „Churn-Modell" übernehmen, haben Sie die Identität von jemand anderem geerbt und werden an etwas gemessen, das Sie nicht entworfen haben. Wenn Sie „12-Monats-Logo-Retention im SMB-Segment" verantworten, können Sie jede Kombination aus Modell, Analyse und operativer Veränderung nutzen, die die Zahl bewegt.

Wählen Sie eine. Nur eine. Sie sollte:

  • Eine Kennzahl sein, die Finance und das Exec-Team bereits verfolgen (erfinden Sie keine neue)
  • In Ihrer Einflusszone liegen (ein Modell berührt sie, aber auch CS-Workflow, Pricing und Product)
  • In 60- bis 90-Tage-Fenstern messbar sein, nicht in 12 Monaten

Gute Kandidaten für einen neuen DS in B2B SaaS: SMB-Churn-Rate, Lead-to-Opp-Conversion, Free-Trial-to-Paid-Conversion, Expansion Revenue pro CSM. Schlechte Kandidaten: Gesamtumsatz (zu viele Inputs, Sie werden nie Anerkennung bekommen), NPS (zu verrauscht), „Modellgenauigkeit" (keine Geschäftskennzahl).

Einem Exec-Bericht nach 90 Tagen präsentieren, an den Exec, der Sie eingestellt hat

15-Minuten-Meeting. Fünf-Folien-Deck. Die Struktur, die funktioniert:

  1. Was ich gefunden habe. Das Audit, in einem Diagramm (eingestellte Modelle, gesunde Modelle, Modelle unter Beobachtung).
  2. Was ich geliefert habe. Die Quick-Win-Analyse, das Einstellungs-Memo, die Kennzahl, die ich jetzt verantworte.
  3. Was ich über das Unternehmen gelernt habe. Die zwei oder drei Dinge, die Sie überrascht haben (Datenqualitätsprobleme, Entscheidungen, die nicht auf Datenbasis getroffen werden, Anfragen, die immer wieder auftauchen).
  4. Die Roadmap. Ihr 6-Monats-Plan mit Kill-Kriterien.
  5. Was ich brauche. Headcount, Infrastruktur, Stakeholder-Zugang, Entscheidungen.

Folie fünf ist die wichtigste und wird am häufigsten ausgelassen. Wenn Sie nicht artikulieren können, was Sie brauchen, um in den nächsten 90 Tagen erfolgreich zu sein, wird der Exec davon ausgehen, dass Sie nichts brauchen, und sich dann in Monat sechs fragen, warum der Fortschritt stagniert.

Einen H2-ML-Plan mit Headcount, Infrastruktur und Kill-Kriterien vorschlagen

Das ist die Roadmap von Tag 60, jetzt geschärft durch drei Monate Kontext. Drei Dinge kommen in den H2-Plan, die nicht in der ursprünglichen Roadmap waren:

  • Headcount-Kalkulation. „Um diesen Plan umzusetzen, brauche ich X Engineering-Tage und Y Data-Engineering-Tage pro Quartal. Aktuell habe ich Z. Hier ist die Lücke." Seien Sie konkret. ML Engineers sind teuer. Data-Engineering-Kapazität ist der Engpass bei 60 Prozent der DS-Arbeit in den meisten B2B-SaaS-Unternehmen, und das früh laut auszusprechen schützt Sie davor, für Lieferprobleme verantwortlich gemacht zu werden, die nicht Ihre sind.
  • Infrastruktur-Bedarf. Feature Store? Experiment-Tracking? Eine verwaltete Inferenz-Plattform? Listen Sie sie mit ungefähren Kosten auf. Der CFO sieht lieber jetzt eine 30.000-USD-Jahresposition als eine 30.000-USD-Überraschung in Q3.
  • Kill-Kriterien, aktualisiert. Sechs Monate Arbeit zeigen immer, welche Wetten falsch waren. Legen Sie fest, wann Sie aufhören, nicht nur wann Sie anfangen.

Das Gespräch, in dem der CFO nach dem ROI fragt

Dieses Gespräch kommt. Wahrscheinlich in Woche 5 oder 6. Es klingt meistens so: „Wann sehen wir also Erträge aus der AI-Investition?"

Die falschen Antworten: „Es ist eine langfristige Investition." „AI braucht Zeit." „Wir sind noch in der Experimentierphase." All das stimmt. Nichts davon funktioniert. Der CFO stellt eine legitime Frage und verdient eine legitime Antwort.

Die Antwort, die funktioniert:

„Gerade befinde ich mich im Audit-Modus. Ich habe zwei Modelle gefunden, die uns etwa X USD pro Monat kosten und keine Entscheidungen antreiben, und ich stelle diese bis Ende des Monats ein. Bis Tag 90 werde ich die SMB-Churn-Kennzahl verantworten und eine Roadmap mit zwei oder drei Wetten haben, jede an eine Geschäftskennzahl geknüpft, die Sie bereits verfolgen, jede mit einem Kill-Kriterium. Die ehrliche Antwort auf die Frage, wann wir Erträge sehen, lautet: bis Ende Q3, wenn ich richtig liege, und wir werden es früh genug wissen, um umzusteuern, wenn ich falsch liege."

Das ist das Framing. Konkrete kurzfristige Maßnahmen, eine Kennzahl, die Sie verantworten, ein Datum und ein Plan, schnell zu scheitern, wenn die Wetten nicht aufgehen. CFOs reagieren gut auf Kill-Kriterien, weil sie noch nie zuvor von einem Data Scientist gehört haben, dass diese erwähnt werden.

Häufige Fallstricke, die die ersten 90 Tage still zum Scheitern bringen

Ein paar Fallen, in die selbst erfahrene DS-Einstellungen tappen:

  • In Woche zwei etwas bauen, um „produktiv zu wirken." Sie werden die Verantwortung für dieses Modell für immer erben. Widerstehen Sie.
  • AI-Anfragen ohne Klärung der tatsächlichen Entscheidung zusagen. Wenn ein VP sagt: „Können wir AI für [vage Sache] nutzen?", ist die richtige Antwort: „Welche Entscheidung würden Sie mit dem Output anders treffen?" Wenn sie das nicht beantworten können, existiert das Projekt noch nicht. Bieten Sie nicht an, es trotzdem zu bauen. (Scoping vague AI requests geht hier tiefer.)
  • Das kaputte Churn-Modell als Ihren KPI erben. Das Modell ist ein Werkzeug. Retention ist die Kennzahl. Verantworten Sie die Kennzahl.
  • Den Data-Engineering-Overhead ignorieren. 60 Prozent Ihrer Zeit im ersten Jahr gehen für Data Plumbing drauf: Pipelines reparieren, Joins debuggen, prüfen, ob die Warehouse-Zahl mit der BI-Tool-Zahl übereinstimmt. Planen Sie das ein. Tun Sie nicht so, als ob es 20 Prozent sein würden.

Erfolg an Tag 90 messen

Der ehrliche Test für erfolgreiche erste 90 Tage ist nicht „haben Sie ein Modell geliefert." Er lautet:

  • Sie können die drei wichtigsten Geschäftskennzahlen nennen und sagen, welche Modelle jede berühren.
  • Ein kaputtes Modell ist eingestellt, mit einer Papierspur.
  • Eine Quick-Win-Analyse wurde geliefert und vom Anfragenden anerkannt.
  • Sie verantworten eine Kennzahl, nicht fünf.
  • Der Exec, der Sie eingestellt hat, kann Ihre Roadmap in einem Satz beschreiben.

Wenn diese fünf Dinge an Tag 91 zutreffen, sind Sie für ein starkes Jahr aufgestellt. Die Data Scientists, die bis Monat neun ausbrennen, haben fast immer in Monat eins ein neues Modell gebaut und die nächsten acht Monate damit verbracht, es zu verteidigen.

Weiterführende Artikel