Gaya Kepemimpinan Werner Vogels: CTO yang Membangun AWS dari Dalam ke Luar

Fakta Kunci: Werner Vogels (l. 1958) telah menjabat sebagai Chief Technology Officer Amazon sejak 2005 (bergabung 2004 sebagai Director of Systems Research). Dia memiliki PhD dari Vrije Universiteit Amsterdam, di mana dia meneliti komputasi enterprise yang dapat diskalakan sebelum Amazon merekrutnya. Dia adalah arsitek fondasi sistem terdistribusi AWS dan teoretisi utama sistem data eventual-consistent — ide yang diformalkan dalam makalah Dynamo yang disetujui bersama (2007) yang mendasari DynamoDB. Prinsipnya "Everything fails all the time" dan ethos DevOps "You build it, you run it" telah menjadi doktrin standar industri. Dia telah menulis terus-menerus di blognya All Things Distributed selama lebih dari 20 tahun, menjadikannya salah satu CTO yang menulis secara publik paling lama di teknologi.

Model You-Build-It-You-Run-It Vogels

Model You-Build-It-You-Run-It Vogels adalah kerangka kerja kepemimpinan teknik di mana tim yang merancang dan mengirimkan layanan perangkat lunak juga memiliki operasi produksinya — memantaunya, merespons insiden, dan memperbaiki kegagalan secara langsung. Dipasangkan dengan aksioma pendamping "everything fails all the time," model itu memperlakukan kegagalan sebagai kondisi operasi yang diharapkan daripada pengecualian, memaksa desain untuk degradasi yang anggun dari baris kode pertama. Hasilnya adalah loop umpan balik yang ketat antara keputusan desain dan konsekuensi operasional, yang Vogels berpendapat adalah rute tercepat menuju keandalan perangkat lunak nyata dalam skala besar.

Werner Vogels adalah profesor sistem terdistribusi di Vrije Universiteit Amsterdam ketika Amazon merekrutnya pada 2004. Dia telah menulis tentang ide-ide ini terus-menerus di blognya All Things Distributed sejak 2005. Dia bukan pendiri startup atau visioner produk. Dia adalah akademisi yang telah menghabiskan bertahun-tahun meneliti cara membangun perangkat lunak yang andal yang tidak jatuh ketika komponen individu gagal.

Amazon membutuhkan keahlian spesifik itu karena Amazon sedang jatuh. Perusahaan telah berkembang menjadi jalinan kompleks dependensi — tim memanggil kode tim lain secara langsung, tidak ada batasan layanan yang jelas, penerapan yang rusak sistem yang tidak terkait. Vogels bergabung sebagai Director of Systems Research pada 2004 dan menjadi CTO pada 2005. Dia kemudian menghabiskan dua dekade berikutnya dalam menciptakan mandat teknik bersama yang menjadi cetak biru untuk cara organisasi teknologi skala besar menata diri mereka sendiri.

"You build it, you run it" adalah doktrin standar di perusahaan yang dia tidak pernah bekerja untuk. Mandat API, arsitektur microservices, dan ide bahwa tim pengembangan harus memiliki sistem mereka dalam produksi — ini adalah ide Vogels-adjacent bahkan ketika namanya tidak terlampir.

Apa yang membuatnya berguna untuk dipelajari bukan hanya output teknis. Itu adalah cara pikiran akademis diterapkan pada masalah operator menghasilkan prinsip yang diskalakan ke bisnis $100 miliar.

Breakdown Gaya Kepemimpinan

Pembagian 60/40 menjelaskan mengapa Vogels dipelajari baik sebagai arsitek teknis maupun sebagai pembangun budaya. Arsitektur pertama-API adalah kontribusi struktural. Postur operator-humility adalah apa yang membuatnya mungkin bagi ribuan insinyur untuk menerapkan arsitektur itu dengan jujur, termasuk di tempat di mana itu sulit dan lambat.

Ciri-Ciri Kepemimpinan Utama

3 Keputusan Yang Mendefinisikan Werner Vogels

1. Mandat API

Mandat API Bezos — terkait langsung dengan pertumbuhan Amazon Web Services — sering digambarkan sebagai ide Jeff Bezos. Itu sebagian akurat. Bezos menulis mandat. Tetapi Vogels menerapkannya, memberlakukannya, dan membangun prinsip arsitektur di sekitarnya.

Mandat, kira-kira: setiap tim harus mengekspos data dan fungsionalitasnya melalui antarmuka layanan. Tidak ada integrasi pintu belakang, tidak ada pembacaan database langsung dari sistem tim lain, tidak ada kode internal bersama. Semua komunikasi terjadi melalui antarmuka. Dan antarmuka harus dirancang sehingga mereka dapat diekspos kepada pengembang eksternal — bukan karena Amazon merencanakan untuk mengeksposnya, tetapi karena batasan itu memaksa Anda merancang antarmuka yang benar-benar bersih daripada jalan pintas nyaman.

