30/60/90 Hari Pertama Anda sebagai EM Baru

Tiga minggu lalu Anda masih menjadi IC senior. Hari ini kalender Anda penuh dengan 14 jam rapat, 26 jam "waktu terbuka," dan sebuah Slack DM dari skip-level Anda yang berbunyi "kabari saya jika ingin ngopi minggu ini." Anda masih punya akses merge. Anda masih tahu persis file mana yang harus dibuka untuk memperbaiki bug yang baru saja membangunkan engineer on-call. Dan itulah jebakan sesungguhnya.

Kebanyakan EM baru memilih kembali ke kode karena terasa lebih aman daripada melakukan pembinaan. Tiket Jira punya definisi selesai yang jelas. Pertemuan 1:1 dengan staff engineer yang diam-diam sedang mencari pekerjaan lain tidak punya itu. Maka EM baru pun merilis fitur di minggu kedua, merasa produktif, dan gagal menjalankan pekerjaan sesungguhnya selama enam bulan, sampai skip-level mereka bertanya mengapa kecepatan pengiriman tim tidak bergerak dan dua orang sudah mengundurkan diri.

Jika Anda masih mengukur minggu kerja dari jumlah PR yang di-merge, Anda telah mengambil jabatannya tanpa mengambil pekerjaannya.

Mengapa 30/60/90 Itu Penting

Jendela waktu di mana tim Anda membentuk pendapat tentang Anda sangat sempit. Pada hari ke-45, mereka sudah memutuskan apakah Anda manajer yang masih berpura-pura menjadi IC, atau IC yang sedang sungguh-sungguh menjadi manajer. Mereka memperhatikan rapat apa yang Anda batalkan, 1:1 siapa yang Anda jadwal ulang, apa yang Anda bicarakan saat hadir. Mereka tidak memberi tahu Anda keputusan itu. Mereka hanya mulai menyesuaikan perilaku mereka.

Rencana di bawah ini dirancang untuk memaksakan hasil yang kedua. Setiap blok 30 hari memiliki tiga hingga lima deliverable yang konkret, dan semuanya adalah hal yang tidak bisa Anda lakukan dari dalam IDE.

Hari 1 sampai 30: Dengarkan, Audit, Hadir

Bulan pertama ini adalah fase pengumpulan informasi. Anda akan tergoda untuk memperbaiki sesuatu. Jangan. Anda belum tahu mana yang benar-benar rusak versus yang hanya terlihat rusak dari posisi Anda sebelumnya.

10 pertemuan 1:1 dengan bawahan langsung dalam dua minggu pertama

Jika Anda memiliki delapan bawahan langsung, itu kira-kira satu 1:1 per hari selama dua minggu ditambah beberapa tindak lanjut 30 menit. Tiga pertanyaan yang sama setiap kali:

1. Apa hal terbaik tentang bekerja di sini saat ini?
2. Apa hal terburuknya?
3. Jika Anda menjadi saya, apa yang akan Anda ubah dalam 90 hari pertama?

Buat catatan dengan tangan. Jangan memecahkan masalah di sana. Kesalahan terbesar yang paling sering dilakukan EM baru dalam 1:1 awal adalah mendengar keluhan lalu berkomitmen untuk memperbaikinya saat itu juga, kemudian memperbaiki hal yang salah atau mengingkari janji tiga minggu kemudian. "Ceritakan lebih lanjut" dan "Saya ingin memikirkan itu" adalah kalimat yang lengkap.

Pada akhir minggu kedua Anda akan memiliki 30 hingga 50 observasi yang berbeda. Pola akan muncul. Tiga bawahan langsung akan menyebutkan hal yang sama namun dengan cara berbeda. Itulah peta Anda.

Audit kecepatan pengiriman tim dan rotasi piket

Ambil data dari 8 sprint terakhir. Anda mencari dua hal:

• Tren throughput. Apakah story points yang diselesaikan per sprint datar, naik, atau turun? Jika turun, kapan mulainya? Kaitkan dengan peristiwa: reorganisasi, perubahan cakupan tanggung jawab, seseorang yang cuti.
• Distribusi rotasi piket. Ambil log halaman dan hitung insiden per engineer selama kuartal terakhir. Jika tiga orang menanggung 70% halaman, Anda punya masalah ketidakadilan dan risiko kelelahan kerja yang tidak Anda ketahui minggu lalu karena tidak ada yang mengeluh cukup keras.

Dokumentasikan temuan Anda. Jangan perbaiki dulu. Audit ini adalah baseline yang akan Anda gunakan di hari 31 hingga 60 saat menjalankan retro pertama.

