Memberikan Feedback: Tips untuk Team Lead

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 pernah memberi efek positif ke orang yang menerimanya.

Tapi saya paham kenapa banyak orang berpikir begitu. Kebanyakan feedback negatif disampaikan dengan buruk. Isinya sering tidak salah. Yang salah caranya, timing-nya, konteksnya, atau niat di baliknya.

Kim Scott, dalam bukunya Radical Candor, menggambarkan ini dengan matriks sederhana yang layak ditempel di dinding setiap meeting room. Dua axis: Care Personally dan Challenge Directly. Kalau kamu challenge directly tanpa care personally, kamu jatuh ke obnoxious aggression. Ini si bos yang brutal dan bangga dengan brutalitasnya. Kalau kamu care personally tanpa challenge directly, kamu jatuh ke ruinous empathy. Ini si leader yang “baik hati” tapi membiarkan timnya jalan di tempat karena tidak pernah bilang yang sebenarnya.

Radical candor ada di sweet spot-nya. Kamu cukup peduli untuk mengatakan hal yang tidak nyaman. Kamu tidak menikmatinya. Kamu melakukannya karena diam juga bentuk pengkhianatan, cuma lebih sopan.

Saya butuh bertahun-tahun untuk paham ini. Di awal jadi team lead, saya otomatis masuk kotak ruinous empathy. Saya ingin disukai. Saya ingin tim merasa nyaman. Jadi ketika ada anggota tim yang performanya turun, saya diam dan berharap masalahnya selesai sendiri. Spoiler: masalahnya tidak pernah selesai sendiri. Yang selesai cuma kesabaran saya, biasanya terlambat.

Hal paling penting ketika memberi feedback, atau validasi, adalah memastikan kita paham value yang diberikan karyawan itu, lalu memberi rekomendasi supaya dia bisa bekerja lebih baik. Rekomendasinya berbentuk kritik atau saran, itu urusan kedua.

Kedengarannya obvious. Tapi dalam praktik, banyak leader memberi feedback tanpa tahu apa yang dikerjakan timnya sehari-hari. Mereka lihat output, deadline, angka. Mereka tidak tahu prosesnya. Tidak tahu constraint-nya. Tidak tahu bahwa si developer sudah dua hari debugging issue yang seharusnya bisa dicegah kalau requirement-nya jelas dari awal.

Feedback tanpa konteks itu noise. Noise, sebaik apa pun niatnya, cuma membuat orang defensif.

Jadi saya pasang aturan sederhana untuk diri sendiri. Sebelum memberi feedback tentang apa pun, saya harus bisa menjelaskan pekerjaan orang itu dalam tiga kalimat. Bukan job description-nya, tapi pekerjaannya yang sebenarnya. Apa yang dia kerjakan minggu ini. Challenge apa yang dia hadapi. Tool apa yang dia pakai. Kalau saya tidak bisa, saya belum punya hak memberi feedback. Aturan ini lebih sering menahan saya daripada yang ingin saya akui.

Beberapa hal yang saya pelajari dalam 5 tahun terakhir soal feedback:

Jangan berikan ikan. Micromanaging, memberi tahu tim sampai detail apa yang harus diperbaiki, biasanya cuma memberi hasil jangka pendek. Kalau kita terus memberi ikan, kreativitas tim jadi tumpul. Ini menumpuk management debt yang mahal dibayar belakangan. Berikan kail.
Contohnya begini. Seorang junior developer di tim saya pernah submit code yang berantakan. Insting pertama saya adalah membuka code-nya, menulis ulang, lalu mengirim balik dengan catatan “harusnya begini.” Itu memberi ikan, dan jujur saja, rasanya enak. Yang akhirnya saya lakukan adalah duduk bersamanya, menanyakan kenapa dia memilih approach itu, menunjukkan satu-dua prinsip yang bisa diterapkan, lalu memintanya menulis ulang sendiri. Waktunya 3x lebih lama. Tapi bulan berikutnya code-nya jauh lebih baik, dan saya tidak perlu review ulang setiap baris.
Kail itu investasi. Ikan itu subsidi.
Komentar sinis bisa jalan, tapi hanya dalam kondisi tertentu. Saya selalu mencoba memegang mantra “be kind”. Tapi kadang datang waktunya ketika feedback positif (kalau kamu melakukan y, kamu bisa lebih baik karena x) sudah tidak mempan, dan tim lebih bereaksi pada feedback negatif (kamu salah melakukan y, karena x). Tanda yang bagus bahwa feedback negatifmu tulus adalah kamu merasa kotor setelah memberikannya. Kalau kamu memberi feedback negatif lalu merasa puas dengan diri sendiri, coba periksa lagi. Feedback itu datang dari performa staf, atau dari ego kamu.
Ini tes yang saya pakai sampai sekarang: the dirty test. Setelah memberi feedback yang tajam, periksa perasaanmu. Kalau kamu merasa tidak enak, bagus. Artinya feedback-mu datang dari tempat yang benar. Kamu peduli dengan orang itu, dan kamu tahu kamu baru saja menyakitinya demi kebaikannya.
Kalau kamu malah merasa lega, puas, atau lebih buruk lagi, merasa powerful, itu red flag. Itu bukan feedback. Itu kamu memakai posisi untuk melampiaskan frustrasi. Timmu tahu bedanya, bahkan kalau kamu sendiri belum.
Fokus ke strength. Feedback yang memperkuat strength staf lebih bagus daripada feedback yang sibuk memperbaiki kesalahan.
Marcus Buckingham banyak menulis soal ini. Orang-orang terbaik di dunia tidak jadi terbaik karena memperbaiki kelemahan. Mereka jadi terbaik karena menggandakan kekuatan. Misalnya ada developer yang brilliant di architecture tapi payah di documentation. Kamu bisa menghabiskan energi memaksanya jadi penulis yang lebih baik. Atau kamu bisa membebaskannya fokus ke architecture, lalu mencari orang lain yang memang senang menulis documentation.
Ini tidak berarti kelemahan boleh diabaikan. Kelemahan yang mengganggu pekerjaan tetap harus di-address. Tapi memperbaiki kelemahan sampai cukup itu beda dengan mengubah kelemahan jadi kekuatan. Yang pertama masuk akal. Yang kedua biasanya sia-sia dan bikin semua orang capek.

