Kristin Isaac, CEO og medgrunnlegger i Strudel – Intervju-serie

Kristin Isaac, CEO og medgrunnlegger i Strudel, er en erfaren leder innen bedriftsteknologi som har hatt seniort stillinger i LinkedIn, Udemy, ESPN og Disney før hun startet Strudel. Hun fokuserer nå på å løse ett av de største friksjonspunktene i programvareorganisasjoner: gapet mellom kundesupport og ingeniørarbeid. Hos Strudel bygger hun en AI-drevet plattform som hjelper tekniske supportteam å løse komplekse problemer raskere ved å koble supportforespørsler direkte til ingeniør-intelligens. Hennes bakgrunn i å skale team, bygge markedsstrategier og drive vekst i globale organisasjoner har bidratt til Strudels rask tidlige fremgang og sterke posisjonering i bedrifts-AI- og utviklerverktøy-markedet.

Strudel er en AI-plattform bygget for å automatisere avansert teknisk support ved å analysere logger, produksjonsdata, kode-repositorier og tidligere support-historikk for å identifisere rotårsaker og anbefale løsninger. Målet er å redusere tiden og ingeniør-innsatsen som kreves for å løse vanskelige support-saker, spesielt de typene eskalasjoner som vanligvis forbruker senior-tekniske ressurser. Ved å koble support direkte til underliggende tekniske problemer, stiller Strudel seg som et verktøy som kan gjøre bedrifts-support-operasjoner raskere, mer effektive og mer skalerbare.

Du har hatt lederstillinger i organisasjoner som LinkedIn, Udemy og Disney før du startet Strudel i 2025. Hva erfaringer fra disse stillingene overbeviste deg om at ingeniørteam trengte en ny type AI-drevet “ingeniør-intelligens”-plattform, og hvordan formede denne innsikten grunnleggingen av Strudel?

Hver bedrift jeg arbeidet for hadde en annen versjon av samme problem. Hos Disney var innsatsen enorm – hvis en strømmingtjeneste gikk ned under en stor lansering, var det ikke bare et inntekts-tap, men et merke-øyeblikk. Hos LinkedIn var skalaen relentløs. Det var tusenvis av tjenester som alle genererte støy, og selv de beste teamene kjempet for å holde pace. Hos Udemy så jeg et lean-team gjøre helte-ting med begrensede verktøy.

Hva som knyttet alle tre sammen, og til mine med-grunnleggeres, Shai Rubins og Brian Kaufmans erfaring med å lede ingeniørteam, var at ingeniører tilbrakte mer tid med å rekonstruere kontekst enn å faktisk løse problemer. Når noen blir vekket klokken 02.00, og før de kan begynne å diagnostisere, må de gå gjennom Slack-tråder, dashboards, Jira-billetter, deploy-logger – bare for å forstå hva som skjedde og når. De spiller i realiteten detektiv før de kan gjøre sitt faktiske jobb. Det er en spille av usedvanlig talentfulle mennesker.

Jeg tenkte hele tiden: det må være en smartere måte å fremheve hva som faktisk betyr noe, når det betyr noe. Det er virkelig frøet til Strudel.

Mange bedrifter måler den finansielle påvirkningen av nedtider i form av tapte inntekter eller SLA-straffer. I din erfaring, hva er noen av de mindre synlige kostnadene ved nedtider som organisasjoner jevnt over undervurderer?

Inntekts-tallet kommer inn i styre-mappen, men den umiddelbare inntekts-påvirkningen er bare en brøkdel av hva nedtiden faktisk koster. De jeg har sett organisasjoner jevnt over overse er:

Først er det kundetillit. SLA-straffer er en juridisk konstruksjon – de fanger ikke kunden som stille og rolig forlater, eller bedrifts-prospektet som så status-siden på feil tidspunkt og valgte en konkurranse. Den skaden er sakte, usynlig og permanent på en måte som en refusjonsjekke ikke er.

Det andre er ingeniør-avgang og utbrenthet. On-call-utmattelse er virkelig. Når dine beste ingeniører blir trukket inn i høy-stress-hendelser – spesielt de som kunne ha blitt forebygget – begynner de å spørre om dette er riktig sted å bygge sin karriere. Erstatning av en senior-ingeniør koster hvor som helst fra en til to ganger deres årlige lønn når du faktorer inn rekruttering, onboarding og tapt institusjonell kunnskap. Ingen legger det i post-mortem.

