Leadership Styles of Legends

The Phoenix Project adalah novel tentang seorang manajer IT fiktif bernama Bill yang memiliki 90 hari untuk memperbaiki proyek IT yang gagal sebelum manajer pabrik menutup departemen. Diterbitkan pada 2013, sudah terjual lebih dari 750.000 salinan. Bukan karena ini fiksi yang hebat, tetapi karena ribuan CTO, VP Engineering, dan CIO telah memberikannya kepada CEO mereka dan berkata: "Ini tepat apa yang salah dengan cara kami bekerja."

Gene Kim memulai sebagai pendiri. Dia ikut mendirikan Tripwire, perusahaan perangkat lunak keamanan, di Purdue University pada 1997 dan melayani sebagai CTO selama 13 tahun sebelum itu terjual ke Thoma Bravo seharga $710M pada 2011. Dia menjadi peneliti paling berpengaruh dalam DevOps setelah itu, mengubah serangkaian praktik deployment menjadi filosofi manajemen yang dapat diterapkan pada organisasi mana pun di mana pekerjaan mengalir melalui sistem yang terbatas.

Memahami kerangka Three Ways-nya (dan di mana itu tidak bekerja) layak waktu Anda apakah Anda menjalankan tim engineering atau tidak menyentuh kode sama sekali.

Fakta Kunci Tentang Gene Kim

Pendiri dan CTO Tripwire Inc. (1997) — perusahaan perangkat lunak keamanan yang dia ikut dirikan di Purdue dan dipimpin selama 13 tahun sebagai pioneer DevOps dan keamanan informasi, sebelum Thoma Bravo mengakuisinya seharga $710M pada 2011.
Penulis "The Phoenix Project" (2013) — klasik DevOps bentuk novel yang telah terjual lebih dari 500.000 salinan dan menjadi bacaan wajib dalam program onboarding CTO.
Penulis bersama "The DevOps Handbook" (2016) — referensi definitif DevOps, ditulis dengan Jez Humble, Patrick Debois, dan John Willis.
Penulis "The Unicorn Project" (2019) — sekuel yang memperkenalkan kerangka Five Ideals untuk budaya engineering.
Penulis bersama "Wiring the Winning Organization" (2023) — dengan Dr. Steven J. Spear, menggeneralisasi playbook DevOps menjadi teori universal organisasi berkinerja tinggi yang dibangun di atas slowification, simplification, dan amplification.
Pendiri DevOps Enterprise Summit — konferensi tahunan (diluncurkan 2014) di mana para pemimpin teknologi Fortune 500 mempresentasikan studi kasus tentang transformasi DevOps skala besar.
Tujuh kali peneliti tentang organisasi IT berkinerja tinggi — penyelidik utama di seluruh tujuh studi State of DevOps berturut-turut dengan Nicole Forsgren dan tim DORA, menghasilkan fondasi empiris operasi perangkat lunak modern.
Pendiri IT Revolution Press — penerbit independen yang dia bangun secara khusus untuk memajukan penelitian DevOps dan manajemen teknologi.

Tiga Cara DevOps (Model The Phoenix Project)

Tiga Cara DevOps adalah kerangka penguasa Gene Kim untuk organisasi teknologi berkinerja tinggi: Flow (optimalkan gerakan pekerjaan dari kiri-ke-kanan dari development ke operations ke pelanggan dengan mengurangi batch size dan membatasi work in progress), Feedback (buat fast feedback loops dari kanan-ke-kiri dari production kembali ke tim yang dapat memperbaiki masalah di sumbernya), dan Continuous Learning (institusionalkan improvement dan experimentation sehingga penemuan lokal menjadi pengetahuan organisasi). Bersama-sama, Tiga Cara mengubah DevOps dari serangkaian praktik deployment menjadi filosofi manajemen yang dapat diterapkan pada aliran nilai mana pun.

Kerusakan Gaya Kepemimpinan

