Bagaimana Startup Kehilangan Gairahnya

• Dalam startup tahap seed yang berjalan baik, engineer biasanya mencari masalah pengguna sendiri lalu mengerjakan implementasi hingga rilis, tetapi saat perusahaan membesar, loop ini berubah menjadi pekerjaan yang lebih lambat dan terpecah-pecah
• Tim dengan kurang dari 10 orang memiliki kecepatan implementasi tinggi berkat kedekatan dengan pengguna, pemilihan ide yang luwes, umpan balik rekan kerja, codebase kecil, dan deployment yang ringan
• Dalam organisasi dengan 100+ orang, kontak dengan pengguna dipisahkan ke PM, sementara review keamanan, CI, review PR, dan prosedur infrastruktur menumpuk sehingga kecepatan kerja melambat drastis
• Latar belakang perubahan ini mencakup menurunnya kepentingan langsung, komunikasi O(N^2) akibat bertambahnya jumlah karyawan, serta toleransi risiko yang makin rendah seiring bertambahnya pengguna dan regulasi
• Hilangnya keseruan sulit dicegah sepenuhnya, tetapi bisa ditunda dengan tidak buru-buru meniru proses perusahaan besar, merancang tim kecil yang independen beserta insentifnya, dan memperlambat laju perekrutan

---

Mengapa pekerjaan di startup kecil terasa begitu membuat ketagihan

• Dalam startup tahap seed yang berjalan baik, pekerjaan inti engineer adalah memahami masalah pengguna, menciptakan ide, mendiskusikannya dengan rekan kerja, mengimplementasikannya, lalu mengulang siklus rilis dan evaluasi
• Dalam tim dengan kurang dari 10 orang, setiap tahap dalam loop ini bisa terasa menyenangkan
  • Bisa langsung menghubungi pengguna yang menarik dan mengobrol sambil minum bir
  • Jika menemukan ide yang bernilai bagi perusahaan dan juga menarik secara pribadi, kita bisa menghentikan pekerjaan yang sedang dilakukan dan langsung mengerjakannya
  • Rekan kerja punya kepentingan langsung terhadap keberhasilan perusahaan yang sama, sehingga mereka terdorong untuk mendukung ide bagus dan menjelaskan masalah pada ide yang buruk
  • Rekan kerja bisa jadi juga pengguna dari ide tersebut, mungkin ingin mengerjakannya bersama, dan kemungkinan besar memahami sebagian besar codebase sehingga bisa memberi wawasan berguna

Implementasi cepat dan ekspektasi tinggi

• Dalam tim kecil, kecepatan implementasi sangat tinggi
  • Bisa memilih alat yang diinginkan dan tidak ada review keamanan
  • Codebase kecil sehingga keseluruhan strukturnya bisa disimpan di kepala, membuat refactor besar pun relatif nyaman untuk dicoba
  • Berkat hot reload yang cepat, debugging dengan pendekatan trial-and-error bisa diulang dengan cepat
• Penggabungan perubahan juga berlangsung ringan
  • Tidak ada test lambat di CI, dan untuk perubahan yang aman mungkin tidak perlu review PR yang bersifat blocking
  • Dalam beberapa kasus, bisa langsung push ke master, atau untuk perubahan berisiko bisa menepuk bahu rekan kerja dan meminta review
  • Jika pengguna belum banyak, downtime bisa ditoleransi demi perubahan backend atau database yang cepat
• Di startup kecil, ada ekspektasi kuat bahwa apa pun mungkin terjadi
  • Fitur baru mungkin bisa menaikkan nilai ekuitas, dan setelah itu orang-orang bisa terus membangun di atas fitur tersebut
  • Bisa membayangkan pengguna berkata, “apakah Anda yang mencetuskan ide ini, ini menyelamatkan hidup saya”
  • Karena semua anggota tim berbagi kepentingan yang sama, tercipta suasana saling mendukung atas keberhasilan satu sama lain

Bagaimana loop yang sama berubah saat perusahaan membesar

• Dalam organisasi dengan 100+ orang, kontak langsung dengan pengguna berkurang
  • Berbicara dengan pengguna menjadi peran PM, dan engineer mungkin hanya menerima ringkasan insight pengguna serta daftar prioritas
  • Dalam kasus buruk, engineer menerima daftar tugas yang membingungkan karena pemahaman pengguna yang salah atau visi manajer yang egois, tanpa ada orang yang bisa menjelaskan mengapa tiap tugas itu penting
• Menjadi lebih sulit untuk langsung memilih pekerjaan yang diinginkan sendiri
  • Jika semua orang mengerjakan apa yang mereka mau, akan muncul kekacauan komunikasi O(N^2)
  • Manajer merancang rencana individu sambil mempertimbangkan pekerjaan lain di organisasi
  • Ide sendiri mungkin hanya bisa dikerjakan setelah tugas yang ditetapkan selesai, atau diam-diam di waktu senggang
• Masih bisa membicarakan ide dengan rekan kerja, tetapi minat dan kelonggaran mereka berkurang
  • Rekan kerja mendapat manfaat yang kecil dari keberhasilan individu, dan bahkan bisa menjadi pesaing promosi
  • Masing-masing punya daftar tugas panjang sehingga tidak bebas meninggalkan pekerjaannya untuk ikut mengerjakan bersama
  • Kemungkinan mereka juga kurang memiliki ingatan atau konteks terhadap kode terkait

