Kesalahan Umum Data Analyst: 7 Kesalahan yang Merusak Karier Anda (Dan Cara Memperbaikinya)

Slack Anda ramai. Looker Anda memiliki 47 dasbor dengan nama Anda di sana. Manajer Anda menyebut Anda "solid" dalam pertemuan 1:1. Namun entah bagaimana, ketika VP of Sales memutuskan untuk merestrukturisasi wilayah penjualan kuartal depan, tidak ada yang mengundang Anda ke pertemuan di mana keputusan itu dibuat.

Selamat datang di paradoks analyst bulan ke-14. Anda cukup kompeten untuk tenggelam dalam pekerjaan, dan belum cukup senior untuk menolak sebagiannya. Pekerjaan yang memenuhi kalender Anda membawa Anda ke IC2. Tidak satu pun yang akan membawa Anda ke Senior.

Saya telah meninjau siklus kinerja untuk analyst di perusahaan dari 80 orang hingga 8.000 orang. Mereka yang stagnan hampir selalu stagnan karena alasan yang sama. Bukan karena keahlian. SQL bisa dipelajari. dbt bisa dipelajari. Python bisa dipelajari dalam akhir pekan jika Anda benar-benar membuka laptop. Jebakan dalam artikel ini adalah kebiasaan, dan kebiasaan lebih sulit ditinggalkan daripada konsep untuk dipelajari.

Jadi inilah tujuh hal yang paling banyak merusak. Masing-masing dilengkapi gejala yang akan Anda kenali dari minggu ini, angka nyata untuk dibandingkan dengan diri Anda, dan perbaikan yang bisa Anda mulai jalankan Senin pagi.

Mengapa Jendela 6-18 Bulan Menentukan Lintasan Anda

Dalam tinjauan kinerja analyst yang pernah saya lihat, sekitar 73% orang yang stagnan di IC2 melakukannya karena pola yang terbentuk antara bulan 6 dan 18. Itulah jendela setelah onboarding berakhir tetapi sebelum Anda mendapatkan modal politik untuk menetapkan lingkup Anda sendiri. Anda menghabiskan enam bulan pertama untuk membuktikan bahwa Anda bisa mengirimkan hasil. Anda menghabiskan bulan 6-18 untuk memutuskan jenis analyst seperti apa yang akan Anda jadikan untuk sisa karier Anda.

Kebanyakan orang tidak memutuskan. Mereka hanyut. Hanyutan itu terlihat seperti mengiyakan setiap notifikasi Slack, membangun dasbor yang tidak dibuka siapa pun, dan mengukur kesuksesan berdasarkan tiket yang ditutup. Dua tahun kemudian, peran itu mengeras. Pada bulan ke-24, orang-orang di tim Anda yang menetapkan batasan mendapat tawaran Senior. Anda mendapat "mari kita tinjau pada siklus berikutnya."

Tujuh kesalahan ini adalah nama dari hanyutan itu.

Kesalahan 1: Menjadi Meja Bantuan

Gejala: Lebih dari 60% minggu Anda adalah permintaan ad hoc di bawah 30 menit masing-masing. Anda belum menyentuh analisis yang lebih mendalam yang Anda rencanakan enam minggu lalu.

Anda bisa melihat ini sendiri di kalender Anda dalam lima menit. Buka Slack, cari pesan di mana Anda mengirimkan hasil kueri, hitung berapa banyak yang diselesaikan dalam waktu kurang dari setengah jam. Jika angka itu lebih dari 25 dalam seminggu yang biasa, Anda bukan data analyst. Anda adalah SQL concierge.

Jebakannya adalah bahwa menjadi meja bantuan terasa seperti berguna. Setiap emoji "terima kasih!" adalah dopamin kecil. Setiap respons cepat membuat Anda terlihat responsif. Dan setiap menit yang Anda habiskan untuk tiket-tiket itu adalah menit yang tidak Anda gunakan untuk membangun hal yang membawa Anda ke promosi, yaitu penilaian.

Perbaikan yang Anda jalankan minggu ini:

Tetapkan SLA triage dan posting di kanal tim Anda. Milik saya berbunyi:

Permintaan ad hoc: saya mengelompokkannya dua kali sehari, pukul 11 dan 16. Untuk yang benar-benar menghambat, tandai saya dengan urgent dan tenggat waktunya. Untuk pertanyaan berulang, berikut dasbor swalayan: [tautan]. Jika pertanyaan membutuhkan lebih dari 45 menit, itu menjadi tiket dan melalui prioritas bersama manajer saya.