Det tredje er mulighetskostnad. Hver time et ingeniør-team tilbringer med å slåss mot brann er en time ikke brukt på å bygge produkt. Det er vanskelig å sette på en regneark, men samlet over måneder, ødelegger det stille din roadmap.

Ingeniører blir ofte trukket bort fra å bygge nye funksjoner for å svare på produksjons-hendelser. Hvordan påvirker denne konstante brann-slukkingen produkt-innovasjon og langsiktige utviklings-veikart?

Det skaper en avgift på ditt ingeniør-teamets evne til å bygge. Hvert team har en begrenset mengde kapasitet, og når en betydelig del av den hele tiden blir omdirigert til hendelser, er den kumulative effekten på produktutvikling alvorlig. Veikart-forpliktelser blir missede. Teknisk gjeld blir ikke betalt ned. Funksjoner blir levert med mindre rigor fordi det er press for å gjøre opp for tapt tid.

Hva som er spesielt skadelig er uforutsigbarheten. Et team kan planlegge sin sprint med gode intensjoner, og så blir en stor hendelse utløst på en tirsdag og alt annet blir sekundært. Denne type vedvarende uforutsigbarhet gjør det nesten umulig å bygge en kultur av dyp arbeid – som ultimate driver de beste ingeniør-resultatene.

Det skaper også en selv-forsterkende syklus. Utsatt investering betyr flere hendelser, som betyr mer brann-slukking, som betyr enda mindre tid til å investere i de underliggende problemene. Hos Strudel er en stor del av hva vi bygger spesifikt for SRE-teamene som lever dette hver dag.

Strudel kobler kundesupport-data, logger, produksjonssystemer og kode-repositorier for å identifisere rotårsaker raskere. Hvordan bringer AI sammen disse forskjellige tekniske signalene på en måte som tradisjonelle overvåkings-verktøy ikke kan?

Tradisjonelle overvåkings-verktøy er fundamentalt alert-systemer. De er gode til å fortelle deg noe har krysset en terskel – en latens-spike, en feil-rate som stiger, en pod-crash. Hva de ikke kan gjøre er å resonnere over domener.

De vet ikke at feil-raten-spike i din betalings-tjeneste skjedde fire minutter etter en deploy til en avhengighet, og at en kundesupport-billett som nevner kjøps-feil kom inn omtrent samme tid, og at siste gang denne mønsteren dukket opp i dine logger var for seks måneder siden under en database-migrering.

Denne tverr-domen-korrelasjonen er hva AI muliggjør. Vi kan behandle en Zendesk-billett, en GitHub-kommit, en Datadog-sporing og en CloudWatch-logg som en del av en samlet historie i stedet for isolerte data-punkter. AI overflater ikke bare hva som er feil, men også den sannsynlige årsak og hvor – og den grunner det i bevis som en menneskelig ingeniør faktisk kan verifisere og handle på. Vi ber ikke teamene om å stole på en svart boks. Vi gir dem en velfunderet hypotese og en forhånds-start.

Du beskriver Strudel som leverer “ingeniør-intelligens”. Hva betyr dette konseptet i praksis, og hvordan er det forskjellig fra konvensjonell overvåkning eller AIOps-plattformer?

Kristin: Overvåkning er fundamentalt om instrumentering og synlighet – å sikre at telemetri er der og at teamene kan spørring det. AIOps, i de fleste av sine nåværende implementasjoner, er om å redusere alert-støy gjennom ML-basert korrelasjon og anomaly-deteksjon. Begge er virkelig verdifulle, og vi integrerer med dem.

Men ingeniør-intelligens er et lag over. Vi tar hva AIOps gjør og utvider på det. Der AIOps forteller deg noe er feil, hjelper ingeniør-intelligens deg å forstå hvorfor det er feil, hvor det startet og hva du skal gjøre med det – trekker signaler fra hele din stack, inkludert kilder tradisjonelle AIOps-verktøy ikke ser på, som kundesupport-billetter eller kode-endringer. Målet er ikke bare å redusere støy. Det er å gi ditt team en fullstendig, handlebar bilde så de kan løse problemet raskere og komme tilbake til å bygge.

