Kesalahan Umum Engineering Manager (Dan Cara Berhenti Melakukannya)

Hari Minggu malam. Anda meninjau PR yang dibuka staff engineer Anda pada hari Jumat karena tidak ada orang lain yang "punya konteksnya." Dokumen 1:1 Anda dengan bawahan langsung paling senior memiliki tiga poin yang sama selama enam minggu. Anda belum menjalankan retro sejak reorganisasi. Anda mengatakan pada diri sendiri bahwa Anda adalah manajer yang melatih. Tim Anda akan mendeskripsikan Anda sebagai "baik tapi tidak hadir."

Panduan ini adalah celah tersebut.

Saya pernah menjadi EM yang buruk dalam setiap cerita ini. Saya tidak akan bermoralisasi. Saya akan menamai polanya, memberi Anda angka yang mengkuantifikasi kerusakannya, dan memberi tahu Anda dengan tepat apa yang harus dilakukan minggu ini. Anda bisa membaca Lara Hogan, Will Larson, dan Camille Fournier sepanjang tahun, tapi sampai Anda memetabolisme saran itu menjadi perubahan perilaku pada Selasa pagi, tim Anda masih menanggung versi Anda yang belum membaca satupun dari itu.

Mengapa Hal Ini Penting Sekarang

EM tahun pertama dinilai berdasarkan dua hal: output tim dan retensi karyawan tim. Sebagian besar gagal dalam retensi karyawan karena mode kegagalannya tidak terlihat sampai seseorang mengundurkan diri. Saat itu sudah terjadi, itu adalah backfill 3 bulan, ramp 6 bulan, dan kira-kira $180K-$250K biaya penuh per kepergian begitu Anda menambahkan kompensasi engineer yang sudah di-load, biaya rekruter, dan hambatan ramp pada tim yang ditinggalkan.

Dua kepergian yang disesalkan dalam setahun menghapus sebagian besar keuntungan produktivitas yang Anda hasilkan. Dan Anda tidak bisa mengelola apa yang tidak Anda lihat, jadi pekerjaan pertama adalah menamai polanya. Berikut tujuh yang paling sering muncul pada EM berusia 6-18 bulan.

Jebakan 1: Coding Daripada Membimbing

Gejala. Anda menutup 3-8 PR milik sendiri per minggu. Anda mengatakan pada diri sendiri bahwa itu "membuka blokir tim." Itu sebenarnya Anda menghindari pekerjaan yang lebih sulit dan lebih lambat untuk memutuskan orang mana dalam tim yang harus tumbuh ke bagian kode tersebut.

Angka nyata. Setiap jam yang Anda habiskan untuk coding kira-kira mengabaikan 1,5-2 jam pembinaan tim, karena pembinaan bersifat interrupt-driven dan Anda sekarang sedang fokus dan tidak tersedia. Untuk tim enam orang, itu sekitar 10 jam pembinaan yang hilang per minggu. Selama satu kuartal, Anda telah mencuri sekitar 130 jam, atau satu sprint penuh waktu pengembangan senior, dari pertumbuhan bawahan langsung Anda.

Perbaikan. Batasi kontribusi IC Anda pada 10% minggu Anda. Blokir di kalender Anda, beri label "waktu IC," dan ketika waktunya habis, sudah habis. Serahkan tugas "saya akan lakukan ini satu kali" berikutnya kepada bawahan langsung yang area pertumbuhannya menyentuh, dan beri tahu mereka mengapa Anda menyerahkannya: "Ini jenis pekerjaan yang membawa Anda ke senior. Saya ingin Anda memilikinya, dan saya ingin meninjau desainnya sebelum Anda mulai." Kalimat terakhir itu adalah perbedaan antara serah terima dan pembuangan.

Jebakan 2: Melewati 1:1 yang Sulit

Gejala. 1:1 mingguan Anda dengan senior yang men-ship tapi beracun dalam tinjauan kode terus "kehabisan waktu" sebelum Anda mengangkat perilakunya. Tiga bulan kemudian, dua orang dalam tim Anda sedang wawancara di tempat lain.

