Akhir-akhir ini, saya terus merenungkan dua topik yang memiliki tema serupa. Topik pertama berkaitan dengan infrastruktur publik negara bagian California dan betapa tidak efisiennya infrastruktur itu selama bertahun-tahun. Yang kedua adalah kegagalan perusahaan teknologi besar untuk berinovasi dan mengeksekusi lebih cepat daripada pemain lama startup. Izinkan saya memberikan beberapa perspektif tentang mengapa topik ini terkait dengan terlebih dahulu memberi Anda dua contoh untuk dipikirkan:

• Infrastruktur : Jembatan Golden Gate membutuhkan waktu sekitar empat tahun untuk dibangun (1933–1937) dan menghabiskan biaya ~$500 juta dalam dolar saat ini. Sebaliknya, SDS ( Suicide Deterrent System ), yang pada dasarnya menambahkan jaring di sekitar jembatan, akan membutuhkan waktu lima tahun untuk diselesaikan (2017–2023) dan diproyeksikan menelan biaya ~$217 juta. Jika Anda meninjau proyek-proyek infrastruktur besar di California, Anda akan menemukan bahwa untuk proyek-proyek yang diselesaikan sebelum tahun 1950-an pekerjaan dilakukan lebih cepat, lebih murah, dan dengan kualitas lebih tinggi daripada yang dilakukan hari ini dengan setidaknya 5x lipat, meskipun hari ini kami memiliki lebih banyak modal, teknologi yang lebih baik, bahan baku yang lebih baik, dan jumlah absolut insinyur sipil dan arsitek yang lebih tinggi.
• Perusahaan Teknologi : Adobe, terlepas dari semua sumber daya keuangan dan manusianya, mendapati dirinya harus mengakuisisi pesaing seharga $20 miliar. Apakah Adobe membayar lebih untuk Figma masih harus dilihat, tetapi pertanyaan yang lebih menarik adalah mengapa perusahaan dengan 100x personel, 100x kedalaman pengalaman dalam perkakas desain, dan 100x modal finansial gagal menang?

Demikian pula, jika Anda melihat ke dalam perusahaan, Anda mungkin menemukan bahwa ketika mereka tumbuh, proses dan pembengkakan merayap menjadi apa saja dan menghambat kerja nyata dan inovasi. Dalam lingkungan itu, karyawan yang paling bersemangat untuk menciptakan sesuatu, para pembuat, menemukan bahwa lebih menarik untuk melompat ke tempat yang lebih kecil di mana pekerjaan mereka memiliki jalan keluar untuk terwujud. Kegagalan infrastruktur dan kegagalan inovasi perusahaan setidaknya sebagian disebabkan oleh kembung dan proses merayap.

Mengapa proses creep terjadi?

Setiap proses dimulai dengan niat baik.

• “Kami ingin memastikan semua pemangku kepentingan memiliki masukan untuk pekerjaan akhir, sehingga semua proposal proyek yang diajukan perlu ditinjau oleh tim hukum, desain, produk, dan teknik.”
• “Kami ingin memastikan bahwa proyek infrastruktur besar tidak menimbulkan kerugian, jadi kami perlu melakukan studi lingkungan secara menyeluruh sebelum pekerjaan apa pun dimulai.”
• “Kami ingin meminimalkan pelanggaran data, sehingga setiap permintaan data harus dilakukan melalui tim IT dan Keamanan.”

Jalan menuju perfeksionisme

Saya ingat pernah mendengar seorang manajer yang bermaksud baik memberi tahu bawahan langsungnya untuk menulis perangkat lunak seolah-olah itu akan bertahan 100 tahun. Meskipun ucapannya hiperbolik, nasihatnya menggemakan sesuatu yang sering saya dengar di industri teknologi melalui pepatah seperti "ukur dua kali dan tulis sekali" atau "jika Anda tidak punya waktu untuk melakukannya dengan benar, apakah Anda punya waktu untuk melakukannya? dua kali?.” Ini bukan saran yang buruk. Dalam beberapa situasi, Anda harus menulis kode seolah-olah itu akan bertahan 100 tahun, dan melakukan eksekusi tanpa perencanaan adalah pemborosan. Meskipun demikian, penekanan ekstrim pada perencanaan dapat menyebabkan kelumpuhan dan kegagalan untuk mengenali manfaat belajar melalui iterasi. Saya lebih suka hidup di dunia di mana perangkat lunak ditulis ulang setiap tahun karena ada pengakuan kuat bahwa kesempurnaan tidak ada dan prasyarat untuk evolusi adalah perubahan, daripada dunia di mana segala sesuatunya berjalan pada " basis kode berusia 50 tahun ."

Terlalu banyak lem

