Kristin Isaac, CEO dan Co-Founder di Strudel – Seri Wawancara

Kristin Isaac, CEO dan Co-Founder di Strudel adalah seorang pemimpin teknologi perusahaan yang berpengalaman yang telah memegang posisi senior di LinkedIn, Udemy, ESPN, dan Disney sebelum meluncurkan Strudel. Ia sekarang fokus untuk mengatasi salah satu titik gesekan terbesar di organisasi perangkat lunak: kesenjangan antara dukungan pelanggan dan teknik. Di Strudel, ia membangun platform yang didorong oleh AI yang membantu tim dukungan teknis menyelesaikan masalah kompleks lebih cepat dengan menghubungkan permintaan dukungan langsung ke kecerdasan teknik. Latar belakangnya dalam menskalakan tim, membangun strategi go-to-market, dan mengarahkan pertumbuhan di seluruh organisasi global telah membantu membentuk traksi awal yang cepat dan posisi yang kuat di pasar alat pengembang dan AI perusahaan.

Strudel adalah platform AI yang dibangun untuk mengotomatisasi dukungan teknis lanjutan dengan menganalisis log, data produksi, repositori kode, dan riwayat dukungan sebelumnya untuk mengidentifikasi penyebab akar dan merekomendasikan solusi. Tujuannya adalah untuk mengurangi waktu dan upaya teknik yang diperlukan untuk menyelesaikan kasus dukungan yang sulit, terutama jenis eskalasi yang biasanya menghabiskan sumber daya teknis senior. Dengan menghubungkan dukungan langsung ke masalah teknis yang mendasarinya, Strudel memposisikan diri sebagai alat yang dapat membuat operasi dukungan perusahaan lebih cepat, lebih efisien, dan lebih scalable.

Anda telah memegang posisi kepemimpinan di organisasi seperti LinkedIn, Udemy, dan Disney sebelum mendirikan Strudel pada 2025. Pengalaman apa dari posisi tersebut yang akhirnya membawa Anda kepada keyakinan bahwa tim teknik membutuhkan platform “kecerdasan teknik” yang didorong oleh AI, dan bagaimana wawasan tersebut membentuk pendirian Strudel?

Setiap perusahaan yang saya kerjakan memiliki versi yang berbeda dari masalah yang sama. Di Disney, taruhannya sangat besar – jika platform streaming mengalami gangguan selama peluncuran besar, itu tidak hanya mengenai pendapatan, tetapi juga momen merek. Di LinkedIn, skala yang tak henti-hentinya. Ada ribuan layanan yang semua menghasilkan kebisingan, dan bahkan tim terbaik berjuang untuk mengikuti.

Apa yang menghubungkan ketiganya dan pengalaman co-founder saya, Shai Rubin dan Brian Kaufman, dalam memimpin tim teknik, adalah bahwa insinyur menghabiskan lebih banyak waktu untuk merekonstruksi konteks daripada benar-benar menyelesaikan masalah. Seseorang dipanggil pada pukul 2 pagi, dan sebelum mereka bahkan dapat memulai diagnosis, mereka menyusuri thread Slack, dashboard, tiket Jira, log penerapan – hanya mencoba memahami apa yang berubah dan kapan. Mereka pada dasarnya bermain detektif sebelum mereka dapat melakukan pekerjaan sebenarnya. Itu adalah pemborosan bakat luar biasa.

Saya terus memikirkan: harus ada cara yang lebih cerdas untuk menyajikan apa yang benar-benar penting, saat itu penting. Itulah benih Strudel.

Banyak perusahaan mengukur dampak keuangan dari gangguan dalam bentuk pendapatan yang hilang atau penalti SLA. Dalam pengalaman Anda, apa saja biaya yang tidak terlihat dari gangguan yang konsisten diremehkan oleh organisasi?

Angka pendapatan masuk ke dalam dek bord, tetapi dampak pendapatan segera hanya sebagian dari apa yang sebenarnya gangguan itu biayai. Yang saya lihat organisasi sering melewatkan jatuh ke dalam beberapa kategori.