Gaya	Bobot	Cara Ditampilkan
Peneliti-Praktisi	60%	Kredibilitas Kim bukan akademis. Dia menjalankan operasi engineering Tripwire selama lebih dari satu dekade, mengelola infrastruktur keamanan dan compliance real sebelum menulis satu kata pun tentang DevOps. "The DevOps Handbook" (2016), ditulis bersama dengan Jez Humble, Patrick Debois, dan John Willis, didasarkan pada studi kasus real dari perusahaan seperti Nordstrom, Etsy, dan Capital One. Penerbit Kim untuk karya-karya ini adalah IT Revolution Press, rumah independen yang dia ikut dirikan secara khusus untuk memajukan penelitian DevOps dan manajemen teknologi. State of DevOps Report, yang Kim berkontribusi di dalamnya bersama Nicole Forsgren, menunjukkan bahwa elite performers melakukan deploy 200x lebih sering daripada low performers dengan 2.604x waktu lead yang lebih cepat. Itu bukan kerangka dari jarak jauh; itu data dari sistem production.
Systems Thinker	40%	Fondasi analitik Kim adalah Theory of Constraints Eliyahu Goldratt dan Lean manufacturing. "The Phoenix Project" secara eksplisit mencerminkan "The Goal" Goldratt: struktur narasi sama, logika system-constraint sama, diterapkan ke IT. Entri Wikipedia novel mendokumentasikan dampaknya — lebih dari 750.000 salinan terjual dan adopsi luas sebagai bacaan wajib dalam program onboarding CTO. Kim tidak berpikir tentang DevOps sebagai masalah toolchain; dia berpikir tentang itu sebagai masalah flow. Kendala bukan pipeline deployment; itu bottleneck dalam value stream. Framing itu memungkinkannya menggeneralisasi dari delivery perangkat lunak ke sistem organisasi mana pun di mana pekerjaan antri dan menjadi rumit.

Pembagian 60/40 menjelaskan mengapa Kim dipelajari oleh operator daripada hanya engineer. Penelitiannya tertanam dalam operasi, dan pemikiran sistemnya tertanam dalam data, yang memberikan kerangkanya jenis otoritas berbeda daripada kebanyakan writing manajemen. Perpaduan kredibilitas lapangan dan ketelitian analitik itu adalah sesuatu yang dia bagikan dengan Werner Vogels, yang kerja distributed-systems-nya di Amazon demikian juga tertanam dalam realitas production daripada abstraksi akademis.

Ciri Kepemimpinan Utama

Ciri	Rating	Apa artinya dalam praktik
Pengajaran format novel	Luar Biasa	Keputusan Kim untuk menulis "The Phoenix Project" sebagai novel daripada buku manajemen bukan kebetulan. Eksekutif non-teknis tidak membaca buku teknis. Mereka membaca narasi bisnis. Dengan menanamkan prinsip DevOps di dalam cerita tentang perusahaan dalam krisis, Kim memberi CTO dokumen yang dapat mereka berikan kepada CEO mereka dan katakan: "Baca ini." Format itu menjangkau audiens yang "The DevOps Handbook" tidak akan pernah jangkau. Itu adalah strategi distribusi yang disengaja, bukan sekadar pilihan gaya.
Sintesis lintas-disiplin	Sangat Tinggi	Kim menggambar dari Lean manufacturing, Theory of Constraints, dan high-reliability organization research untuk menjelaskan DevOps. Sintesisnya tentang bidang-bidang ini adalah apa yang membuat kerangkanya bertahan lama. Kebanyakan writing DevOps tetap di dalam pengembangan perangkat lunak. Writing Kim menggambar dari Deming, Goldratt, dan Sidney Dekker, yang memungkinkannya membuat argumen tentang blameless postmortems, work-in-progress limits, dan deployment frequency yang menghubungkan ke manufacturing, aviation safety, dan organizational psychology secara bersamaan. Martin Fowler mengambil stance lintas-disiplin yang sebanding, mendasarkan continuous delivery dan refactoring dalam prinsip Lean dan XP daripada memperlakukannya sebagai kekhawatiran purely teknis.
Kredibilitas praktisi	Tinggi	13 tahun sebagai CTO Tripwire, menjalankan operasi keamanan untuk pelanggan enterprise selama periode ketika requirement compliance meningkat dan infrastructure semakin kompleks. Itu bukan stint singkat. Kim memahami apa rasanya mengelola on-call rotations, menangani requirement audit, dan mencoba melakukan deploy features sambil menjaga production stabil. Pengalaman itu adalah apa yang membuat penelitiannya kredibel untuk operator yang telah melakukan hal yang sama.
Kesabaran dengan organizational change	Tinggi	Kerangka Tiga Cara bukan proyek 90-hari. Pesan konsisten Kim di seluruh "The Phoenix Project," "The DevOps Handbook," dan "The Unicorn Project" adalah bahwa transformasi dari proses deployment lambat, rapuh menjadi deployment dengan frekuensi tinggi, resilient membutuhkan tahun-tahun upaya berkelanjutan. Dia tidak menjanjikan quick wins. Kesabaran itu adalah fitur atau bug tergantung pada apakah Anda memiliki runway organisasi untuk menunggu compounding returns.