Tenk på det som forskjellen mellom en røyk-detektor og en brann-etterforsker. Overvåkning og AIOps er røyk-detonatoren – essensiell, men de stopper ved alarmen. Ingenicør-intelligens er hva som skjer etter: her er hva som skjedde, her er hvorfor, her er hvor det startet.

AI-agenter blir stadig mer deployert for å automatisere komplekse tekniske arbeidsflyter. Hva rolle ser du AI-agenter spille i å diagnostisere og løse programvare-hendelser de neste fem årene?

Jeg tror det mer interessante spørsmålet ikke er hva agenter vil gjøre – det er hva ingeniører vil slutte å gjøre. De beste ingeniører jeg har arbeidet med, ble ikke med i denne bransjen for å tilbringe netter med å triage-alarm eller jakte gjennom logger for en konfig-endring noen gjorde på en fredag-ettermiddag. Det er ikke hvorfor de ble gode på jobben sin. Men det er hva en stor del av deres tid blir spist opp av.

De neste fem årene tror jeg agenter tar på seg mye av denne sliten – den repetitive, mønster-matching, kontekst-sammenstilling-arbeidet som er viktig, men ikke hvor senior-ingeniør-talent bør tilbringe sin tid. Det frigjør mennesker til å fokusere på komplekse problemer, arkitektur-beslutninger, ting som faktisk krever menneskelig dømmekraft.

Hva som er spennende for meg er at dette ikke bare er en fremtid-tilstand – vi ser det utspille seg nå, inkludert hos Strudel. Vår hele veikart er orientert rundt å fjerne administrativt og vedlikeholds-arbeid fra ingeniørers tallerkener. Og hva vi finner, ærlig talt, er at det endrer hva som er mulig for et team. Du kan bygge mer, flytte raskere og gjøre det med færre mennesker – fordi menneskene du har er fokusert på strategi og kompleksitet i stedet for å betale sine skatter på det repetitive-stoffet. Det føles som en meningsfull skift i hvordan team blir bygget og strukturert fremover.

Mange nedtider oppstår fra små feil eller konfigurasjons-endringer som glipper gjennom testing. Hvordan kan AI-systemer identifisere subtile mønster i kode, logger eller infrastruktur-signaler tidlig nok til å forhindre store hendelser?

Veldesignet AI har en virkelig fordel her, og det er ikke at det er smartere enn dine ingeniører – det er at det aldri glemmer og aldri sover. En menneskelig kan ikke koble en subtil log-mønster i dag til noe som skjedde for seks måneder siden i en helt annen del av systemet. AI kan. Det ser på alt, hele tiden, og det har en mye lengre og bredere minne enn noen enkelt person på ditt team.

Det sagt, er det også noe annet jeg hører fra kunder ofte: forebygging er bare så god som dataene under. Hvis dine logger er inkonsistente, ufullstendige eller fragmenterte over en dusin verktøy som ikke snakker sammen, er AI-arbeidet med en fragmentert bilde. Skrald inn, skrald ut – det er fortsatt sant. Vi tilbringer mye tid med kunder til å tenke på data-kvalitet og instrumentering fordi den beste AI i verden ikke kan overflate en signal som aldri ble fanget opp i første omgang.

Så svaret er begge deler: ja, AI kan fange ting tidligere og koble punkter mennesker ville ha misset. Men teamene som får mest verdi ut av det er de som også har gjort arbeidet for å sikre at deres data faktisk er verdt å resonnere over.

Bedrifter investerer ofte tungt i deteksjons-verktøy, men sliter likevel med gjennomsnittlig tid til løsning. Hva er de største hindrene for å lukke gapet mellom hendelses-deteksjon og faktisk rot-årsak-løsning?

Deteksjon er i stor grad et løst problem på dette tidspunktet. De fleste teamene har alarm. De vet noe er feil. Gapet er alt som skjer neste.