Mengapa implementasi melambat di organisasi besar

• Dalam organisasi dengan 100+ orang, pemilihan alat biasanya sudah ditentukan
  • Meski ada alat baru yang lebih baik, bisa dianggap tidak layak diadopsi karena biaya merusak konsistensi
  • Untuk memakai alat baru, perlu bertanya ke manajer dan mengirim email ke tim review keamanan
• Codebase besar biasanya membesar karena alasan legacy
  • Banyak kode yang menakutkan untuk disentuh, dan banyak juga yang sudah tidak dipahami siapa pun lagi
  • Testing yang ketat menjadi satu-satunya dasar keyakinan bahwa perubahan tidak akan merusak seluruh sistem
  • Debugging trial-and-error tetap dibutuhkan, tetapi waktu kompilasi yang panjang membuat siklus iterasinya lambat
• Bahkan menggabungkan satu PR kecil pun bisa memakan waktu 2 minggu
  • Menunggu 20 menit agar CI lolos, lalu jika test flaky harus menjalankannya lagi
  • Sambil menunggu review, konflik merge terus menumpuk
  • Reviewer mungkin tidak punya cukup konteks atau motivasi, sehingga alih-alih memberi saran penting mereka hanya menyoroti hal-hal sepele
  • Setelah menerapkan perubahan yang diminta dan push ulang, harus menunggu 20 menit lagi, dan proses ini bisa terulang tiga kali untuk setiap PR
• Perubahan infrastruktur bisa menjadi prosedur 14 langkah demi menghindari downtime atau kehilangan data untuk 10 juta pengguna
• Bahkan setelah bekerja diam-diam selama 3 bulan lalu merilis sesuatu, imbalan dan pengakuan bisa tetap terbatas
  • Mungkin mendapat kesempatan demo di rapat hari Jumat yang bisa dilihat CEO, tetapi rekan kerja yang benar-benar memperhatikan mungkin hanya segelintir
  • Manajer bisa mengatakan bahwa ini akan membantu pada siklus evaluasi kinerja 5 bulan lagi
  • Dalam skenario baik, bisa mendapat kenaikan gaji 20% dan perubahan jabatan; dalam skenario buruk, 4 bulan kemudian terjadi reorganisasi, datang manajer baru, dan proyek terdorong ke belakang prioritas atau dibatalkan

Cara menunda kematian keseruan

• Perubahan ini lebih merupakan masalah menundanya daripada mencegahnya sepenuhnya
  • Akar masalahnya adalah menurunnya kepentingan langsung, komunikasi O(N^2), dan menurunnya toleransi risiko
  • Menurunnya kepentingan langsung dan masalah komunikasi makin sulit dihindari seiring bertambahnya jumlah karyawan
  • Menurunnya toleransi risiko adalah akibat bertambahnya jumlah pengguna, dan sebagian juga terkait regulasi pemerintah
• Startup bisa terlalu cepat menjadi korporat dengan meniru proses perusahaan besar secara tidak perlu
  • Jika merekrut manajer dari perusahaan besar, playbook yang biasa mereka pakai bisa ikut terbawa
  • Banyak startup memakai Jira hanya karena perusahaan besar memakainya, tetapi pandangannya adalah pendekatan seperti itu sebaiknya dihindari
  • Y Combinator bisa dianggap telah memperluas pemahaman bahwa justru perusahaan besar yang seharusnya beroperasi lebih seperti startup
• Playbook perusahaan besar dibuat untuk perusahaan besar, dan saat startup mulai membesar mungkin sudah ada solusi yang lebih baik untuk menangani masalah skala
  • Saat menghadapi rasa sakit karena skala, lebih baik menyelesaikannya dari first principles, atau mencari inspirasi dari startup lain dengan ukuran serupa yang bergerak lebih cepat
• Menyusun perusahaan sebagai beberapa startup independen adalah pendekatan yang layak dicoba sejauh memungkinkan
  • Rippling disebut sebagai contoh yang sampai tingkat tertentu berhasil melakukan ini
  • Namun biasanya ada batasan karena komponen produk terlalu erat terhubung, dan sebagian besar komponen tidak bisa menghasilkan pendapatan sendiri
• Merancang insentif dapat secara berarti menunda menurunnya kepentingan langsung
  • Tetapi insentif yang sekuat kepemilikan saham besar dan kemampuan untuk mengubah nilainya sangat jarang ada
• Salah satu cara terbaik adalah merekrut lebih sedikit
  • Banyak perusahaan merekrut terlalu cepat karena ketidakselarasan insentif manajer, tekanan investor untuk terlihat seperti startup lain yang tumbuh cepat, dan kegagalan memahami biaya nyata dari satu orang tambahan
  • Semakin baik alat, terutama AI, semakin besar jumlah pengguna yang bisa didukung tim kecil
  • Pendiri di masa depan mungkin akan lebih sedikit mengkhawatirkan rasa sakit karena skala ini, dan pekerjaan bisa menjadi lebih menyenangkan bagi semua orang

[GN⁺]

Komentar Hacker News