Hadiri 5 rapat lintas fungsi

Perencanaan produk. Tinjauan desain. Sales enablement (ya, sales, karena tim Anda kemungkinan merilis fitur yang harus di-demo oleh tim AE). Sinkronisasi eskalasi support. Rapat mingguan yang dijalankan skip-level Anda bersama rekan mereka di organisasi lain.

Anda tidak hadir untuk berbicara. Anda hadir untuk belajar bagaimana tim Anda terlihat dari luar. Product manager yang memuji tim Anda di standup mungkin mengerlingkan mata tentang mereka dalam rapat perencanaan lintas fungsi. Lead support mungkin menyebutkan tiga eskalasi pelanggan yang belum pernah Anda dengar. Reputasi tim Anda hidup di ruangan-ruangan yang sebelumnya tidak Anda masuki.

Buat catatan dalam rapat tersebut khusus tentang tim Anda. Bawa observasi kembali ke bawahan langsung Anda dalam 1:1 tanpa menyebutkan siapa yang mengatakan apa.

NOL commit kode

Aturan keras. Jika ada bug kritis yang butuh tangan Anda, berpasanganlah dengan seorang engineer dan biarkan mereka yang melakukan merge.

Setiap commit yang Anda kirimkan di bulan pertama adalah sinyal kepada tim bahwa pekerjaan lama masih tersedia untuk Anda. Mereka akan melewati Anda untuk mengirimkan sesuatu lebih cepat. Mereka akan berhenti membawa masalah-masalah manusiawi yang rumit karena mereka bisa melihat Anda lebih suka berada di kode. Anda akan merasa produktif padahal sedang mengelabui diri sendiri.

Pertama kali saya memberi tahu seorang senior engineer bahwa saya akan berpasangan dengannya pada migrasi yang rumit tetapi tidak akan melakukan push commit, dia terlihat kesal selama sekitar sepuluh menit, lalu tampak jauh lebih nyaman sepanjang sisa kuartal. Dia tidak ingin saya mengetik di repo-nya. Dia ingin saya memikirkan hal-hal lainnya.

Hari 31 sampai 60: Jalankan Satu Hal, Perbaiki Satu Hal, Katakan Satu Hal yang Sulit

Bulan kedua adalah saat Anda beralih dari menerima masukan ke menghasilkan keluaran. Tiga deliverable, semuanya cukup kecil untuk benar-benar diselesaikan dalam 30 hari.

Jalankan 1 retro

Retro pertama Anda sebagai fasilitator, bukan peserta. Gunakan data dari audit kecepatan pengiriman. Formatnya tidak terlalu penting (mulai-berhenti-lanjutkan, marah-sedih-senang, atau apa pun yang digunakan tim Anda). Yang penting adalah Anda mengangkat satu pola yang tidak nyaman dan membiarkan ruangan merenunginya.

Misalnya: "Kita menutup tiket tapi membukanya kembali sebanyak 22% dalam dua sprint. Apa yang terjadi?" Lalu diam. Sembilan puluh detik pertama akan hening atau dipenuhi pengalihan. Bersabarlah. Para engineer akhirnya akan mengatakan hal yang jujur jika Anda tidak mengisi keheningan dengan teori Anda sendiri.

Pertama kali saya menjalankan retro sebagai manajer, saya bicara selama 18 dari 30 menit. Itulah pelajarannya. Tugas Anda dalam retro adalah bertanya, merangkum, dan menetapkan satu atau dua tindak lanjut. Bukan mengendalikan percakapan.

Perbaiki 1 proses yang rusak

Hal terkecil yang dikeluhkan bawahan langsung dalam 1:1 yang dapat Anda perbaiki dalam dua minggu. Bukan perombakan besar desain organisasi. Hal yang sudah mengganggu semua orang berbulan-bulan namun tidak ada yang cukup senior atau terorganisir untuk sekadar menghapusnya.

Contoh nyata yang berhasil:

• Standup yang berlangsung 45 menit: dipotong menjadi 15, formatnya diubah menjadi async-first dengan sinkronisasi langsung 10 menit hanya jika ada blocker.
• SLA tinjauan kode tiga hari yang sering terlewat: menerbitkan dokumen ekspektasi satu halaman, menambahkan bot pengingat Slack, menunjuk reviewer cadangan per area.
• Serah terima on-call tanpa runbook tertulis: mewajibkan rapat serah terima 20 menit di akhir setiap rotasi, dengan catatan dalam dokumen bersama.

