Ein Datenteam in einem Startup aufbauen

• Die Geschichte einer Person, die zu einem Mid-Stage-Startup mit einem Jahresumsatz von etwa 10 Milliarden Won gestoßen ist, um ein kleines Datenteam von etwa vier Personen aufzubauen

• Ein metaphorischer Text, der auf einigen Erfahrungen beruht und voreingenommen* sein kann; bitte mit diesem Vorbehalt lesen

1. Juli: Morgen

• Erster Arbeitstag als Leiter des Datenteams

• Begrüßung mit dem CMO

(Der CMO ist sehr aufgeregt, dass ich da bin, und erzählt, dass die Firma eines Freundes mit AI Kundensegmentierung macht und das großartig aussieht.)

(Nach einem kurzen Gespräch untersuche ich die Datenpraxis des Marketingteams.)

DATA: "Wie sehen die Customer Acquisition Costs (CAC) aus?"

CMO: "Hm ... tatsächlich hervorragend. Unser Data Scientist hat die Zahlen gemessen, und die Cost per Click sinken immer weiter."

DATA: (Ich hatte gehört, dass alle Data Scientists an das Datenteam berichten, aber es gibt also einen Data Scientist in einer anderen Organisation?)

CMO: "Das eigentliche Problem ist, dass das Growth-Team nicht den gesamten Traffic konvertiert, den wir auf die Website bringen."

DATA: "Gibt es ein Dashboard, auf dem man den Conversion Funnel sehen kann?"

CMO: "Leads zu konvertieren ist doch Aufgabe des Growth-Teams."

• Gespräch mit einem der Product Manager

Der PM, der die Startseite komplett neu gestaltet hatte, war begeistert, dass die Zahl der Nutzerregistrierungen um ganze 14 % gestiegen sei.

DATA: "Ist dieser Unterschied statistisch signifikant?"

PM: "Das ist nicht mein Job, das ist die Aufgabe Ihres Teams."

PM: "Als wir früher danach gefragt haben, sagte das Datenteam, es gebe keine Daten, und es würde Monate dauern, sie zu bekommen."

PM: "Das Erstaunliche ist, dass wir das nicht inkrementell geändert haben. Für diese Änderung haben wir beschlossen, keinen A/B-Test zu machen. Manchmal muss man groß wetten, um einem Local Maximum zu entkommen."

PM: "Steve Jobs hat beim Launch des iPhone auch keinen A/B-Test gemacht. Unser Team hat das zwei Tage vor der Deadline gelauncht, und das ist doch das Wichtige!"

DATA: (Kritzelt etwas ins Notizbuch und tut so, als wäre ich beschäftigt.)

• Gespräch mit den neuen Teammitgliedern

→ Es ist zwar ein Dreierteam, aber es gibt Budget, bis Jahresende auf zehn Personen zu wachsen.

→ Die Teammitglieder scheinen begeistert, dass ich da bin.

→ Sie zeigen mir, was sie bisher gebaut haben. Es gibt ziemlich viel, und manches davon ist beeindruckend.

✓ Ein neuronales Netz zur Vorhersage von Nutzerabwanderung (Churn Prediction)

✓ Ein Notebook mit implementiertem Empfehlungssystem für verwandte Produkte

→ Viel Code beginnt mit sehr komplexen Vorverarbeitungsschritten, die Daten aus verschiedenen Systemen holen müssen.

✓ Es scheint mehrere Skripte zu geben, die man in der richtigen Reihenfolge manuell ausführen muss, um Teile dieser Arbeit zu erledigen.

→ Als ich das Team frage, warum das nicht in Produktion gebracht wurde:

✓ Die Engineers sagen, dass es ein sehr großes Projekt wäre, das auf Produktionsniveau zu bringen.

✓ Ein Product Manager hat es zwar ins Backlog aufgenommen, aber es wird ständig verschoben, weil immer etwas anderes dazwischenkommt.

✓ Sie sagen, dafür brauche es Rückhalt vom Management.

1. Juli: Nachmittag

• Gespräch mit dem Head of Supply Chain (er wirkt nicht ganz so aufgeregt wie der CMO)

"Ehrlich gesagt weiß ich nicht, ob wir die Hilfe des Datenteams brauchen."

