Percakapan Promosi dan Kinerja yang Dihormati para Engineer

Seorang senior engineer di tim yang pernah saya tangani mengundurkan diri seminggu setelah mendapat tinjauan kinerja "melampaui ekspektasi." Bukan karena ratingnya. Karena berkas promosinya ditolak dalam kalibrasi dua hari kemudian, dan tidak ada seorang pun (bukan EM-nya, bukan skip-level-nya) yang memperingatkan bahwa hasilnya bisa saja 50-50. Mereka sudah delapan belas bulan mendengar "kamu luar biasa." Cerita yang mereka sampaikan ke jaringan mereka saat pergi sederhana: manajer saya entah tidak tahu, atau tahu tapi tidak memberi tahu saya. Kedua versi itu buruk untuk proses perekrutan.

Siklus enam bulan memadatkan enam bulan sinyal yang tidak terucapkan menjadi satu percakapan 45 menit. Apa yang tidak Anda catat dianggap tidak terjadi. Apa yang tidak Anda namakan di bulan Mei tidak bisa tiba-tiba dihitung di bulan Oktober hanya karena Anda mengingatnya saat persiapan kalibrasi. Panduan ini untuk EM yang ingin engineernya bisa memprediksi sendiri hasil setiap tinjauan, berdasarkan artefak yang sudah ada di atas kertas.

Kriteria promosi sebagai daftar bukti, bukan pendapat

Cara tercepat untuk kehilangan kepercayaan seorang engineer adalah mempertahankan keputusan promosi dengan sifat-sifat abstrak. "Kepemimpinan teknis yang kuat." "Dampak lintas tim yang hebat." "Kepemilikan yang luar biasa." Tidak satu pun kata-kata itu berarti apa-apa bagi engineer yang memegang berkas yang ditolak. Mereka ingin artefaknya.

Jalankan promosi berdasarkan rubrik empat kolom yang terikat pada hasil kerja nyata:

Perhatikan apa yang tidak ada dalam rubrik: kesan subjektif, senioritas berdasarkan masa kerja, "terasa seperti Staff engineer di ruangan itu." Itulah cara Anda kalah dalam argumen kalibrasi. Kolom-kolom di atas adalah cara Anda menang.

Saat Anda duduk untuk menulis berkas, pertanyaannya bukan lagi "apakah Priya siap untuk Staff?" melainkan "apakah Priya memiliki tiga design doc yang diadopsi seluruh organisasi, dua layanan yang dimiliki secara penuh, dan satu kuartal di mana ia membuka blokir setidaknya lima engineer?" Jika ia baru punya dua design doc, Anda belum siap mengajukannya. Jika ia punya empat ditambah peran incident command dalam insiden P0, Anda punya kasus.

Tunjukkan standarnya dengan contoh bernama. "Di level Staff, kami mengharapkan pekerjaan seperti RFC payments-rewrite Marco atau kerangka retry-budget Lin." Level generik di wiki bukan bukti. Berkas nyata yang sudah disetujui itulah buktinya.

Artikel pendamping ini adalah deskripsi jabatan Staff Software Engineer. Bahasa cakupan, dampak, dan leverage dalam rubrik promosi Anda harus mencerminkan JD tersebut kata per kata. Jika rubrik Anda mengatakan "mendorong keputusan arsitektur" tetapi JD Anda mengatakan "memiliki desain sistem multi-layanan," engineer Anda sedang mengkalibrasi diri terhadap dua standar yang berbeda.

Rencana visibilitas 6 bulan

Alasan sebagian besar berkas promosi gagal bukan karena engineer tidak berkembang. Melainkan karena tidak ada yang tahu bahwa mereka berkembang. Kandidat Staff yang menyelesaikan pekerjaan hebat pada tiga tiket internal yang tidak dikenal siapa pun di luar tim adalah kandidat Staff yang berkasnya gugur dalam kalibrasi. Visibilitas adalah sebuah deliverable.

Di bulan pertama setiap setengah siklus, duduklah bersama setiap engineer yang menjadi kandidat promosi dalam 12 bulan ke depan dan tulislah rencana visibilitas 6 bulan bersama. Empat artefak, ditandatangani dan diberi tanggal:

1. Satu proyek stretch dengan sponsor eksekutif yang disebutkan namanya dan area permukaan yang bisa dirilis (lebih lanjut tentang jebakannya di bawah).
2. Satu artefak lintas tim: RFC yang dikonsumsi tim lain, integrasi yang bisa disebutkan oleh EM lain, migrasi yang menutup tiket utang teknis di dua organisasi berbeda.
3. Satu hasil mentorship: junior yang dipromosikan, karyawan baru yang ramp dalam 30 hari alih-alih 90, hiring loop yang mereka pimpin.
4. Satu design doc tertulis yang bertahan dari tinjauan dan dikutip oleh seseorang di luar tim langsung dalam 6 bulan.

Dokumen itu masuk ke folder bersama. Keduanya menandatanganinya. Sekarang tidak ada lagi ambiguitas tentang apa yang menjadi dasar penilaian siklus berikutnya, dan engineer bisa mengaudit diri sendiri di bulan ketiga dan bulan kelima, bukan baru mengetahui hasilnya di meja kalibrasi.

Jika mereka menyelesaikan keempat artefak, berkasnya menulis dirinya sendiri. Jika mereka menyelesaikan dua dari empat, mereka mengetahui di bulan keempat (bukan pada hari tinjauan) bahwa berkas belum siap, dan mereka punya kesempatan untuk berubah arah atau menerima penundaan 6 bulan tanpa merasa dikhianati.

Percakapan kinerja yang sulit: SBI + Permintaan + Komitmen

Kebanyakan EM menggunakan pola sandwich. Mereka membuka dengan pujian, menyampaikan kritik di tengah, menutup dengan jaminan. Para engineer tidak mendengar bagian tengahnya. Mereka mendengar "Anda hebat, ada hal kecil, Anda hebat." Lalu mereka terkejut di bulan Oktober dan menceritakannya kepada teman-teman mereka.

Berhenti menggunakan pola sandwich. Gunakan SBI + Permintaan + Komitmen. Empat langkah, tanpa padding.

Situasi. Waktu, tempat, dan konteks yang spesifik. "Dalam tinjauan desain ulang auth-service pada 12 Maret."

Perilaku. Apa yang dilakukan orang tersebut secara terlihat. Bukan apa yang Anda simpulkan tentang keadaan pikiran mereka. "Anda menolak menanggapi dua dari empat pertanyaan peninjau dan berkata 'kita bisa selesaikan itu nanti.'"

Dampak. Apa biayanya bagi tim atau pekerjaan. "Para peninjau mengadukan ke saya setelahnya. Kami menunda peluncuran satu minggu untuk mengerjakan ulang model ancaman."

Permintaan. Apa yang Anda inginkan secara berbeda, secara spesifik, lain kali. "Ketika seorang peninjau menandai pertanyaan keamanan pada sebuah design doc, saya perlu Anda menjawabnya dalam doc tersebut dalam 48 jam, bahkan jika jawabannya adalah 'kami akan menunda ini dan inilah alasannya.'"

Komitmen. Tanggal dan titik pemeriksaan. "Mari kita tinjau kembali ini di 1:1 kita pada 9 April dan lihat bagaimana dua tinjauan desain berikutnya berjalan."

Dua contoh skrip yang bisa Anda gunakan langsung:

Tinjauan kode yang memblokir tim. "Pada sprint 23, tiga tinjauan kode Anda membutuhkan lebih dari 4 hari untuk diselesaikan. Salah satunya memblokir peluncuran checkout-revamp selama satu sprint penuh. Tim mulai melewati Anda, yang berarti Anda kehilangan konteks pada codebase. Saya perlu Anda menyelesaikan tinjauan dalam 24 jam atau mendelegasikannya kepada seseorang yang bisa. Mari kita periksa di 1:1 kita pada tanggal 15."