Pilih satu. Kirimkan perbaikannya. Beritahu tim bahwa Anda mendengar mereka. Poinnya bukan pada perbaikan prosesnya sendiri (meski itu bagus). Poinnya adalah mereka ingin melihat apakah Anda benar-benar mendengarkan, dan jawabannya kini adalah ya.

Sampaikan 1 percakapan umpan balik sulit

Percakapan yang selama ini Anda hindari.

Senior engineer yang brilian tapi selalu menekan junior dalam tinjauan kode. Engineer mid-level yang terus meleset dari estimasi sebesar 3 kali lipat. Tech lead yang sudah tidak bersemangat dan tim diam-diam bekerja mengelilinginya.

Tuliskan skrip sebelum pertemuan. Gunakan struktur situasi-perilaku-dampak-permintaan:

• Situasi: "Dalam tinjauan desain kemarin, ketika Priya mengusulkan pendekatan berbasis antrean..."
• Perilaku: "...Anda memotongnya dua kali lalu mengatakan desainnya 'tidak akan berhasil' tanpa menjelaskan alasannya."
• Dampak: "Dua engineer lain memberi tahu saya bahwa mereka tidak lagi membawa ide awal ke channel tim karena sudah mengantisipasi akan dipadamkan. Kita kehilangan masukan yang kita butuhkan."
• Permintaan: "Saya perlu Anda membiarkan orang menyelesaikan pemikirannya, dan jika Anda tidak setuju, ajukan satu pertanyaan sebelum mendebat. Bisakah Anda melakukan itu?"

Latih dengan suara keras. Sampaikan dalam 1:1, tidak pernah di depan kelompok. Beri ruang hening setelahnya. Percakapan itu akan terasa berat saat berlangsung dan terasa lebih mudah untuk kedua kalinya. Percakapan inilah yang membuktikan kepada diri sendiri bahwa Anda mampu menjalankan pekerjaan ini.

Hari 61 sampai 90: Ambil Alih Hasil, Rencanakan ke Depan

Bulan ketiga adalah saat Anda berhenti menjadi "EM baru" dan mulai menjadi "si EM." Tiga deliverable, semuanya terlihat oleh skip-level Anda.

Miliki satu OKR tim

Bukan "mendukung inisiatif platform." Sebuah hasil yang spesifik dan terukur yang akan menjadi bahan evaluasi Anda di akhir kuartal.

Kurang baik: "Meningkatkan developer experience." Baik: "Mengurangi median waktu tinjauan kode dari 38 jam menjadi 12 jam pada akhir Q3, diukur melalui dashboard metrik GitHub yang sudah ada."

Tuliskan. Dapatkan persetujuan skip-level Anda. Beritahu tim bahwa ini milik Anda, bukan milik mereka. Anda yang akan mempertahankan angka itu, mereka yang melakukan pekerjaannya. Perbedaan ini penting karena tim sudah terlalu sering menyaksikan manajer yang menumpukkan OKR ke piring mereka lalu menghilang saat angka mulai meleset.

Presentasikan laporan 90 hari kepada skip-level Anda

Maksimal tiga slide. Struktur yang berhasil:

• Slide 1, apa yang saya warisi. Baseline kecepatan pengiriman, distribusi rotasi piket, tiga risiko teratas yang saya temukan, tiga kekuatan teratas. Dua kalimat masing-masing.
• Slide 2, apa yang saya selesaikan. Retro yang Anda jalankan, proses yang Anda perbaiki, OKR yang Anda ambil alih. Artefak konkret yang dapat diverifikasi skip-level.
• Slide 3, apa yang saya minta. Rencana perekrutan H2 dan proposal utang teknis (item berikutnya). Permintaan yang spesifik, biaya yang spesifik, hasil yang diharapkan secara spesifik.

Inilah artefak yang menghasilkan kepercayaan 90 hari berikutnya. Ini juga yang akan dikutip skip-level Anda kepada atasan mereka saat menjelaskan mengapa mereka mempromosikan Anda. Permudah tugas mereka.

Ajukan rencana perekrutan H2 dan peta jalan utang teknis

Satu headcount terbuka dengan JD yang Anda tulis (tautkan template JD staff software engineer pendamping) dan daftar berperingkat dari 3 item utang teknis teratas dengan estimasi biaya kasar.

Rencana perekrutan harus menjawab: peran apa, mengapa peran ini dan bukan yang lain, apa yang terbuka saat mereka mulai, apa trade-off jika Anda tidak mendapat headcount. Satu halaman.