Angka nyata. Rata-rata masa kerja engineer yang memiliki rekan yang dianggap beracun dan manajer yang belum menanganinya: 8-11 bulan. Rata-rata masa kerja engineer yang manajernya menamai perilaku tersebut dalam empat minggu pertama: 2,5+ tahun. Perbedaannya adalah satu biaya backfill penuh per tahun penghindaran, ditambah pajak budaya pada seluruh tim yang menyaksikan Anda tidak bertindak.

Perbaikan. Jika Anda telah menghindari topik selama dua minggu atau lebih, 1:1 berikutnya dibuka dengannya. Tanpa basa-basi, tanpa "bagaimana akhir pekan Anda." Skrip: "Saya ingin menggunakan 15 menit pertama untuk percakapan sulit tentang bagaimana tinjauan kode berjalan. Saya mendengar X dari dua rekan. Ceritakan perspektif Anda." Jangan melembutkan pembukaan. Lembutkan pendengarannya. Alasan paling umum percakapan ini berjalan buruk bukan karena Anda mengatakan hal yang salah. Itu karena Anda mengatakan hal yang benar selama 30 detik lalu menghabiskan 14 menit berikutnya meminta maaf karenanya.

Jebakan 3: Terlalu Mengandalkan Metrik Kecepatan Pengiriman

Gejala. Anda mengutip story point dalam skip-level. Anda merayakan kenaikan kecepatan pengiriman 20% kuartal lalu yang berasal dari senior yang menunjuk ulang backlog, bukan dari perubahan nyata dalam throughput sebenarnya. Ketika ditanya bagaimana keadaan tim, "kecepatan pengiriman naik" adalah hal pertama yang keluar dari mulut Anda.

Angka nyata. Sekitar 70% perubahan kecepatan pengiriman dalam kuartal tertentu adalah drift estimasi, bukan perubahan produktivitas nyata. Tim yang mengelola kecepatan pengiriman melihat tingkat kegagalan perubahan DORA naik 15-25% dalam dua kuartal, karena mereka memotong kedalaman pengujian dan ketelitian review untuk menjaga angka poin tetap menyenangkan. Anda mengoptimalkan untuk dasbor dan merusak sistem di bawahnya.

Perbaikan. Ganti kecepatan pengiriman dalam laporan mingguan Anda dengan tiga angka: frekuensi deploy, tingkat kegagalan perubahan, dan time-to-recover. Jika organisasi Anda tidak melacaknya, lakukan sendiri dalam spreadsheet selama satu kuartal. Butuh sekitar 90 menit untuk menyiapkannya dan 10 menit per minggu untuk mempertahankannya. Bawa DORA ke skip-level Anda dan jelaskan mengapa Anda beralih dari poin. Pertama kali Anda melakukan ini, skip-level Anda akan lebih menghormati Anda, bukan lebih sedikit. Hentikan mengutip poin.

Jebakan 4: Kurang Mendokumentasikan Kriteria Promosi

Gejala. Anda memiliki satu bawahan langsung yang "merasa dekat" ke senior dan satu lagi yang "belum sampai." Jika seseorang meminta Anda menuliskan perbedaan di antara mereka dalam 90 detik, Anda tidak bisa. Anda akan berbicara tentang "kehadiran" dan "kepemilikan" dan "pertimbangan" dan ruangan itu akan mengangguk dengan sopan.

Angka nyata. Hasil promosi berkorelasi sekitar 0,4 dengan kriteria yang terdokumentasi dan sekitar 0,7 dengan kepercayaan manajer dan bias kebaruan ketika kriteria tidak tertulis. Kesenjangan muncul dalam kalibrasi sebagai "saya percaya pembacaan Anda," yang merupakan cara yang keras mendapat promosi sementara yang pendiam terhenti. Biayanya jatuh pada tim sekitar 18 bulan kemudian, ketika IC terkuat, yang dilewati tanpa alasan yang jelas, pergi ke perusahaan yang memberinya alasan.

Perbaikan. Minggu ini, tulis dokumen satu halaman "seperti apa tampilan staff di tim ini." Tiga bagian: cakupan tanggung jawab, dampak, perilaku. Letakkan 4-6 contoh konkret di bawah masing-masing, diambil dari orang yang akan Anda promosikan besok. Bagikan kepada setiap bawahan langsung dalam 1:1 berikutnya, bukan dalam email samar "ini dok-nya, beri tahu saya jika ada pertanyaan." Ajak mereka membahasnya. Tanyakan di mana menurut mereka posisi mereka. Gunakan dokumen yang sama dalam kalibrasi. Perbarui setiap kuartal. Dokumennya bukan tujuannya; percakapan yang dipaksanya adalah tujuannya.