• Saya sangat menyukai cara Netflix bekerja 10 tahun lalu, saat ukurannya masih kecil. Mereka bisa menghilangkan proses dengan merekrut orang-orang yang matang, dan memang berusaha membuat semuanya bebas dari proses
  Hasilnya, pekerjaan berjalan begitu saja, dan saat itu di Netflix, “sesuatu yang terjadi secara alami tanpa insiden besar” sering menjadi ekspektasi. Region active-active juga selesai dalam beberapa bulan, alat deployment yang mudah dipakai, Asgard, juga muncul, dan rencana membuat CDN sendiri serta bermitra dengan ISP pun selesai dalam 6 bulan oleh sekitar 12 orang
  Dari sudut pandang engineer, hanya ada satu rapat tim mingguan, sementara manajer dan direktur mengadakan banyak rapat untuk menyelaraskan konteks antartim, sehingga para engineer bisa bekerja produktif sebebas-bebasnya. Saat itu saya menganggapnya wajar, tetapi belakangan saya sadar itu adalah standar yang sangat tinggi

  • Yang penting, cara seperti ini membutuhkan engineer dan manajer yang matang. Tidak ada yang lebih buruk daripada organisasi yang merekrut engineer berpengalaman lalu “leadership” yang belum matang memberi berbagai instruksi
    Diperlukan developer yang bisa menyelesaikan pekerjaan tanpa harus dituntun, tetapi manajer juga harus mampu berkoordinasi, bukan menggandeng tangan dan mengontrol
  • Cara seperti ini cocok untuk organisasi deep tech yang tidak melakukan enterprise sales dan bisa tenggelam dalam masalah teknis. Yang terlintas adalah tempat seperti MongoDB atau divisi hardware NVIDIA
    Namun jika produknya perlu menerima masukan subjektif dari dua orang atau lebih lalu diperbaiki secara iteratif, komunikasi dan kolaborasi terdistribusi menjadi penting dan diperlukan. Bukan berarti itu harus menyakitkan, tetapi model Netflix di atas tidak berlaku di mana-mana dan tidak boleh ditiru secara membabi buta
  • Bahkan jika anekdot-anekdot kecil ini benar, waktunya mungkin jauh lebih awal dari 10 tahun lalu. Ketika saya mendengar presentasi Adrian Cockroft pada 2012, Netflix sudah memiliki ribuan engineer dan ratusan layanan, dan Asgard juga sudah ada serta sedang dijadikan open source
  • Saya bertanya-tanya apakah ini juga mungkin karena Netflix adalah produk yang didefinisikan relatif sempit. Tujuannya jelas: layanan yang men-streaming library konten ke layar
    Tempat-tempat tempat saya bekerja produknya tidak terdefinisi dengan baik; bukan karena dibiarkan begitu saja, melainkan karena baru dan bentuknya belum jelas sehingga tak seorang pun tahu seharusnya menjadi apa. Sebaliknya, Netflix punya tujuan jelas, yaitu “mengirim video ke layar seefisien mungkin”, sehingga lebih dekat ke pemecahan masalah teknis murni
    Tentu pengembangan produk seperti iklan atau back office akan terus ada, tetapi saya penasaran apakah karena misi inti produknya cukup kokoh, mereka perlu menghabiskan lebih sedikit waktu untuk menyelaraskan orang ke arah yang sama
  • Saya penasaran apakah sekarang mereka tidak lagi bekerja seperti itu. Jika mereka masih merekrut engineer berpengalaman, apa yang berubah? Selain itu, saya juga penasaran apakah di Netflix masih ada hasil yang mudah diraih atau pekerjaan menarik yang tersisa