Konsekuensi bisnis dari mandat itu adalah AWS. Amazon harus membangun infrastruktur layanan internal yang cukup andal dan bersih untuk melayani pelanggan eksternal. Layanan yang mereka jalankan secara internal — komputasi, penyimpanan, database, pesan — ternyata adalah layanan yang dibutuhkan perusahaan lain juga. AWS bukan direncanakan sebagai produk dari awal. Ini muncul dari disiplin arsitektur internal yang Vogels dipilih dan diberlakukan.

Untuk operator hari ini, prinsip mandat API menerjemahkan: apa dalam organisasi Anda yang terintegrasi melalui hubungan informal, akses data langsung, atau dependensi yang tidak terdokumentasi daripada melalui antarmuka yang eksplisit dan dimiliki? Integrasi informal itu adalah utang operasi Anda. Ketika komponen apa pun berubah, segalanya yang bergantung padanya dengan cara yang tidak terdokumentasi pecah dengan cara yang tidak terduga. Mandat API tidak memerlukan membangun REST API untuk komunikasi tim internal — itu memerlukan menanyakan siapa yang memiliki setiap sistem, apa kontrak antara sistem itu, dan apa yang terjadi ketika komponen gagal atau berubah.

2. "You Build It, You Run It"

Vogels mengartikulasikan prinsip ini dalam wawancara 2006, tetapi dia telah menerapkannya di Amazon selama dua tahun sebelumnya. Konsep mendahului gerakan DevOps dengan beberapa tahun dan mengantisipasi sebagian besar dari apa yang DevOps akhirnya kodifikasi.

Argumennya mudah: insinyur perangkat lunak membuat keputusan desain yang berbeda ketika mereka tahu mereka akan dibangunkan pada 2am jika sistem gagal. Empati operasional — memahami bagaimana kode Anda berperilaku dalam produksi — dibangun melalui kepemilikan konsekuensi keputusan Anda. Ketika dev dan ops adalah tim terpisah, gradien insentif tidak selaras: dev ingin mengirim fitur, ops ingin stabilitas, dan handoff antara mereka menjadi negosiasi daripada tanggung jawab bersama.

"You build it, you run it" menghilangkan handoff itu. Tim yang mengirim fitur juga memantaunya, merespons insiden, dan memperbaiki masalah yang muncul dalam produksi. Itu menciptakan loop umpan balik langsung antara keputusan desain dan konsekuensi operasional — cara tercepat untuk meningkatkan keandalan perangkat lunak.

Model ini memerlukan investasi. Anda perlu membangun monitoring, alerting, dan on-call tooling yang membuat kepemilikan produksi dapat dikelola untuk insinyur pengembangan. Anda perlu menciptakan budaya di mana insiden produksi diperlakukan sebagai peluang pembelajaran daripada insiden kinerja — jika tidak akuntabilitas on-call menciptakan jenis rasa takut yang merosot loop umpan balik. Dan Anda perlu merekrut insinyur yang bersedia mengambil akuntabilitas itu, yang tidak semua insinyur.

Amazon membuat investasi itu, dan catatan keandalan AWS mencerminkannya. Andy Jassy, yang membangun dan memimpin AWS sebelum menjadi CEO Amazon, menskalakan budaya kepemilikan ini di seluruh ribuan insinyur — menunjukkan bahwa model bekerja pada ukuran jauh melampaui apa yang sebagian besar pengamat pikir mungkin ketika Vogels pertama kali mengartikulasikannya. Perusahaan yang mengadopsi "you build it, you run it" setelah melihat AWS sukses sering mengadopsi frasa tanpa investasi infrastruktur yang mendasarinya, itulah mengapa beberapa implementasi model itu membakar tim teknik.

3. Surat CTO Tahunan

Setiap tahun di AWS re:Invent, Vogels menerbitkan surat terbuka yang meninjau komitmen Amazon dari tahun sebelumnya, mengakui di mana Amazon kurang memberikan, dan menetapkan prioritas untuk tahun yang akan datang. Dia telah melakukan ini sejak tahun-tahun awal AWS.

Format itu — komitmen publik tahunan dengan tinjauan akuntabilitas eksplisit — tidak biasa untuk CTO perusahaan. Sebagian besar surat tahunan forward-looking: berikut adalah rencana menarik kami untuk tahun depan. Surat Vogels backward-looking pertama: berikut adalah apa yang kami katakan kami akan lakukan, berikut adalah apa yang kami lakukan, berikut adalah apa yang kami tidak lakukan dan mengapa.

