Leadership Styles of Legends

Peran: Chief Scientist di ThoughtWorks sejak 2000 (bergabung 1999)
Buku penentu: Refactoring: Improving the Design of Existing Code (1999), Patterns of Enterprise Application Architecture (2002), Microservices (co-authored bersama James Lewis, 2014)
Platform: martinfowler.com — esai teknis otoritatif dalam format "bliki" (blog + wiki) yang dia pelopori, dipublikasikan terus-menerus sejak akhir 1990an
Agile Manifesto: Salah satu dari 17 penandatangan asli (Snowbird, Utah, 2001); menyediakan tulang punggung praktik teknis Extreme Programming
Model pengaruh: Sepenuhnya diperoleh — tanpa wewenang posisional, tidak memiliki perusahaan sendiri, tidak memimpin tim ribuan orang

Martin Fowler tidak pernah menjalankan FAANG. Dia tidak pernah mengumpulkan miliaran dolar atau memimpin organisasi ribuan orang. Dia bergabung dengan ThoughtWorks pada 1999 sebagai Chief Scientist dan tetap di sana hingga sekarang, menulis, mengkonsultasi, dan menerbitkan terus-menerus selama lebih dari 25 tahun.

Model Pengaruh Fowler Tanpa Wewenang

Model kepemimpinan di mana kredibilitas yang berkelanjutan diperoleh dengan mendefinisikan dan mengkodifikasi praktik yang sudah dilakukan bidang secara informal, menerbitkan definisi tersebut terus-menerus selama puluhan tahun, dan secara publik merevisi posisi ketika praktik melampaui teori. Wewenang berkembang melalui akurasi, bukan hierarki — dan tubuh pekerjaan itu sendiri menjadi bagan organisasi.

Namun hampir setiap tim software yang bekerja hari ini menggunakan terminologi, pola, dan praktik yang dia definisikan atau populerkan. Refactoring, praktik meningkatkan struktur kode tanpa mengubah perilakunya, adalah sesuatu yang dikerjakan developer secara diam-diam sebelum Fowler menulis buku yang memberinya nama pada 1999. Continuous integration adalah praktik terukur sebelum dia membantu menjadikannya standar. Domain models, active records, dan data mappers adalah pola arsitektural sebelum dia mengatalognya pada 2002. Dan microservices adalah kata yang hampir tidak ada sebelum dia dan James Lewis menerbitkan artikel yang mendefinisikan konsep di martinfowler.com pada 2014, memicu gelombang arsitektural yang mengubah cara industri membangun software.

Pengaruh Fowler datang sepenuhnya tanpa wewenang posisional. Dia tidak bisa membuat siapa pun melakukan apa pun. Dia memimpin melalui kejernihan pemikiran yang dipublikasikan kepada developer di seluruh dunia selama horizon waktu yang sangat panjang.

Memahami cara itu bekerja — dan di mana ia tidak — layak untuk waktu Anda apakah Anda memimpin tim 10 orang atau organisasi engineering 500 orang.

Rincian Gaya Kepemimpinan

Gaya	Bobot	Cara Ditampilkan
Praktisi-Cendekiawan	55%	Kredibilitas Fowler berasal dari kombinasi pengalaman development hands-on dan dokumentasi ketat. Dia tidak menulis teori dalam isolasi dari departemen universitas. Dia bekerja pada proyek nyata dengan klien nyata dan mengekstrak pola yang muncul berulang kali. "Refactoring" didasarkan pada teknik terdokumentasi yang dia dan kolega terapkan dalam engagement konsultasi. "Patterns of Enterprise Application Architecture" mengatalog pola yang dia amati di puluhan sistem enterprise. Fondasi praktisi adalah apa yang membuat scholarship mencapai orang-orang yang harus menulis kode setiap hari.
Pembangun Infrastruktur Intelektual	45%	Kontribusi kedua Fowler adalah menciptakan kosakata bersama. Sebelum "refactoring" adalah praktik bernama, tim berbicara samar tentang "membersihkan kode" atau "restrukturisasi." Setelah memiliki nama dan katalog teknik spesifik, tim bisa memiliki percakapan presisi tentang apa yang mereka lakukan dan mengapa. Hal yang sama berlaku untuk microservices: sebelum artikel 2014, arsitektur membangun layanan terdistribusi tanpa bahasa bersama yang jelas untuk mendiskusikan trade-off. Fowler memberi konsep nama dan definisi, yang memungkinkan industri memiliki argumen nyata tentang kapan microservices masuk akal dan kapan tidak.