• Setiap kali melihat tulisan seperti ini, saya jadi ingin memutar mata. Rasanya penulisnya masih cukup junior, atau tipe founder yang punya ekspektasi aneh dan rusak tentang mengapa karyawan bekerja untuk perusahaannya
  Ini banyak berasal dari budaya aneh industri teknologi SF, tetapi di luar itu orang tidak memandang pekerjaan mereka seperti ini. Developer terbaik yang pernah bekerja dengan saya tidak “mabuk” kerja; mereka adalah profesional yang tahu apa yang mereka lakukan, mendapat kompensasi bagus atas pengetahuan itu, dan memiliki kehidupan yang penuh di luar pekerjaan, dengan teman dan minat pribadi
  Narasi seperti ini lebih mirip propaganda agar engineer muda yang mudah dipengaruhi menyerahkan lebih banyak hidup mereka untuk pekerjaan daripada yang dibenarkan oleh gajinya. Jika Anda engineer muda, jangan lakukan itu. Ada banyak atasan yang memanfaatkan antusiasme dan kepolosan untuk benar-benar merusak kehidupan pribadi, tetapi banyak juga tempat yang mengharapkan hubungan pemberi kerja-karyawan yang normal

  • Pekerjaan pertama saya adalah proyek yang baik bagi dunia, tetapi upahnya hampir setara upah toko kelontong. Secara harfiah itu perusahaan kecil berisi 2–3 orang, dan CEO-nya adalah orang tua yang “tidak punya dana pensiun” serta “berutang 2 juta dolar”
    Ketika ia mengusulkan untuk menunda upah sampai produk diluncurkan, taktik membangun kepercayaan selama bertahun-tahun akhirnya diuangkan, dan saya perlahan menyadari bahwa gaji buruk itu memang disengaja. Mereka sebenarnya bisa membayar upah yang layak untuk pekerjaan itu, tetapi ketika saya menuntut kompensasi yang semestinya, yang saya dapat hanya penolakan, janji-janji remah roti, dan tembok penghalang
    Belakangan ketika saya menagih uang yang tertunggak, ia berkata “tidak ada uang untuk membayar”, tetapi setelah saya marah dan berhenti, ia mempekerjakan orang lain untuk mengerjakan ulang proyek kedua saya dari awal. Saya bukan developer tercepat dan orang baru itu tampaknya juga cukup bagus, tetapi menurut saya dan developer lain, pekerjaan saya sudah cukup terselesaikan
  • Cukup lihat /r/sysadmin, mengejutkan betapa banyak orang yang punya kompleks mesias
    Situasinya seperti, “tiga rekan kerja dipecat sehingga sekarang saya mengerjakan pekerjaan empat orang, tetapi atasan tidak mendengarkan saat saya bilang ini terlalu berat.” Orang yang profesional kemungkinan sudah pergi sebelum PHK, atau jika situasi seperti itu terjadi, ia akan menetapkan batas dan bernegosiasi tentang apa yang akan dan tidak akan dikerjakan dalam minggu kerja normal
    Perusahaan bisa memecat orang tanpa berpikir panjang, tetapi terlalu banyak orang dicuci otak sampai lebih mengkhawatirkan perusahaan daripada hidup mereka sendiri, dan itu tidak masuk akal
  • Tidak semua orang sama, dan motivasinya juga berbeda. Selama 10 tahun pertama saya bekerja di pekerjaan yang stabil dan bayarannya lumayan, tetapi saya begitu bosan sampai setiap hari hanya menghitung waktu pulang dan memesan liburan berbulan-bulan sebelumnya
    Setelah itu saya pindah ke startup dan tidak menyesal. Saya bekerja lebih banyak, tetapi jauh lebih menyenangkan, dan meski tidak bisa dilakukan selamanya, imbalan finansialnya juga lebih baik, jadi sepertinya saya tidak perlu bekerja sampai usia 65 seperti di pekerjaan lama yang stabil dan membosankan itu
  • Banyak orang bersemangat terhadap pekerjaan mereka. Fakta bahwa pekerjaannya adalah pemrograman komputer, bukan menyembuhkan kanker, tidak mengubah itu
    Itu juga bukan berarti hidup mereka tidak penuh, atau bahwa mereka dieksploitasi. Justru orang-orang yang mengatakan sebaliknya tampak seperti mendapatkan lebih sedikit dari apa yang bisa diberikan pekerjaan. Agak sayang menghabiskan 40 jam seminggu seperti itu
  • Mudah ditemukan secara online. Polanya seperti putus kuliah, lalu bekerja 4 tahun sebagai “founding engineer” di startup, dan sekarang tahun pertama di startup lain
    Pada dasarnya ia sudah meminum Kool-Aid, dan berada dalam kondisi tidak tahu apa yang tidak ia ketahui