Bertahun-tahun yang lalu saya membaca postingan blog Tanya Reilly tentang Menjadi Lem (sangat disarankan untuk dibaca, btw). Pada saat itu dalam karir saya, kontennya benar-benar bergema karena saya berurusan dengan beberapa kolega yang meskipun kompeten secara teknis, tidak mengerjakan hal yang benar. Lem orang terlibat dalam proses kepemimpinan teknis dan bimbingan yang mengarah pada membuat orang lain dalam tim lebih produktif. Sejumlah lem diperlukan, namun, saya menemukan bahwa terlalu banyak lem menciptakan serangkaian masalah lain:

• Orang-orang yang melakukan pekerjaan lem mencegah orang lain meningkatkan keterampilan non-teknis mereka. Misalnya, Tech Lead yang tidak membiarkan timnya berbicara tentang pekerjaan mereka atau sering bertindak sebagai "penyangga" pada dasarnya mengambil peluang dari IC untuk berjuang dan pada akhirnya meningkatkan keterampilan komunikasi mereka.
• Versi ekstrim dan beracun dari perilaku lem kadang-kadang bermanifestasi dalam mengambil pujian atas pekerjaan orang lain atau menghasilkan atribusi yang terlalu dilebih-lebihkan (“misalnya, tanpa saya bertindak sebagai perantara, proyek tidak akan berhasil”). Sementara Tanya berbicara tentang situasi di mana orang Lem sering tidak diakui, pengalaman saya justru sebaliknya. Karena orang Glue adalah komunikator yang baik, mereka tahu cara mengiklankan karya mereka dan bermain politik dengan baik. Sebagai imbalannya, mereka berakhir dengan visibilitas yang lebih tinggi dan lebih banyak peluang promosi, sementara insinyur yang bekerja pada detail implementasi sering kali mendapat pengakuan token atau tidak mendapat kredit sama sekali.
• Terakhir, menambahkan terlalu banyak lem akan mengurangi rasa kepemilikan dan akuntabilitas bagi masing-masing insinyur. Alih-alih menambahkan orang lem untuk mengelola tim yang kompeten secara teknis, saya akan melepaskan insinyur yang tampaknya tidak memiliki intuisi bisnis, kurang keterampilan komunikasi, atau tidak dapat menyusun paragraf yang menjelaskan mengapa pekerjaan yang mereka lakukan berdampak. Menyarankan bahwa Anda membutuhkan lebih banyak lem untuk mengelola insinyur pada akhirnya mengabaikan pola umum bahwa orang-orang yang secara teknis brilian juga memiliki kecerdasan umum tingkat tinggi, banyak membaca, pembelajar seumur hidup, dan sangat pandai dalam bisnis dan bukan hanya kode.

Ketika saya di Novell, saya mengetahui bahwa ada orang yang saya sebut "orang lem". Orang lem adalah orang yang sangat baik yang duduk di batas antar kelompok, dan mereka membantu dalam aktivitas. Dan mereka sangat, sangat setia, dan orang-orang menyukainya, dan Anda tidak membutuhkan mereka sama sekali.

Di Novell, saya terus berusaha menyingkirkan orang-orang lem ini, karena mereka menghalangi, karena mereka memperlambat semuanya. Dan setiap kali saya menyingkirkan mereka di satu grup, mereka akan muncul di grup lain, dan mereka akan dipindahkan, dan dipekerjakan kembali, dan sebagainya.

Entropi

Seiring pertumbuhan organisasi, pengetahuan kelembagaan, jumlah pemangku kepentingan, basis kode, dan entropi meningkat. Entropi yang meningkat menyebabkan pemborosan yang tinggi, beban kognitif yang tinggi, disorganisasi, dan kekacauan.

Sebagai insinyur perangkat lunak, saya pikir kami telah melakukan pekerjaan yang buruk dalam mengelola kompleksitas. Misalnya, selama bertahun-tahun kami telah mendengar bahwa monolit itu buruk karena menghasilkan basis kode yang membengkak, mempersulit penerapan, atau menimbulkan masalah dengan skalabilitas. Namun di sisi ekstrim lainnya, di mana kita harus beroperasi di dunia layanan mikro, saya menemukan bahwa untuk mengirimkan hal-hal dasar yang saya perlukan untuk beroperasi di beberapa basis kode yang ditulis dalam bahasa berbeda, masing-masing memiliki kebiasaan penyebaran dan pola arsitektur, dengan keseluruhan paradigma berubah menjadi spageti lambda . Menghentikan dan memfokuskan kembali pada hal yang penting berdampak besar pada pengurangan entropi. Pada tingkat yang rendah dan berorientasi pada tindakan, hal itu dapat bermanifestasi sebagai berikut:

• Menghapus kode mati yang tidak dieksekusi dalam produksi. Saya telah berinteraksi dengan begitu banyak basis kode di mana >50% kodenya adalah kode mati dan membuat beban kognitif untuk rekan kerja. Saya berharap ada sesuatu di ruang produktivitas dev yang menghasilkan cakupan kode berdasarkan baris yang dieksekusi dalam produksi. Setiap kuartal Anda berhenti dan meninjau laporan tersebut dan cukup menghapus file yang tidak memiliki eksekusi.
• Sebagai manajer produk, kami tidak cukup memikirkan fitur apa yang harus kami matikan atau kembalikan. Namun berhenti dan merenungkan apa yang harus dihapus bisa sangat berarti dalam menyederhanakan dan meningkatkan pengalaman pengguna. Saya menganggap diri saya paham teknologi, namun saya menemukan bahwa banyak produk yang dibuat hari ini telah dioptimalkan secara berlebihan pada kumpulan pengguna yang ada, yang mengarah ke pengalaman UX yang berantakan dan membingungkan bagi pengguna baru. Menanyakan di akhir kuartal "Fitur apa yang dapat kami batalkan pengirimannya?" dapat berguna untuk mengurangi kekacauan.

Ego adalah musuh

Ryan Holiday menyarankan dalam bukunya Ego is the Enemy, ada "godaan yang kuat yang ada untuk semua orang - untuk berbicara dan hype untuk menggantikan tindakan." Ego adalah alasan utama mengapa kemajuan dan inovasi bisa menjadi kurang bersemangat di banyak institusi. Inilah bagaimana ego memanifestasikan dirinya:

• Melihat orang yang sama sangat ingin menyampaikan pemikiran mereka ke dalam percakapan kelompok, meskipun ide mereka tidak menambah atau sangat sedikit nilai marjinal.
• Memiliki orang-orang yang tidak pernah terlibat secara aktif mensponsori kolega mereka atau yang mencoba menimbun visibilitas. Jika Anda seorang manajer atau manajer dari manajer, Anda dapat melihat ini dengan melihat seberapa sering bawahan langsung Anda berbicara tentang keberhasilan atau kontribusi orang lain dalam 1:1 Anda. Kurangnya pengakuan atau sponsor tanpa pamrih dari orang lain bisa menjadi tanda ego yang tidak sehat.
• Mengoptimalkan tim, bukan keseluruhan perusahaan atau organisasi. Saya meminjam diagram dari Staff Engineer's Path oleh Tanya Reilly dan dengan sempurna mencontohkan masalah ini di mana tim mengoptimalkan maksimum lokal. Misalnya, apakah Anda boleh membubarkan tim Anda dan mendistribusikan kembali karyawan ke tim lain jika dalam domain Anda, Anda memasuki mode pemeliharaan? Kebanyakan manajer tidak akan pernah melakukan itu karena itu berarti kehilangan modal sosial dan politik di dalam perusahaan.

• Tergantung pada peran Anda, ada dikotomi yang sangat kuat dalam hal cara Anda memandang nilai rapat. “ Orang yang paling berkuasa ada dalam jadwal manajer ”. Sayangnya, persepsi mereka tentang nilai pertemuan menciptakan perubahan budaya yang memengaruhi orang-orang yang lebih suka memiliki waktu tanpa gangguan untuk memikirkan masalah dan solusinya. Bahkan untuk tujuan brainstorming, bukti menunjukkan bahwa brainstorming kelompok hanya membuang-buang waktu . Namun mengapa begitu banyak organisasi yang membengkak berakhir dengan setengah dari waktu IC dihabiskan untuk rapat?

Kesimpulan

Mesin inovasi bergantung pada perubahan evolusioner. Pada akhirnya, jika sebuah institusi menjadi kaku dan tidak beradaptasi dengan perubahan, ia akan mati secara perlahan. Dalam pengalaman saya, memperkenalkan suatu proses seringkali memiliki biaya yang tidak diinginkan yang menyebabkan berkurangnya kecepatan. Sebaliknya, saya akan fokus pada hal-hal berikut:

• Menyukai iterasi dan belajar dari kesalahan alih-alih mencoba mencapai perfeksionisme.
• Merekatkan orang memang diperlukan, tetapi harus ada batasan jumlah mereka, sehingga mereka dapat bertindak dengan daya ungkit yang tinggi. Cukup mempekerjakan orang-orang yang kompeten secara teknis dan memiliki intuisi bisnis yang baik dapat mengatasi kebutuhan akan perekrutan yang berlebihan untuk peran perekat.
• Terakhir saya akan fokus pada pengurangan entropi dengan terus-menerus menanyakan apa yang dapat dibuang dan memberi penghargaan kepada orang-orang atas perilaku yang meningkatkan kesederhanaan.