"Wir haben keine Probleme dieser Art. Was wir brauchen, sind Business-Analysten."

"Ich habe ein ganzes Team, und sie verbringen täglich mehrere Stunden damit, an sehr komplexen Modellen zu arbeiten."

"Sie haben nicht einmal Zeit, meine grundlegenden Fragen zu beantworten."

"Ich habe eine Tabellenkalkulation voller Fragen, auf die ich Antworten haben möchte."

(In der Tabelle stehen Dinge wie:)

"Vergleich der Conversion Rate zwischen Kunden, deren Ticket innerhalb einer Stunde gelöst wurde, und Kunden, deren Ticket nach mehr als einer Stunde gelöst wurde, gruppiert in Bestellwert-Intervallen von 100 $."

(Als ich nach dem Modell frage:)

• Offenbar muss etwas in Google Sheets in das richtige Format gebracht und in den passenden Tab kopiert werden, mit unzähligen VLOOKUPs.

• Die Daten werden täglich aktualisiert, und anhand des Modell-Outputs werden die Prioritäten des Teams für den Tag festgelegt.

• Auch die an Lieferanten (Vendoren) auszuzahlenden Kosten werden per Tabellenkalkulation berechnet.

(Zu Hause schenke ich mir ein großes Glas Whisky ein ...)

[ Was ist hier passiert? ]

• Das ist im Grunde eine (etwas zynische) Beschreibung dessen, was in vielen frühen Unternehmen auf einer niedrigen Stufe der Datenreife passiert.

• Fehlende Daten und fragmentierte Daten

→ Oft existieren Daten von Anfang an gar nicht, weil das Produkt nicht richtig instrumentiert wurde.

→ Fragmentierung des Datensystems, bei der Daten über mehrere Systeme verteilt sind.

→ Datengetriebene, aber fragile Business-Prozesse mit kaum oder gar keiner Automatisierung.

• Unklare Erwartungen daran, was die Aufgabe des Datenteams ist

→ Data Scientists werden eingestellt, um R&D zu betreiben und AI auszurollen – mit dem Ergebnis, dass es keine klaren Business-Ziele gibt.

→ Das Datenteam beklagt sich, dass es schwer sei, ML in Produktion zu bringen, während sich das Produktteam für diese Funktionalitäten kaum interessiert.

→ Menschen, die einen "English-to-SQL-Übersetzer" brauchen.

• Produktteams ohne datengetriebenes Training

→ Product Manager sehen Daten nicht als Werkzeug, um bessere Funktionen zu bauen.

→ Es fehlt an Alignment zwischen dem, was das Produktteam bauen will, und dem, was das Datenteam hat.

• Eine Kultur, die grundsätzlich im Widerspruch zu einer datenorientierten Kultur steht

→ Eine Kultur, die Shipping feiert statt messbaren Fortschritt und Lernen.

→ Selbst Teams, die tatsächlich mit Metriken arbeiten, tun das inkonsistent, messen nicht sauber und geraten teils in Konflikt mit anderen Teams.

• Keine Data Leadership

→ Eine zersplitterte Datenorganisation, in der verschiedene Datenrollen an unterschiedliche Abteilungen bzw. Funktionen berichten.

→ Andere Abteilungen stellen viele Analysten rund um das Datenteam ein, weil sie nicht die Unterstützung bekommen, die sie brauchen.

→ Fehlende Standardisierung bei Toolchain und Best Practices.

(Das ist ja deprimierend. Was muss man tun, um dieses Problem zu lösen?)

8. Juli

• Ab nächster Woche beginne ich damit, eine neue Richtung für das Datenteam festzulegen.

• Eine Person scheint Erfahrung mit Infrastruktur zu haben, also lasse ich sie ein zentrales Data Warehouse aufbauen.

• Fürs Erste brauchen wir nur den schnellsten Weg, die Daten an einem Ort zu sammeln.

• Der Plan ist im Grunde, stündlich die Produktions-DB in das Data Warehouse zu dumpen.

• Das Framework, das im Frontend für Ad-Tracking verwendet wird, könnte auch umfangreiche Event-Logs schicken, aber das verbuchen wir erst einmal als Technical Debt.

• Gemeinsam mit dem Recruiting-Team definiere ich eine Generalist-Data-Role.