Yang pertama adalah kepercayaan pelanggan. Penalti SLA adalah konstruk hukum – mereka tidak menangkap pelanggan yang diam-diam berhenti berlangganan, atau prospek perusahaan yang melihat halaman status Anda pada saat yang salah dan memilih kompetitor. Kerusakan itu lambat, tidak terlihat, dan permanen dengan cara yang cek pengembalian tidak.

Yang kedua adalah atrisi insinyur dan kelelahan. Kebutuhan pada-caller yang sebenarnya. Ketika insinyur terbaik Anda terus-menerus ditarik ke dalam insiden yang penuh tekanan – terutama yang bisa dicegah – mereka mulai mempertanyakan apakah ini tempat yang tepat untuk membangun karier mereka. Menggantikan insinyur senior membutuhkan biaya antara satu hingga dua kali gaji tahunan mereka ketika Anda mempertimbangkan perekrutan, onboarding, dan kehilangan pengetahuan institusional. Tidak ada yang memasukkan itu ke dalam post-mortem.

Yang ketiga adalah biaya kesempatan. Setiap jam tim teknik menghabiskan waktu untuk memerangi kebakaran adalah satu jam yang tidak dihabiskan untuk membangun produk. Itu sulit untuk dimasukkan ke dalam spreadsheet, tetapi dikompresi selama berbulan-bulan, itu diam-diam meledak roadmap Anda.

Insinyur sering ditarik dari membangun fitur baru untuk merespons insiden produksi. Bagaimana pemadaman kebakaran yang konstan ini mempengaruhi inovasi produk dan peta jalan pengembangan jangka panjang?

Ini menciptakan pajak pada kemampuan tim teknik Anda untuk membangun. Setiap tim memiliki bandwidth yang terbatas, dan ketika sebagian besar bandwidth itu terus-menerus diarahkan ke insiden, efek kumulatif pada pengembangan produk sangat parah. Komitmen roadmap terlewat. Utang teknis tidak dibayar. Fitur dikirim dengan kurang ketat karena ada tekanan untuk mengganti waktu yang hilang.

Apa yang merusak adalah ketidakpastian. Tim dapat merencanakan sprint dengan niat baik, dan kemudian insiden besar meledak pada hari Selasa dan semua yang lain menjadi sekunder. Ketidakpastian yang berkelanjutan itu membuatnya hampir mustahil untuk membangun budaya kerja dalam – yang pada akhirnya mengarahkan hasil teknik terbaik.

Ini juga menciptakan siklus yang memperkuat diri sendiri. Investasi yang ditunda berarti lebih banyak insiden, yang berarti lebih banyak pemadaman kebakaran, yang berarti lebih sedikit waktu untuk berinvestasi pada masalah yang mendasarinya. Di Strudel, bagian besar dari apa yang kami bangun khusus untuk tim SRE yang mengalami ini setiap hari.

Strudel menghubungkan data dukungan pelanggan, log, sistem produksi, dan repositori kode untuk mengidentifikasi penyebab akar lebih cepat. Bagaimana AI menghubungkan sinyal teknis yang berbeda ini dengan cara yang tidak dapat dilakukan oleh alat pemantauan tradisional?

Alat pemantauan tradisional pada dasarnya adalah sistem peringatan. Mereka hebat dalam mengatakan bahwa sesuatu telah melewati ambang – lonjakan latensi, tingkat kesalahan yang meningkat, pod yang crash. Apa yang tidak bisa mereka lakukan adalah bernalar melintasi domain.

Mereka tidak tahu bahwa lonjakan tingkat kesalahan di layanan pembayaran Anda terjadi empat menit setelah penerapan ke ketergantungan, dan bahwa tiket dukungan pelanggan yang menyebutkan kegagalan checkout datang sekitar waktu yang sama, dan bahwa pola ini terakhir kali muncul di log Anda enam bulan yang lalu selama migrasi database.