Pembagian 55/45 menjelaskan mengapa Fowler dipelajari oleh praktisi daripada hanya strategis. Infrastruktur intelektual yang dia bangun berakar dalam praktik, yang memberikannya durabilitas berbeda dari kerangka kerja yang diciptakan jauh dari kode kerja.

Ciri-Ciri Kepemimpinan Utama

Ciri	Rating	Apa artinya dalam praktik
Dokumentasi pola ketat	Luar Biasa	Buku Fowler terkenal karena mendokumentasikan tidak hanya apa pola itu tetapi kapan menggunakannya, kapan tidak menggunakannya, dan trade-off apa yang melibatkannya. "Patterns of Enterprise Application Architecture" bukan daftar praktik baik. Ini adalah kerangka keputusan: diberikan konteks spesifik dengan batasan spesifik, berikut adalah pola yang berlaku, ini adalah biayanya, dan ini adalah apa yang Anda dapatkan. Jenis dokumentasi kontekstual ketat ini jarang dan adalah apa yang membuat buku dapat direferensikan bertahun-tahun setelah ditulis, daripada berguna hanya ketika Anda pertama kali membacanya.
Pengaruh diperoleh (tanpa wewenang posisional)	Sangat Tinggi	Fowler telah mempengaruhi praktik ratusan ribu developer tanpa pernah memiliki wewenang atas satu pun. Mekanisme murni persuasi: kualitas pemikirannya, kejernihan tulisannya, dan konsistensi keluarannya selama 25 tahun. Model itu dapat ditransfer ke pemimpin mana pun yang ingin membangun pengaruh organisasi yang tidak bergantung pada gelar mereka. Ini lambat — membutuhkan bertahun-tahun bagi Fowler untuk membangun wewenang yang membuat tulisannya saat ini langsung berpengaruh — tetapi tahan lama dengan cara yang wewenang posisional tidak.
Kadensnya publishing panjang (25+ tahun)	Tinggi	Bliki di martinfowler.com telah diperbarui terus-menerus sejak akhir 1990an. Itu adalah komitmen yang luar biasa: kebanyakan praktisi berhenti menerbitkan secara teratur setelah membuat kontribusi utama mereka. Publishing berkelanjutan Fowler berarti model intelektualnya terlihat selama horizon waktu panjang — Anda dapat melihat bagaimana pemikirannya berubah, apa yang dia pertimbangkan kembali, dan di mana dia memperbarui posisi yang dia pegang secara publik. Catatan panjang itu adalah bagian dari apa yang membuatnya dapat dipercaya: dia sudah konsisten benar cukup lama sehingga posisi baru yang dia ambil diambil dengan serius.
Kesediaan mengembangkan posisi publik	Tinggi	Fowler telah secara publik memperbarui pandangannya tentang beberapa topik utama. Dia membantu menulis Agile Manifesto pada 2001 dan telah menulis secara ekstensif tentang bagaimana Agile dirusak oleh sertifikasi dan bloat proses — pada dasarnya mengkritik industri yang terbentuk di sekitar kontribusinya sendiri. Dia menciptakan microservices dan kemudian menulis tentang "microservice premium": idenya bahwa microservices menambah kompleksitas yang tidak layak untuk sebagian besar organisasi. Dia tidak mempertahankan tubuh kerjanya sendiri. Dia mencoba mendeskripsikan keadaan praktik saat ini dengan akurat, bahkan ketika itu berarti merevisi posisi yang terkait dengan namanya.

