Paul Green menulis dalam Giving Negative Feedback:

It doesn’t provide the sustenance we need to maintain a positive view of ourselves. And that’s the ultimate irony. The idea behind performance appraisals, and feedback in general, is that to grow and improve, we must have a light shined on the things we can’t see about ourselves. We need the brutal truth. There’s an assumption that what motivates people to improve is the realization that they’re not as good as they think they are. But in fact, it just makes them go and people who will not shine that light on them. It may not be having the intended effect at all.

Saya tidak setuju kalau feedback negatif itu errr selalu negatif dan tidak akan memberikan efek positif kepada yang menerima feedback.

Tapi saya paham kenapa banyak orang berpikir begitu. Karena kebanyakan feedback negatif disampaikan dengan buruk. Bukan isinya yang salah — caranya. Timing-nya. Konteksnya. Niat di baliknya.

Kim Scott, dalam bukunya Radical Candor, menggambarkan ini dengan matriks sederhana yang seharusnya ditempel di dinding setiap meeting room. Dua axis: Care Personally dan Challenge Directly. Ketika kamu challenge directly tanpa care personally, kamu jadi obnoxious aggression — si bos yang brutal dan bangga dengan brutalitasnya. Ketika kamu care personally tanpa challenge directly, kamu jadi ruinous empathy — si leader yang “baik hati” tapi membiarkan timnya stagnan karena tidak pernah mengatakan yang sebenarnya.

Radical candor — sweet spot-nya — adalah ketika kamu peduli cukup dalam untuk mengatakan hal yang tidak nyaman. Bukan karena kamu menikmati ketidaknyamanan itu. Tapi karena kamu tahu diam adalah bentuk pengkhianatan yang lebih halus.

Saya butuh waktu bertahun-tahun untuk memahami ini. Di awal-awal jadi team lead, saya default ke ruinous empathy. Saya ingin disukai. Saya ingin tim merasa nyaman. Jadi ketika ada anggota tim yang performanya menurun, saya cenderung diam, berharap masalahnya selesai sendiri. Spoiler: masalahnya tidak pernah selesai sendiri.

Hal yang paling penting ketika memberikan feedback – atau validasi, adalah memastikan kalau kita paham tentang value yang diberikan oleh karyawan, dan memberikan rekomendasi bagaimana dia bisa melakukan pekerjaannya lebih baik. Terlepas dari apakah rekomendasi itu berupa kritik ataukah saran merupakan urusan kedua.

Ini terdengar obvious. Tapi dalam praktiknya, kebanyakan leader memberikan feedback tanpa benar-benar memahami apa yang dikerjakan timnya sehari-hari. Mereka lihat output. Mereka lihat deadline. Mereka lihat angka. Tapi mereka tidak tahu prosesnya. Tidak tahu constraint-nya. Tidak tahu bahwa si developer sudah spending dua hari debugging sebuah issue yang seharusnya bisa dicegah kalau requirement-nya lebih jelas dari awal.

Feedback tanpa context adalah noise. Dan noise, tidak peduli seberapa well-intentioned, hanya membuat orang defensive.

Saya punya aturan sederhana: sebelum memberikan feedback tentang apapun, saya harus bisa menjelaskan pekerjaan orang itu dalam tiga kalimat. Bukan job description-nya — pekerjaannya yang sebenarnya. Apa yang dia kerjakan minggu ini. Challenge apa yang dia hadapi. Tool apa yang dia gunakan. Kalau saya tidak bisa melakukan itu, saya belum punya hak untuk memberikan feedback.

Beberapa hal yang saya pelajari di 5 tahun terakhir tentang feedback :