Korelasi antar domain itu yang diaktifkan oleh AI. Kami dapat memperlakukan tiket Zendesk, komit GitHub, jejak Datadog, dan log CloudWatch sebagai bagian dari satu cerita yang terpadu daripada poin data yang terisolasi. AI menyajikan tidak hanya apa yang rusak, tetapi mengapa dan di mana – dan itu didasarkan pada bukti yang dapat diverifikasi dan diaktifkan oleh insinyur manusia. Kami tidak meminta tim untuk mempercayai kotak hitam. Kami memberi mereka hipotesis yang terbukti dan awal yang cepat.

Anda menjelaskan Strudel sebagai memberikan “kecerdasan teknik”. Apa yang dimaksud dengan konsep ini dalam prakteknya, dan bagaimana itu berbeda dari platform observabilitas atau AIOps konvensional?

Kristin: Observabilitas pada dasarnya tentang instrumentasi dan visibilitas – memastikan bahwa telemetry ada dan tim dapat mengquerynya. AIOps, dalam sebagian besar implementasinya saat ini, adalah tentang mengurangi kebisingan peringatan melalui korelasi dan deteksi anomali berbasis ML. Keduanya sangat berharga, dan kami mengintegrasikannya.

Tapi kecerdasan teknik adalah lapisan di atas. Kami mengambil apa yang AIOps lakukan dan memperluasnya. Di mana AIOps mengatakan sesuatu salah, kecerdasan teknik membantu Anda memahami mengapa itu salah, dari mana itu berasal, dan apa yang harus dilakukan tentang hal itu – menarik sinyal dari seluruh tumpukan Anda, termasuk sumber yang alat AIOps tradisional tidak melihat, seperti tiket dukungan pelanggan atau perubahan kode. Tujuannya bukan hanya mengurangi kebisingan. Ini adalah memberi tim Anda gambaran lengkap dan dapat diaktifkan sehingga mereka dapat menyelesaikan masalah lebih cepat dan kembali membangun.

Pikirkan ini sebagai perbedaan antara detektor asap dan penyelidik kebakaran. Observabilitas dan AIOps adalah detektor asap – penting, tetapi mereka berhenti di peringatan. Kecerdasan teknik adalah apa yang terjadi setelahnya: ini yang terjadi, ini mengapa, ini dari mana itu berasal.

Agen AI semakin banyak dikerahkan untuk mengotomatisasi alur kerja teknis yang kompleks. Peran apa yang Anda lihat agen AI memainkan dalam mendiagnosis dan menyelesaikan insiden perangkat lunak selama lima tahun ke depan?

Saya pikir pertanyaan yang lebih menarik bukanlah apa yang agen akan lakukan – tetapi apa yang insinyur akan berhenti lakukan. Insinyur terbaik yang saya kerjakan dengan tidak masuk ke bidang ini untuk menghabiskan malam mereka untuk menangani peringatan atau menyusuri log untuk perubahan konfigurasi yang dilakukan pada hari Jumat sore. Itu bukan mengapa mereka menjadi baik dalam pekerjaan mereka. Tapi itu adalah apa yang sebagian besar waktu mereka habiskan.

Selama lima tahun ke depan, saya pikir agen mengambil sebagian besar dari pekerjaan itu – pekerjaan pengulangan, pencocokan pola, dan perakitan konteks yang penting tetapi tidak di mana bakat insinyur senior harus dihabiskan. Itu membebaskan orang untuk fokus pada masalah kompleks, keputusan arsitektur, hal-hal yang benar-benar memerlukan penilaian manusia.