3 Keputusan yang Mendefinisikan Martin Fowler

1. Menerbitkan "Refactoring" pada 1999

Sebelum 1999, pembersihan kode adalah praktik informal yang tidak dapat dibicarakan. Developer melakukannya, tetapi kurang kosakata, justifikasi, atau teknik sistematis. Manajer yang melihat developer "membersihkan kode lama" daripada mengirim fitur tidak memiliki kerangka untuk memahami mengapa itu berharga.

Refactoring: Improving the Design of Existing Code mengubah itu. Fowler terus mendokumentasikan praktik yang berkembang di martinfowler.com, yang telah melayani sebagai referensi praktisi selama lebih dari 25 tahun. Buku Fowler, ditulis bersama Kent Beck dan lainnya, memberi praktik nama dan mendokumentasikan 72 teknik refactoring spesifik dengan mekanika presisi: apa yang harus dilakukan, apa yang harus diperiksa sebelum melakukannya, dan seperti apa hasilnya. Ini juga mengartikulasikan hubungan antara refactoring dan testing — Anda hanya dapat dengan aman mem-refactor kode yang memiliki test, karena test adalah apa yang memungkinkan Anda memverifikasi perilaku tidak berubah.

Konsekuensi bisnis adalah bahwa tim sekarang bisa memiliki percakapan jujur tentang technical debt. Bukan "kami perlu waktu untuk membersihkan kode" — permintaan yang terdengar vague dan opsional — tetapi "kami perlu menerapkan refactorings spesifik ini sebelum menambah fitur ini, karena struktur saat ini akan membuat fitur itu mahal untuk ditest dan mahal untuk diubah." Itu adalah klaim spesifik dengan justifikasi dapat dipertahankan. Fowler memberi developer kosakata untuk membuatnya.

Edisi kedua pada 2018 memperbarui katalog untuk JavaScript modern dan pola berorientasi objek, menunjukkan bahwa Fowler masih terlibat dengan praktik saat ini hampir 20 tahun kemudian daripada menyimpan snapshot 1999.

Untuk operator hari ini, pelajaran dari "Refactoring" bukan tentang kode secara spesifik. Ini tentang nilai mendefinisikan praktik yang organisasi Anda lakukan secara informal. Setiap organisasi memiliki perilaku efektif yang bekerja tetapi tidak dinamai, didokumentasikan, atau diajarkan dengan sengaja. Saat Anda menamakannya, Anda dapat mendiskusikannya, meningkatkannya, dan memasukkan orang-orang baru kedalamnya. Itu adalah metode Fowler diterapkan ke domain apa pun.

2. Membantu Menulis Agile Manifesto pada 2001

Pada Februari 2001, 17 praktisi berkumpul di Snowbird, Utah, dan menghasilkan Agile Manifesto — dokumen empat nilai, dua belas prinsip yang mendeskripsikan cara berbeda membangun software daripada metodologi proses berat yang dominan pada waktu itu. Fowler adalah salah satu dari 17 penandatangan.

Kontribusi Fowler pada Manifesto bukan pernyataan nilai itu sendiri — itu kolektif — tetapi tulang punggung praktik teknis. Dia telah mempraktikkan dan mengajar teknik Extreme Programming (XP): test-driven development, continuous integration, pair programming, small releases. Praktik-praktik itu adalah apa yang membuat nilai Manifesto beroperasi. "Merespons perubahan atas mengikuti rencana" terdengar seperti nilai. Continuous integration dan test-driven development adalah praktik engineering yang membuat aman merespons perubahan tanpa merusak fungsionalitas yang ada.

Agile Manifesto menjadi dokumen paling berpengaruh dalam metodologi pengembangan software abad ke-21. Ini juga menghasilkan industri sertifikasi, proses, dan framework konsultasi yang Fowler kemudian menghabiskan bertahun-tahun mengkritik sebagai fundamentally bertentangan dengan maksud aslinya.