3 Kerangka yang Mendefinisikan Gene Kim

Cara Pertama — Flow

Cara Pertama adalah tentang mengoptimalkan flow pekerjaan dari development ke operations ke pelanggan. Tujuannya adalah mengurangi waktu yang dibutuhkan untuk code change pergi dari laptop developer ke production, dan meningkatkan reliabilitas journey itu.

Praktik spesifik: kurangi batch sizes (jangan coba deploy 3 bulan pekerjaan sekaligus), batasi work in progress (terlalu banyak hal in flight secara bersamaan menciptakan lebih banyak bottleneck daripada yang dipecahnya), dan bangun quality di dalamnya daripada inspeksi di akhir. Poin terakhir ini adalah yang sebagian besar organisasi dapatkan salah. Quality assurance sebagai fase di akhir proses development adalah equivalent perangkat lunak dari inspeksi produk di factory floor setelah mereka telah dibangun. Pada saat Anda menemukan defect, Anda sudah membayar untuk pekerjaan yang menciptakannya.

Untuk operator non-perangkat lunak, Cara Pertama menerjemahkan langsung ke workflow mana pun dengan handoffs. Di mana pekerjaan mengantri dalam organisasi Anda? Di mana itu batch? Setiap batch mengakumulasi WIP cost tak terlihat: keputusan menunggu approval, deals menunggu legal review, customer requests menunggu engineering prioritization. Poin Kim adalah bahwa mengurangi batch size dan membatasi WIP bukan hanya tentang speed. Itu tentang membuat masalah terlihat sebelum mereka menjadi rumit.

Cara Kedua — Feedback

Cara Kedua adalah tentang menciptakan fast feedback loops dari kanan-ke-kiri dalam value stream: dari operations kembali ke development, dari customers kembali ke product teams, dari production data kembali ke engineer yang menulis kode.

Insight inti adalah bahwa masalah dalam production paling berharga saat mereka terjadi, bukan minggu kemudian dalam post-mortem. Penelitian Kim, diinformasikan oleh data dari DORA State of DevOps Report, menunjukkan bahwa tim dengan shorter mean time to recovery dari incidents belajar lebih cepat daripada tim dengan lower incident rates. Itu tidak intuitif: tim yang recover cepat dari lebih banyak incidents outperform tim yang jarang memiliki incidents tetapi recover lambat. Learning menjadicompound.

Implikasi praktis signifikan. Blameless postmortems, monitoring yang surfaces anomalies ke orang yang dapat memperbaikinya, dan deployment pipelines yang memberikan immediate feedback pada test failures semuanya praktik Cara Kedua. Begitu juga dengan kebiasaan memiliki engineer duduk dengan customer support. Feedback mechanism hanya bekerja jika signal mencapai orang yang dapat bertindak dengan cukup cepat untuk penting.

Cara Ketiga — Continuous Learning

Cara Ketiga adalah tentang institusionalisasi improvement. Bukan hanya memperbaiki masalah individual, tetapi membangun sistem yang mengkonversi penemuan lokal menjadi pengetahuan organisasi dan terus-menerus eksperimen untuk menghasilkan learning baru.