• Ada juga faktor-faktor yang melangkah lebih jauh dari sekadar “kobaran api” dan memicu kehancuran total
  Daftar yang belum lengkap, yang sejauh ini saya lihat berperan besar dalam membuat tim engineering dan produk merosot atau runtuh, adalah: pemimpin yang terlalu teknis, pemimpin non-teknis, engineer bermasalah, dan micromanagement
  Saat startup tumbuh, engineer superstar sering berpindah ke peran kepemimpinan seperti VP Engineering, arsitek, atau CTO. Namun jika mereka bukan tipe pemimpin, tim mudah berubah menjadi kebun binatang tanpa visi. Sebaliknya, pemimpin non-teknis yang hampir tidak punya pengalaman engineering juga sama berbahayanya
  Jika engineer bermasalah masuk karena wawancara yang dangkal dan proses pemecatan juga longgar, meski hanya 5–10% dari tim yang bertipe seperti itu, mereka bisa menghambat kemajuan, menghindari tanggung jawab, hanya membangun reputasi, dan memaksakan hasil kerja sampah sehingga sangat merusak moral. Mempertahankan tim dan budaya engineering yang baik tampak sesulit menegakkan pensil di atas ujungnya

  • Sebagai konsekuensi dari masalah manusia, saya juga ingin menambahkan tidak segera memperbaiki rekrutmen yang bermasalah
    Founder pemula sering terlalu ragu untuk memberi umpan balik negatif, menurunkan jabatan manajer yang terlalu teknis dan seharusnya tetap menjadi IC, atau melepas karyawan yang tidak cocok
    Sebuah startup lokal menempatkan teman desainer UI dari seorang eksekutif level C sebagai VP produk. Ia sama sekali tidak mampu menangani pekerjaannya, tetapi dipertahankan selama 2 tahun dengan alasan “memberinya kesempatan untuk berkembang”. Semua orang di bawah VP itu tahu ia tidak kompeten dan membicarakan cara untuk mengakalinya
    Pada akhirnya, inisiatif produk bahkan tidak pernah dimulai dan perusahaan harus berputar sepenuhnya ke pekerjaan berbasis layanan. Sebaiknya jangan bertahan di startup yang terus mempertahankan pemimpin tidak berkualifikasi yang sudah ditinggalkan secara mental oleh orang-orang di perusahaan
    Perusahaan yang sama, saat melakukan perampingan, punya kesempatan sempurna untuk membereskan VP produk itu beserta kerajaannya yang hampir tidak bekerja dengannya. Namun karena koneksinya dengan level C, mereka menghindarinya dan malah memotong engineer. Mereka mulai mengurangi engineer dengan kompensasi tinggi, lalu kehilangan engineer inti, mengirim sinyal bahwa ketidakmampuan bisa ditoleransi asal mengenal orang yang tepat, dan dalam beberapa bulan berikutnya lebih banyak talenta inti pergi
    Semua orang bisa membuat kesalahan rekrutmen, tetapi cara merespons kesalahan itulah yang menentukan nasib perusahaan
  • Setelah 25 tahun menjalani peran IC dan manajemen secara bergantian, saya yakin tidak ada pengganti untuk keahlian, kedewasaan, dan penilaian yang baik
    Kita bisa menyebut aturan praktis seperti “IC harus diberi otonomi sebesar mungkin yang masih bisa mereka tangani”, tetapi setiap aturan punya pengecualian. Kebijaksanaan yang dipadatkan kehilangan konteks dan mudah disalahartikan, atau ditiru secara cargo cult oleh orang yang kurang berpengalaman
    Saya pernah melihat dinamika kecil yang muncul dari perbedaan halus dalam kepribadian individu dan struktur organisasi, meski semua orang berniat baik dan berusaha sebaik mungkin, berujung pada disfungsi besar dan hilangnya produktivitas. Engineering yang baik tidak bisa dicapai dengan perintah dari atas dan perencanaan terpusat
    Harus ada cukup banyak orang yang memahami produk dan bisnis sampai tuntas, termasuk engineer di lapangan, agar keputusan-keputusan kecil bisa dibuat selaras dengan gambaran besar dan kekhawatiran yang tepat bisa naik ke leadership. Biaya jangka pendek dan jangka panjang dari produk, desain, legal, keuangan, support, security, dan operasi harus ditimbang bersama
    Ini hanya mungkin jika ada tingkat kepercayaan dan rasa aman yang tinggi sehingga para ahli bisa menyampaikan pendapat dan menemukan kompromi yang tepat. Ego dan benturan kepribadian mudah menghalanginya, jadi dibutuhkan kedewasaan leadership. Analogi menegakkan pensil di atas ujungnya cukup tepat
  • Tambahan satu hal lagi: masalah serupa juga muncul ketika merekrut orang hebat dari luar dan menempatkannya di peran arsitek atau principal
    Orang itu mulai meninjau aplikasi dan menyebut semua keputusan yang tidak ia punya konteksnya sebagai technical debt. Saya sudah beberapa kali melihatnya, dan pernah mengatakan kepada VP Engineering baru bahwa menyebutnya keputusan buruk, padahal ia tidak ada saat masalah, keputusan, dan jadwal aslinya terjadi, membuatnya terlihat tidak paham
    Untungnya, kemudian ia memanggil saya secara terpisah, berterima kasih, dan menanyakan lebih banyak latar belakang. Setelah mendengar keseluruhan cerita, ia setuju bahwa kami telah membuat pilihan yang tepat. Namun saya juga pernah melihat kasus yang berjalan sebaliknya, dan ketika itu terjadi, rasanya sangat berat
  • Saya sangat setuju soal pemimpin yang terlalu teknis. Beberapa kali saya melihat engineer hebat diberi tanggung jawab atas 50 tim, lalu mereka hanya mencoba “menskalakan” apa yang dulu mereka lakukan di satu tim
    Mereka memasukkan semua tim ke spreadsheet dan mencoba mengotomatiskan manajemen dengan metrik seragam, bukannya fokus mengelola dan mengembangkan orang-orang yang melapor langsung kepada mereka
    Sebaliknya, saya pernah melihat pemimpin yang kurang teknis datang dan para engineer di sekitarnya memutar mata dengan sedikit campuran sikap male chauvinist. Namun pada kenyataannya, ia mengeluarkan rekrutan buruk, merekrut pemain bintang, menyelaraskan prioritas semua orang, dan membuat mereka produktif. Leadership adalah pekerjaan yang sepenuhnya berbeda dari keunggulan teknis, dan kemampuan yang seharusnya terlalu sering dihargai dengan kenaikan gaji atau bonus justru dihargai dengan promosi
  • Saya pernah melihat pendekatan yang tidak mengasumsikan bahwa orang berusia 35 tahun ke atas tidak cocok untuk startup ternyata berhasil
    Orang yang punya pengalaman leadership tetapi tetap punya kemampuan praktis, dan jika diberi waktu yang cukup dapat memahami detail stack teknologi baru atau manuver finansial, bisa dihormati oleh para superstar di lapangan melalui kontribusi leadership jangka panjang