Jebakan 5: Melindungi Tim dari Konteks (dengan Cara yang Salah)

Gejala. Anda "melindungi tim dari politik" dengan tidak memberi tahu mereka bahwa proyek berisiko, headcount dibekukan, atau pelanggan membenci v1. Mereka mengetahuinya melalui channel Slack dua minggu kemudian, sering dari seseorang yang bahkan tidak bekerja di tim Anda. Kemudian mereka menanya Anda dan Anda mengatakan sesuatu seperti, "Ya, saya akan menyebutkan itu."

Angka nyata. Engineer yang merasa kurang terinformasi mendapat skor 30-40 poin lebih rendah dalam survei keterlibatan dibandingkan rekan yang merasa terlalu terinformasi. Keterlibatan kuartil bawah memprediksi pergantian karyawan dalam 12 bulan pada tingkat 2-3x tingkat dasar. Terjemahan: perlindungan yang buruk menghabiskan Anda kira-kira satu dari setiap empat bawahan langsung per tahun, dan empat yang Anda kehilangan adalah empat yang memiliki opsi.

Perbaikan. Default untuk berbagi. Tesnya bukan "apakah ini akan membuat mereka stres," melainkan "apakah saya ingin mengetahui ini jika saya adalah mereka." Jalankan standup konteks mingguan 15 menit: apa yang berubah di tingkat kepemimpinan, apa yang masih tidak pasti, apa yang harus mereka abaikan. Jika sesuatu benar-benar terlalu sensitif, katakan "ada hal yang belum bisa saya bagikan, ini kapan saya berharap bisa." Kalimat itu membeli lebih banyak kepercayaan daripada eufemisme apa pun. Engineer bisa membedakan antara manajer yang melindungi mereka dan manajer yang melindungi dirinya sendiri.

Jebakan 6: Tidak Menjalankan Retro (Atau Menjalankan yang Palsu)

Gejala. Retro terakhir 11 minggu lalu. Atau Anda memang menjalankannya, tapi tindakannya tidak pernah mendapat pemilik atau tanggal jatuh tempo, jadi tiga masalah yang sama muncul di setiap retro selamanya. Seseorang menyebutkan deploy masih menyakitkan. Semua orang mengangguk. Tidak ada yang terjadi. Retro berikutnya, seseorang menyebutkan deploy masih menyakitkan. Semua orang mengangguk.

Angka nyata. Tim yang menjalankan retro nyata, dengan pemilik bernama dan tanggal dan tindak lanjut di retro berikutnya, men-ship sekitar 25% lebih banyak kuartal bebas insiden daripada tim yang tidak menjalankannya. Tim yang menjalankan retro palsu mendapat skor yang sama dengan tim yang tidak menjalankan sama sekali, artinya ritual tanpa loop secara aktif lebih buruk dari tidak ada. Anda telah mengajari tim bahwa mengangkat masalah tidak memperbaikinya, yang merupakan pelajaran yang jauh lebih sulit untuk dibatalkan daripada memulai dari awal.

Perbaikan. Kadens: setiap dua sprint, 60 menit, tanpa pengecualian. Format: empat kolom (dipertahankan, dihentikan, lebih banyak dilakukan, terhambat pada). Setiap tindakan mendapat nama pemilik dan tanggal. Lacak tindakan di board publik. Buka retro berikutnya dengan meninjau tindakan sebelumnya. Jika kurang dari 70% tertutup, itulah percakapannya, dan Anda melewati brainstorming. Tim akan keberatan pertama kali. Lakukan saja. Dua siklus ke dalam, mereka akan mulai muncul dengan tindakan yang sudah dinamai, karena mereka tahu Anda akan memeriksanya.

Jebakan 7: Merekrut Lambat Karena Perekrutan Sulit

Gejala. Anda memiliki req terbuka yang sudah terbuka selama empat bulan. Anda telah mewawancarai delapan kandidat. Tidak ada yang "memenuhi standar." Sementara itu tim Anda telah berada di kapasitas 80% selama satu kuartal dan senior terkuat Anda melakukan pekerjaan dua orang dan mulai terlihat lelah dalam 1:1.