Kemudian bangun perpustakaan kueri swalayan. 10 pertanyaan yang paling sering Anda jawab, ditampilkan sebagai dasbor atau Looker explore tersimpan dengan dokumentasi. Anda akan memotong volume meja bantuan sebesar 40-60% dalam dua minggu. Manajer Anda akan memperhatikan. Pemangku kepentingan Anda akan complain selama seminggu lalu berhenti.

Ketidaknyamanan mengatakan "ini melalui prioritas" adalah harga untuk diperlakukan seperti analyst, bukan mesin pencari.

Kesalahan 2: Melewatkan Persetujuan Kebutuhan

Gejala: Anda sedang dalam putaran revisi ke-3 suatu proyek, dan pemangku kepentingan baru saja berkata, "Sebenarnya, yang saya maksud adalah..." Anda akan mengerjakan ulang model dan mengirimkannya lagi pada hari Jumat.

Ini menghabiskan lebih banyak biaya dari yang Anda pikirkan. Tim analitik di perusahaan berukuran sedang yang saya kerjakan pernah mengaudit tingkat pengerjaan ulang mereka dan menemukan 31% jam analyst dihabiskan untuk proyek yang sudah pernah "dikirimkan" sebelumnya. Tiga dari setiap sepuluh jam, mengerjakan ulang pekerjaan karena spesifikasi hanya berupa thread Slack.

Anda melewatkan persetujuan kebutuhan karena memintanya terasa lambat. Meminta pemangku kepentingan menuliskan apa yang mereka inginkan, menandatanganinya, dan berkomitmen pada kriteria penerimaan terasa seperti birokrasi. Jadi Anda melewatinya. Dan sekarang Rabu dan Anda sedang membangun ulang funnel untuk ketiga kalinya dan VP of Marketing "frustrasi dengan waktu respons analitik."

Perbaikan yang Anda jalankan minggu ini:

Satu halaman ringkas untuk setiap proyek di atas empat jam pengerjaan. Template:

Proyek: [nama]
Pemohon: [nama + peran]
Keputusan yang didorong analisis ini: [keputusan sebenarnya]
Pengambil keputusan: [siapa yang bertindak berdasarkan ini]
Tenggat keputusan: [tanggal]
Kriteria penerimaan: [daftar 3-5 hasil spesifik yang harus ada agar ini "selesai"]
Di luar lingkup: [apa yang TIDAK kita kerjakan]
Persetujuan pemangku kepentingan: [nama + tanggal]

Kirim email. Tunggu "disetujui." Baru tulis SQL. Jika pemangku kepentingan tidak mau menandatangani, proyek itu tidak nyata dan Anda tidak perlu memulainya.

Ya, ini memperlambat 24 jam pertama suatu proyek. Ini menghilangkan 24 jam berikutnya dari pengerjaan ulang. Matematikanya tidak halus.

Kesalahan 3: Membangun Dasbor Sebelum Mendefinisikan Keputusan

Gejala: Dasbor terbaru Anda memiliki 14 tile, tiga filter, dan pemilih rentang tanggal. Ketika ditanya tindakan apa yang dipicunya, ruangan menjadi sunyi.

Ini adalah kebiasaan buruk yang paling umum saya lihat, dan yang paling keras dipertahankan oleh analyst. Instingnya adalah "lebih banyak itu lebih baik." Berikan pengguna setiap irisan, setiap rincian, setiap dimensi, dan biarkan mereka mengiris. Hasilnya adalah dasbor yang tidak bisa digunakan siapa pun karena tidak ada pertanyaan yang dijawabnya.

Tolok ukur internal dari perusahaan SaaS berukuran 400 orang tahun 2024: dari 287 dasbor di instansi Looker mereka, 41 memiliki lebih dari 10 pemirsa per minggu. 246 lainnya adalah kota hantu. 41 yang berhasil semuanya menjawab tepat satu pertanyaan dan memicu satu tindakan. 246 yang tidak berhasil adalah dasbor "ikhtisar", dasbor "ringkasan eksekutif", dasbor "kesehatan tim": kata benda samar yang dibalut sebagai deliverable.

Perbaikan yang Anda jalankan minggu ini:

Sebelum dasbor baru apa pun, jawab empat pertanyaan secara tertulis:

1. Keputusan apa yang didorong oleh ini?
2. Siapa yang membuat keputusan itu?
3. Pada frekuensi apa (harian, mingguan, kuartalan)?
4. Tindakan apa yang diambil ketika metrik melewati ambang batas?