• Tidak setuju. Saya pernah memulai perusahaan kecil dan juga bekerja di perusahaan raksasa, termasuk FAANG dan bank besar, tetapi lingkungan yang imersif seperti itu bisa diciptakan di mana saja
  Kuncinya adalah pemimpin yang dinamis membentuk tim yang benar-benar tahu mengapa orang-orang berada di sana, menugaskan tiap orang pada hal yang mereka kuasai, dan membuat orang yang ahli membantu pada hal-hal yang tidak mereka kuasai. Setelah itu, harus dijelaskan dengan gamblang apa nilai misi tim bagi misi perusahaan dan tujuan perusahaan di dunia, lalu secara gigih menyingkirkan hambatan yang menghalangi produksi dan dampak
  Klaim seperti komunikasi N² itu reduksionis dan tidak akurat. Tidak ada tim yang bergantung pada semua tim dalam organisasi; biasanya domainnya kecil dan tim yang berdekatan pun terbatas. Tim inti adalah pengecualian, tetapi tim inti yang berfungsi baik bertindak seperti titik fokus, bukan overhead N², sehingga menjadi struktur N tempat tim-tim datang mencari bantuan
  N memang bisa besar, jadi penyaringan yang efektif, otomatisasi, self-service, platform konsisten yang terdokumentasi dengan sendirinya, serta anggota tim yang benar-benar suka mengajar menjadi penting. Membentuk tim seperti ini sangat melelahkan dari sisi manajemen hingga saya kehabisan tenaga, tetapi manajemen memang seharusnya sangat sulit. Untuk pekerjaan berikutnya, saya akan kembali ke akar untuk sementara sebagai distinguished engineer di startup tahap lanjut

  • Saya tidak setuju bahwa “semua klaimnya salah”, karena saya pernah mengalami persis hal yang digambarkan penulis
    Namun benar bahwa lingkungan yang imersif seperti itu bisa diciptakan di mana saja, dan pemimpin dinamis yang membentuk tim yang tahu mengapa orang-orang ada di sana memang penting. Meski begitu, menurut saya tetap ada kaitannya dengan skala dan insentif yang buruk. Saya pernah dengar bahwa bahkan di FAANG, sebagian divisi terasa seperti startup sementara divisi lain adalah kebosanan yang menyedot jiwa
  • Saat ini saya adalah engineering IC paling senior dari sisi level dan pengalaman di organisasi engineering dengan lebih dari 100 orang, dan semua masalah yang saya tangani adalah masalah nonteknis dan organisasi. Padahal di atas kertas saya seharusnya menghabiskan 30% waktu untuk coding
  • Menyebut klaim komunikasi N² sebagai “reduksionis dan konyol” rasanya terlalu kasar dan tidak perlu dalam merangkum argumen tulisan itu. Saya pernah mengalami pola kegagalan persis seperti itu di startup
    Contoh tandingan yang Anda berikan bukanlah contoh bahwa kompleksitas N² tidak ada, melainkan contoh bahwa kompleksitas itu dikelola dengan benar
  • Tulisan itu mengatakan, “Anda tidak bisa begitu saja melakukan apa pun yang Anda mau. Koordinasi akan menjadi kekacauan komunikasi O(N²)”
    Kalau Anda mengatakan tidak semua tim bergantung pada semua tim lainnya, justru itu berarti Anda setuju dengan tulisannya. Jadi saya tidak paham bagian mana yang menurut Anda salah
  • Saya setuju dengan ini. Kalimat pertama tulisan itu terlalu sederhana dan tidak akurat. Sebagian besar pekerjaan di perusahaan besar memang bisa cukup membosankan, tetapi dalam kondisi yang tepat, api itu bisa dinyalakan kembali