→ Im Fokus stehen solide Software-Skills, aber auch eine Generalist-Haltung und die Fähigkeit, sich tief in Business-Anforderungen hineinzuversetzen.

→ Alle Hinweise auf Künstliche Intelligenz und Machine Learning werden fürs Erste entfernt.

• Ich verbringe Zeit mit anderen Datenleuten, die nicht an das Datenteam berichten.

→ Der Data Scientist im Marketingteam war ein junger Mensch. "Ich wollte schon immer Data Scientist werden. Ich möchte viel von Ihnen lernen."

• Ich habe einen Freund, der ein Coding-Bootcamp betreibt, gefragt, ob er einen guten "SQL-Schulungskurs" kennt. Er kennt einen, also führen wir ihn Ende dieses Monats ein.

• Ich erstelle Präsentationsunterlagen für das Produktteam, die erklären, was A/B-Tests sind und wie sie funktionieren.

→ Ich zeige viele Beispiele für Tests mit unerwarteten Ergebnissen,

→ und gestalte es interaktiv, damit man raten kann, was gewonnen hat.

• Die Assistentin des CEO treffen und herausfinden, welche „Kennzahlen, über die per automatisch versendeter E-Mail jede Woche berichtet werden soll“, wichtig sind

• Im Gespräch mit den Business-Analysten des Supply-Chain-Teams stellt sich heraus: Es sind vernünftige Leute, aber sie wurden in früheren Gesprächen mit dem Datenteam verletzt

• Einer von ihnen hatte in der Vergangenheit mit SQL gearbeitet. Als er Fragen zur Conversion Rate stellte, bekam er Zugriff auf das Data Warehouse

• Wöchentliche 1:1-Meetings mit Leuten aus der ganzen Organisation aufsetzen, die Daten benötigen

→ Der Punkt ist, Datenlücken (Gaps) und Chancen zu finden und sie an die Data Scientists weiterzugeben

→ Die Data Scientists könnten frustriert sein, weil ihre Forschungsprioritäten nach hinten rücken

→ Du sagst zwar: „Konzentriert euch darauf, so schnell wie möglich Business Value zu liefern“, fügst aber auch hinzu: „Vielleicht kommen wir bald wieder zu Machine-Learning-Themen zurück. Mal sehen.“

1. September: Morgen

• Drei Monate sind vergangen, und jetzt fühlt es sich langsam so an, als würde es funktionieren

• Durch wöchentliche 1:1-Meetings mit verschiedenen Stakeholdern werden weiter blinde Flecken und Chancen gefunden, wo Daten Veränderungen bewirken können

• Das Gefundene nutzen, um es in die Kernarbeit an der Plattform einzuspeisen

• Um „abgeleitete“ Datensätze zu erstellen, müssen viele Pipelines gebaut werden. Die Anfangskosten sind hoch, aber wenn die richtigen Datensätze einmal erstellt sind, werden spätere Analysen viel einfacher

• Anderen Abteilungen nach und nach Zugriff auf das Data Warehouse geben

• Sie beginnen, mit SQL selbst einfache Analysen durchzuführen

→ Ein großartiger Fund: Eine Junior Product Managerin entdeckt, dass die Conversion Rate in iOS Safari extrem schlecht ist. Es war ein Frontend-Bug rund um Local Storage und wurde mit einer einzigen Zeile behoben

• Der Leiter der Supply Chain schickt eine verärgerte E-Mail

→ Eine Datenbankänderung hat dazu geführt, dass eine 500-Zeilen-Abfrage fehlschlägt ...

→ Einem murrenden Data Scientist die Korrektur übertragen und ihm eine andere Karotte vorhalten: „Ich suche dir bis Ende des Monats ein cooles Machine-Learning-Problem.“

1. September: Nachmittag

• Der Produktmanager des Checkout-Teams analysiert noch immer keine Metriken

• Ein Data Scientist aus dem Marketing-Team spricht mit seinem Manager und berichtet fortan direkt an mich

[ Was passiert hier? ]

• Es wird gerade das grundlegende Fundament für die dringendsten Dinge gelegt

→ Wichtige Daten an einem Ort abfragbar machen

→ SQL-Zugriff öffnen und von anderen Teams nutzen lassen, um viele „SQL-Übersetzungs“-Aufgaben zu beseitigen