Jika Anda tidak bisa menjawab keempatnya, Anda tidak sedang membangun dasbor. Anda sedang membangun wallpaper. Kembalikan proyek ke pemohon sampai mereka bisa menjawabnya bersama Anda.

Dasbor yang dibangun dengan cara ini memiliki 3-7 tile, satu rentang tanggal, dan catatan "jika angka ini turun di bawah X, lakukan Y" yang jelas. Mereka digunakan karena menjawab sesuatu yang spesifik.

Kesalahan 4: Terlalu Bergantung pada Ekspor Excel

Gejala: Setiap "angka final" yang dikutip pemangku kepentingan Anda ada dalam CSV di desktop seseorang, terakhir dimodifikasi tiga minggu lalu.

Tombol ekspor adalah musuh analitik yang dipercaya. Setiap ekspor adalah cabang di data Anda. Begitu sebuah angka meninggalkan gudang data dan mendarat di Q3_pipeline_v4_FINAL_real.xlsx, Anda kehilangan kendali atasnya. Enam minggu kemudian, CFO akan mengutip file itu dalam deck presentasi dewan dan itu akan salah, dan angka yang salah itu akan dikaitkan dengan Anda.

Saya pernah melihat tim finance mengutip cakupan pipeline 19% dari CSV ketika angka gudang data langsung adalah 14%. CSV itu berasal dari sebelum sebuah kesepakatan direklasifikasi sebagai komitmen. CFO mempresentasikan 19% kepada dewan. Dua bulan kemudian, dewan bertanya mengapa kita meleset begitu jauh. Jawabannya adalah "spreadsheet-nya basi," yang bukan jawaban yang bertahan dalam rapat dewan.

Perbaikan yang Anda jalankan minggu ini:

Bangun lapisan semantik yang terkelola. Model dbt, metrik yang didefinisikan, diekspos melalui Looker / Sigma / Hex / apa pun yang digunakan stack Anda. Akses hanya-baca untuk pemangku kepentingan. Kemudian, di kanal tim Anda, buat pengumuman ini:

Mulai [tanggal], sumber kebenaran untuk [pipeline | pendapatan | retensi | metrik yang penting] adalah [tautan dasbor]. CSV yang berusia lebih dari 24 jam tidak akan direkonsiliasi. Jika Anda memerlukan angka untuk deck, tautkan dasbornya.

Beberapa pemangku kepentingan akan melawan ini. Tidak masalah. CFO yang melawannya adalah CFO yang sama yang akan berterima kasih kepada Anda pertama kali gudang data menangkap angka yang spreadsheet-nya akan luput.

Hentikan kebiasaan ekspor. Reputasi yang Anda selamatkan adalah milik Anda sendiri.

Kesalahan 5: Tidak Ada Kontrol Versi pada SQL atau dbt

Gejala: Kueri atribusi produksi Anda ada di thread Slack dari bulan Maret. Atau lebih buruk, ada di tile Looker dan tiga orang telah mengeditnya tanpa sepengetahuan Anda.

Satu ini terasa terlalu memalukan untuk diakui, tetapi saya pernah mengaudit tim analitik di perusahaan Series C di mana kalkulasi nilai seumur hidup adalah kueri 400 baris yang ditempel ke tabel turunan Looker tanpa komentar dan tanpa riwayat siapa yang mengubah apa kapan. Analyst yang menulisnya pergi pada 2024. Tidak ada yang bisa mengubah apa pun dengan penuh keyakinan.

Anda pikir kontrol versi untuk engineer. Itu bukan. Itu untuk siapa pun yang pekerjaannya bergantung pada orang lain, yaitu Anda. Analyst tanpa kontrol versi hanya selangkah dari penggabungan buruk atau penghapusan tidak sengaja dari insiden seharian penuh.

Perbaikan yang Anda jalankan minggu ini:

Bahkan jika Anda analyst solo, siapkan:

1. Repositori git untuk SQL Anda, bernama analytics-sql atau sejenisnya.
2. dbt untuk model apa pun yang digunakan lebih dari satu orang atau satu dasbor.
3. Tinjauan PR. Jika Anda solo, tinjau PR Anda sendiri keesokan paginya. Baca ulang diff dengan pikiran segar sebelum Anda menggabungkannya.
4. Pemeriksaan CI (dbt test, bahkan tiga yang dasar: not null, unique, accepted values).