Pada 2018, Fowler co-menulis "Agile Fluency," yang secara eksplisit membedakan antara tim yang menggunakan kosakata Agile dan tim yang memiliki praktik teknis underlying yang membuat Agile berharga. Posisinya, dinyatakan dengan jelas: Scrum tanpa continuous integration dan test-driven development adalah teater. Praktiknya penting; ceremoninya sekunder. Kebanyakan organisasi mengimplementasikan ceremoni dan melewatkan praktik, itulah mengapa mereka tidak mendapat hasil yang diharapkan penulis manifesto.

3. Menciptakan "Microservices" bersama James Lewis pada 2014

Pada Maret 2014, Fowler dan James Lewis menerbitkan artikel di martinfowler.com berjudul "Microservices." Artikel mendeskripsikan gaya arsitektur software — layanan kecil yang dapat dideploy secara independen yang berkomunikasi melalui API — yang tim di Netflix, Amazon, dan ThoughtWorks telah membangun tanpa nama bersama.

Artikel mendapat nama yang tepat, trade-off sebagian besar tepat, dan kurva adopsi secara dramatis salah. Apa yang diikuti adalah gelombang arsitektural yang menyapu industri, dengan ribuan perusahaan membangun kembali aplikasi monolitik mereka sebagai ekosistem microservices. Ekosistem Docker dan Kubernetes yang muncul secara paralel membuat microservices secara teknis praktis pada skala jauh lebih besar daripada yang mungkin sebelumnya.

Fowler dan Lewis mendeskripsikan pola dengan akurat. Tetapi menamai sesuatu menciptakan permintaan untuk menerapkannya di mana-mana, termasuk tempat di mana itu tidak cocok. Werner Vogels di Amazon telah membangun model layanan terdistribusi dari dalam ke luar — operasional, pada skala — sementara Fowler mendefinisikannya secara konseptual, dan kesenjangan antara batasan produksi yang diperoleh dengan berat Vogels dan adopsi industri konsep tanpa batasan itu menjelaskan banyak kegagalan microservices yang diikuti. Microservices menambah overhead nyata: latensi jaringan antar layanan, kompleksitas distributed tracing, infrastruktur service discovery, dan beban operasional menjalankan puluhan sistem yang dideploy secara independen daripada satu. Untuk tim 5 engineer mengirim produk yang belum perlu penskalaan, overhead itu mahal relatif terhadap manfaat.

Fowler kemudian menulis tentang apa yang dia sebut "microservice premium" — pengamatan bahwa microservices hanya membayar pada skala dan ukuran organisasi yang kebanyakan tim tidak miliki. Dia juga menulis "MonolithFirst," berdebat bahwa tim harus mulai dengan monolith dan ekstrak microservices ketika mereka memahami batasan mana yang benar-benar stabil. Itu adalah revisi signifikan dari narasi yang diciptakan artikel 2014, dan ini mencerminkan kesediaan Fowler untuk melakukan koreksi jalur bahkan ketika koreksi bertentangan dengan pekerjaannya sendiri yang berprofil tinggi.

Apa yang Martin Fowler Lakukan dalam Peran Anda

Jika Anda adalah CEO, prinsip refactoring berlaku untuk proses organisasi. Setiap organisasi mengakumulasi process debt: approval workflows dirancang untuk masalah yang tidak lagi ada, struktur reporting yang masuk akal pada skala sebelumnya, decision rights yang belum diperbarui sejak akuisisi dua tahun lalu. Wawasan Fowler adalah bahwa Anda tidak bisa refactor dengan aman tanpa test — mekanisme feedback yang memberi tahu Anda apakah perilaku berubah tanpa disengaja. Sebelum merancang ulang proses organisasi utama, tanyakan: apa yang setara dengan suite test di sini? Mekanisme feedback apa yang akan memberi tahu Anda apakah perubahan meningkatkan hal atau hanya mengubahnya?

