Interviste
Kristin Isaac, CEO e Co-Fondatore di Strudel – Serie di Interviste
Kristin Isaac, CEO e Co-Fondatore di Strudel è un veterano leader tecnologico aziendale che ha ricoperto ruoli senior in LinkedIn, Udemy, ESPN e Disney prima di lanciare Strudel. Ora si concentra sull’eliminazione di uno dei maggiori punti di frizione nelle organizzazioni software: il divario tra il supporto clienti e l’ingegneria. In Strudel, sta costruendo una piattaforma guidata da AI che aiuta i team di supporto tecnico a risolvere problemi complessi più velocemente collegando le richieste di supporto direttamente all’intelligenza ingegneristica. La sua esperienza nel far crescere team, costruire strategie di mercato e guidare la crescita in organizzazioni globali ha aiutato a plasmare la rapida presa iniziale di Strudel e la forte posizione nel mercato dell’AI e degli strumenti per sviluppatori.
Strudel è una piattaforma AI progettata per automatizzare il supporto tecnico avanzato analizzando log, dati di produzione, repository di codice e storia di supporto passata per identificare le cause radice e raccomandare soluzioni. Il suo obiettivo è ridurre il tempo e lo sforzo ingegneristico necessari per risolvere casi di supporto difficili, in particolare le escalation che di solito consumano risorse tecniche senior. Collegando il supporto direttamente ai problemi tecnici sottostanti, Strudel si posiziona come uno strumento che può rendere le operazioni di supporto aziendale più veloci, efficienti e scalabili.
Ha ricoperto ruoli di leadership in organizzazioni come LinkedIn, Udemy e Disney prima di fondare Strudel nel 2025. Quali esperienze in quei ruoli l’hanno convinta che i team di ingegneria avevano bisogno di una nuova piattaforma di “intelligenza ingegneristica” guidata da AI, e come quell’intuizione ha plasmato la fondazione di Strudel?
Ogni azienda in cui ho lavorato aveva una versione diversa dello stesso problema. A Disney, le poste in gioco erano enormi – se una piattaforma di streaming andava giù durante un lancio importante, non era solo un colpo al fatturato, era un momento di marca. A LinkedIn, la scala era implacabile. C’erano migliaia di servizi che generavano rumore, e anche i migliori team faticavano a tenere il passo. A Udemy, ho visto un team magro fare cose eroiche con strumenti limitati.
Ciò che collegava tutti e tre e all’esperienza dei miei co-fondatori, Shai Rubin e Brian Kaufman, nel guidare team di ingegneria, era che gli ingegneri stavano spendendo più tempo a ricostruire il contesto che a risolvere realmente i problemi. Qualcuno viene chiamato alle 2 del mattino, e prima di poter iniziare a diagnosticare, stanno setacciando thread di Slack, dashboard, biglietti Jira, log di deploy – solo per capire cosa è cambiato e quando. Stanno essenzialmente giocando a detective prima di poter fare il loro lavoro vero. È uno spreco di persone incredibilmente talentuose.
Continuavo a pensare: deve esserci un modo più intelligente per portare alla luce ciò che realmente conta, quando conta. È realmente il seme di Strudel.
Molte aziende misurano l’impatto finanziario del downtime in termini di fatturato perso o penalità SLA. Nella sua esperienza, quali sono alcuni dei costi meno visibili degli outage che le organizzazioni sottostimano costantemente?
Il numero del fatturato finisce nel board deck, ma l’impatto immediato sul fatturato è solo una frazione di ciò che l’outage effettivamente costa. Quelli che vedo le organizzazioni costantemente trascurare rientrano in alcune categorie.
Il primo è la fiducia del cliente. Le penalità SLA sono una costruzione legale – non catturano il cliente che si disiscrive silenziosamente, o il prospetto aziendale che ha visto la pagina di stato al momento sbagliato e ha scelto un concorrente. Quel danno è lento, invisibile e permanente in un modo che un assegno di rimborso semplicemente non è.
Il secondo è l’abbandono e il burnout degli ingegneri. La fatica on-call è reale. Quando i migliori ingegneri vengono ripetutamente coinvolti in incidenti ad alto stress – specialmente quelli che potevano essere prevenuti – iniziano a chiedersi se questo è il posto giusto per costruire la loro carriera. Sostituire un ingegnere senior costa da uno a due volte il loro stipendio annuale quando si considera il reclutamento, l’onboarding e la perdita di conoscenze istituzionali. Nessuno lo mette nel post-mortem.
Il terzo è il costo di opportunità. Ogni ora che un team di ingegneria spende a combattere incendi è un’ora non spesa a costruire un prodotto. È difficile metterlo su uno spreadsheet, ma accumulato su mesi, silenziosamente fa esplodere la tua roadmap.
Gli ingegneri vengono spesso allontanati dal costruire nuove funzionalità per rispondere a incidenti di produzione. Come questo costante lavoro di estinzione degli incendi impatta l’innovazione del prodotto e le roadmap di sviluppo a lungo termine?
Crea una tassa sulla capacità del team di ingegneria di costruire. Ogni team ha una quantità finita di banda, e quando una parte significativa di essa continua a essere dirottata verso incidenti, l’effetto composto sullo sviluppo del prodotto è severo. Gli impegni della roadmap vengono persi. Il debito tecnico non viene pagato. Le funzionalità vengono spedite con meno rigore perché c’è pressione per recuperare il tempo perso.
Ciò che è particolarmente dannoso è l’imprevedibilità. Un team può pianificare il proprio sprint con buone intenzioni, e poi un incidente maggiore esplode di martedì e tutto il resto diventa secondario. Quel tipo di imprevedibilità sostenuta rende quasi impossibile costruire una cultura di lavoro profondo – che è alla fine ciò che guida i migliori risultati ingegneristici.
Crea anche un ciclo auto-rinforzante. Gli investimenti differiti significano più incidenti, che significano più lavoro di estinzione degli incendi, che significa ancora meno tempo per investire nei problemi sottostanti. In Strudel, una grossa parte di ciò che stiamo costruendo è specificamente per i team SRE che vivono questo ogni giorno.
Strudel collega i dati di supporto clienti, log, sistemi di produzione e repository di codice per identificare le cause radice più velocemente. Come l’AI unisce questi diversi segnali tecnici in un modo che gli strumenti di monitoraggio tradizionali non possono?
Gli strumenti di monitoraggio tradizionali sono fondamentalmente sistemi di allarme. Sono grandi per dirti che qualcosa ha superato una soglia – un picco di latenza, una frequenza di errore in aumento, un pod in crash. Ciò che non possono fare è ragionare attraverso domini.
Non sanno che il picco della frequenza di errore nel tuo servizio di pagamento è avvenuto quattro minuti dopo un deploy di una dipendenza, e che un biglietto di supporto clienti che menziona problemi di checkout è arrivato più o meno nello stesso momento, e che l’ultima volta che questo pattern si è verificato nei tuoi log è stato sei mesi fa durante una migrazione del database.
Quella correlazione cross-dominio è ciò che l’AI consente. Possiamo trattare un biglietto Zendesk, un commit GitHub, una traccia Datadog e un log CloudWatch come parte di una storia unificata piuttosto che punti di dati isolati. L’AI porta alla luce non solo cosa è rotto, ma anche il probabile perché e dove – e lo basa su prove che un ingegnere umano può effettivamente verificare e agire. Non stiamo chiedendo ai team di fidarsi di una scatola nera. Stiamo dando loro un’ipotesi ben ragionata e un vantaggio.
Descrive Strudel come fornitore di “intelligenza ingegneristica”. Cosa significa questo concetto nella pratica, e come si differenzia dalle piattaforme di osservabilità o AIOps convenzionali?
L’osservabilità è fondamentalmente questione di strumentazione e visibilità – assicurarsi che la telemetria sia presente e che i team possano interrogarla. L’AIOps, nella maggior parte delle sue implementazioni attuali, è questione di ridurre il rumore degli allarmi attraverso la correlazione e la rilevazione delle anomalie basate su ML. Entrambi sono genuinamente preziosi, e noi integriamo con loro.
Ma l’intelligenza ingegneristica è un livello sopra. Stiamo prendendo ciò che fa l’AIOps e ampliandolo. Laddove l’AIOps ti dice che qualcosa è sbagliato, l’intelligenza ingegneristica aiuta a capire perché è sbagliato, dove è iniziato e cosa fare al riguardo – attingendo a segnali da tutta la tua pila, comprese fonti che gli strumenti AIOps tradizionali non guardano nemmeno, come biglietti di supporto clienti o modifiche al codice. L’obiettivo non è solo ridurre il rumore. È dare al tuo team un’immagine completa e azionabile in modo che possano risolvere il problema più velocemente e tornare a costruire.
Pensateci come alla differenza tra un rilevatore di fumo e un investigatore di incendi. L’osservabilità e l’AIOps sono il rilevatore di fumo – essenziale, ma si ferma all’allarme. L’intelligenza ingegneristica è ciò che viene dopo: ecco cosa è successo, ecco perché, ecco dove è iniziato.
Gli agenti AI vengono sempre più utilizzati per automatizzare flussi di lavoro tecnici complessi. Qual è il ruolo che vede gli agenti AI svolgere nella diagnosi e risoluzione degli incidenti software nei prossimi cinque anni?
Penso che la domanda più interessante non sia cosa faranno gli agenti – ma cosa gli ingegneri smetteranno di fare. I migliori ingegneri con cui ho lavorato non sono entrati in questo campo per passare le loro notti a triare allarmi o a cercare nei log per una modifica di configurazione che qualcuno ha fatto di venerdì pomeriggio. Non è per questo che sono diventati bravi nel loro lavoro. Ma è ciò che una grande parte del loro tempo viene consumato.
Nei prossimi cinque anni, penso che gli agenti prendano su di sé molto di quel lavoro di routine – il lavoro di riconoscimento di pattern, di assemblaggio del contesto, che è importante ma non è dove il talento ingegneristico senior dovrebbe spendere il suo tempo. Ciò libera le persone per concentrarsi sui problemi complessi, le decisioni architettoniche, le cose che richiedono realmente giudizio umano.
Ciò che è emozionante per me è che non si tratta solo di uno stato futuro – lo stiamo vedendo realizzarsi proprio adesso, compreso in Strudel. La nostra intera roadmap è orientata a rimuovere il lavoro amministrativo e di manutenzione dalle piastre degli ingegneri. E ciò che stiamo trovando, onestamente, è che cambia ciò che è possibile per un team. Puoi costruire di più, muoverti più velocemente e farlo con meno persone – perché le persone che hai sono concentrate sulla strategia e sulla complessità piuttosto che pagare i loro debiti sul lavoro ripetitivo. Sembra un cambiamento significativo nel modo in cui i team vengono costruiti e strutturati in futuro.
Molte interruzioni originano da piccoli bug o modifiche di configurazione che sfuggono al testing. Come possono i sistemi AI identificare pattern sottili nel codice, log o segnali di infrastruttura abbastanza presto per prevenire incidenti maggiori?
Un AI ben progettato ha un vero vantaggio qui, e non è che sia più intelligente dei suoi ingegneri – è che non dimentica mai e non dorme mai. Un umano potrebbe non collegare un pattern di log sottile di oggi a qualcosa che è successo sei mesi fa in una parte completamente diversa del sistema. L’AI può. Sta guardando tutto, tutto il tempo, e ha una memoria molto più lunga e ampia di qualsiasi individuo nel tuo team.
Detto questo, c’è anche qualcos’altro che sento dai clienti molto spesso: la prevenzione è solo buona quanto i dati sottostanti. Se i tuoi log sono inconsistenti, incompleti o frammentati in una dozzina di strumenti che non parlano tra loro, l’AI sta lavorando con un’immagine frammentata. Spazzatura dentro, spazzatura fuori – è ancora vero. Passiamo molto tempo con i clienti aiutandoli a pensare alla qualità dei dati e alla strumentazione perché il miglior AI del mondo non può portare alla luce un segnale che non è stato catturato in primo luogo.
Quindi la risposta è entrambi: sì, l’AI può cogliere le cose prima e collegare i punti che gli umani potrebbero perdere. Ma i team che ottengono il maggior valore da esso sono quelli che hanno anche fatto il lavoro per assicurarsi che i loro dati siano effettivamente degni di essere ragionati.
Le aziende spesso investono molto in strumenti di rilevamento ma ancora lottano con il tempo medio di risoluzione. Quali sono i maggiori ostacoli che impediscono alle organizzazioni di colmare il divario tra la rilevazione degli incidenti e la risoluzione effettiva della causa radice?
La rilevazione è fondamentalmente un problema risolto a questo punto. La maggior parte dei team ha allarmi. Sanno che qualcosa è sbagliato. Il divario è tutto ciò che accade dopo.
Quando un ingegnere viene chiamato, non entra in una situazione chiara con tutto il contesto rilevante assemblato. Entra in un pasticcio. Deve capire cosa è cambiato, quando è cambiato, quale sistema ha toccato, se c’è un impatto sul cliente, se è relazionato a qualcosa che è successo la settimana scorsa. Sta estraendo da Slack, da dashboard, da biglietti Jira, da log di deploy – solo per capire cosa sta realmente guardando. Quell’assemblaggio del contesto è l’ostacolo. Non è che gli ingegneri e i team di supporto tecnico non sappiano come risolvere problemi – è che stanno spendendo i primi 30-60 minuti di ogni incidente solo per capire cosa stanno realmente guardando. È lì che vive Strudel. La nostra intera tesi è che se puoi consegnare a un ingegnere un’immagine coerente e supportata da prove di ciò che è successo e perché – proprio quando ne ha bisogno – comprimi drasticamente quel divario. Il lavoro di risoluzione è ancora loro. Noi li portiamo solo alla linea di partenza molto più velocemente.
Man mano che i sistemi AI iniziano ad analizzare dati di produzione, codice e log operativi, quali considerazioni di governance o sicurezza gli ingegneri dovrebbero tenere presente durante il deploy di questi strumenti?
La cosa di cui mi preoccupo di più qui è che gli umani dovrebbero ancora revisionare il codice che va in produzione.
Ho parlato con molti ingegneri di questo, e una cosa che sento ripetere è che l’AI scrive bug in modo efficiente e astuto. Davvero astuto, in realtà. In un modo che può essere genuinamente difficile da cogliere – anche per ingegneri senior che revisionano il codice con cura. I bug non sono sempre ovvi. Possono sembrare perfettamente ragionevoli a un’occhiata.
Quindi, man mano che l’AI scrive più e più codice che finisce in produzione, penso che vedremo più di questi problemi sottili e difficili da rilevare sfuggire – non perché qualcuno è stato negligente, ma perché la natura dei bug generati dall’AI è diversa. Più difficile da rilevare in revisione. Più difficile da cogliere nel testing.
Onestamente? È una delle ragioni per cui penso che il caso per ciò che fa Strudel diventa solo più forte con il tempo. Se più bug stanno finendo in produzione, la capacità di trovarli e risolverli più velocemente diventa più importante, non meno. La questione di governance non è solo sui controlli di accesso ai dati e sulle autorizzazioni – sebbene quelle cose contino e i team dovrebbero essere pensierosi su quali dati stanno dando accesso a qualsiasi sistema AI. È anche sul tenere gli umani ai punti di controllo giusti, specialmente intorno a tutto ciò che tocca la produzione.
Guardando avanti, pensa che il futuro dell’ingegneria della affidabilità si sposti verso un’infrastruttura AI-first, dove sistemi autonomi monitorano, diagnosticano e addirittura risolvono problemi prima che gli umani ne siano a conoscenza? Se sì, cosa sembra il flusso di lavoro futuro per gli ingegneri?
Penso che stiamo andando in quella direzione, ma sono pragmatica sul cronogramma. Sistemi completamente autonomi che risolvono incidenti di produzione senza alcuna consapevolezza umana – non è dove siamo, e non penso che lo saremo nei prossimi few anni. E penso che va bene.
Ciò in cui credo è che il ciclo si stringe e diventa molto meno doloroso. Il futuro che mi emoziona non è uno in cui gli umani vengono rimossi dall’equazione – è uno in cui gli umani integrati nel processo spendono il loro tempo sulle parti che realmente richiedono loro. Chiamate di giudizio. Situazioni nuove. Un incidente che non hai mai visto prima. L’AI gestisce il riconoscimento di pattern, l’assemblaggio del contesto, la triage di routine. Gli ingegneri gestiscono le decisioni.
Per gli ingegneri stessi, penso che assomiglia a: meno tempo in turno di notte per cose che non dovevano svegliarli, e più tempo a costruire sistemi che non si rompono per prima. Il lavoro di estinzione degli incendi non scompare del tutto. Ma diventa l’eccezione piuttosto che lo stato di default di essere un ingegnere in un’azienda che esegue software su larga scala. È un futuro verso il quale vale la pena costruire.
Grazie per la grande intervista, i lettori che desiderano saperne di più possono visitare Strudel.