Di sini Kim menggambar paling berat dari Toyota Production System research dan high-reliability organizations. Praktik: dedikasikan waktu untuk improvement work (bukan hanya feature delivery), buat experiments aman untuk dijalankan sehingga failed experiments menghasilkan learning daripada punishment, dan ciptakan mekanisme untuk sharing apa yang bekerja di seluruh tim daripada meninggalkannya lokal.

"The Unicorn Project" (2019), sekuel Kim untuk "The Phoenix Project," memperkenalkan Five Ideals, yang kondisi budaya yang membuat Cara Ketiga mungkin: Locality and Simplicity (tim memiliki apa yang mereka ubah), Focus/Flow/Joy (developer melakukan best work mereka), Improvement of Daily Work (membuat improvement time protected, bukan deferred), Psychological Safety (orang dapat surface problems tanpa takut), dan Customer Focus (keputusan traced kembali ke customer impact). Five Ideals adalah upaya Kim untuk menamakan budaya yang sustains DevOps transformation setelah praktik teknis di tempatnya.

Apa yang Akan Dilakukan Gene Kim di Peran Anda

Jika Anda seorang CEO, hal paling berguna yang Kim tawarkan adalah diagnostic untuk mengapa organisasi teknologi Anda tidak bisa bergerak secepat yang Anda butuhkan. Krisis sentral Phoenix Project adalah proses deployment yang begitu rapuh dan lambat sehingga bisnis tidak bisa merespons perubahan pasar. Jika tim engineering Anda mengatakan feature membutuhkan enam bulan dan Anda tidak mengerti mengapa, kerangka Kim memberikan Anda pertanyaan yang benar: Apa batch size? Di mana pekerjaan mengantri? Berapa lama untuk mendeteksi masalah production dan memperbaikinya? Pertanyaan itu akan surface constraint. Constraint hampir tidak pernah "kami membutuhkan lebih banyak engineer."

Jika Anda seorang COO, Cara Pertama berlaku langsung ke operational workflows Anda. Temukan langkah dalam cross-functional process mana pun di mana pekerjaan paling terakumulasi. Itu constraint Anda. Poin Kim adalah bahwa mengoptimalkan upstream dari constraint tidak membantu; pekerjaan hanya antri lebih cepat. Anda harus mengidentifikasi constraint dan subordinate semuanya ke elevating itu. Ini adalah logika Goldratt diterapkan ke operations. Itu bekerja apakah Anda mengelola software deployment pipelines atau contract review cycles.

Jika Anda pemimpin produk, Cara Kedua adalah tanggung jawab langsung Anda. Feedback loops antara apa yang Anda bangun dan apa yang benar-benar dilakukan user dengannya adalah apa yang mendorong keputusan produk Anda. Penelitian Kim menyarankan bahwa frekuensi dan kecepatan feedback loops itu penting lebih dari sophistication methodology penelitian Anda. Weekly user data yang dapat Anda bertindak outperforms quarterly research yang Anda bertindak dalam planning cycles. Instrument produk Anda untuk menghasilkan signal dengan cepat, dan bangun team culture di mana signal itu langsung ke orang yang membuat keputusan, bukan ke reporting layer.

Jika Anda berada dalam penjualan atau marketing, strategi konten Kim layak dipelajari. "The Phoenix Project" ada karena Kim memahami bahwa target audience-nya, eksekutif yang perlu mengubah cara perusahaan mereka mengelola teknologi, tidak akan membaca handbook teknis. Dia mengemas kerangka dalam format audience-nya benar-benar consume. Itu adalah strategi distribution-first: identifikasi insight, kemudian tanya format apa yang memasukkannya di depan decision-maker yang membutuhkannya. Pertanyaan itu lebih menarik daripada "format apa yang kami lebih suka produksi."

Bagaimana Rework Mengoperasionalisasi Tiga Cara Di Luar Engineering