Design doc kurang ketelitian. "Dua design doc terakhir Anda (migrasi antrean dan penulisan ulang rate-limiter) tidak memiliki bagian failure-mode dan tidak ada rencana rollback. Komite tinjauan arsitektur mengembalikan keduanya untuk putaran kedua, yang menghabiskan dua minggu masing-masing. Di level Staff, design doc harus lolos tinjauan pertama setidaknya 70% dari waktu. Saya ingin doc berikutnya yang Anda tulis menyertakan tabel failure-mode dan bagian rollback sebelum dikirim ke ARC. Kita akan meninjau doc berikutnya bersama sebelum pengajuan pada tanggal 22."

Perhatikan apa yang tidak ada. Tidak ada "tapi kamu sudah mengerjakan hal-hal hebat selain itu." Kalimat itu untuk kenyamanan Anda sendiri, bukan mereka. Simpan untuk akhir pertemuan jika diperlukan, setelah komitmen.

Sinyal PIP: kapan memulai, kapan melewati

Rencana peningkatan kinerja (PIP) adalah alat, bukan hukuman. Kesalahan terbesar yang dibuat EM adalah memulainya terlambat, yang biasanya karena mereka menggunakan pola sandwich selama enam bulan. Kesalahan terbesar kedua adalah memulainya ketika masalah sebenarnya adalah ketidakcocokan, bukan kinerja.

Mulai PIP jika ketiga hal ini benar:

1. Perilaku tersebut telah dinamai kepada engineer secara tertulis (dalam catatan 1:1 yang bisa mereka baca kembali).
2. Perilaku tersebut berulang setidaknya dalam dua siklus atau dua bulan.
3. Perilaku tersebut tidak berubah setelah setidaknya dua catatan 1:1 tertulis yang menyebutkannya dan setidaknya satu percakapan SBI.

Jika Anda tidak bisa menunjukkan ketiganya dari dokumen 1:1 Anda, Anda tidak punya kasus PIP. Anda punya kesenjangan umpan balik, dan PIP akan ditantang oleh HR dan sesama EM Anda dalam kalibrasi.

Lewati PIP jika ini masalah ketidakcocokan, bukan masalah kinerja.

"Masalah ketidakcocokan" terlihat seperti ini: engineer secara teknis baik-baik saja, menyelesaikan pekerjaannya, tetapi tidak cocok dengan domain tim (orang yang sangat berorientasi infrastruktur di tim produk, atau sangat berorientasi produk di tim platform) atau tahap perusahaan (menyukai kekacauan tim 10 orang, dipekerjakan saat perusahaan sudah 800 orang). Engineer tidak gagal. Posisinya yang salah.

Memaksakan PIP pada masalah ketidakcocokan akan menghasilkan pengunduran diri yang disertai kemarahan. Engineer itu melawan, menang secara teknis, tetap pergi, dan menceritakan kepada semua orang bahwa Anda mencoba menyingkirkan mereka secara tidak adil. Biayanya: 6 bulan moral tim dan reputasi Anda di pasar yang lebih luas.

Tawarkan transisi yang dikelola dengan baik. Langsung, penuh perhatian, dan disertai tenggat waktu. "Saya pikir Anda akan lebih cocok di tim platform. Saya sudah berbicara dengan Maria dan dia punya lowongan. Saya ingin mendukung Anda bertransisi dalam 4 minggu ke depan. Jika Anda lebih suka mencari di luar, saya bisa memberi Anda 6 minggu dan referensi yang kuat." Para engineer menghormati ini. Teman-teman mereka menghormati ini. Alur perekrutan Anda pun diuntungkan.

Pohon keputusan PIP, disederhanakan:

PIP yang bersih selesai dalam 60 hari, baik melalui peningkatan nyata maupun pengunduran diri yang bersih. Jika PIP Anda berlanjut hingga bulan keempat, Anda sedang mengelola ketidaknyamanan Anda sendiri, bukan kinerja engineer tersebut.

Kalibrasi promosi bersama sesama EM

Kalibrasi adalah rapat di mana keputusan promosi sebenarnya dibuat. Berkas yang Anda tulis adalah tiket masuknya. Sembilan puluh menit di ruangan bersama 4-6 sesama EM dan Director Anda adalah tempat di mana dinamika champion vs. challenger menentukan hasilnya.