Apa yang menarik bagi saya adalah bahwa ini bukan hanya keadaan di masa depan – kami melihatnya terjadi sekarang, termasuk di Strudel. Seluruh roadmap kami diarahkan untuk menghapus pekerjaan administratif dan pemeliharaan dari piring insinyur. Dan apa yang kami temukan, jujur, adalah bahwa itu mengubah apa yang mungkin untuk sebuah tim. Anda dapat membangun lebih banyak, bergerak lebih cepat, dan melakukannya dengan lebih sedikit orang – karena orang yang Anda miliki fokus pada strategi dan kompleksitas daripada membayar upah pada hal-hal berulang. Itu terasa seperti perubahan yang signifikan dalam cara tim dibangun dan diatur ke depan.

Banyak gangguan berasal dari bug kecil atau perubahan konfigurasi yang terlewatkan dalam pengujian. Bagaimana sistem AI dapat mengidentifikasi pola halus dalam kode, log, atau sinyal infrastruktur cukup awal untuk mencegah insiden besar?

AI yang dirancang dengan baik memiliki keuntungan nyata di sini, dan itu bukan karena lebih pintar dari insinyur Anda – tetapi karena tidak pernah lupa dan tidak pernah tidur. Seorang manusia mungkin tidak menghubungkan pola log halus hari ini dengan sesuatu yang terjadi enam bulan yang lalu di bagian lain sistem. AI bisa. Ini memantau semua, sepanjang waktu, dan memiliki memori yang lebih panjang dan lebih luas daripada individu mana pun di tim Anda.

Tetapi ada hal lain yang kami dengar dari pelanggan banyak: pencegahan hanya sebaik data yang mendasarinya. Jika log Anda tidak konsisten, tidak lengkap, atau terisolasi di selusin alat yang tidak berbicara satu sama lain, AI bekerja dengan gambaran yang terfragmentasi. Sampah masuk, sampah keluar – itu masih benar. Kami menghabiskan banyak waktu dengan pelanggan untuk membantu mereka memikirkan kualitas data dan instrumentasi karena AI terbaik di dunia tidak dapat menyajikan sinyal yang tidak pernah ditangkap sebelumnya.

Jadi jawabannya adalah keduanya: ya, AI dapat menangkap hal-hal lebih awal dan menghubungkan titik-titik yang manusia akan lewatkan. Tapi tim yang mendapatkan nilai terbaik dari itu adalah mereka yang telah melakukan pekerjaan untuk memastikan data mereka sebenarnya layak untuk diatur.

Perusahaan sering berinvestasi besar dalam alat deteksi tetapi masih berjuang dengan waktu rata-rata untuk resolusi. Apa yang menjadi penghalang terbesar yang mencegah organisasi menutup kesenjangan antara deteksi insiden dan resolusi penyebab akar?

Deteksi pada dasarnya adalah masalah yang sudah terpecahkan pada titik ini. Sebagian besar tim memiliki peringatan. Mereka tahu sesuatu salah. Kesenjangan adalah segala sesuatu yang terjadi setelah itu.

Ketika seorang insinyur dipanggil, mereka tidak memasuki situasi yang jelas dengan semua konteks yang relevan yang teratur. Mereka memasuki kekacauan. Mereka harus mencari tahu apa yang berubah, kapan itu berubah, sistem mana yang disentuh, apakah ada dampak pelanggan, apakah itu terkait dengan sesuatu yang terjadi minggu lalu. Mereka menarik dari Slack, dari dashboard, dari tiket Jira, dari log penerapan – melakukan pekerjaan perakitan konteks secara manual, di bawah tekanan, sering di tengah malam.

Perakitan konteks itu adalah bottleneck. Bukan karena insinyur dan tim dukungan teknis tidak tahu cara menyelesaikan masalah – tetapi karena mereka menghabiskan 30 hingga 60 menit pertama dari setiap insiden hanya mencoba memahami apa yang mereka lihat sebenarnya. Itulah di mana Strudel hidup. Seluruh tesis kami adalah bahwa jika Anda dapat memberikan insinyur gambaran yang kohesif, didukung bukti, tentang apa yang terjadi dan mengapa – tepat ketika mereka membutuhkannya – Anda secara dramatis mengompresi kesenjangan itu. Pekerjaan resolusi masih milik mereka. Kami hanya mendapatkan mereka ke garis start lebih cepat.