Ada satu hal yang jarang dibahas di buku leadership, tapi nyata sekali dalam pengalaman saya: feedback berjenjang. Cara memberi feedback ke junior beda dengan ke senior. Isinya bisa sama. Yang beda relasinya.

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, pilihan kata penting sekali. Harus spesifik dan bisa langsung dikerjakan. “Di slide 5, coba pindahkan data point ke depan sebelum narasi. Itu akan membuat argument-mu lebih kuat.” Jangan cuma “presentasimu perlu diperbaiki.”

Senior biasanya punya kulit yang lebih tebal. Mereka sudah biasa menerima feedback. Yang mereka butuhkan perspektif, bukan instruksi. “Saya perhatikan dalam tiga sprint terakhir, estimasimu konsisten melebihi actual. Menurut kamu kenapa?” Pertanyaan, bukan pernyataan. Senior yang baik biasanya sudah tahu jawabannya. Mereka cuma butuh seseorang yang cukup peduli untuk bertanya.

Terakhir, soal frekuensi. Ini sebenarnya yang menopang semua poin di atas.

Feedback bagus yang disampaikan sebulan sekali kalah telak dari feedback biasa-biasa saja yang disampaikan setiap minggu. Feedback itu relationship, bukan event.

Kalau kamu bertemu tim seminggu sekali, benar-benar bertemu, bukan status update meeting yang seharusnya cukup jadi email, kamu dan tim punya konteks yang sama. Kamu tahu apa yang mereka kerjakan. Mereka tahu apa yang kamu pikirkan. Tidak ada kejutan. Feedback muncul di obrolan biasa, bukan di sesi formal yang membuat dua pihak sama-sama tegang.

Saya pernah punya staf yang kinerjanya turun selama dua bulan. Di one-on-one mingguan, penurunan itu kelihatan sedikit demi sedikit. Jadi saya bisa memberi feedback kecil setiap minggu: “Hei, saya perhatikan minggu ini kamu agak lambat di project X. Ada yang bisa saya bantu?” Pelan-pelan, dia bounce back.

Seandainya saya cuma bertemu dia sebulan sekali, ceritanya lain. Setelah dua bulan, penurunan itu sudah menumpuk jadi masalah besar. Kalimat saya bukan lagi “ada yang bisa saya bantu?” tapi “kita perlu bicara serius soal performamu.” Orangnya sama. Situasinya sama. Hasilnya jauh berbeda, cuma karena frekuensi.

Satu hal lagi. Feedback harus berangkat dari kepedulian kamu pada tim. Dan kepedulian itu tidak cukup ditunjukkan sekali atau dua kali sebulan. Bertemu tim minimal seminggu sekali itu wajib kalau kamu mau jadi team lead yang lebih bagus.

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

Kedengarannya galak. Tapi makin lama saya makin yakin ini bukan hiperbola. Ini batas minimum. Kalau kamu memimpin 5 orang dan tidak bisa menyisihkan 5 jam seminggu untuk one-on-one, satu jam per orang, berarti kamu terlalu sibuk dengan pekerjaan yang seharusnya bisa di-delegate. Atau kamu sebenarnya tidak tertarik memimpin, dan cuma tertarik dengan title-nya.

Leadership is not a promotion. It’s a career change. Yang kamu hasilkan bukan lagi code, design, atau strategi. Yang kamu hasilkan adalah orang yang sedikit lebih baik dari kemarin, dan itu butuh kehadiran yang konsisten.

Tiga puluh menit. Satu orang. Satu pertanyaan: “Apa yang bisa saya bantu?” Buat saya, bagian tersulitnya justru sesudah itu. Diam, dan mendengarkan sampai dia selesai.

Photo by Wynand van Poortvliet on Unsplash