Efeknya dua kali lipat. Secara eksternal, itu menciptakan kepercayaan dengan komunitas pengembang dan pelanggan enterprise bahwa komitmen AWS dilakukan dengan itikad baik, karena ada catatan publik apakah komitmen masa lalu dihormati. Secara internal, itu menciptakan standar akuntabilitas yang meluas ke seluruh organisasi: jika CTO secara publik bertanggung jawab atas apa yang dikatakan AWS akan disampaikan, setiap tim yang berkontribusi pada komitmen itu memahami bahwa kegagalan untuk memberikan memiliki konsekuensi nyata.

Model itu dapat ditransfer. Sebagian besar organisasi membuat komitmen dalam siklus perencanaan kuartalan dan mengevaluasi mereka dalam retrospektif yang tidak pernah muncul secara publik. Kontribusi Vogels adalah menunjukkan bahwa akuntabilitas publik, dinyatakan cukup spesifik untuk dapat disangkal, mengubah serius komitmen itu diambil.

Apa Yang Akan Dilakukan Werner Vogels dalam Peran Anda

Jika Anda adalah CEO, prinsip mandat API berlaku pada antarmuka organisasi Anda, bukan hanya perangkat lunak Anda. Setiap kali satu tim mendapat informasi dari tim lain melalui hubungan informal daripada proses terdokumentasi, Anda telah menciptakan dependensi yang tidak terdokumentasi. Itu berfungsi dengan baik sampai orang di pusat hubungan itu pergi, sakit, atau mengubah peran. Minta COO Anda untuk memetakan aliran informasi penting dalam organisasi Anda dan mengidentifikasi mana yang ada hanya karena orang-orang spesifik mempertahankannya. Itu adalah titik kegagalan operasi tunggal Anda. Vogels akan membuat antarmuka eksplisit dan dimiliki daripada informal dan person-dependent.

Jika Anda adalah COO, "you build it, you run it" memiliki setara manajemen operasi: orang-orang yang merancang proses harus mengalami konsekuensi bagaimana itu bekerja. Jika tim operasi Anda merancang alur kerja onboarding yang dibenci perwakilan customer success, dan tim operasi tidak pernah berbicara dengan pelanggan atau perwakilan secara langsung, loop umpan balik terputus. Bangun setara kepemilikan produksi ke dalam desain proses Anda: siapa pun yang menentukan proses harus menghabiskan waktu dalam sistem yang mereka tentukan, secara teratur cukup untuk merasakan gesekan yang mereka buat.

Jika Anda adalah pemimpin produk, prinsip "everything fails all the time" Vogels layak diterapkan pada persyaratan produk Anda. Sebagian besar persyaratan produk ditulis sebagai spesifikasi jalur bahagia: apa yang terjadi ketika semuanya berfungsi. Persyaratan yang menarik — yang menentukan keandalan produk Anda — adalah mode kegagalan: apa yang terjadi ketika panggilan API gagal, ketika pengguna kehilangan konektivitas di tengah alur, ketika integrasi pihak ketiga mengembalikan data yang tidak terduga. Tanyakan tim Anda berapa persentase dokumen persyaratan Anda mencakup jalur kegagalan. Jika di bawah 20%, Anda merancang produk yang akan berperilaku secara tidak terduga dalam produksi dengan cara yang tidak Anda antisipasi.

Jika Anda dalam penjualan atau pemasaran, model komunikasi publik jangka panjang Vogels memiliki aplikasi langsung dalam manajemen akun dan customer success. Sebagian besar komunikasi vendor adalah forward-looking: berikut adalah apa yang kami bangun, berikut adalah roadmap kami, berikut adalah apa yang akan datang. Pendekatan Vogels adalah backward-looking pertama: berikut adalah apa yang kami komitmenkan, berikut adalah apa yang kami sampaikan, berikut adalah di mana kami kurang memberikan dan mengapa. Pelanggan enterprise paling penting Anda akan merespons lebih baik dengan format itu daripada dek roadmap kuartalan lainnya. Mereka tahu produk Anda memiliki kesenjangan. Pertanyaan yang benar-benar mereka tanyakan adalah apakah Anda jujur tentang mereka.

Bagaimana Rework Menerjemahkan Doktrin Teknik Vogels ke Kepemilikan Tim Kecil

Vogels membangun modelnya dengan asumsi bahwa Anda memiliki headcount untuk menempatkan setiap layanan di belakang tim yang memilikinya dalam produksi. Sebagian besar perusahaan yang menjalankan Rework tidak. Apa yang Rework lakukan adalah menutup kesenjangan antara "siapa merancang alur kerja" dan "siapa menjalankannya setiap hari" dalam permukaan operasi tunggal — orang yang menyiapkan pipeline CRM, aturan otomasi, dan logika eskalasi adalah orang yang sama yang dipanggil ketika deal berhenti atau SLA pecah. Itulah versi tim kecil dari "you build it, you run it," dan itu bekerja karena sinyal kegagalan dan perbaikan hidup dalam alat yang sama. Rework juga mengkode postur "everything fails all the time" ke dalam defaultnya: setiap otomasi memiliki status kegagalan yang terlihat, setiap bidang pemilik diperlukan, dan setiap handoff adalah peristiwa yang dicatat daripada DM Slack. Untuk tim operasi 10 orang, itu adalah jalur realistis menuju standar keandalan Vogels — Anda tidak dapat merekrut tim platform, tetapi Anda dapat membuat kepemilikan dan kegagalan terlihat dengan konstruksi.

