- Pemimpin engineering Apple Michael Lopp menekankan bahwa di era ketika produk bisa dibuat dengan cepat, operasi yang berpusat pada manusia dan kemampuan mengambil keputusan justru semakin penting
- “Siapa yang mengambil keputusan, dan bagaimana keputusan itu dijalankan?” adalah inti sebenarnya dari engineering
- Bukan kemampuan menulis kode, melainkan organisasi dan kepemimpinan yang berpusat pada manusia yang menentukan kinerja organisasi
- Berdasarkan pengalamannya di berbagai lingkungan seperti Borland, Netscape, Palantir, dan Slack, ia memaparkan secara konkret struktur organisasi, budaya kolaborasi, dan kompetensi inti kepemimpinan
- Fokusnya bukan pada kepemimpinan teknis, melainkan pada operasi organisasi, kolaborasi antarmanusia, dan pemahaman terhadap manusia
- Wawancara ini bukan sekadar diskusi teknis, tetapi berfokus pada perancangan organisasi engineering yang berkelanjutan dan efektif, serta menyajikan saran praktis bagi pendiri dan pemimpin teknologi mengenai hubungan dengan tim produk, kemampuan yang berpusat pada manusia, dan syarat menjadi pemimpin yang baik
Bagaimana merancang struktur organisasi engineering
- Bahkan di industri yang berbeda-beda, ia menyebut kepercayaan terhadap engineering, pertumbuhan cepat, dan perekrutan talenta cerdas sebagai faktor sukses yang sama
- Berdasarkan hal itu, ia mengusulkan tiga tips praktis untuk merancang organisasi engineering yang sukses
Tip #1: Dorong “Wolf Time”
- Bagi waktu engineer menjadi 71% pekerjaan inti / 29% waktu kreasi bebas
- 29% tersebut adalah “waktu yang tidak bisa diukur dan tidak perlu dijelaskan”, yaitu ruang tempat kreativitas dan inisiatif tumbuh
- Upaya untuk memformalkannya di Palantir gagal → dorongan informal dan komunikasi lebih efektif daripada formalisasi
- Contoh: mengusulkan waktu berbagi ide informal setiap Jumat
> “Kalau anggota tim tidak sadar bahwa waktu ini diizinkan, mereka akan melakukannya diam-diam di sela-sela rapat, dan tidak ada yang akan tumbuh”
Tip #2: Semakin rutin perdebatan, semakin baik
- Produk hebat lahir dari kolaborasi engineering, desain, dan produk
- Kolaborasi ini sering disertai konflik, tetapi justru perdebatan itulah kunci untuk meningkatkan kualitas produk
- Perdebatan dalam tim harus aktif seputar apakah ini masalah desain, masalah produk, atau masalah pemahaman fungsi
- Pemimpin harus mendorong tantangan pendapat bukan hanya dari bawah ke atas, tetapi juga dari atas ke bawah
- Sering ada momen ketika perdebatan antara pendiri dan karyawan mengubah arah perusahaan
Tip #3: Bangun sistem operasi yang bisa diskalakan
- Penilaian yang baik + kemampuan operasional adalah dasar produk yang bisa diskalakan
- Penilaian bukan sekadar hasil akhir, melainkan kemampuan menjelaskan “mengapa keputusan itu diambil”
- Arti akuntabilitas adalah memiliki “cerita yang bisa dipertanggungjawabkan”
- Agar penilaian dari segelintir orang bisa meluas menjadi sistem organisasi secara keseluruhan, dibutuhkan proses yang jelas
- Kualitas operasi bahkan terlihat dari proses rekrutmen saja (kecepatan respons, kejelasan jadwal, dan sebagainya)
- Jangan mengabaikan proses dengan alasan startup → membangun perusahaan pada dasarnya adalah membangun operasi
Bagaimana memperkuat hubungan antara engineering dan tim produk
- Ketegangan dan kesalahpahaman antara tim produk dan tim engineering adalah cerita lama, tetapi
untuk menciptakan produk berkualitas tinggi yang bisa diskalakan, hubungan ini wajib dipoles dengan baik
- PM yang buruk membuat engineer sekadar mengikuti tanpa rasa memiliki terhadap produk,
- PM yang baik membantu engineer memahami sepenuhnya “mengapa kita membuat ini”
- Lopp mendefinisikan engineer sebagai orang “bagaimana (how)”, dan PM sebagai orang “mengapa (why)”
- Tim produk harus menyampaikan cerita pelanggan, lalu mendelegasikan cara membangunnya kepada engineer dan desainer
- Kuncinya adalah berbagi “why”
> Tanyakan langsung kepada engineer, bukan PM, “mengapa fitur ini dibuat?”
- Jika jawabannya “karena disuruh PM”, itu memicu kemarahan
- Masalah sebenarnya bukan karena penilaian tim produk salah, tetapi karena engineer tidak memahami konteksnya
> “Engineer adalah orang yang membangun produk dengan tangan mereka. Organisasi yang membuat mereka bekerja tanpa memahami ‘mengapa ini dibuat’ akan gagal”
- Saat ditanya mengapa Slack tidak punya fitur blokir, Stewart menjelaskan dengan jelas filosofi bahwa “informasi penting untuk terlihat oleh semua orang”
- Ini menunjukkan sudut pandang bahwa hal itu adalah masalah visi, bukan sekadar fitur
- Product manager yang baik harus mampu menempatkan tiap fitur atau ide dalam konteks visi keseluruhan produk saat menyampaikannya
- Itulah bagian dari ‘why’ yang harus menjadi fokus semua orang
Seperti apa pemimpin yang hebat?
- Kepemimpinan engineering yang benar-benar berdampak melampaui sekadar kemampuan teknis
- “Pada akhirnya, kepemimpinan adalah keterampilan mengelola manusia”
-
Karakteristik kepemimpinan #1: Memiliki fleksibilitas (Malleability)
- Pemimpin bekerja dengan orang-orang yang memiliki karakter berbeda-beda, sehingga harus mampu menyesuaikan gaya dirinya sesuai situasi
- Ia menegaskan hal ini dengan mencontohkan pengalamannya memimpin tim dengan cara yang sangat berbeda di Pinterest dan Slack
- Kepada manajer baru, ia selalu menanyakan hal yang sama: “Setelah menerima feedback, apa yang Anda ubah?”
- Susunan tim pun bukan didasarkan pada standar yang kaku, melainkan diorganisasi ulang berdasarkan kekuatan dan kelemahan yang muncul saat benar-benar bekerja bersama
- Untuk itu, ia melakukan reorganisasi setiap 6 bulan
-
Karakteristik kepemimpinan #2: Unggul dalam storytelling
- Ia menunjukkan penolakan kuat terhadap micromanagement: "Tidak ada yang lebih menyebalkan daripada mendikte engineer"
- Sebagai gantinya, pemimpin harus menyediakan "kotak (Box) dan sup (Soup)"
- Kotak: ruang yang diisi ide dan konteks
- Sup: dasar informasi yang bisa diminum atau diracik bebas oleh anggota tim
- Alih-alih memberi instruksi, jika pemimpin memberi cerita yang menginspirasi, anggota tim akan membuat keputusan sendiri dan bertumbuh
- Beberapa anggota tim memang berkata, “cukup bilang saja saya harus apa”, tetapi itu pun pada akhirnya tetap mereka tafsirkan dengan cara mereka sendiri
> Peran pemimpin adalah memberi sup. Apakah akan diminum, dan apa yang akan ditambahkan ke dalamnya, itu pilihan mereka.
-
Karakteristik kepemimpinan #3: Memahami motivasi dan tujuan anggota tim
- Pemimpin harus tahu apa yang membuat tiap anggota tim bertumbuh dan termotivasi
- Satu contoh: bagi engineer yang tantangan teknis adalah penggerak hidupnya, berikan kesempatan memecahkan masalah tanpa henti
- Contoh lain: asisten di Palantir dengan jelas menyatakan motivasi yang berpusat pada kompensasi → lebih mudah dikelola secara jelas
- Intinya adalah memahami “satu motivasi inti” dari tiap orang, lalu terus berinvestasi di sana
- Untuk itu, dibutuhkan rasa ingin tahu (curiosity) dan pertanyaan “mengapa?” yang terus-menerus
> Pemimpin harus menemukan motivasi yang bahkan belum disadari anggotanya sendiri, lalu menciptakan peluang pertumbuhan.
Kesimpulan: inti engineering yang sukses adalah memahami manusia
- Organisasi engineering yang sukses bergantung pada dinamika manusia (Human Dynamics) yang berjalan mulus
- Produk hebat lahir bukan dari individu yang luar biasa, tetapi dari sekumpulan orang yang bekerja sama dengan baik
- Peran pemimpin dimulai dari memberdayakan orang-orang yang membentuk organisasi
- “Tim engineering adalah sebuah tapestry besar yang rumit sekaligus indah, yang terdiri dari manusia”
- Upaya untuk memahami struktur dan aliran dalam tapestry ini adalah kunci agar nilai produk dapat disampaikan secara efektif melalui seluruh organisasi
> "Ketika Anda memiliki dorongan untuk memahami bagaimana orang saling berinteraksi, perusahaan Anda akan siap menyampaikan nilai produk dalam skala besar."
6 komentar
Ada Slack untuk para pemimpin teknis yang dikelola oleh Michael Lopp.
RLS - Rands Leadership Slack
Bagi yang tertarik, silakan coba bergabung. Saat ini ini adalah Slack raksasa dengan lebih dari 36.000 peserta.
Untuk mendaftar, baca baik-baik isi di tautan di atas lalu kirim email ke Lopp.
Nama/profesi/alasan ingin bergabung/dari mana mengetahui RLS/akun LinkedIn atau Twitter Anda
Kalau sudah merekrut engineer mahal, jangan mentang-mentang kerjanya kelihatan cuma main pena lalu memperlakukan engineer seperti LLM, memberi perintah sampai hal-hal sepele seolah menyuruh Doraemon yang bisa langsung bikin barang jadi; cukup bagikan visinya saja, lalu biarkan mereka menangani sendiri pendekatan rekayasa untuk mewujudkannya, karena itulah bidang keahlian mereka.
Semakin dipikir-pikir, kenapa yang terbayang di kepala saya justru alur orang-orang di negara kita yang mau membangun rumah di desa atau merenovasi apartemen lama lalu ribut adu argumen dengan kontraktor, pelaksana, atau perancangnya?
Bukankah kasus yang belakangan itu konteksnya agak berbeda?
Remodeling rumah pedesaan atau apartemen lama
pertama-tama lebih dekat ke mewujudkan impian pribadi daripada bisnis,
dan karena anehnya memang sangat sering terjadi orang mempercayakan semuanya kepada kontraktor konstruksi/remodeling lalu malah ditipu dari belakang...
Kalau pemiliknya tidak membuatnya sendiri dan menyuruh orang lain, sepertinya situasinya akan jadi sama saja.
Sehebat apa pun penjelasannya, tetap ada salah paham, dan sesermat apa pun diperiksa, ternyata selalu ada area yang luput terpikirkan.
Kalau setiap bagian yang tidak dijelaskan oleh pemilik harus ditanyakan satu per satu sambil mengerjakannya, itu makan banyak waktu dan bikin frustrasi, jadi ada sangat banyak bagian yang ditangani sendiri oleh ahlinya, dan sepertinya justru bagian-bagian itulah yang jadi sumber tarik-ulur.
Ngomong-ngomong, saya iri karena sepertinya Anda belum terlalu sering kena tipu oleh vendor SI.
Buku Modern Software Engineering yang baru-baru ini saya baca juga mengingatkan saya akan hal ini. Buku itu juga membahas tim dan organisasi, bukan hanya pengembangan itu sendiri.
Ada berbagai pendapat dan pendekatan tentang kepemimpinan engineering, tetapi tampaknya esensinya sama: semuanya berlandaskan pada pemahaman terhadap para anggota tim. Memahami anggota tim memang terdengar mudah, tetapi rasanya itu adalah bagian yang menuntut dibangunnya kepercayaan berdasarkan empati antara pemimpin dan anggota tim melalui umpan balik satu sama lain. Sepertinya ini bukan sesuatu yang bisa tercipta sekaligus. Terima kasih atas tulisan yang bagus dan memberi bahan untuk dipikirkan.