• Umgekehrt könnten andere Teams mit dieser Freiheit auch zu weit gehen. Das ließe sich zwar durch Berechtigungen beim Datenzugriff verhindern, aber die Nachteile wären größer

• Dass das Checkout-Team keine Datenanalyse gemacht hat, lag daran, dass niemand wusste, wen man fragen musste

• Das ist in erster Linie ein organisatorisches Problem

→ Die Teams wissen nicht, wie sie mit dem Datenteam zusammenarbeiten sollen

→ Ohne es zu merken, könnte das Datenteam selbst der Bottleneck sein

• Am sinnvollsten ist es, „Reporting zu zentralisieren und das Arbeitsmanagement zu dezentralisieren“

→ Weil Daten und Entscheidungen dadurch engere Feedback-Loops erzeugen

→ So, dass die Mitglieder des Datenteams jeweils in den einzelnen Teams mitarbeiten und nur mir (dem Leiter des Datenteams) berichten

2. September

• Das Datenteam wächst auf 6 Personen

→ 1 Person für die Data-Warehouse-Infrastruktur

→ 5 Personen jeweils einem Team zugeordnet: Onboarding, Supply Chain, Checkout, Marketing sowie CEO-Support und die Erstellung von Präsentationsunterlagen für Investoren/Vorstand

• Dem gesamten Unternehmen die Veränderung erklären und klar machen, mit wem für Datenanforderungen gearbeitet werden soll

• Künftige Data-Hires sollen ebenfalls anderen Teams zugeordnet werden

3. Januar

• Einer der Data Scientists beschließt zu gehen. Da es auch nicht viele Dinge gibt, an denen er Freude hätte, wird nicht versucht, ihn zu halten

• Im Team gibt es viele neue Leute. Menschen mit etwas Software-Engineering-Wissen und SQL-Kenntnissen, die interessante Dinge in Daten finden wollen

→ Weil sie in den Daten nach „Scoops“ suchen, werden sie als „Datenjournalisten“ verstanden

• Im Fall des Teammitglieds, das mit dem Onboarding-Team arbeitet

→ Es entdeckt, dass im Onboarding-Flow nach der Kundenadresse gefragt wird, obwohl sie gar nicht benötigt wird

→ Wird das entfernt, steigt die Conversion Rate im A/B-Test um 21 %

→ Einfach war es nicht, weil ETL-Arbeit nötig war, um die Daten leichter abfragbar zu machen, aber mit etwas Hilfe von Python war es machbar

• Quartalsreport mit dem CEO

→ Beim Growth-Initiative-Projekt stellt ein PM das neu gelaunchte Redesign der Landingpage vor

→ Der PM betont, dass 20 Ingenieure Überstunden machen, um die Deadline einzuhalten

→ Auch der CMO ist stark involviert, weil er sich im Rahmen dieses Redesigns viel von Direct Mail verspricht

→ Frage des CEO: „Wie sehen die aktuellen Kennzahlen aus? Sind die Customer Acquisition Costs gesunken?“

→ (Du hast genau mit so einer Frage des CEO gerechnet und lächelst, als sie tatsächlich kommt)

→ Der PM zeigt Zahlen im Anhang und erklärt, dass tatsächlich ein A/B-Test durchgeführt wurde

→ Einige Kennzahlen steigen, andere fallen, es gibt also kein aussagekräftiges Ergebnis, und die Zahlen zu den Customer Acquisition Costs sehen nicht gut aus

→ Der CMO betont, dass die Zahlen noch im Aufbau seien und solche Kampagnen mehrere Monate dauern könnten

[ Was passiert hier? ]

• Die gute Nachricht ist, dass das Produktteam begonnen hat, A/B-Tests durchzuführen

• Die schlechte Nachricht ist, dass die Ergebnisse ignoriert werden und Projekte größtenteils nach Milestones und künstlichen Deadlines vorangetrieben werden

• Die beste Nachricht ist, dass der CEO die einzelnen Teams dazu drängt, Daten als Wahrheit zu nutzen

• Wenn die Organisation stärker unter Druck gerät, data-driven zu werden, muss beschleunigt werden, wie das Datenteam mit anderen Teams zusammenarbeitet