Når en ingeniør blir vekket, går de ikke inn i en klar situasjon med all relevant kontekst nøye samlet. De går inn i en rot. De må finne ut hva som skjedde, når det skjedde, hvilken system det berørte, om det er en kunde-påvirkning, om det er relatert til noe som skjedde forrige uke. De trekker fra Slack, fra dashboards, fra deploy-logger, fra support-billetter – gjør denne kontekst-sammenstillingen manuelt, under press, ofte midt på natten.

Denne kontekst-sammenstillingen er flasken-halen. Det er ikke at ingeniører og tekniske support-team ikke vet hvordan de skal løse problemer – det er at de tilbringer de første 30-60 minuttene av hver hendelse bare med å prøve å forstå hva de faktisk ser på. Det er hvor Strudel bor. Vår hele tese er at hvis du kan gi en ingeniør en koherent, bevis-basert bilde av hva som skjedde og hvorfor – rett når de trenger det – dramatisk komprimerer du gapet. Løsnings-arbeidet er fortsatt deres. Vi får dem bare til start-linjen mye raskere.

Da AI-systemer begynner å analysere produksjons-data, kode-basen og operasjonelle logger, hva slags styrings- eller sikkerhets-considerasjoner bør ingeniør-teamene ha i mente når de deployer disse verktøyene?

Det jeg føler sterkest om her er at mennesker fortsatt bør gjennomgå kode som går i produksjon.

Jeg har talt med mange ingeniører om dette, og en ting jeg hører over og over igjen er at AI skriver feil effektivt og kreativt. Virkelig kreativt, faktisk. På en måte som kan være genuint vanskelig å fange – selv for senior-ingeniører som gjennomgår koden nøye. Feilene er ikke alltid åpenbare. De kan se perfekt rimelige ut ved første øyekast.

Så når AI skriver mer og mer av koden som havner i produksjon, tror jeg vi kommer til å se mer av disse subtile, vanskelige å fange feil glide gjennom – ikke fordi noen var uaktsom, men fordi naturen til AI-genererte feil er forskjellig. Hardere å se i gjennomgang. Hardere å fange i testing.

Ærlig talt? Det er en av grunnene til at tilfellet for hva Strudel gjør bare blir sterkere over tid. Hvis flere feil havner i produksjon, blir evnen til å finne og løse dem raskere mer viktig, ikke mindre. Styrings-spørsmålet er ikke bare om data-tilgangskontroller og tillatelser – selv om det betyr og teamene bør være nøye med hva de gir AI-systemer tilgang til. Det handler også om å holde mennesker på riktig checkpoint, spesielt rundt alt som berører produksjon.

Ser du fremover, tror du fremtiden for pålitelighets-ingeniør-arbeid vil skifte mot AI-først-infrastruktur, hvor autonome systemer overvåker, diagnostiserer og til og med fikser problemer før mennesker er klar over dem? Hvis ja, hva ser denne fremtidige arbeidsflyten ut for ingeniører?

Jeg tror vi er på vei i den retningen, men jeg er pragmatisk omkring tidsrammen. Fullt autonome systemer som løser produksjons-hendelser uten noen menneskelig innblanding – det er ikke hvor vi er, og jeg tror ikke det er hvor vi kommer til å være de neste få årene. Og jeg tror det er ok.

Hva jeg tror er at løkken blir mye tettere og mindre smertefull. Fremtiden jeg er spennende for er ikke en hvor mennesker fjernes fra ligningen – det er en hvor menneskene integrert i prosessen tilbringer sin tid på delene som faktisk krever dem. Dømmekraft. Nyttige situasjoner. En hendelse du aldri har sett før. AI håndterer mønster-matching, kontekst-sammenstilling, rutine-triage. Ingeniører håndterer beslutningene.

For ingeniørerne selv, tror jeg det ser ut som: mindre tid på vakt midt på natten for ting som ikke trenger å vekke dem, og mer tid på å bygge systemer som ikke bryter sammen i første omgang. Brann-slukkingen forsvinner ikke helt. Men det blir unntaket i stedet for standard-tilstanden for å være en ingeniør i et selskap som kjører programvare i skala. Det er en fremtid verdt å bygge mot.

Takk for det flotte intervjuet, lesere som ønsker å lære mer bør besøke Strudel.