Three Ways Kim ditulis untuk software delivery, tetapi logika menggeneralisasi bersih ke tim mana pun di mana pekerjaan mengalir melalui handoffs. Pertanyaan untuk pemimpin non-teknis adalah: di mana batch size, delay feedback, dan blocked learning loop Anda? Operational layer Rework adalah apa yang membuat pertanyaan itu dapat dijawab. Pipeline visibility di seluruh sales, customer operations, dan account management menunjukkan tepat di mana pekerjaan mengantri — Cara Pertama constraint hunt, diterapkan ke revenue operations daripada deployment pipelines. Shared activity feeds dan real-time status collapse waktu antara masalah surfacing dan orang yang dapat memperbaikinya melihatnya — Cara Kedua, rebuilt untuk cross-functional teams tanpa monitoring stack. Dan karena sistem yang sama captures outcomes di sebelah pekerjaan yang menghasilkannya, manajer mendapat raw material untuk Cara Ketiga: recurring retrospectives grounded dalam data aktual, bukan recollection. Kerangka Kim mengubah operations dari art menjadi infrastructure ketika instrumentation ada untuk supportnya.

Kutipan Terkenal dan Pelajaran Melampaui Ruang Rapat

Dari "The Phoenix Project," karakter Brent (engineer senior yang semuanya bergantung padanya) adalah teaching tool paling berguna Kim. Brent adalah bottleneck yang management ciptakan dengan memperlakukan engineer terbaik mereka sebagai solusi untuk setiap masalah daripada sebagai risiko yang dapat didistribusikan. Quote yang diingat operator: "Mampu mengeluarkan pekerjaan yang tidak perlu dari sistem lebih penting daripada mampu memasukkan lebih banyak pekerjaan ke dalam sistem." Setiap organisasi memiliki Brent. Masalah Brent bukan tentang orang itu. Itu tentang management system yang membuat availability satu orang constraint pada semuanya.

Dari "The DevOps Handbook": "Improvements made di mana pun selain bottleneck adalah illusion." Itu adalah pernyataan tepat dari constraint theory Goldratt diterapkan ke technology operations, dan itu layak ditempel di atas desk Anda jika Anda mengelola sistem kompleks. Kebanyakan optimization efforts dalam organisasi target bagian yang mudah dioptimalkan, bukan constraint. Hasilnya adalah efficiency dalam area yang tidak mengontrol throughput dan tidak ada improvement dalam overall output.

Kim juga telah mengatakan, dalam berbagai talks dan interviews, bahwa State of DevOps research mengubah viewnya tentang apa high performance sepertinya. Partnership research-nya dengan Nicole Forsgren dan broader DevOps community mencerminkan open, collaborative ethos yang Linus Torvalds established dalam open-source software — ide bahwa distributed peer review menghasilkan sistem lebih reliable daripada centralized gatekeeping. Sebelum data, dia assumed high-deployment-frequency organizations akan memiliki lebih banyak stability problems. Data menunjukkan kebalikannya: elite performers melakukan deploy lebih sering dan memiliki higher stability secara bersamaan. Temuan itu, bahwa speed dan stability bukan dalam tension jika underlying practices tepat, adalah hasil empiris paling penting dalam modern software operations research.

Di Mana Gaya Ini Rusak

Three Ways Kim bekerja terbaik dalam product organizations dengan stable, identifiable value stream dari development ke customer. Mereka lebih sulit untuk diterapkan dalam consulting firms, agencies, atau project-based businesses di mana "flow" terlihat berbeda di setiap engagement. Kerangka juga memerlukan IT function dengan cukup organizational standing untuk implement cross-team practices. Dalam perusahaan di mana engineering lacks executive backing, Three Ways menghasilkan insight tetapi bukan movement.

Dan format novel yang membuat Kim broadly influential juga membatasi depth kerangkanya dapat capai. "The Phoenix Project" accessible karena itu cerita. Itu limited karena cerita hanya dapat illustrate, bukan fully specify. Operator yang membaca novel dan berhenti di sana mendapat diagnosis tanpa treatment protocol. "The DevOps Handbook" adalah treatment protocol, tetapi itu memerlukan significantly lebih banyak commitment untuk work through.

Untuk bacaan terkait tentang engineering practice dan culture, lihat Gaya Kepemimpinan Martin Fowler, Gaya Kepemimpinan Werner Vogels, Gaya Kepemimpinan Linus Torvalds, Gaya Kepemimpinan Will Larson, dan Gaya Kepemimpinan Camille Fournier.

Victor Hoang

Co-Founder & CMO, Rework