• Vor allem das Top-Management wird sich stärker auf Kennzahlen konzentrieren, und es ist deine Aufgabe, dafür zu sorgen, dass das Datenteam an diesen Kennzahlen arbeitet

• Einer der einfachsten Wege ist sicherzustellen, dass jedes Team ein Dashboard für die Kennzahlen hat, die ihm wichtig sind

1. April

• Die früheren Machine-Learning-Arbeiten des Datenteams existieren noch immer

• Der Data Scientist, der im Inventory-Produktteam arbeitet, interessiert sich für die früher erstellten Arbeiten am Empfehlungssystem

• Eines der neu eingestellten Teammitglieder ist ein Generalist und hat das Notebook für das Empfehlungssystem in eine kleine Flask-App verwandelt und intern deployt

• Der Produktmanager des Inventory-Teams sieht es und ist begeistert: „Wie deployen wir das?“

• Eine der wichtigsten Kennzahlen des Inventory-Teams ist der „durchschnittliche Bestellwert“, und man geht davon aus, dass diese Empfehlung ihn deutlich verbessern kann

• Schon eine grobe Abschätzung legt nahe, dass ein großer Rollout schwierig wäre, aber die Idee kommt auf: „Wie wäre es, wenn wir es erst nur für 1 % der Kunden deployen?“

• „Es ist zwar dumm, aber wir könnten die empfohlenen Produkte per Cron Job im Voraus erzeugen, und das sollte in ein paar Tagen machbar sein“

• Bei der Arbeit mit dem Supply-Chain-Team werden noch mehr riesige SQL-Abfragen entdeckt

• Sie gehen zwar ständig kaputt, aber das Datenteam arbeitet daran, sie in vernünftige Pipelines zu überführen

• Der Leiter des Supply-Chain-Teams bittet darum, mehr Data Scientists einzustellen

[ OK, was passiert hier eigentlich? ]

• Erstens: Es gibt wieder Hoffnung auf coole Machine-Learning-Arbeit

• Das Produktteam ist endlich begeistert davon, das Empfehlungssystem in einem kleinen Test zu launchen

• Früher wäre das nicht möglich gewesen, weil das Product-Engineering-Team die Arbeit schwer einschätzen konnte und nicht direkt dazu beitragen wollte und dem Datenteam die Skills zur Produktivsetzung fehlten

• Gelöst wurde dieses Problem dadurch, dass das Datenteam tatsächlich eine Demo gebaut hat. Das bringt die Sache nicht nur näher an die Produktion, sondern macht auch die Möglichkeiten klar sichtbar

• Dann ist da noch das, was im Supply-Chain-Team passiert

→ Es begann mit eigenen „Business-Analysten“, aber um an Daten zu kommen, musste das Datenteam die Abfragen ausführen

→ Mit Unterstützung des Datenteams begannen die Analysten, Abfragen selbst auszuführen

→ Zuerst begann man, die „Schatten-Technikschulden“ (SQL-Abfragen von monströser Größe), die zuvor Reibungen mit dem Datenteam verursacht hatten, abzubauen

→ Das Datenteam begann, das Supply-Chain-Team eng zu unterstützen

→ Durch das Embedding von Datenteam-Mitgliedern sank der Bedarf an Business-Analysten, während die Zahl der Data Scientists zunahm

• Denken Sie daran, dass Sie die „Technikschulden“ übernommen haben, als Sie anfangs begannen, die Produktions-DB direkt in das Data Warehouse zu dumpen

• Am Anfang geht vieles kaputt, aber Sie müssen eine zusätzliche Schicht einziehen, die stabiles Querying ermöglicht. Das kann sehr viel Arbeit sein

1. Juli

• Planungsmeeting für Q3

→ Früher wurde darüber gestritten, worauf das Unternehmen im nächsten Quartal setzen soll

→ Diesmal präsentieren Sie die Top-Level-Metriken des Unternehmens, und jedes Team präsentiert, wie es diese über Submetriken herunterbricht

• Die Arbeit des Produktmanagement-Teams hat Ergebnisse geliefert

→ PMs rechtfertigen Investitionen in Projekte, indem sie darüber sprechen, was sie beim Durchführen von Tests gelernt oder in den Daten entdeckt haben