1. Jangan berikan ikan. Micromanaging, memberitahu secara detail kepada tim kamu tentang apa yang harus dia perbaiki, biasanya akan memberikan hasil jangka pendek saja. Dalam jangka waktu panjang ketika kita terus menerus memberikan ikan, kreativitas tim akan tumpul dan ini menciptakan management debt yang harganya akan mahal dibayar di kemudian hari. Selalu berikan kail.

   Contoh konkret: seorang junior developer di tim saya pernah submit code yang berantakan. Instinct pertama saya adalah membuka code-nya, rewrite, dan kirim balik dengan catatan “harusnya begini.” Itu memberikan ikan. Yang akhirnya saya lakukan: duduk bersamanya, tanyakan kenapa dia memilih approach itu, tunjukkan satu-dua prinsip yang bisa diterapkan, lalu minta dia rewrite sendiri. Butuh waktu 3x lebih lama. Tapi bulan berikutnya, code-nya sudah jauh lebih baik — tanpa saya harus review ulang setiap baris.

   Kail itu investasi. Ikan itu subsidi.

2. Komentar sinis bisa jalan – tapi hanya dalam beberapa kondisi. Saya selalu mencoba untuk menerapkan mantra “be kind”, namun terkadang akan datang waktunya di mana memberikan feedback positif (kalau kamu melakukan y, kamu akan bisa lebih baik karena x) tidak efektif lagi, dan tim kamu lebih bereaksi ketika diberikan feedback negatif (kamu salah melakukan y, karena x). Indikator yang baik bahwa feedback negatif kamu itu tulus adalah ketika setelah memberikan feedback negatif kamu merasa kotor. Kalau kamu memberikan feedback negatif dan kamu merasa puas dengan diri kamu sendiri, kamu perlu mengevaluasi apakah feedback negatif itu datang dari performa staff ataukah dari ego diri sendiri.

   Ini tes yang saya gunakan sampai sekarang: the dirty test. Setelah memberikan feedback yang tajam, periksa perasaanmu. Kalau kamu merasa tidak enak — good. Itu artinya feedback-mu datang dari tempat yang benar. Kamu peduli dengan orang itu dan kamu tahu kamu baru saja menyakitinya demi kebaikannya. Rasa tidak enak itu adalah harga dari kepedulian.

   Tapi kalau kamu merasa lega, puas, atau — lebih buruk lagi — powerful? Itu red flag. Itu bukan feedback. Itu kamu menggunakan posisi otoritas untuk melampiaskan frustrasi. Dan timmu tahu bedanya. Mereka selalu tahu bedanya.

3. Fokus ke strength. Feedback yang fokus kepada meningkatkan strength staff lebih kuat lagi lebih bagus daripada feedback yang fokus kepada memperbaiki kesalahan.

   Marcus Buckingham menulis tentang ini secara ekstensif: orang-orang terbaik di dunia tidak menjadi terbaik dengan memperbaiki kelemahan mereka. Mereka menjadi terbaik dengan menggandakan kekuatan mereka. Seorang developer yang brilliant di architecture tapi jelek di documentation — apakah kamu mau menghabiskan energi memaksanya jadi better writer, atau apakah kamu mau membebaskannya untuk fokus ke architecture dan mencari orang lain yang passion-nya memang di documentation?

   Ini bukan berarti kelemahan boleh diabaikan. Kelemahan yang mengganggu pekerjaan harus diaddress. Tapi ada perbedaan antara “memperbaiki kelemahan sampai adequate” dan “mengubah kelemahan jadi kekuatan.” Yang pertama reasonable. Yang kedua biasanya sia-sia dan demoralizing bagi semua pihak.

Ada satu hal yang jarang dibahas dalam buku-buku leadership tapi sangat real dalam pengalaman saya: feedback berjenjang. Cara kamu memberikan feedback ke junior berbeda dengan cara kamu memberikan feedback ke senior. Bukan karena isinya berbeda. Tapi karena konteks relasi-nya berbeda.