Jika Anda adalah COO, pelajaran tulang punggung teknis Agile Manifesto secara langsung dapat diterapkan. Kebanyakan organisasi yang "melakukan Agile" telah mengimplementasikan ceremonial sprint — sprint dua minggu, standup harian, retrospektif — tanpa praktik engineering yang membuat ceremonial tersebut berharga. Continuous integration, automated testing, dan small frequent releases adalah apa yang membuat aman merencanakan dalam increment dua minggu tanpa mengakumulasi risiko tersembunyi. Jika tim engineering Anda melakukan sprint tetapi deployment membutuhkan minggu dan coverage test rendah, Anda mendapatkan overhead Agile tanpa manfaat. Fix bukan lebih banyak proses; itu adalah praktik teknis yang Fowler deskripsikan pada 2001.

Jika Anda adalah product leader, saran MonolithFirst Fowler layak diterapkan pada keputusan arsitektur produk. Tekanan merancang untuk skala dari hari pertama — untuk membangun arsitektur microservices sebelum Anda memiliki skala yang membutuhkannya — menghasilkan sistem yang kompleks sebelum mereka benar. Anda tidak tahu modul mana yang akan perlu diskalakan secara independen sampai Anda telah membangun produk dan melihat bagaimana benar-benar digunakan. Marty Cagan membuat argumen paralel dari sisi produk: Anda tidak tahu apa yang harus dibangun sampai Anda belajar dari pengguna, itulah mengapa investasi arsitektur prematur dan komitmen roadmap prematur gagal untuk alasan underlying yang sama. Saran Fowler: bangun hal paling sederhana yang bekerja, belajar dari produksi, dan ekstrak bagian yang perlu penskalaan independen ketika Anda memahami bagian apa itu. Arsitektur harus mencerminkan sistem yang benar-benar Anda miliki, bukan sistem yang Anda harapkan dalam tiga tahun.

Jika Anda dalam penjualan atau pemasaran, model pengaruh Fowler — mendapatkan kepercayaan melalui keluaran berkualitas tinggi konsisten selama horizon waktu panjang — lebih dapat diterapkan ke content marketing dan thought leadership daripada pendekatan eksekutif lain dalam seri ini. Dia membangun salah satu suara paling otoritatif dalam software dengan menerbitkan terus-menerus, memperbarui posisinya secara publik ketika mereka ternyata tidak lengkap, dan memprioritaskan akurasi atas engagement. Kebanyakan program content marketing dioptimalkan untuk reach. Fowler dioptimalkan untuk kepercayaan. Perbedaan berkembang selama bertahun-tahun: audiensnya membaca artikel baru karena mereka mempercayai penilaiannya dari artikel sebelumnya, bukan karena headline membuat mereka klik.

Bagaimana Rework Operasionalisasi Playbook Fowler

Leverage Fowler datang dari mengkodifikasi pola — mengambil perilaku yang tim lakukan secara implisit dan mengubahnya menjadi artefak bernama, dapat diajarkan, dapat direferensikan. Itu persis kesenjangan yang sebagian besar tim operasi alami: pengetahuan institusional tentang bagaimana deal benar-benar menutup, bagaimana onboarding benar-benar bekerja, atau bagaimana eskalasi benar-benar route hidup di kepala beberapa senior dan di tempat lain tidak ada. Peran Rework adalah menjadi katalog pola untuk operasi Anda. Pipeline stages, handoff checklists, approval flows, dan playbooks lintas-tim menjadi "Patterns of Enterprise Application Architecture" tim Anda — didokumentasikan, diversi, dan dapat direferensikan daripada tribal. Dan seperti pekerjaan Fowler, pola berkembang terbuka: ketika stage tidak lagi cocok, Anda menamakannya kembali, merevisi entri, dan seluruh tim melihat perubahan. Itu adalah ops yang digerakkan pola — pengaruh tanpa wewenang, diterapkan ke cara kerja benar-benar mengalir.

Kutipan Terkenal & Pelajaran Melampaui Ruang Rapat