• Efisiensi skala yang konon didapat dari organisasi besar terasa seperti sebenarnya bukan efisiensi. Maksud saya efisiensi berupa memiliki tenaga spesialis untuk perekrutan, HR, quality assurance, riset pengguna, dan sebagainya
  Alih-alih membuat struktur organisasi yang lebih “efisien”, mungkin lebih baik menumbuhkan organisasi dengan berulang kali mereplikasi tim terkecil yang pernah berjalan efektif. Namun, bagaimana “perusahaan mini” seperti itu berkomunikasi secara efisien satu sama lain adalah masalah lain lagi

  • Menurut saya ini bukan hanya soal efisiensi skala. Setelah mencapai skala tertentu, aturan main berubah bukan hanya berdasarkan jumlah karyawan, tetapi juga berdasarkan pendapatan, dan tiba-tiba perusahaan mendapat jauh lebih banyak pengawasan regulasi
    Ketika nilai perusahaan naik dan pemegang saham serta manajer yang lebih rendah toleransi risikonya masuk, perusahaan harus menghabiskan banyak uang untuk manajemen dan penghindaran risiko. Di perusahaan saya sebelumnya, pesaing secara terang-terangan melanggar hukum demi memenuhi kebutuhan pengguna, tetapi tampaknya lolos begitu saja karena mereka kecil dan tidak menghasilkan banyak pendapatan
    Selain itu, dari pengalaman pribadi, sebagian besar karyawan tidak menginvestasikan energi sebesar pendiri, dan itu sepenuhnya bisa dimengerti. Makin kecil rasio pendiri terhadap karyawan, makin besar kemungkinan Anda mempekerjakan tiga orang agar pekerjaan yang bisa Anda lakukan sendiri selesai dengan stabil dan tepat waktu
    Karyawan awal dekat dengan pendiri dan punya lebih banyak hal yang bisa diperoleh jika perusahaan sukses, sehingga lebih mirip pendiri; tetapi karyawan ke-213 menjual kerja 40 jam per minggu dan pada dasarnya hanya mendapat gaji tetap. Ide romantis tentang perusahaan besar yang terdiri dari banyak startup independen memang bagus, tetapi saya belum pernah melihatnya benar-benar berhasil dan sulit membayangkannya
  • Mereplikasi tim itu mustahil. Tim adalah kumpulan individu, jadi ini mirip mengatakan bahwa untuk menang Piala Dunia, kita cukup mereplikasi tim terbaik
    Menurut saya cara terbaik untuk berkembang adalah membuat proses yang memperkuat karakteristik yang diinginkan dalam tim, dan merekrut manajer yang memahami bahwa tim adalah kumpulan individu yang berbeda-beda. Manajer harus bebas mengelola orang-orangnya dengan cara yang mengoptimalkan delivery dan mengurangi churn
    Di antara tim, standar komunikasi dan kualitas hasil kerja harus sangat tinggi, dan budaya organisasi harus dibangun di atas rasa hormat terhadap tiap individu yang direkrut serta fokus yang gigih untuk menempatkan tiap orang di tim tempat mereka bisa bekerja efektif
  • Saya setuju dengan pendekatan ini, dan pernah melihatnya berjalan baik di beberapa perusahaan. Namun, menurut saya ada masalah yang lebih besar yang anehnya sama sekali tidak dibahas penulis, dan itu ikut berkontribusi pada hilangnya “api”
    Buah dari kerja makin lama makin tergantung semakin tinggi. Pada tahap awal startup, ruang masalah melimpah, dampak yang bisa diciptakan individu luar biasa besar, dan jumlah orang yang harus berbagi hasilnya paling sedikit
    Ketika perusahaan membesar, ketiga unsur itu semuanya tertekan. Ruang masalah menjadi semakin langka, pengakuan atas dampak besar makin banyak diambil oleh pihak yang lebih tinggi dalam hierarki, jumlah orang yang berbagi dampak bertambah, dan pengakuannya menjadi singkat serta kabur
  • Studio game mobile Supercell melakukan itu pada masa awalnya. Sesuai namanya, perusahaan itu dibagi menjadi beberapa studio indie beranggotakan 15–25 orang
    Namun pada akhirnya tetap menjadi satu organisasi raksasa. Struktur organisasi datar Valve juga mirip. Jika sudah cukup besar, apa pun pada akhirnya akan menggumpal
  • Menambah orang dan peran bermanfaat ketika itu membebaskan orang lain dari pekerjaan yang berat dan mengganggu fokus. Sebaliknya, itu menjadi masalah jika malah menambah pekerjaan berat dan mengganggu fokus bagi semua orang
    Seni mengelola pertumbuhan sebagian besar terletak pada menemukan cara untuk membebaskan orang, bukan membelenggu mereka

• Kalimat “Sebagian besar startup mempercepat proses menjadi korporat secara tidak perlu dengan meniru proses perusahaan besar. Biasanya mereka mendatangkan manajer dari perusahaan besar, dan para manajer itu membawa playbook mereka sendiri” terasa menyakitkan karena sangat tepat

  • Tidak ada yang berhenti sejenak untuk berpikir, “Apakah perusahaan itu melakukan hal tersebut karena memang efektif, atau karena itu inefisiensi yang bisa mereka tanggung karena mereka besar?”

• Saya sudah beberapa kali mengalami siklus ini. Startup yang paling saya sukai dan terakhir yang sukses diakuisisi oleh perusahaan global raksasa pada 2007, tahun keempatnya, dan saya bertahan 2 tahun lagi.
  Setelah produk diluncurkan, jelas kecepatannya melambat karena kebutuhan dukungan pelanggan dan dukungan penjualan. VP Engineering yang hebat menjadi CTO, lalu ketika mereka mengangkat orang manajemen menengah yang bodoh sebagai VP, masa-masa indah pun berakhir. VP baru itu merekrut “team player” alih-alih engineer yang bagus, memberi penghargaan pada loyalitas ketimbang kemampuan, dan hal-hal konyol mulai terjadi.
  Waktu saya yang terasa seperti startup yang menyenangkan menyusut menjadi tepat satu minggu dalam setahun, di antara Natal dan Tahun Baru. Pada minggu itu tidak ada siapa-siapa, sehingga saya jauh lebih bebas mengerjakan hal yang saya anggap penting, dan bisa membuat versi alfa dari fitur baru yang berkilau lalu membuat organisasi ikut mengejarnya.

  • Pelajaran tersulit yang saya dapat setelah naik ke jajaran pimpinan senior adalah bahwa merekrut manajemen menengah itu luar biasa sulit.
    Di kumpulan kandidat ada jumlah orang bertipe hiu yang mengejutkan. Mereka muncul, mendeteksi bahwa Anda masih baru, mengatakan semua hal yang ingin Anda dengar, dan berjanji menyelesaikan semua masalah. Mereka mengaku sudah melakukan persis hal yang Anda butuhkan di setiap perusahaan sebelumnya, menyanjung Anda, dan berkata mereka sudah menunggu kesempatan bekerja dengan orang seperti Anda.
    Anggap saja mereka versi lima kali lebih kuat dan lebih sulit dibaca daripada kandidat IC paling licin yang pernah Anda wawancarai. Mereka punya karisma yang sulit dipercaya, tetapi tidak terlalu berniat melakukan pekerjaan sulit; setelah menyusup ke perusahaan, mereka berusaha mengeruk apa yang bisa diambil.
    Mereka mengeruk kompensasi untuk diri sendiri, headcount untuk mempekerjakan teman, kompensasi untuk teman-teman mereka, kontrak menguntungkan untuk teman-teman outsourcing, bahkan mungkin ada kickback. Karena mereka menciptakan banyak aktivitas, bisa butuh bertahun-tahun sampai orang menyadari bahwa sebenarnya tidak banyak yang mereka kerjakan. Dalam prosesnya, karyawan yang kompeten bisa pergi karena muak dengan omong kosong, atau tersingkir karena menunjuk ketidakmampuan mereka.