Bulan pertama terasa lambat. Bulan kedua Anda akan menangkap bug dalam tinjauan yang seharusnya menurunkan kalkulasi bonus pemimpin penjualan sebesar 8%. Dari sana, Anda tidak akan pernah kembali.

Senior analyst di perusahaan Anda memiliki semua ini. IC2 yang tidak pernah dipromosikan tidak memilikinya. Itulah sebagian besar kesenjangan itu.

Kesalahan 6: Mengabaikan Tinjauan Penghapusan

Gejala: Anda memelihara 200+ dasbor. Anda tidak bisa memberi tahu saya 12 mana yang benar-benar dalam penggunaan aktif. Anda juga tidak bisa memberi tahu saya mana yang harus dihapus, jadi Anda menyimpan semuanya, dan setiap perubahan dbt merambat melalui 200 tile hilir.

Audit sederhana di sebagian besar tim BI: dasbor dengan 3 pemirsa unik atau lebih sedikit dalam 30 hari terakhir. Di perusahaan berukuran sedang yang tipikal, itu adalah 60-75% dari inventaris. Biayanya bukan hanya penyimpanan, itu adalah hambatan. Setiap refactor, setiap perubahan definisi metrik, setiap penggantian nama kolom harus diuji regresinya terhadap dasbor yang tidak dibuka siapa pun.

Anda tidak menjalankan audit karena penghapusan terasa politis. Seseorang membuat masing-masing dasbor itu. Seseorang mungkin masih menginginkannya. Jadi Anda menyimpan semuanya, dan sampah itu bertumpuk, dan build dbt Anda menjadi lebih lambat, dan waktu-untuk-mengirimkan metrik baru meningkat dari dua hari menjadi dua minggu.

Perbaikan yang Anda jalankan minggu ini:

Tinjauan penghapusan kuartalan. Undangan kalender, 90 menit, setiap kuartal, berulang selamanya:

1. Tarik statistik penggunaan: dasbor dengan kurang dari 3 pemirsa unik per bulan selama kuartal terakhir.
2. Beri tahu pemilik (atau @channel jika tidak ada pemilik): "Dasbor ini ada dalam daftar penghapusan. Jika Anda masih membutuhkannya, balas sebelum [tanggal]. Jika tidak, akan diarsipkan."
3. Arsipkan (jangan hapus; pindahkan ke folder terpisah selama 90 hari, lalu hapus).
4. Lacak jumlahnya. Targetkan penghapusan 20-30% inventaris dalam audit pertama Anda. Kurang dari itu dan Anda tidak cukup agresif.

Pemangku kepentingan akan lebih berisik dari yang Anda perkirakan untuk putaran pertama dan lebih sunyi setiap putaran berikutnya. Pada putaran ketiga, tim sudah ramping dan build dbt Anda selesai sebelum makan siang.

Kesalahan 7: Mengukur Penggunaan Tanpa Dampak Keputusan

Gejala: Dokumen tinjauan kinerja Anda berkata "tampilan dasbor: 1.200 per bulan" dan "tiket ditutup: 47 per bulan." Tidak ada satu pun tentang apa yang berubah dalam bisnis karena Anda.

Ini adalah pembunuh karier paling senyap dari ketujuhnya, karena terasa tidak salah saat Anda melakukannya. Tampilan halaman naik, tiket ditutup, Anda terlihat produktif. Kemudian siklus promosi datang dan senior analyst di pod sebelah dipromosikan dengan setengah jumlah tiket Anda, karena evaluasi diri mereka berkata:

"Membangun model retensi kohort yang mengarahkan ulang gerakan perpanjangan tim customer success. Menyebabkan $1,4M ARR yang diselamatkan di Q3 dengan menandai akun berisiko 60 hari lebih awal dari model sebelumnya."

Kalimat itu mengalahkan "tampilan dasbor: 1.200/bulan" setiap siklus. Tidak dekat.

Jebakannya adalah bahwa metrik aktivitas mudah dihitung dan dampak keputusan itu sulit. Jadi Anda menghitung yang mudah, dan senior analyst menghitung yang penting. Coba tebak siapa yang mendapat gelarnya.

Perbaikan yang Anda jalankan minggu ini:

Mulai "log keputusan." Satu baris per analisis, kolom-kolomnya:

Sebagian besar minggu Anda akan menambahkan 0-2 baris. Itulah intinya. Standarnya adalah "keputusan berubah karena analisis ini," bukan "saya mengirimkan sebuah angka." Jika Anda tidak bisa mengisi kolom 4, pekerjaan itu tidak menggerakkan apa pun, dan itu juga merupakan sinyal yang berguna. Mungkin proyek itu adalah proyek yang salah.

