Häufige Fehler von Data Analysten: 7 Fallen, die Ihre Karriere gefährden (und wie Sie sie beheben)

Ihr Slack ist voll. Ihr Looker hat 47 Dashboards mit Ihrem Namen. Ihr Vorgesetzter nennt Sie in 1:1-Gesprächen „solide". Und wenn der VP of Sales beschließt, die Gebiete nächstes Quartal umzustrukturieren, lädt Sie trotzdem niemand zu dem Meeting ein, in dem die Entscheidung fällt.

Willkommen im 14-Monats-Analyst-Paradox. Sie sind kompetent genug, um in Arbeit zu versinken, und noch nicht senior genug, um irgendetwas davon abzulehnen. Die Arbeit, die Ihren Kalender gefüllt hat, hat Sie bis IC2 gebracht. Nichts davon wird Sie zur Senior-Stufe bringen.

Ich habe Performance-Zyklen für Analysten in Unternehmen von 80 bis 8.000 Mitarbeitern ausgewertet. Diejenigen, die stagnieren, tun es fast immer aus denselben Gründen. Es ist keine Frage der Fähigkeiten. SQL können Sie lernen. dbt können Sie lernen. Python können Sie an einem Wochenende lernen, wenn Sie den Laptop tatsächlich aufklappen. Die Fallen in diesem Artikel sind Gewohnheiten, und Gewohnheiten sind schwerer zu verlernen als Konzepte zu erlernen.

Hier sind die sieben, die den größten Schaden anrichten. Jede kommt mit einem Symptom, das Sie aus dieser Woche erkennen werden, einer echten Zahl zum Vergleich und einer Lösung, die Sie am Montagmorgen umsetzen können.

Warum das Fenster von Monat 6 bis 18 Ihre Laufbahn entscheidet

In den Performance-Bewertungen von Analysten, die ich gesehen habe, stagnieren rund 73 % der Personen, die auf IC2-Niveau verharren, aufgrund von Mustern, die zwischen Monat 6 und 18 entstanden sind. Das ist das Fenster, nachdem das Onboarding endet, aber bevor Sie das politische Kapital angehäuft haben, um Ihren eigenen Scope zu setzen. Die ersten sechs Monate verbringen Sie damit, zu beweisen, dass Sie liefern können. Monat 6 bis 18 entscheiden, welche Art von Analyst Sie für den Rest Ihrer Karriere sein werden.

Die meisten Menschen entscheiden nicht. Sie treiben. Das Treiben sieht so aus: jede Slack-Benachrichtigung annehmen, Dashboards bauen, die niemand öffnet, und Erfolg in geschlossenen Tickets messen. Nach zwei Jahren verhärtet sich die Rolle. Um Monat 24 herum bekommen die Kolleginnen und Kollegen in Ihrem Team, die Grenzen gesetzt haben, Senior-Angebote. Sie bekommen: „Lassen Sie uns das beim nächsten Zyklus überprüfen."

Diese sieben Fallen sind das Treiben, beim Namen genannt.

Falle 1: Zum Helpdesk werden

Symptom: Mehr als 60 % Ihrer Woche sind Ad-hoc-Anfragen unter 30 Minuten. Das tiefergehende Projekt, das Sie vor sechs Wochen geplant haben, haben Sie nicht angerührt.

Das können Sie in fünf Minuten in Ihrem eigenen Kalender erkennen. Öffnen Sie Slack, suchen Sie Nachrichten, in denen Sie ein Abfrageergebnis gesendet haben, und zählen Sie, wie viele davon weniger als eine halbe Stunde zur Lösung benötigt haben. Wenn diese Zahl in einer typischen Woche über 25 liegt, sind Sie kein Data Analyst. Sie sind ein SQL-Concierge.

Die Falle besteht darin, dass sich der Helpdesk nützlich anfühlt. Jedes „Danke!"-Emoji ist ein kleiner Dopamin-Schub. Jede schnelle Antwort lässt Sie reaktionsschnell wirken. Und jede Minute, die Sie für diese Tickets aufwenden, ist eine Minute, in der Sie nicht das aufbauen, was Sie befördert, nämlich Urteilsvermögen.