Bawa pre-read satu halaman. Dua hari sebelum kalibrasi, kirimkan kepada sesama EM Anda satu halaman per kandidat:

• Nama, level saat ini, level target
• 3 artefak teratas (dengan tautan ke design doc, RFC, retro insiden)
• Bukti cakupan/dampak/leverage dalam tiga poin singkat masing-masing
• Satu paragraf tentang argumen kontra terkuat dan respons Anda terhadapnya

Poin terakhir itu yang memisahkan EM yang keluar ruangan dengan engineernya dipromosikan dari yang tidak. Mengantisipasi argumen penantang dalam pre-read berarti penolakan di ruangan sudah Anda tangani secara tertulis. Jika Anda tidak mengantisipasi, rekan Anda yang menolak mendapat kesempatan untuk membingkainya terlebih dahulu.

Pertahankan kasus yang berada di batas tanpa melebih-lebihkan. Berada di batas berarti engineer memenuhi standar di dua dari tiga dimensi dan mendekati pada dimensi ketiga. Jangan katakan "mereka jelas Staff." Katakan "mereka memenuhi standar pada cakupan dan leverage, mendekati pada dampak, dan ini pekerjaan yang sedang berjalan yang menutup celah pada Q3." Bahasa seperti itulah yang bertahan dari scrutini Director. Melebih-lebihkan kasus yang berada di batas merusak kredibilitas Anda untuk dua siklus berikutnya.

Ketika sesama EM memblokir engineer Anda untuk melindungi milik mereka sendiri (ini terjadi, terutama saat rating di-stack-ranked atau anggaran terbatas), jangan melawannya di ruangan. Anda akan kalah, dan Anda akan membakar hubungan. Sebaliknya, bawa ke luar ruangan. "Saya ingin memastikan saya memahami kekhawatiran Anda tentang standar design-doc Priya. Bisakah kita telusuri tiga RFC-nya bersama minggu ini?" Sembilan dari sepuluh kali, resistansi itu mencair saat Anda membawa percakapan keluar dari panggung kalibrasi.

Jebakan "proyek stretch"

Separuh berkas promosi yang gagal yang pernah saya lihat gugur akibat proyek stretch yang sejak awal tidak akan pernah menghasilkan pekerjaan yang terlihat. Polanya selalu sama. EM menugaskan proyek stretch yang terdengar bagus di atas kertas. Engineer menghabiskan 4 bulan untuknya. Proyek kehilangan prioritas, dipotong cakupannya, atau sponsor eksekutifnya pindah tim. Engineer tidak menghasilkan apa pun yang terlihat dari luar. Ruangan kalibrasi bertanya "apa yang dilakukan Priya setengah tahun ini?" EM tidak punya apa-apa untuk ditunjuk.

Validasi cakupan stretch terlebih dahulu sebelum menugaskan. Tiga pemeriksaan, semuanya wajib:

1. Anggaran nyata. Ada pos anggaran atau alokasi headcount, bukan "kita atur nanti." Jika keuangan tidak bisa menyebutkannya, itu tidak ada.
2. Sponsor eksekutif yang disebutkan namanya. Director atau VP tertentu yang, secara tertulis atau dalam rapat yang direkam, berkata "ini salah satu dari 3 prioritas utama saya setengah tahun ini." Bukan sekadar di-CC dalam email peluncuran. Sebuah pernyataan.
3. Area permukaan yang bisa dirilis. Ada pengguna, pelanggan, atau tim internal yang akan menggunakan hasilnya dan bisa mengonfirmasi bahwa itu berhasil. Jika satu-satunya orang yang akan melihatnya adalah tim engineer itu sendiri, itu proyek biasa, bukan stretch.

Jika salah satu dari ketiga syarat ini tidak terpenuhi, proyek itu adalah jebakan karier. Tolak, bahkan jika engineer tersebut bersemangat. "Saya suka ide ini. Sebelum saya menugaskannya sebagai proyek stretch Anda, saya perlu tahu siapa sponsor eksekutifnya dan pengguna mana yang akan menggunakannya. Tanpa keduanya, Anda akan menghabiskan 4 bulan untuk sesuatu yang tidak membantu berkas Anda." Engineer yang baik berterima kasih di bulan kelima. Yang hebat berterima kasih di bulan pertama.