Saat promosi tiba, evaluasi diri Anda menulis dirinya sendiri. Dan percakapan dengan manajer Anda bergeser dari "apakah Anda mengikuti tiket" menjadi "apa keputusan berikutnya yang layak dibuat."

Biaya Gabungan dari Membawa Ini ke Tahun Kedua

Pilih salah satu dari ini dan Anda akan merasakannya sebagai hambatan tetapi bisa pulih. Bawa tiga atau lebih ke tahun kedua dan lintasan itu mengeras. Reputasi terbentuk. Anda menjadi "orang dasbor" atau "orang SQL" bukan "analyst yang mendorong kita untuk menghapus langkah onboarding yang salah."

Reputasi itulah yang sebenarnya sulit dibatalkan. Keterlambatan promosi 9-15 bulan adalah hal yang umum. Peran senior diberikan kepada rekan yang menulis lebih sedikit kode tetapi menjalankan lebih banyak keputusan. Dan hasil terburuknya bukan bahwa Anda tidak dipromosikan, melainkan bahwa Anda mulai percaya bahwa versi meja bantuan dari peran itu ADALAH perannya, dan Anda berhenti mencapai hal lain.

Kabar baiknya adalah pembalikannya membutuhkan satu kuartal, bukan satu tahun. Sebagian besar analyst yang memperbaiki pola-pola ini melihat pergeseran nyata dalam cara mereka diperlakukan dalam 6-8 minggu. Pemangku kepentingan mulai bertanya "apa yang harus kita lakukan?" sebagai pengganti "bisakah kamu tarik angka ini?" Itulah seluruh permainannya.

Reset 30 Hari

Jangan mencoba memperbaiki ketujuhnya sekaligus. Anda tidak akan memperbaiki satupun.

Pilih dua yang paling menyentuh. Jujurlah. Yang paling tidak ingin Anda akui kemungkinan besar adalah yang harus dimulai terlebih dahulu. Sebagian besar analyst yang saya coaching memilih "menjadi meja bantuan" dan "mengukur penggunaan tanpa dampak keputusan." Keduanya cenderung saling memperkuat.

Kemudian:

• Minggu 1: Pilih kesalahan #1. Tulis perbaikan sebagai rencana satu halaman. Beri tahu manajer Anda bahwa Anda menjalankannya.
• Minggu 2-3: Jalankan perbaikan. Lacak apa yang berubah: jam yang kembali, penolakan pemangku kepentingan, kualitas hasil Anda.
• Minggu 4: Tambahkan kesalahan #2. Playbook yang sama.

Pada hari ke-30 Anda akan memiliki dua kebiasaan baru. Pada hari ke-90 keduanya akan terasa otomatis. Pada hari ke-180 Anda akan melihat kembali analyst yang Anda dulu dan tidak mengenalinya.

Itulah pekerjaannya. Bukan mempelajari alat baru. Bukan menjadi lebih pintar. Hanya menolak untuk hanyut.

Daftar periksa audit diri

Jalankan ini Senin pagi. Hanya jawaban jujur:

• Kurang dari 40% minggu saya adalah permintaan ad hoc di bawah 30 menit
• Setiap proyek di atas 4 jam memiliki ringkasan tertulis dan ditandatangani sebelum SQL ditulis
• Setiap dasbor yang saya miliki dapat menyebutkan keputusan yang didorongnya, pengambil keputusan, dan frekuensinya
• Pemangku kepentingan saya mengutip dasbor langsung, bukan CSV, dalam pertemuan mereka
• Setiap SQL atau model dbt yang saya miliki ada di git dengan riwayat PR
• Saya menjalankan audit penghapusan kuartalan dan mengarsipkan setidaknya 20% inventaris yang tidak digunakan
• Evaluasi diri saya memiliki setidaknya 5 entri dalam log keputusan dengan dampak yang disebutkan

Skor Anda dari 7. Di bawah 4, Anda mengalami hanyutan. 4-5, Anda rata-rata. 6-7 berarti Anda beroperasi seperti senior analyst dan mungkin harus dibayar seperti itu, yang merupakan percakapan berbeda untuk minggu yang berbeda.

Pelajari Lebih Lanjut

• Template Job Description Data Analyst
• Jalur Karier Data Analyst: IC1 hingga Staff
• Menerjemahkan Permintaan Samar Pemangku Kepentingan menjadi Analisis yang Dapat Dikirimkan
• Desain Dasbor yang Mendorong Keputusan