• Ein großer Erfolg war, dass ein mit dem Checkout-Team arbeitender Data Scientist entdeckte, dass das Warenkorbobjekt in einen seltsamen Zustand geriet, wenn Nutzer auf der Bestätigungsseite den Zurück-Button drückten

→ Nachdem dieses Problem behoben wurde, stieg die Conversion-Rate deutlich an

• Eine weitere Erkenntnis war, dass Traffic aus unterschiedlichen Werbekampagnen sehr unterschiedliche Conversion-Profile hatte

→ Einige Kampagnen hatten niedrige Klickpreise, aber eine schreckliche Conversion-Rate, während andere teuer waren, aber eine sehr hohe Conversion-Rate hatten

• Durch das Tracking von UTM-Variablen und deren Verknüpfung mit der Kontoerstellung wurde es möglich, die Conversion-Rate vom Anzeigenklick bis zum Kauf zu messen

→ Das war unmöglich, bevor alle Daten in dasselbe Data Warehouse gebracht und so normalisiert wurden, dass sie sich leicht abfragen ließen

→ In Zusammenarbeit mit dem Marketing lautet die wichtigste KPI nicht Kosten pro Klick, sondern die End-to-End-Kosten der Kundengewinnung

• Eine weitere spannende Nachricht war, dass ein 1%-Test des Empfehlungssystems ungewöhnlich erfolgreich war

→ Die Ausweitung auf 100 % der Nutzer ist zwar ein sehr großes Projekt, aber der CEO hat es genehmigt

• Nicht alle Ergebnisse waren positiv, und viele Tests sind gescheitert.

→ Eine der Folien erklärte einen Test, bei dem Versandkosten nicht separat berechnet, sondern in den Preis eingerechnet wurden

→ Der CEO sagte: „Was haben wir daraus gelernt?“

→ Daraus entwickelte sich erneut ein Gespräch über die Planung einer Reihe von Folgeexperimenten

(Zu Hause wird der Champagner geöffnet)

[ Was ist passiert? ]

• Sie haben es geschafft.

• Sie haben die Organisation in ein wirklich data-native Unternehmen verwandelt.

• Das Datenteam arbeitet funktionsübergreifend mit unterschiedlichen Stakeholdern zusammen.

• Daten und Erkenntnisse fließen in die Planung ein, und Daten werden genutzt, um Business Value zu schaffen, statt für Forschung mit unklaren Zielen.

• Das Unternehmen nutzt schnelle datenbasierte Feedbackzyklen und arbeitet iterativ statt mit groß angelegter Planung im „Waterfall“-Stil.

• Metriken werden so definiert, dass sie Business Value schaffen und Verantwortlichkeit dafür ermöglichen.

• Die Datenkultur wird sowohl von oben (vom CEO vorangetrieben) als auch von unten (von den Mitarbeitenden) gemeinsam getragen.

• Scheitern ist in Ordnung, solange man zumindest etwas daraus gelernt hat.

(Glückwunsch. Sie haben sich den Champagner verdient)

[hangnim]

Beim Lesen des Anfangsteils dachte ich, es wäre unsere Firma,,,, schluchz (wobei wir natürlich nicht einmal ein Datenteam haben, haha)

[dajoa]

Das war unterhaltsam zu lesen. Vielen Dank~!

[shawn]

Es fühlt sich an, als würde man eine Episode aus einer Drama-Serie über Tech-Startups sehen, die Ingenieure gern schauen würden. Macht Spaß! 👍

[hangnim]

22222

[laeyoung]

Es sieht nach vielen Leuten aus, aber in etwa dieser Größe ist es wohl schon für Mid-Stage.

[xguru]

Wahrscheinlich ist die betrachtete Größenordnung etwas anders als bei uns im Inland.

[xguru]

Für „opinionated“ ist eine saubere Übersetzung schwierig; ich verwende meist „voreingenommen“ im Sinne von „durch die eigene Meinung geprägt und damit voreingenommen“.

Dazu gibt es einen Beitrag von jemand anderem, auf den Sie sich beziehen können:

• Die Bedeutung von opinionated (voreingenommen) als Computerbegriff https://www.clien.net/service/board/cm_app/13558026

Außerdem ist der Originaltext eigentlich ausführlicher geschrieben, ich habe ihn aber der besseren Lesbarkeit halber etwas in eine dialogische Form umstrukturiert.