Anti-pattern untuk Pemimpin Engineering

• Saat bertemu CTO atau pemimpin engineering, topik percakapan yang paling sering muncul adalah tekanan dari CEO untuk "meningkatkan kecepatan engineering"
• Tidak seperti penjualan atau rekrutmen, engineering tidak memiliki metrik hasil yang jelas
• Dari sudut pandang pemimpin engineering, sulit untuk mengatakan kepada CEO bahwa "engineering adalah seni sehingga hasilnya sulit diprediksi"
• Penyebab perbedaan pandangan antara pemimpin engineering dan jajaran eksekutif
  • Pemimpin engineering cenderung mengikuti nasihat kepemimpinan yang bersifat konvensional dengan terlalu kaku
  • Jika suatu praktik digeneralisasi sebagai berguna atau tidak berguna, akan sulit menerapkannya sesuai konteks organisasi
  • Inti dari kepemimpinan engineering yang efektif adalah menilai, berdasarkan situasi, apakah perlu mengikuti praktik yang ada atau mencoba pendekatan baru
• Tulisan yang merangkum pembahasan CTO Carta, Will Larson, dalam sebuah podcast

3 anti-pattern dalam kepemimpinan engineering

1. Menghindari micromanagement
2. Enggan mengukur metrik yang tidak sempurna
3. Pemimpin menjadi payung bagi tim