Angka nyata. Biaya req senior terbuka pada kompensasi SaaS tipikal: kira-kira $20K-$30K per bulan dalam output yang tersia-siakan, ditambah beban yang Anda berikan pada tim lainnya, yang meningkatkan risiko atrisi mereka (lihat Jebakan 5). Req terbuka empat bulan telah menelan biaya perusahaan $100K dan mungkin membeli Anda kepergian yang disesalkan di atasnya. Standar yang Anda pegang sekarang telah menghabiskan lebih banyak dari dua perekrutan lebih murah yang digabungkan.

Perbaikan. Tentukan standar secara tertulis: tiga must-have, tiga nice-to-have. Jalankan setiap loop wawancara terhadap dokumen itu, bukan berdasarkan perasaan. Jika Anda menolak lima kandidat berturut-turut, standarnya yang bermasalah, bukan pasarnya. Turunkan secara sengaja dan beri tahu skip-level Anda mengapa, atau bagi peran menjadi dua rekrutan lebih murah yang bisa berkembang menjadi satu yang kuat. JD Staff Software Engineer yang menjadi pendamping adalah titik awal yang baik untuk seperti apa "standar" itu tertulis. Hentikan menunggu unicorn sementara tim Anda terbakar. Unicorn itu tidak akan datang, dan tim adalah aset yang benar-benar Anda miliki.

Menyatukan Semuanya: Audit 30 Menit

Setel timer. Untuk masing-masing dari tujuh jebakan di atas, beri skor diri sendiri 1-5. Jujurlah. Skip-level Anda sudah tahu.

Apa pun yang mendapat skor 3 atau di bawah: pilih satu perbaikan dari panduan ini, jadwalkan untuk minggu ini, dan beri tahu satu rekan EM apa yang Anda komitmen agar Anda tidak bisa diam-diam melepaskannya. Jangan coba memperbaiki semua tujuh sekaligus. Anda akan mental pada semuanya. Pilih skor terendah, jalankan perbaikan itu selama dua minggu, lalu audit lagi.

Alasan ini berhasil dan "saya akan lebih disengaja dalam pembinaan" tidak adalah bahwa perbaikannya adalah blok kalender, bukan aspirasi. Blok kalender bertahan di hari Senin. Aspirasi tidak.

Seperti Apa Hasilnya yang Baik 90 Hari dari Sekarang

Gambaran konkret. Jika Anda menjalankan audit minggu ini dan berkomitmen pada satu perbaikan per dua minggu, ini adalah tim yang harus Anda miliki pada bulan Agustus:

• Anda men-ship kode kurang dari 10% minggu Anda dan Anda tidak merasa bersalah karenanya.
• Anda telah menjalani setidaknya dua 1:1 yang sulit dan tim lebih baik karenanya, bukan lebih buruk.
• Laporan mingguan Anda dimulai dengan frekuensi deploy dan tingkat kegagalan perubahan, bukan story point.
• Setiap bawahan langsung mengetahui seperti apa level berikutnya bagi mereka, di atas kertas, dan telah melakukan setidaknya satu percakapan dengan Anda tentang posisi mereka terhadap hal itu.
• Tim mendapatkan konteks secara default-berbagi, bukan default-dilindungi, dan standup konteks mingguan Anda adalah kebiasaan yang tidak dipertanyakan siapa pun.
• Retro berjalan pada kadens dua sprint dengan log tindakan tertutup yang lebih dari 70% tepat waktu.
• Tidak ada req yang terbuka lebih dari delapan minggu tanpa rekalibrasi standar yang tertulis.

Tidak ada dari ini yang memerlukan transplantasi kepribadian. Ini memerlukan keputusan bahwa versi Anda yang menoleransi pola-pola ini adalah yang dibayar tim Anda, lalu membuat satu perubahan pada satu waktu sampai mereka tidak lagi demikian.

Pelajari Lebih Lanjut

• 30/60/90 Hari Pertama sebagai EM Baru
• Menjalankan 1:1 dengan Engineer yang Menggerakkan Hal-Hal
• Metrik EM: Kecepatan Pengiriman, Kualitas, Retensi Karyawan, Perekrutan
• Percakapan Promosi dan Kinerja
• JD Staff Software Engineer