Belajar Engineering Manager - Managing AI Teams

#Pendahuluan

Setelah di episode 23 kita menjadikan AI asisten pribadi, sekarang kita balik kursinya: kalian memimpin tim yang membangun AI/ML — entah itu tim ML platform, tim fitur berbasis model, atau tim riset yang harus mengirim produk.

Mengapa topik ini layak episode tersendiri? Karena manajemen tim AI bukan software engineering biasa plus model: unit kerjanya beda (eksperimen, bukan task), ketidakpastiannya beda struktural (hasil bisa saja tidak mungkin dicapai dengan budget mana pun), dan kegagalannya beda bentuk (model bagus di lab, hancur di production). EM yang membawa playbook sprint biasa ke tim riset akan memaksa kedua sisi gagal — tim dipaksa janji yang tak bisa dijanjikan, stakeholder kecewa pada hal yang sebenarnya wajar.

#Riset vs Delivery: Spektrum Kerja Tim AI

Langkah pertama memahami tim kalian: posisinya di spektrum riset-delivery:

Mayoritas tim AI di industri Indonesia berada di sisi applied: menerapkan teknik matang ke masalah domain sendiri. Konsekuensi manajerialnya penting: untuk tim applied, disiplin delivery (episode 7) tetap berlaku; untuk komponen riset di dalamnya, pakai pola time-boxed exploration — budget waktu dan compute eksplisit, pertanyaan hipotesis tertulis, dan kriteria berhenti yang disepakati sebelum mulai. Eksplorasi tanpa time-box adalah cara termahal membeli kepastian yang tidak datang.

#Siklus Hidup Proyek ML

Proyek ML punya tahapan yang lebih panjang dari CRUD biasa:

Tiga titik yang paling sering diremehkan EM baru. Problem framing: banyak proyek mati karena dimulai dari "kita punya model hebat" alih-alih "masalah bisnis apa yang metrik barunya bernilai" — tugas kalian sama seperti problem framing product (episode 7): paksa definisi dampak terukur sebelum satu GPU dinyalakan. Data quality: 60-80% effort proyek ML riil ada di sini — akuisisi, pembersihan, labeling; stakeholder yang menyangka fase ini "persiapan kecil" akan syok saat mendengar estimasinya. Monitoring & drift: model bukan artefak statis — distribusi data dunia bergeser dan akurasi meluruh diam-diam; tanpa retraining pipeline dan alert drift (episode 9 quality gate), fitur AI kalian membusuk tanpa insiden yang membangunkan siapa pun.

#Ekspektasi Stakeholder: Probabilistik, Bukan Deterministik

Perbedaan komunikasi terpenting: hasil ML bersifat probabilistik. Klasifikasi tiket dengan akurasi 90% berarti satu dari sepuluh salah, selamanya — bukan bug yang akan hilang di rilis depan. Stakeholder yang dibesarkan di software deterministik butuh dididik sistematis:

1. Definisikan baseline dulu: proses manual saat ini benar berapa persen? Model yang "hanya" 90% bisa jadi lompatan besar dari manusia lelah yang 82%.
2. Komunikasikan trade-off error: false positive vs false negative punya biaya bisnis berbeda (menolak transaksi sah vs meloloskan fraud); threshold adalah keputusan bisnis, bukan teknis semata.
3. Janji dalam rentang dan milestone pembelajaran: "Q2: prototype dengan eval report; Q3: piloted 10% traffic" — bukan "fitur jadi tanggal 14".
4. Rayakan kill decision: proyek yang dihentikan setelah evaluasi jujur adalah uang yang selamat, bukan kegagalan tim.

Struktur status report-nya juga beda dari episode 7: tambahkan blok "apa yang kita pelajari minggu ini" — di kerja eksperimental, pembelajaran terverifikasi adalah progres nyata yang harus terlihat, kalau tidak stakeholder hanya melihat "belum ada fitur".

#Eval-Driven Development