Ketika sistem AI mulai menganalisis data produksi, kodebase, dan log operasional, apa yang harus dipertimbangkan oleh tim teknik dalam hal tata kelola atau keamanan saat menerapkan alat ini?

Hal yang saya rasakan paling kuat tentang hal ini adalah: manusia masih harus meninjau kode yang masuk ke produksi.

Saya telah berbicara dengan banyak insinyur tentang hal ini, dan satu hal yang saya dengar berulang-ulang adalah bahwa AI menulis bug dengan efisien dan cerdas. Sangat cerdas, sebenarnya. Dalam cara yang bisa sulit untuk ditangkap – bahkan oleh insinyur senior yang meninjau kode dengan hati-hati. Bug tidak selalu jelas. Mereka bisa terlihat sangat masuk akal pada pandangan pertama.

Jadi ketika AI menulis lebih banyak kode yang masuk ke produksi, saya pikir kita akan melihat lebih banyak masalah halus ini slip melalui – tidak karena siapa pun yang ceroboh, tetapi karena sifat bug AI yang dihasilkan berbeda. Lebih sulit untuk ditemukan dalam tinjauan. Lebih sulit untuk ditangkap dalam pengujian.

Jujur, itu adalah salah satu alasan mengapa saya pikir kasus untuk apa yang Strudel lakukan hanya menjadi lebih kuat seiring waktu. Jika lebih banyak bug masuk ke produksi, kemampuan untuk menemukan dan menyelesaikannya lebih cepat menjadi lebih penting, bukan kurang. Pertanyaan tata kelola bukan hanya tentang kontrol akses data dan izin – meskipun itu penting dan tim harus berpikir tentang apa data yang mereka berikan akses ke sistem AI. Ini juga tentang menjaga manusia di checkpoint yang tepat, terutama di sekitar apa pun yang menyentuh produksi.

Menghadap ke depan, apakah Anda pikir masa depan teknik keandalan akan bergeser ke arah infrastruktur AI-pertama, di mana sistem otonom memantau, mendiagnosis, dan bahkan memperbaiki masalah sebelum manusia menyadarinya? Jika demikian, apa yang terlihat seperti alur kerja untuk insinyur?

Saya pikir kita menuju ke arah itu, tetapi saya pragmatis tentang timeline. Sistem otonom yang sepenuhnya menyelesaikan insiden produksi tanpa kesadaran manusia – itu bukan di mana kita sekarang, dan saya tidak pikir itu di mana kita akan berada dalam beberapa tahun ke depan. Dan saya pikir itu tidak apa-apa.

Apa yang saya percayai adalah bahwa loop itu menjadi lebih ketat dan kurang menyakitkan. Masa depan yang saya eksit tentang bukanlah di mana manusia dihilangkan dari persamaan – itu adalah di mana manusia yang terintegrasi ke dalam proses menghabiskan waktu mereka pada bagian yang benar-benar memerlukan mereka. Panggilan penilaian. Situasi baru. Insiden yang tidak pernah Anda lihat sebelumnya. AI menangani pencocokan pola, perakitan konteks, triase rutin. Insinyur menangani keputusan.

Bagi insinyur itu sendiri, saya pikir itu terlihat seperti: lebih sedikit waktu on-call di tengah malam untuk hal-hal yang tidak perlu membangunkan mereka, dan lebih banyak waktu untuk membangun sistem yang tidak pecah di tempat pertama. Pemadaman kebakaran tidak menghilang sepenuhnya. Tapi itu menjadi pengecualian daripada keadaan default menjadi insinyur di perusahaan yang menjalankan perangkat lunak dengan skala. Itu adalah masa depan yang layak dibangun.

Terima kasih atas wawancara yang luar biasa, pembaca yang ingin mempelajari lebih lanjut harus mengunjungi Strudel.