[Anti-pattern #1: Menghindari micromanagement]

Tiga peran yang saling bertentangan untuk menjadi eksekutif engineering terbaik

• Eksekutif engineering harus menjalankan tiga peran yang saling bertentangan, dan eksekutif terbaik mampu berpindah di antara peran-peran ini dengan luwes
  • Peran sebagai anggota eksekutif: mencari cara untuk memajukan bisnis
    • Terkadang harus mengambil keputusan yang "buruk bagi engineering secara keseluruhan", seperti pemotongan anggaran engineering
    • Bisa juga mencakup perpindahan ke model unit bisnis di mana suara engineering berkurang pada topik tertentu
  • Peran sebagai manajer engineering
    • Memahami struktur kebijakan yang dibutuhkan untuk mengoperasikan organisasi engineering dan mencari cara menjadi pemimpin talenta yang efektif
  • Peran sebagai engineer
    • Bertanggung jawab atas keunggulan teknis dan eksekusi engineering meskipun ada faktor tekanan dari luar
    • Harus menjaga standar keunggulan teknis tetap tinggi
• Banyak eksekutif cenderung terlalu berat ke salah satu dari tiga peran tersebut
• Apa pun peran yang dijalankan, pemimpin membuat kesalahan ketika mereka tetap berpegang pada praktik manajemen yang sudah tidak membantu lagi
• Saat seseorang tiba-tiba menjadi manajer tim, ia memiliki konteks teknis terbanyak tentang semua yang dikerjakan tim, tetapi pada saat yang sama juga menjadi people manager
• Pada titik ini, orang-orang terus diberi nasihat untuk menjauh dari detail
• Manajer engineering yang baru sering diberi saran untuk "menjauh dari kode"
• Diakui bahwa bagi sebagian orang, nasihat seperti ini bisa membantu
• Namun, eksekutif yang sangat kompeten tetap memiliki pemahaman detail sampai tingkat tertentu tentang domain yang mereka jalankan
• Jika terlalu jauh dari detail, mereka hanya akan menjadi birokrat, dan inilah alasan terlalu banyak manajer engineering pada akhirnya menjadi birokrat

Mengembangkan gaya kepemimpinan

• Larson menyarankan para eksekutif engineering untuk melupakan sepenuhnya istilah micromanagement, dan sebaliknya fokus mengembangkan berbagai gaya kepemimpinan yang bisa dipilih
• Ketika tidak ada jalur ke depan yang jelas, atau ketika orang-orang yang punya konteks tentang arah ke depan sangat tidak sepakat, akan membantu jika pemimpin masuk ke detail dan mengambil keputusan sendiri
• Ini membantu memahami tuas yang benar-benar bisa mengubah bisnis, hasil yang harus dicapai tim, jangka waktu untuk mencapainya, dan cara melayani pengguna dengan lebih baik
• Mengembangkan keyakinan yang lebih kuat dalam pengambilan keputusan adalah latihan seumur hidup, dan Larson sendiri masih terus mengusahakannya
• Mengajukan pertanyaan seperti "Apa yang sedang kita lakukan? Mengapa kita melakukannya? Apa datanya? Di mana sumber data yang sebenarnya?" setiap bulan atau kuartal membantu menggali detail lebih dalam

Dua taktik untuk mendekati detail

1. Memahami konteks melalui "menggali konflik"

   • Di lingkungan baru, melewatkan perbedaan konteks yang kecil pun dapat merusak keberhasilan operasional
   • Meskipun memakan waktu lama, penting untuk menemukan "benih konflik" dengan berbicara kepada orang-orang yang memiliki sudut pandang berlawanan
   • Pemimpin yang sukses bertanya, "Bagaimana saya harus berubah agar sesuai dengan organisasi ini?", bukan "Bagaimana saya harus mengubah organisasi agar sesuai dengan cara saya?"

2. Mendokumentasikan detail

   • Strategi ada di mana-mana, tetapi hampir tidak pernah didokumentasikan
   • Dalam banyak kasus, dasar dari keputusan penting tidak didokumentasikan
   • Membangun budaya dokumentasi adalah kunci organisasi engineering yang bergerak cepat
   • Pemimpin baru harus menyelidiki semua yang sudah ada dan menjadikan kisah sukses perusahaan lain sebagai benchmark sebelum membuat strategi sendiri
   • Saat menulis dokumen strategi, direkomendasikan menggunakan framework "Good Strategy, Bad Strategy" dari Richard Rumelt
   • Sejelek apa pun strategi ditulis, hanya dengan mendokumentasikannya saja strategi itu bisa membaik dalam semalam

[Anti-pattern #2: Enggan mengukur metrik yang tidak sempurna]

• Anti-pattern sangat lazim dalam pengukuran
• Secara ideal memang mudah mengatakan "kita seharusnya tidak mengukur itu", tetapi jika begitu, yang terjadi hanya memperlambat pembelajaran organisasi di sekitar kita
• Hal paling bernilai yang dapat dilakukan eksekutif engineering adalah mendidik eksekutif lain tentang cara kerja engineering

Fokus pada perbaikan mental model

• Kita berharap metrik menunjukkan realitas, tetapi metrik bukan hanya untuk menunjukkan kebenaran, melainkan juga untuk mendidik orang
• Kita seharusnya lebih peduli untuk memberi pemahaman pada dewan direksi atau CEO dibanding merasa tersinggung karena mental model kita sendiri dilukai

Menarik CEO ke dalam detail

• Alih-alih berkata, "Ini cara yang buruk sekali untuk mengukurnya", kita harus berkata, "Mari mulai dari sini dan gali sampai kita memahami keterbatasan mengukurnya dengan cara ini"
• Memaksa orang menjauh dari detail tidak pernah menjadi cara yang baik. Mereka harus ditarik masuk ke detail dan dididik dari sana

[Anti-pattern #3: Menjadi payung bagi tim]

• Dulu ada keyakinan bahwa untuk melindungi tim, manajer harus bertindak seperti "payung"
• Namun melindungi tim dari realitas justru merugikan tim dalam jangka panjang
• Baik manajer maupun engineer perlu bisa ikut serta dalam percakapan penting

Perlu perspektif baru dalam pengambilan keputusan strategis

1. Strategi Bottom-Up
   • Kelebihan: memungkinkan tim bergerak cepat dan mengendalikan tool mereka
   • Kekurangan: tidak memiliki kemampuan investasi teknis yang terfokus, dan mendapatkan informasi sedikit lebih lambat
2. Strategi Top-Down
   • Kekurangan: tidak efisien bila CTO atau kelompok arsitektur mengambil semua keputusan
   • Komite hampir tidak pernah menghasilkan keputusan terbaik

Memanfaatkan "navigator" untuk mempercepat pengambilan keputusan

• Menempatkan "navigator" yang berperan sebagai "mini CTO" di setiap unit bisnis untuk mempercepat pengambilan keputusan
• Ini memungkinkan orang-orang yang memiliki konteks paling banyak di lapangan untuk membuat keputusan tech stack yang paling tepat
• Pelajaran untuk sukses:
  1. Jangan melewatkan dokumentasi
  2. Lakukan review setelahnya
  3. Sangat berhati-hati dalam memilih orang yang diberi kepercayaan
• Organisasi adalah akumulasi daya nilai individu dari sejumlah kecil orang, dan kita tidak bisa lepas dari itu

Penutup

• Risiko mengikuti aturan terlalu kaku
  • Ketika tim engineering mulai tumbuh bersama perusahaan, para pemimpin tidak boleh melupakan hal-hal yang sebelumnya membuat banyak eksekutif berniat baik berada dalam kesulitan
  • Tujuan akhirnya adalah menciptakan mekanisme berkualitas tinggi agar orang tetap penasaran dan mencari pengecualian
• Learning Circle
  • Selama tiga setengah tahun terakhir, Larson telah mengadakan "Learning Circle" setiap dua minggu sekali
    • 6 hingga 10 CTO, VP of Engineering, atau eksekutif engineering senior lainnya dari perusahaan teknologi berkumpul, saling memberi kabar terbaru, serta bertukar taktik dan masalah proses
    • Setiap pertemuan dimulai dengan giliran satu menit per orang untuk menyampaikan fokus minggu itu dan topik yang ingin dibahas
    • Setelah sekitar 5 menit membahas topik-topik tersebut, kelompok memilih satu dan menggali lebih dalam selama sekitar 20 menit berikutnya
    • Topiknya beragam, dari "Saya sedang kesulitan karena proyek ini" hingga "Kami baru merekrut orang yang sangat hebat dan saya antusias"
• Belajar melalui praktik
  • Orang yang belajar lewat praktik dapat mengandalkan refleksi rutin seperti learning circle atau refleksi pribadi untuk memaksa munculnya introspeksi yang dibutuhkan agar bisa menyetel aturan dengan halus
  • Larson berkata, "Saya menjadi pemimpin yang lebih baik dengan belajar dari pelajaran orang lain yang pernah membuat kesalahan mirip dengan saya"

[geniuskey]

Bagian terakhir, "Larson berkata, "Saya menjadi pemimpin yang lebih baik ..."", terasa agak memalukan bagi saya. Rasanya akan lebih enak dibaca jika ditulis seperti, "Seorang pemimpin harus terus berusaha untuk .... Saya sendiri juga masih banyak kekurangan, dan sedang berupaya untuk menjadi lebih baik". Mungkin ini sudut pandang yang terlalu khas Korea? ^^;;

[savvykang]

Melihat Anda bertanya apakah ini dari sudut pandang khas Korea, tampaknya Anda cukup paham. Menurut saya, pembicaranya juga tidak menunjukkan narsisme, jadi reaksi seperti ini agak membingungkan.

[tofumaker]

Fokus pada sikap pembicara, bukan pada esensi atau isi tulisanmu, terasa sangat khas Korea.

[savvykang]

Ini tentang 'Anti-pattern #1: menghindari micromanagement', tetapi pembahasannya malah menyuruh melupakan micromanagement, jadi alur isinya terasa janggal.

[frog08]

Menganggap micromanagement sebagai sesuatu yang buruk dan harus selalu dihindari justru merupakan sebuah anti-pattern. Intinya, jangan menilai apakah ini micromanagement atau bukan, tetapi perhatikan detail seperlunya sesuai kebutuhan.

[savvykang]

Kalau setidaknya ditulis sebagai 'anti-pattern: menganggap micromanage sebagai sebuah opsi' atau 'menganggap memperhatikan detail sama dengan micromanaging', konteksnya akan terasa lebih mulus. Saya paham maksud tulisannya, tetapi pada akhirnya pesan yang ingin disampaikan adalah melakukan manajemen yang memperhatikan detail alih-alih 'micro'manage, bukan?

[kandk]

Topik percakapan yang paling sering muncul saat bertemu CTO atau pemimpin engineering adalah tekanan dari CEO untuk "meningkatkan kecepatan engineering"
Tidak seperti penjualan atau perekrutan, engineering tidak memiliki metrik kinerja yang jelas
Dari sudut pandang pemimpin engineering, sulit untuk mengatakan kepada CEO bahwa "engineering adalah seni sehingga hasilnya sulit diprediksi"

[xguru]

Lihat juga pendapat di Hacker News tentang artikel ini.

• Ada pendapat bahwa metodologi Will Larson yang telah diterapkan di berbagai organisasi tidak terlalu efektif. Metodologinya memicu konflik antara engineer dan bisnis.
• Rekomendasi buku dari Ron Jeffries: merekomendasikan buku "The Nature of Software Development", yang menekankan nilai bertahap, dipimpin engineer, umpan balik berkelanjutan, dan fleksibilitas.
• Hal positif dari Larson adalah kemampuannya untuk melakukan refleksi diri dan menerima kritik. Tulisannya tidak selalu benar atau salah, tetapi ia sangat mendalami pemecahan masalah.
• Karena sifat produk berbasis web, kesalahan tidak bersifat fatal, dan perubahan yang sering terjadi kerap dilakukan karena alasan pemasaran. Karena itu, terbentuk budaya bergerak cepat dan mentoleransi kesalahan.
• Sisi positif micromanagement: pemimpin engineering yang baik memahami detail dengan baik dan mampu berkomunikasi dengan tim. Ini berbeda dari micromanagement.
• Terlalu banyak tenaga teknis justru menimbulkan masalah. Jika alat yang lebih baik dikembangkan, tim kecil pun akan cukup untuk menyelesaikan pekerjaan.
• Masalahnya bukan pada pengukuran itu sendiri, melainkan pada pengambilan keputusan yang keliru berdasarkan hasil pengukuran tersebut. Metrik seharusnya digunakan sebagai alat untuk mengajukan pertanyaan.
• Dalam pengembangan perangkat lunak skala besar, kolaborasi adalah inti. Runtuhnya komunitas menjadi penyebab utama melambatnya proyek.
• Jika peran dan ekspektasi masing-masing dalam pipeline pengembangan tidak jelas, masalah akan muncul. Manajer harus menyelesaikan situasi seperti ini.
• Ada pendapat bahwa ini tulisan yang bagus, tetapi akan lebih baik jika panjangnya dikurangi 25%.