Jantung disiplin engineering tim AI modern: evaluation harness — suite pengujian model persis seperti test suite kode:

eval_suite:
  dataset:
    golden_set: "500 tiket berlabel (frozen, tidak dilatih)"
    adversarial: "120 kasus sulit: bahasa campuran, sarcasm, multi-intent"
  metrics:
    - nama: "accuracy_keseluruhan"
      target: ">= 0.88"          # quote agar tetap string
    - nama: "false_negative_kategori_fraud"
      target: "<= 0.02"          # biaya bisnis tinggi
    - nama: "latency_p95_ms"
      target: "<= 400"
  gates:                          # quality gate ep. 9 versi ML
    - "Semua metric memenuhi target sebelum promote ke staging"
    - "Regression vs model produksi saat ini wajib ditunjukkan"
  cadence: "setiap iterasi model + full run pre-release"

Nilai manajerialnya besar: eval suite mengubah diskusi "menurut saya modelnya sudah bagus" menjadi angka yang bisa dibela; ia membuat regression terdeteksi sebelum user yang menemukannya; dan ia memberi kalian — manager non-modeling — telemetri objektif atas pekerjaan yang paling sulit dinilai. Kalau tim kalian belum punya ini, membangun eval harness adalah intervensi EM berdampak tertinggi yang bisa kalian lakukan bulan ini.

#Struktur Tim dan Peran

Tim AI sehat umumnya memuat kombinasi peran:

Untuk tim kecil, satu orang bisa memakai dua topi — tetapi catat gap-nya di skills matrix (episode 6), karena absennya peran data engineer adalah penyebab tersering proyek ML meleset berbulan-bulan. Dan soal talenta: pasar engineer ML 2026 sangat kompetitif; retensi (episode 16) mereka bertumpu pada akses compute yang layak, masalah yang menantang, dan publikasi/internal showcase — bukan sekadar gaji.

#Jebakan Klasik Manajemen Tim AI

Empat pola kegagalan yang berulang di industri:

• Demo-to-production gap: demo mengagumkan di notebook, lalu delapan bulan tersesat di integrasi. Penawar: mulai dari baseline sederhana yang di-deploy end-to-end sejak minggu-minggu awal, iterasi kualitasnya kemudian.
• PoC abadi: proof of concept demi PoC, tak pernah ada yang productionized. Setiap PoC wajib punya jalur lanjut eksplisit (ship/kill) di quarterly planning.
• Metrik proxy yang menyimpang: accuracy naik terus padahal nilai bisnis tidak bergerak — karena golden set tidak lagi merepresentasikan trafik nyata. Review dataset eval berkala seperti review debt register.
• Hero researcher tunggal: satu orang memegang semua pemahaman model (bus factor 1). Pairing dan dokumentasi eksperimen (experiment tracking) adalah mitigasinya.

#Penutup

Inti yang harus dibawa pulang:

• Posisikan tim di spektrum riset-delivery; applied pakai disiplin delivery, komponen riset pakai time-boxed exploration dengan kriteria berhenti.
• Siklus hidup ML: framing → data → baseline → iterasi+eval → serving → monitoring/drift; data quality memakan mayoritas effort.
• Didik stakeholder bahwa hasil ML probabilistik: baseline dulu, trade-off error eksplisit, milestone pembelajaran, rayakan kill decision.
• Eval-driven development adalah telemetri objektif kalian: golden set, adversarial cases, gates pre-release.
• Waspadai empat jebakan: demo-to-production gap, PoC abadi, proxy metrics menyimpang, hero tunggal.

Di episode 26 selanjutnya kita beralih dari mengelola tim ke mengelola karir kalian sendiri: Engineering Leadership Growth — jalur Senior EM menuju Director dan VP Engineering, pergeseran scope dan horizon tiap level, sponsorship vs mentorship, membangun bench pemimpin, dan personal board of advisors. Sampai jumpa!