Daftar utang teknis harus menjawab untuk setiap item: apa yang rusak hari ini karenanya, biaya engineering kasar untuk memperbaikinya (dalam satuan orang-minggu), peningkatan yang diharapkan (dalam istilah terukur seperti 30% lebih sedikit halaman, orientasi karyawan 2 minggu lebih cepat, atau apa pun yang sesuai). Beri peringkat ketiganya. Pertahankan peringkat itu ketika ditantang.

Ajukan. Pertahankan. Bahkan jika Anda tidak mendapat headcount atau anggaran utang teknis, tindakan menulis dan mempertahankan rencana itulah yang menggerakkan Anda dari "EM baru" ke "EM yang punya sudut pandang."

Kegagalan Umum dalam Praktik Nyata

Tiga cara yang dapat diprediksi di mana rencana ini menjadi berantakan.

Tarikan eks-IC ke kode

Ketika tangan Anda ingin mengetik, itu adalah penarikan, bukan kelemahan. Blokir 90 menit per minggu untuk "waktu engineering" (tinjauan arsitektur, membaca PR tanpa merge, mendebug masalah sulit bersama junior) dan namakan demikian. Jangan sebut itu coding. Label itu penting karena memaksa Anda bertanya setiap kali apakah yang akan Anda lakukan adalah mentoring atau bersembunyi.

Krisis identitas "saya bukan benar-benar manajer"

Jika Anda masih mengatakan ini di minggu keenam, tim Anda sudah menyadarinya. Mereka mendengarnya sebagai "saya berencana kembali menjadi IC saat ini mulai tidak nyaman," yang membuat mereka semakin tidak mau membawa masalah-masalah tidak nyaman kepada Anda.

Ganti dengan: "Saya adalah manajer yang dulu mengirimkan kode. Sekarang saya mengirimkan orang-orang yang mengirimkan kode." Ucapkan dengan lantang pertama kalinya terasa aneh. Pada minggu kesepuluh, itu tidak akan terasa aneh lagi.

Koreksi berlebihan

EM yang membaca tiga buku manajemen di minggu pertama lalu muncul Senin dengan kerangka baru, ritual baru, dan standup yang diganti nama. Bawahan langsung membenci ini. Mereka tidak meminta sistem operasi baru. Mereka meminta manajer yang mendengarkan.

Dengarkan dulu. Ubah kemudian. Audit 30 hari ada persis untuk mencegah hal ini.

Template dan Alat yang Benar-Benar Akan Anda Gunakan

Empat artefak yang layak dibangun sekali dan digunakan selamanya:

• Skrip pertanyaan 1:1 pertama. Tiga pertanyaan di atas, ditambah tiga pertanyaan lanjutan: "Seperti apa tampilan minggu yang hebat bagi Anda?" "Siapa di tim yang harus saya pastikan untuk meluangkan lebih banyak waktu?" "Apa yang harus saya ketahui yang tidak akan dikatakan siapa pun kepada saya?"
• Template log observasi 30 hari. Tiga kolom: apa yang saya dengar, apa yang saya lihat, apa yang belum saya ubah dan mengapa. Kolom ketiga adalah disiplinnya.
• Template laporan 90 hari. Tiga slide, struktur di atas, batas jumlah kata yang ketat per slide agar tidak ada padding.
• Skrip percakapan umpan balik sulit. Situasi, perilaku, dampak, permintaan. Cetak. Isi sebelum setiap 1:1 yang sulit selama enam bulan pertama.

Mengukur Keberhasilan di Hari ke-90

Anda akan tahu 90 hari itu berhasil jika kelima hal ini benar pada hari terakhir:

1. Setiap bawahan langsung telah menjalani setidaknya 6 pertemuan 1:1 dengan Anda dan dapat menyebutkan apa yang sedang Anda kerjakan untuk mereka.
2. Kecepatan pengiriman tim terukur dan menunjukkan tren. Meski tren datar, Anda tahu persis alasannya.
3. Satu proses terlihat lebih baik dan tim memberi Anda kredit atas itu.
4. Skip-level Anda dapat menggambarkan risiko terbesar tim Anda dalam satu kalimat karena Anda yang memberi tahu mereka.
5. Anda tidak melakukan merge kode dalam 90 hari dan tim baik-baik saja.

Yang terakhir itulah ujian sesungguhnya. Sembilan puluh hari ini bukan tentang membuktikan bahwa Anda masih bisa menulis kode. Ini tentang membuktikan bahwa Anda bisa berhenti.

Pelajari Lebih Lanjut

• Menjalankan 1:1 yang Dinantikan Bawahan Anda
• Pergeseran dari Mengerjakan ke Memimpin
• Mengelola Mantan Rekan Sejawat
• Template JD Staff Software Engineer