Ritme dokumen pertumbuhan tertulis

Satu dokumen. Dokumen yang sama. Hidup sepanjang masa jabatan engineer di tim Anda. Bukan tiga dokumen terpisah di tiga tempat berbeda.

Tiga ritme mengisi dokumen tersebut:

Pembaruan bulanan dalam poin-poin adalah yang paling sering diremehkan. Lima menit. Engineer menulis apa yang mereka selesaikan, apa yang menghambat mereka, apa yang mereka pelajari, apa yang mereka minta dari Anda. Anda membacanya sebelum 1:1 berikutnya dan merespons secara tertulis. Enam bulan kemudian, saat persiapan kalibrasi dimulai, Anda memiliki 6 bulan poin-poin yang bisa dipadatkan menjadi berkas formal tanpa upaya mengingat yang heroik.

Aturan besarnya: engineer bisa membaca trajektori mereka sendiri kapan saja. Jika engineer Anda bertanya "di mana posisi saya?" jawabannya adalah "buka dokumennya, gulir ke tinjauan kuartalan terakhir, Anda bisa melihat persis di mana Anda berdiri." Tidak ada kejutan. Tidak ada "izinkan saya jadwalkan waktu untuk membahasnya." Dokumen itulah jawabannya.

Ini juga cara Anda pulih ketika seorang engineer pindah tim atau Anda meninggalkan perusahaan. EM berikutnya mewarisi dokumen yang nyata. Bukan riwayat Slack DM.

Kesalahan umum yang harus dihindari

• Menyimpan umpan balik nyata untuk hari tinjauan. Jika engineer Anda mendengarnya untuk pertama kali di bulan Oktober, Anda gagal di bulan Mei.
• Mempromosikan berdasarkan potensi alih-alih bukti. Potensi adalah taruhan Anda saat perekrutan, bukan saat promosi. Promosi berjalan berdasarkan artefak yang telah diselesaikan.
• Bahasa lunak yang diterjemahkan menjadi "tidak masalah" dalam pikiran engineer. "Saya ingin melihat sedikit lebih banyak ketelitian pada design doc Anda" bukan umpan balik. Itu petunjuk yang diabaikan. Gunakan SBI.
• Kalibrasi tanpa artefak di ruangan. Jika Anda tidak bisa menautkan design doc-nya, Anda tidak punya argumen.
• Mengacaukan jam kerja dengan dampak yang diselesaikan. Engineer yang bekerja 60 jam dan menyelesaikan dua fitur tidak mengalahkan engineer yang bekerja 40 jam dan menyelesaikan empat.

Mengukur keberhasilan

Anda akan tahu panduan ini berhasil ketika:

• Nol engineer terkejut oleh rating tinjauan mereka, karena mereka sudah membaca dokumen pertumbuhan yang sama dengan yang Anda baca.
• Berkas promosi disetujui pada putaran kalibrasi pertama 70% dari waktu, karena Anda berhenti mengajukan kasus yang berada di batas sebagai upaya spekulatif.
• PIP selesai dalam 60 hari (melalui peningkatan nyata atau transisi yang bersih) alih-alih berlanjut hingga bulan keenam dan meracuni tim.
• Engineer bisa mengutip kriteria level berikutnya dari ingatan, karena Anda menuliskan rubrik dan membahasnya pada artefak nyata.

Standarnya sederhana. Engineer yang memegang berkas yang ditolak harus bisa menunjuk pada kriteria, menunjuk pada pekerjaan mereka, dan menyetujui kesenjangan yang ada. Jika mereka tidak bisa, kegagalannya ada pada Anda, bukan pada mereka.

Pelajari Lebih Lanjut

• Deskripsi Jabatan Staff Software Engineer
• Menjalankan 1:1 dengan Engineer yang Menggerakkan Hal-hal
• Merekrut Senior Engineer yang Bertahan
• 1:1 Skip-Level yang Benar-benar Mengungkap Kebenaran