Dari martinfowler.com: "Siapa pun bisa menulis kode yang bisa dipahami komputer. Programmer baik menulis kode yang dipahami manusia." Jeff Dean membangun sistem pada skala yang sedikit engineer telah sentuh, tetapi poin Fowler berlaku bahkan di sana: kendala pada tim infrastruktur Google bukan kelicikan mentah — itu apakah orang-orang yang mewarisi sistem dapat memahaminya cukup baik untuk memperluas dengan aman. Itu adalah prinsip praktisi-cendekiawan dalam satu kalimat. Kode adalah komunikasi antara orang, bukan hanya instruksi untuk mesin. Kendala dominan dalam pengembangan software berskala besar bukan apakah kode bekerja — itu apakah orang-orang yang perlu mengubahnya enam bulan dari sekarang dapat memahaminya cukup baik untuk mengubahnya dengan aman. Seluruh tubuh pekerjaan Fowler adalah elaborasi prinsip itu.

Tentang refactoring, dari pengenalan buku: "Refactoring adalah teknik terukur untuk restrukturisasi tubuh kode yang ada, mengubah struktur internalnya tanpa mengubah perilaku eksternal." Presisi definisi itu penting. "Tanpa mengubah perilaku eksternal" adalah batasan yang membuat refactoring aman. Setiap teknik refactoring dalam katalognya dirancang untuk menyimpan perilaku sambil meningkatkan struktur. Disiplin adalah apa yang membedakan refactoring dari rewriting — distinsi tim kehilangan ketika mereka menggunakan kata secara longgar.

Dia juga menulis, dalam "Is Design Dead?" pada 2000, tentang hubungan antara design dan perubahan: "Banyak hal yang kami gunakan untuk membenarkan upfront design ternyata salah dalam praktik." Itu pernyataan lebih keras daripada terlihat bagi engineer yang dilatih untuk merancang sebelum membangun. Argumen Fowler adalah bahwa design harus berkelanjutan daripada front-loaded — bahwa Anda belajar apa design yang tepat dengan membangun, dan bahwa over-designing sebelum Anda memiliki pembelajaran itu menghasilkan sistem dioptimalkan untuk masalah yang Anda tidak sepenuhnya pahami belum.

Di Mana Gaya Ini Rusak

Pengaruh tanpa wewenang lambat. Fowler telah membangun reputasinya selama 25 tahun. Anda tidak bisa meminjam metodenya pada siklus produk enam bulan.

Menamai pola tidak menjamin implementasi baik. Microservices adalah contoh paling jelas: deskripsi arsitektur ketat menjadi cargo cult. Tim mengadopsi pola tanpa kematangan organisasi, investasi tooling, atau skala yang membuatnya berharga. Fowler menamai konsep dengan benar, tetapi penamaan mempercepat adopsi lebih cepat daripada pemahaman. Itu adalah risiko yang melekat dalam pembangunan infrastruktur intelektual — Anda menyerahkan alat yang kuat kepada orang-orang yang mungkin tidak memiliki konteks untuk menggunakannya dengan aman.

Dan suara praktisi-cendekiawan tidak diterjemahkan ke perusahaan di bawah tekanan eksekusi. Penulisan Fowler disengaja, bernuansa, dan panjang. Ini dirancang untuk refleksi, bukan untuk membuat keputusan di bawah deadline. Pemimpin yang perlu memilih arsitektur dalam seminggu dan mengirim dalam sebulan tidak memiliki kemewahan bekerja melalui analisis kontekstual penuh yang bukunya butuhkan. Framework-nya paling berguna untuk pemimpin yang memiliki stabilitas operasional cukup untuk berpikir dengan hati-hati — yang tidak selalu situasi yang benar-benar Anda alami.

Untuk bacaan terkait tentang praktik engineering dan budaya, lihat Gaya Kepemimpinan Werner Vogels, Gaya Kepemimpinan Linus Torvalds, dan Gaya Kepemimpinan Andy Grove.

Victor Hoang

Co-Founder & CMO, Rework