Diese Woche umsetzen:

Setzen Sie ein Triage-SLA und veröffentlichen Sie es in Ihrem Team-Kanal. Meines lautet:

Ad-hoc-Anfragen: Ich bearbeite diese zweimal täglich, um 11 Uhr und um 16 Uhr. Was wirklich blockiert, bitte mit dem Tag dringend und dem Termin versehen. Für häufig gestellte Fragen gibt es das Self-Service-Dashboard: [Link]. Wenn die Frage mich mehr als 45 Minuten kostet, wird sie zum Ticket und durchläuft die Priorisierung mit meinem Vorgesetzten.

Dann bauen Sie eine Self-Service-Abfragebibliothek. Die 10 Fragen, die Sie am häufigsten beantworten, als Dashboard oder gespeichertes Looker-Explore mit Dokumentation. Sie reduzieren Ihr Helpdesk-Volumen in zwei Wochen um 40 bis 60 %. Ihr Vorgesetzter wird es bemerken. Ihre Stakeholder werden eine Woche lang protestieren und dann aufhören.

Das Unbehagen, „das durchläuft die Priorisierung" zu sagen, ist der Preis dafür, wie ein Analyst und nicht wie eine Suchmaschine behandelt zu werden.

Falle 2: Anforderungen ohne Freigabe überspringen

Symptom: Sie befinden sich in Revisionsrunde 3 eines Projekts, und der Stakeholder hat gerade gesagt: „Was ich eigentlich meinte, war..." Sie werden das Modell überarbeiten und es am Freitag erneut liefern.

Das kostet mehr, als Sie denken. Ein Analytics-Team eines mittelgroßen Unternehmens, mit dem ich zusammengearbeitet habe, hat seine Nacharbeitsquote ausgewertet und festgestellt, dass 31 % der Analystenzeit für Projekte aufgewendet wurde, die bereits einmal „geliefert" worden waren. Drei von zehn Stunden, um Arbeit zu wiederholen, weil die Spezifikation ein Slack-Thread war.

Sie haben die Anforderungsfreigabe übersprungen, weil das Einholen dieser Freigabe langsam wirkte. Den Stakeholder zu bitten, aufzuschreiben, was er möchte, seinen Namen darunter zu setzen und sich auf Abnahmekriterien festzulegen, fühlte sich wie Bürokratie an. Also haben Sie es übersprungen. Und jetzt ist Mittwoch, Sie bauen den Funnel zum dritten Mal und der VP of Marketing ist „frustriert über die Reaktionszeit von Analytics".

Diese Woche umsetzen:

Ein einseitiges Briefingdokument für jedes Projekt, das mehr als vier Stunden Arbeit umfasst. Vorlage:

Projekt: [Name]
Anforderer: [Name + Rolle]
Entscheidung, die diese Analyse treibt: [die eigentliche Entscheidung]
Entscheidungsträger: [wer darauf reagiert]
Entscheidungstermin: [Datum]
Abnahmekriterien: [Liste von 3 bis 5 konkreten Ergebnissen, die vorhanden sein müssen, damit es als „fertig" gilt]
Nicht im Umfang: [was wir NICHT tun]
Freigabe des Stakeholders: [Name + Datum]

Senden Sie es per E-Mail. Warten Sie auf „genehmigt". Dann schreiben Sie SQL. Wenn der Stakeholder nicht freigibt, ist das Projekt nicht real, und Sie müssen nicht anfangen.

Ja, das verlangsamt die ersten 24 Stunden eines Projekts. Es eliminiert die nächsten 24 Stunden an Nacharbeit. Die Rechnung ist eindeutig.

Falle 3: Dashboards bauen, bevor die Entscheidung definiert ist

Symptom: Ihr neuestes Dashboard hat 14 Elemente, drei Filter und eine Datumsbereichsauswahl. Wenn man fragt, welche Aktion es auslöst, wird es still im Raum.

Das ist die häufigste schlechte Gewohnheit, die ich sehe, und die, die Analysten am stärksten verteidigen. Der Instinkt lautet „mehr ist mehr". Dem Nutzer jede Aufteilung, jede Aufschlüsselung, jede Dimension geben und ihn slicen lassen. Das Ergebnis ist ein Dashboard, das niemand nutzen kann, weil es keine Frage beantwortet.

Ein internes Benchmark aus dem Jahr 2024 eines SaaS-Unternehmens mit 400 Mitarbeitern: Von 287 Dashboards in ihrer Looker-Instanz hatten 41 mehr als 10 Besucher pro Woche. Die anderen 246 waren Geisterstädte. Die 41, die funktionierten, beantworteten alle genau eine Frage und lösten eine Aktion aus. Die 246, die es nicht taten, waren „Übersichts"-Dashboards, „Executive-Summary"-Dashboards, „Team-Health"-Dashboards: vage Nomen, die als Liefergegenstände verkleidet waren.

Diese Woche umsetzen:

Beantworten Sie vor jedem neuen Dashboard vier Fragen schriftlich:

1. Welche Entscheidung treibt das?
2. Wer trifft diese Entscheidung?
3. In welchem Rhythmus (täglich, wöchentlich, quartalsweise)?
4. Welche Aktion wird ergriffen, wenn die Kennzahl einen Schwellenwert überschreitet?

Wenn Sie nicht alle vier beantworten können, bauen Sie kein Dashboard. Sie bauen eine Tapete. Geben Sie das Projekt an den Anforderer zurück, bis er sie gemeinsam mit Ihnen beantworten kann.

Auf diese Weise gebaute Dashboards haben 3 bis 7 Elemente, einen Datumsbereich und einen klaren „Wenn diese Zahl unter X fällt, tue Y"-Hinweis. Sie werden genutzt, weil sie etwas Konkretes beantworten.

Falle 4: Zu starke Abhängigkeit von Excel-Exporten

Symptom: Jede „endgültige Zahl", die Ihre Stakeholder zitieren, lebt in einer CSV auf dem Desktop von jemandem, zuletzt geändert vor drei Wochen.

Der Export-Button ist der Feind vertrauenswürdiger Analytics. Jeder Export ist eine Abzweigung in Ihren Daten. In dem Moment, in dem eine Zahl das Data Warehouse verlässt und in Q3_pipeline_v4_FINAL_echt.xlsx landet, haben Sie die Kontrolle darüber verloren. Sechs Wochen später wird der CFO diese Datei in einem Board-Deck zitieren, und sie wird falsch sein, und die falsche Zahl wird Ihnen zugeschrieben.

Ich habe erlebt, dass Finance-Teams 19 % Pipeline-Deckung aus einer CSV zitierten, während die Live-Warehouse-Zahl 14 % betrug. Die CSV stammte aus der Zeit vor der Neueinstufung eines Deals als Commit. Der CFO hat dem Board 19 % präsentiert. Zwei Monate später fragte das Board, warum wir so weit verfehlt haben. Die Antwort lautete „das Spreadsheet war veraltet", was in einem Board-Meeting keine akzeptable Antwort ist.

Diese Woche umsetzen:

Bauen Sie eine kontrollierte semantische Schicht. dbt-Modelle, definierte Kennzahlen, über Looker / Sigma / Hex / was auch immer Ihr Stack verwendet, exponiert. Leserechte für Stakeholder. Dann machen Sie in Ihrem Team-Kanal diese Ankündigung:

Ab [Datum] ist die maßgebliche Datenquelle für [Pipeline | Umsatz | Bindung | die relevante Kennzahl] das [Dashboard-Link]. CSVs, die älter als 24 Stunden sind, werden nicht abgeglichen. Wenn Sie eine Zahl für eine Präsentation benötigen, verlinken Sie das Dashboard.

Einige Stakeholder werden dagegen protestieren. Das ist in Ordnung. Der CFO, der dagegen protestiert, ist derselbe CFO, der Ihnen das erste Mal dankt, wenn das Data Warehouse eine Zahl auffängt, die das Spreadsheet übersehen hätte.

Beenden Sie die Export-Gewohnheit. Der Ruf, den Sie schützen, ist Ihrer.

Falle 5: Keine Versionskontrolle für SQL oder dbt

Symptom: Ihre Produktions-Attributionsabfrage lebt in einem Slack-Thread vom März. Oder schlimmer: Sie lebt in einem Looker-Element, und drei Personen haben sie ohne Ihr Wissen bearbeitet.

Das ist zu peinlich, um es zuzugeben, aber ich habe Analytics-Teams bei Series-C-Unternehmen ausgewertet, bei denen die Lifetime-Value-Berechnung eine 400-zeilige Abfrage war, die in eine abgeleitete Looker-Tabelle eingefügt worden war, ohne Kommentare und ohne Geschichte, wer was wann geändert hatte. Der Analyst, der sie geschrieben hat, hat das Unternehmen 2024 verlassen. Niemand kann irgendetwas sicher ändern.

Sie denken, Versionskontrolle ist für Ingenieure. Das stimmt nicht. Sie ist für jeden, dessen Arbeit andere Menschen benötigen, und das sind Sie. Ein Analyst ohne Versionskontrolle ist einen schlechten Merge oder ein versehentliches Löschen von einem ganztägigen Vorfall entfernt.

Diese Woche umsetzen:

Auch wenn Sie als Solo-Analyst arbeiten, richten Sie Folgendes ein:

1. Ein Git-Repository für Ihr SQL, benannt analytics-sql oder ähnlich.
2. dbt für jedes Modell, das von mehr als einer Person oder einem Dashboard verwendet wird.
3. Pull-Request-Prüfung. Wenn Sie alleine sind, prüfen Sie Ihren eigenen PR am nächsten Morgen. Lesen Sie den Diff mit frischem Blick, bevor Sie mergen.
4. CI-Prüfungen (dbt test, auch nur drei grundlegende: not null, unique, accepted values).

Der erste Monat fühlt sich langsam an. Im zweiten Monat werden Sie einen Fehler in der Prüfung entdecken, der die Bonusberechnung eines Sales-Leaders um 8 % verfälscht hätte. Danach kehren Sie nie zurück.

Der Senior Analyst in Ihrem Unternehmen hat all das. Der IC2, der nie befördert wird, hat nichts davon. Das ist ein Großteil des Unterschieds.

Falle 6: Außerbetriebnahme-Prüfungen ignorieren

Symptom: Sie pflegen mehr als 200 Dashboards. Sie können mir nicht sagen, welche 12 tatsächlich aktiv genutzt werden. Sie können mir auch nicht sagen, welche gelöscht werden sollen, also behalten Sie alle, und jede dbt-Änderung überträgt sich auf 200 nachgelagerte Elemente.

Eine einfache Prüfung bei den meisten BI-Teams: Dashboards mit 3 oder weniger eindeutigen Besuchern in den letzten 30 Tagen. Bei einem typischen mittelgroßen Unternehmen sind das 60 bis 75 % des Bestands. Die Kosten sind nicht nur der Speicher, sondern der Widerstand. Jede Überarbeitung, jede Änderung an Kennzahlendefinitionen, jede Spaltenumbenennung muss gegen Dashboards regressionstestbar sein, die niemand öffnet.

Sie führen die Prüfung nicht durch, weil das Löschen politisch wirkt. Jemand hat jedes dieser Dashboards erstellt. Jemand möchte es vielleicht noch. Also behalten Sie sie, der Schmutz häuft sich an, Ihre dbt-Builds werden langsamer, und die Zeit bis zur Lieferung einer neuen Kennzahl steigt von zwei Tagen auf zwei Wochen.

Diese Woche umsetzen:

Quartalsweise Außerbetriebnahme-Prüfung. Kalender-Einladung, 90 Minuten, jedes Quartal, dauerhaft wiederkehrend:

1. Nutzungsstatistiken ziehen: Dashboards mit weniger als 3 eindeutigen Besuchern pro Monat im letzten Quartal.
2. Eigentümer benachrichtigen (oder @channel, wenn kein Eigentümer): „Dieses Dashboard steht auf der Außerbetriebnahmeliste. Wenn Sie es noch benötigen, antworten Sie bis [Datum]. Andernfalls wird es archiviert."
3. Archivieren (nicht löschen; in einen separaten Ordner für 90 Tage verschieben, dann löschen).
4. Zählung nachverfolgen. Streben Sie an, bei Ihrer ersten Prüfung 20 bis 30 % des Bestands zu entfernen. Weniger als das, und Sie waren nicht konsequent genug.

Stakeholder werden in der ersten Runde lauter sein, als Sie erwarten, und in jeder folgenden Runde leiser. Ab der dritten Runde ist das Team schlank, und Ihre dbt-Builds sind vor dem Mittagessen fertig.

Falle 7: Nutzung messen, ohne Entscheidungswirkung zu berücksichtigen

Symptom: Ihr Performance-Review-Dokument sagt „Dashboard-Aufrufe: 1.200 pro Monat" und „geschlossene Tickets: 47 pro Monat". Es sagt nichts darüber aus, was sich im Unternehmen aufgrund Ihrer Arbeit verändert hat.

Das ist die stillste Karrierebremse der sieben, weil sie sich beim Tun nicht falsch anfühlt. Seitenaufrufe steigen, Tickets schließen, Sie wirken produktiv. Und dann kommt der Beförderungszyklus, und der Senior Analyst im Nachbar-Pod wird mit der Hälfte Ihrer Ticket-Anzahl befördert, weil seine Selbstbewertung lautete:

„Hat das Kohortenbindungsmodell gebaut, das die Renewal-Arbeit des Customer-Success-Teams neu ausgerichtet hat. Hat in Q3 durch das Markieren von Risikokunden 60 Tage früher als das vorherige Modell 1,4 Mio. USD an ARR gerettet."

Dieser Satz schlägt „Dashboard-Aufrufe: 1.200/Monat" in jedem Zyklus. Es ist kein knapper Vergleich.

Die Falle besteht darin, dass Aktivitätskennzahlen einfach zu zählen sind und Entscheidungswirkung schwierig. Also zählen Sie, was einfach ist, und der Senior Analyst zählt, was zählt. Wer bekommt den Titel?

Diese Woche umsetzen:

Starten Sie ein „Entscheidungsprotokoll". Eine Zeile pro Analyse, Spalten:

In den meisten Wochen fügen Sie 0 bis 2 Zeilen hinzu. Das ist der Sinn. Der Maßstab lautet „Entscheidung aufgrund dieser Analyse geändert", nicht „Ich habe eine Zahl gesendet". Wenn Sie Spalte 4 nicht ausfüllen können, hat die Arbeit nichts bewegt, und das ist auch ein nützliches Signal. Vielleicht war das Projekt das falsche Projekt.

Zum Zeitpunkt der Beförderung schreibt sich Ihre Selbstbewertung von selbst. Und das Gespräch mit Ihrem Vorgesetzten wechselt von „Halten Sie mit den Tickets Schritt?" zu „Was ist die nächste lohnenswerte Entscheidung?"

Die kumulierten Kosten, diese Fallen ins zweite Jahr mitzunehmen

Wählen Sie eine dieser Fallen, und Sie werden sie als Reibungspunkt spüren, können sich aber erholen. Nehmen Sie drei oder mehr ins zweite Jahr mit, und die Laufbahn verhärtet sich. Der Ruf entsteht. Sie werden zur „Dashboard-Person" oder zur „SQL-Person", statt zum „Analyst, der uns dazu gebracht hat, den falschen Onboarding-Schritt abzuschaffen".

Dieser Ruf ist das, was tatsächlich schwer rückgängig zu machen ist. Beförderungsverzögerungen von 9 bis 15 Monaten sind häufig. Senior-Rollen gehen an Kolleginnen und Kollegen, die weniger Code geliefert, aber mehr Entscheidungen getrieben haben. Und das schlimmste Ergebnis ist nicht, dass Sie nicht befördert werden, sondern dass Sie beginnen zu glauben, die Helpdesk-Version der Rolle IST die Rolle, und aufhören, nach etwas anderem zu greifen.

Die gute Nachricht ist, dass die Kurskorrektur ein Quartal braucht, nicht ein Jahr. Die meisten Analysten, die diese Muster korrigieren, bemerken innerhalb von 6 bis 8 Wochen eine spürbare Veränderung in der Art, wie sie behandelt werden. Stakeholder beginnen zu fragen „Was sollten wir tun?" statt „Können Sie diese Zahl ziehen?" Das ist das ganze Spiel.

Der 30-Tage-Neustart

Versuchen Sie nicht, alle sieben auf einmal zu beheben. Sie werden keine einzige beheben.

Wählen Sie die zwei, die am härtesten treffen. Seien Sie ehrlich. Die eine, die Sie am wenigsten zugeben möchten, ist wahrscheinlich diejenige, mit der Sie anfangen sollten. Die meisten Analysten, die ich begleite, wählen „zum Helpdesk werden" und „Nutzung messen, ohne Entscheidungswirkung". Sie neigen dazu, sich gegenseitig zu verstärken.

Dann:

• Woche 1: Wählen Sie Falle Nr. 1. Schreiben Sie die Lösung als einseitigen Plan. Teilen Sie Ihrem Vorgesetzten mit, dass Sie sie umsetzen.
• Wochen 2 bis 3: Setzen Sie die Lösung um. Verfolgen Sie, was sich ändert: Ihre zurückgewonnenen Stunden, den Widerstand der Stakeholder, Ihre Ergebnisqualität.
• Woche 4: Fügen Sie Falle Nr. 2 hinzu. Dieselbe Vorgehensweise.

Bis Tag 30 haben Sie zwei neue Gewohnheiten. Bis Tag 90 werden sie sich automatisch anfühlen. Bis Tag 180 werden Sie auf den Analyst, der Sie waren, zurückblicken und ihn nicht wiedererkennen.

Das ist die Arbeit. Kein neues Tool lernen. Nicht klüger werden. Einfach aufhören zu treiben.

Selbstprüfungs-Checkliste

Führen Sie das am Montagmorgen durch. Nur ehrliche Antworten:

• Weniger als 40 % meiner Woche sind Ad-hoc-Anfragen unter 30 Minuten
• Jedes Projekt über 4 Stunden hat ein schriftliches, freigegebenes Briefingdokument, bevor SQL geschrieben wird
• Jedes Dashboard, das ich besitze, kann die Entscheidung, die es treibt, den Entscheidungsträger und den Rhythmus benennen
• Meine Stakeholder zitieren in ihren Meetings Live-Dashboards, keine CSVs
• Jedes SQL- oder dbt-Modell, das ich besitze, ist in Git mit einer PR-Geschichte
• Ich führe eine quartalsweise Außerbetriebnahme-Prüfung durch und archiviere mindestens 20 % des ungenutzten Bestands
• Meine Selbstbewertung enthält mindestens 5 Einträge in einem Entscheidungsprotokoll mit benannter Wirkung

Bewerten Sie sich von 7. Alles unter 4 bedeutet, Sie treiben. 4 bis 5 bedeutet, Sie sind durchschnittlich. 6 bis 7 bedeutet, Sie arbeiten wie ein Senior Analyst und sollten wahrscheinlich auch so bezahlt werden, was ein anderes Gespräch für eine andere Woche ist.

Weiterführende Artikel

• Data Analyst Stellenbeschreibungsvorlage
• Data-Analyst-Karrierepfad: von IC1 zum Staff Level
• Stakeholder-Übersetzung: Vage Anfragen in lieferbare Analysen
• Dashboard-Design, das Entscheidungen treibt