• Loonshots karya Safi Bahcall menjelaskan fenomena ini dengan cukup baik. Di sekitar 150 orang, terjadi “transisi fase” dalam insentif, dan ini bisa fatal bagi banyak organisasi.
  Kuncinya adalah bagaimana startup melewati jumlah orang ini. Terus terang, banyak perusahaan software mungkin tidak membutuhkan lebih dari 150 orang.

  • Angka Dunbar juga layak dijadikan rujukan.
    Angka Dunbar adalah konsep yang diusulkan sebagai batas kognitif jumlah orang yang dapat mempertahankan hubungan sosial yang stabil. Hubungan di sini berarti mengetahui siapa tiap orang, dan bagaimana mereka saling terhubung.
    https://en.wikipedia.org/wiki/Dunbar%27s_number
    Dunia sudah berkembang melampaui batas ini ribuan tahun lalu, dan perusahaan pun bisa berkembang melampauinya.
  • Barbarians to Bureaucrats karya Miller juga menjelaskan seluruh siklus hidup perusahaan. Urutannya adalah barbar → pembangun → penjelajah → administrator → birokrat → aristokrat.
  • Ini adalah logika yang menguntungkan organisasi yang tetap dekat dengan bisnis inti dan bersedia menanggung biaya outsourcing untuk fungsi non-inti.
  • Ketika orang mengatakan “100 orang” atau “150 orang”, saya penasaran apakah biasanya yang dimaksud adalah ukuran seluruh perusahaan, atau jumlah orang di engineering dan produk.

• Nilai dari anjuran rekrut lebih sedikit tidak bisa terlalu ditekankan. Dengan kata lain, rekrut hanya ketika tidak ada cara lain untuk menyelesaikan masalah, dan bahkan saat itu pun harus hati-hati.
  Karena prinsip ini, Anda harus siap menerima jadwal yang menjadi jauh lebih panjang. Biaya jangka menengah-panjang dari overhiring jauh lebih buruk daripada biaya keterlambatan rilis. Sayangnya, lingkungan pendanaan startup dan ekspektasi pertumbuhan sering mendorong perilaku sebaliknya.

  • Dari sudut pandang orang Kanada, khususnya Quebec, menarik melihat kesadaran seperti ini muncul di Silicon Valley. Secara historis, Quebec punya masalah karena pendanaan untuk perusahaan kecil datang dari sumber yang mensyaratkan komitmen rencana perekrutan. Misalnya, Anda harus berjanji merekrut 50 orang dalam 2 tahun agar mendapat uang, dan ini menghasilkan kegilaan total; tidak mengherankan jika exit yang sukses juga kurang banyak.
    Namun saya memang cukup meremehkan seberapa buruk situasi perekrutan startup Silicon Valley telah menjadi. Banyak orang menggunakan startup sebagai tempat untuk dicantumkan di CV sambil memulihkan diri dari burnout FAANG atau menyiapkan wawancara.
    Dalam struktur seperti ini, hiring manager mudah menjadi terlalu optimistis karena takut melewatkan segelintir orang yang benar-benar bisa membangun perusahaan. Pada akhirnya, orang yang tidak cocok perlu dikeluarkan secara agresif.

• Ada bagian dari tulisan ini yang saya suka dan ada bagian yang tidak saya setujui.
  Bagian yang paling saya setujui adalah “jangan merekrut terlalu cepat”. Saya sulit memikirkan startup atau perusahaan yang gagal atau menderita karena perekrutan terlalu lambat, tetapi ada sangat banyak masalah yang muncul karena perekrutan terlalu cepat, termasuk dari pengalaman pribadi.
  Sebaliknya, bagian “jangan pakai Jira” membuat saya memutar mata. Seperti matahari terbit dari timur, mengkritik Jira adalah hobi favorit para engineer. Bergantung pada jenis startup, Jira bisa menjadi alat yang sangat bagus untuk pekerjaan itu.
  Jika perusahaan memiliki banyak workflow yang harus didukung, maka ketika pelacakan buruk dan kepemilikan isu tidak jelas, banyak hal bisa terlewat dan waktu terbuang besar. Tentu saja, jika Anda membuat sejuta status yang tidak perlu dan membuat Jira terlalu rumit, waktu juga mudah terbuang; tetapi menurut saya Jira sekarang sudah menjadi cukup mudah dipakai oleh tim kecil agar cepat produktif.
  Bukan berarti Jira adalah alat terbaik untuk memulai; startup saya sebelumnya memulai dengan Trello dan berjalan baik. Namun ketika sudah masuk operasi dan harus mengelola serta memprioritaskan banyak isu operasional bersamaan dengan pengembangan fitur baru, kemungkinan besar Anda akan membutuhkan alat seperti Jira untuk menyelaraskan semua orang dan berbagi informasi.

  • Bagian “jangan pakai Jira” juga membuat saya bingung. Kalau begitu, saya penasaran apa alternatif yang memungkinkan perusahaan dinosaurus “beroperasi seperti startup”.