Junior cenderung menerima feedback secara literal. Kalau kamu bilang “code-mu perlu improvement,” dia dengar “code-mu jelek.” Kalau kamu bilang “presentasimu kurang structured,” dia dengar “kamu tidak kompeten.” Dengan junior, precision dalam bahasa adalah segalanya. Spesifik. Konkret. Actionable. “Di slide 5, coba pindahkan data point ke depan sebelum narasi — itu akan membuat argument-mu lebih kuat.” Bukan “presentasimu perlu diperbaiki.”

Senior, sebaliknya, cenderung punya filter yang lebih tebal. Mereka sudah terbiasa menerima feedback. Yang mereka butuhkan bukan instruksi — mereka butuhkan perspektif. “Saya perhatikan dalam tiga sprint terakhir, estimasimu konsisten melebihi actual. Menurut kamu kenapa?” Pertanyaan, bukan pernyataan. Karena senior yang baik biasanya sudah tahu jawabannya — mereka hanya butuh seseorang yang peduli cukup untuk menanyakan.

Satu hal terakhir tentang frekuensi. Karena ini sebenarnya inti dari semuanya.

Feedback yang baik, disampaikan sebulan sekali, kalah telak dengan feedback yang biasa-biasa saja yang disampaikan setiap minggu. Kenapa? Karena feedback bukan event — feedback adalah relationship.

Ketika kamu bertemu tim seminggu sekali — benar-benar bertemu, bukan status update meeting yang seharusnya bisa jadi email — kamu membangun sebuah konteks bersama. Kamu tahu apa yang mereka kerjakan. Mereka tahu apa yang kamu pikirkan. Tidak ada surprise. Tidak ada ambush. Feedback mengalir secara natural dalam percakapan, bukan disampaikan dalam sesi formal yang membuat kedua belah pihak tegang.

Saya pernah punya seorang staff yang kinerjanya menurun selama dua bulan. Dalam sesi one-on-one mingguan, penurunan itu terlihat gradual — sedikit di sini, sedikit di sana. Saya bisa memberikan feedback kecil-kecilan setiap minggu: “Hei, saya perhatikan minggu ini kamu agak lambat di project X — ada yang bisa saya bantu?” Perlahan, dia bounce back.

Bandingkan dengan skenario di mana saya hanya bertemu dia sebulan sekali. Setelah dua bulan, penurunan kinerjanya sudah akumulasi menjadi masalah besar. Feedback-nya bukan lagi “ada yang bisa saya bantu?” tapi “kita perlu bicara serius tentang performamu.” Situasi yang sama, outcome yang sangat berbeda — hanya karena frekuensi.

Satu hal lagi adalah, feedback harus berangkat dari kepedulian kamu terhadap tim. Dan untuk menunjukkan kepedulian itu gak cukup dengan sekali atau dua kali dalam sebulan. Bertemu dengan tim minimal seminggu sekali adalah esensial untuk membuat kamu bisa menjadi team lead yang lebih bagus lagi.

Tidak punya waktu untuk bertemu dengan tim, seminggu sekali? Ya jangan jadi team lead.

Itu terdengar harsh. Tapi saya semakin yakin bahwa ini bukan hyperbole — ini minimum viable leadership. Kalau kamu memimpin 5 orang dan tidak bisa menyisihkan 5 jam seminggu untuk one-on-one (satu jam per orang), maka entah kamu terlalu sibuk dengan pekerjaan yang seharusnya bisa di-delegate, atau kamu sebenarnya tidak tertarik untuk memimpin — kamu hanya tertarik dengan title-nya.

Leadership is not a promotion. It’s a career change. Yang kamu produce bukan code atau design atau strategi — yang kamu produce adalah orang yang lebih baik dari kemarin. Dan produk itu butuh waktu, perhatian, dan kehadiran yang konsisten.

Mulai minggu ini. Tiga puluh menit. Satu orang. Tanyakan: “Apa yang bisa saya bantu?” Dan dengarkan — benar-benar dengarkan — jawabannya.

Sisanya akan mengikuti.

Photo by Wynand van Poortvliet on Unsplash