Kutipan Terkenal & Pelajaran Melampaui Ruang Rapat

Dari blognya All Things Distributed: "Everything fails all the time." Pernyataan itu, yang telah dia kembali dalam berbagai bentuk di seluruh lebih dari 20 tahun penulisan, menangkap prinsip sistem terdistribusi inti: keandalan bukan tentang mencegah kegagalan. Itu tentang merancang sistem yang terus berfungsi ketika komponen gagal. Dalam perangkat lunak, itu berarti degradasi yang anggun, circuit breaker, dan logika ulang. Dalam organisasi, itu berarti merancang proses yang terus berfungsi ketika orang kunci tidak tersedia, vendor gagal memberikan, atau sistem jatuh.

Di re:Invent 2022, Vogels menggambarkan janji cloud dengan cara ini: "Kemampuan untuk bereksperimen dengan biaya rendah adalah salah satu hadiah paling kuat yang teknologi telah berikan kepada kami." Itu bukan pernyataan pemasaran — itu adalah pernyataan arsitektur. Ketika Anda dapat memutar infrastruktur dalam hitungan menit dan membayar hanya untuk apa yang Anda gunakan, biaya eksperimen yang gagal turun mendekati nol. Itu mengubah apa yang layak dicoba. Sebagian besar organisasi dengan infrastruktur warisan membuat keputusan bet-the-quarter tentang infrastruktur karena biaya salah tinggi. Argumen Vogels adalah bahwa respons yang tepat terhadap ketidakpastian adalah membuat biaya eksperimen rendah, bukan meningkatkan prediksi Anda.

Dia juga berbicara jarang tentang kegagalan asingnya sendiri, yang membuat contoh ketika dia melakukannya penting. Dalam wawancara 2022, dia mengakui bahwa pilihan database awal Amazon menciptakan utang migrasi signifikan yang memakan waktu bertahun-tahun untuk dipecahkan. Jeff Dean di Google menghadapi momen reckoning arsitektur serupa — semacam yang terjadi ketika sistem yang dibangun untuk satu skala berhenti bekerja pada yang berikutnya — dan kemauan untuk menamai ini secara publik adalah apa yang membedakan insinyur yang menjadi pengetahuan institusional dari insinyur yang menjadi mitologi institusional. Kemauan untuk menamai keputusan teknis spesifik yang ternyata salah — bukan secara samar mengakui kesalahan dibuat — adalah standar intelektual yang dia tetapkan secara publik dan mungkin pegang secara internal.

Di Mana Gaya Ini Rusak

"You build it, you run it" memerlukan insinyur senior yang bersedia memiliki produksi. Itu bekerja buruk dalam startup terkendali biaya dengan tim junior, karena beban on-call pada tim kecil dengan pengalaman terbatas dapat menjadi tidak berkelanjutan dengan cepat. Amazon dapat berinvestasi dalam monitoring, tooling, dan infrastruktur respons insiden yang membuat kepemilikan produksi dapat dikelola. Startup 15 orang tidak bisa.

Mandat pertama-API juga memperlambat perusahaan tahap awal yang perlu bergerak cepat. Memberlakukan batasan layanan bersih sebelum Anda tahu apa produk Anda menciptakan overhead yang tidak perlu. Prinsip Vogels dioptimalkan untuk organisasi yang sudah memiliki product-market fit dan menskalakan kompleksitas. Mereka adalah alat yang salah untuk menemukan product-market fit pada tempat pertama.

Dan lock-in platform adalah kritik yang sah dari pendekatan arsitektur AWS. Ketika Anda membangun dalam mendalam pada primitif AWS — DynamoDB, SQS, Lambda — bergerak ke cloud berbeda atau on-premise menjadi mahal. Counter-argumen Vogels adalah bahwa efisiensi operasional sekarang layak biaya portabilitas kemudian. Trade-off itu nyata, dan itu adalah keputusan setiap pemimpin teknik harus membuat secara eksplisit daripada default ke dalam.

---

Untuk membaca terkait arsitektur teknik dan penskalaan, lihat Gaya Kepemimpinan Linus Torvalds, Gaya Kepemimpinan Andy Grove, dan Gaya Kepemimpinan Martin Fowler.