Kristin Isaac, CEO und Mitgründerin bei Strudel – Interviewreihe

Kristin Isaac, CEO und Mitgründerin bei Strudel, ist eine erfahrene Führungskraft im Bereich Unternehmens-Technologie, die vor der Gründung von Strudel Führungspositionen bei LinkedIn, Udemy, ESPN und Disney innehatte. Sie konzentriert sich nun darauf, einen der größten Reibungspunkte in Software-Organisationen anzugehen: die Lücke zwischen Kundensupport und Ingenieurwesen. Bei Strudel baut sie eine künstliche Intelligenz-getriebene Plattform auf, die technischen Support-Teams hilft, komplexe Probleme schneller zu lösen, indem sie Support-Anfragen direkt mit Ingenieur-Intelligenz verbindet. Ihre Erfahrung im Aufbau von Teams, der Erstellung von Go-to-Market-Strategien und der Steigerung des Wachstums in globalen Organisationen hat dazu beigetragen, Strudels schnellen frühen Erfolg und starke Positionierung im Bereich Unternehmens-KI und Entwickler-Tools zu prägen.

Strudel ist eine KI-Plattform, die darauf ausgelegt ist, erweiterten technischen Support zu automatisieren, indem sie Protokolle, Produktionsdaten, Code-Repositorys und die Vergangenheit von Support-Anfragen analysiert, um die Ursachen zu identifizieren und Lösungen vorzuschlagen. Ihr Ziel ist es, die Zeit und den Ingenieuraufwand, der zur Lösung schwieriger Support-Fälle erforderlich ist, insbesondere der Art von Eskalationen, die normalerweise senior-technische Ressourcen verbrauchen, zu reduzieren. Durch die direkte Verbindung von Support mit den zugrunde liegenden technischen Problemen positioniert Strudel sich als Werkzeug, das Unternehmens-Support-Operationen schneller, effizienter und skalierbarer machen kann.

Sie haben Führungspositionen bei Unternehmen wie LinkedIn, Udemy und Disney innegehabt, bevor Sie Strudel 2025 gegründet haben. Welche Erfahrungen aus diesen Positionen haben Sie letztendlich davon überzeugt, dass Ingenieur-Teams eine neue Art von KI-gesteuerter “Ingenieur-Intelligenz”-Plattform benötigen, und wie hat diese Erkenntnis die Gründung von Strudel geprägt?

Jedes Unternehmen, bei dem ich gearbeitet habe, hatte eine andere Version des gleichen Problems. Bei Disney waren die Einsätze enorm – wenn eine Streaming-Plattform während eines großen Launchs ausfiel, war es nicht nur ein Umsatzeinbruch, sondern ein Marken-Moment. Bei LinkedIn war der Umfang unerbittlich. Es gab Tausende von Diensten, die alle Lärm erzeugten, und sogar die besten Teams kämpften darum, mitzuhalten. Bei Udemy sah ich ein schmales Team, das Heldentaten mit begrenzter Ausstattung leistete.

Was alle drei und die Erfahrungen meiner Mitgründer, Shai Rubin und Brian Kaufman, bei der Leitung von Ingenieur-Teams, verband, war, dass Ingenieure mehr Zeit damit verbrachten, Kontext wiederherzustellen, als tatsächlich Probleme zu lösen. Jemand wird um 2 Uhr morgens alarmiert, und bevor er überhaupt beginnen kann, das Problem zu diagnostizieren, muss er durch Slack-Threads, Dashboards, Jira-Tickets, Deploy-Protokolle – nur um zu verstehen, was sich geändert hat und wann. Sie spielen im Grunde Detektiv, bevor sie ihre eigentliche Arbeit tun können. Das ist eine Verschwendung unglaublich talentierter Menschen.

Ich dachte immer: Es muss eine intelligentere Möglichkeit geben, das zu zeigen, was tatsächlich wichtig ist, wenn es wichtig ist. Das ist wirklich der Same von Strudel.

Viele Unternehmen messen die finanziellen Auswirkungen von Ausfällen in Form von Umsatzeinbußen oder SLA-Strafen. Welche weniger sichtbaren Kosten von Ausfällen unterschätzen Organisationen Ihrer Erfahrung nach regelmäßig?

Die Umsatzzahl kommt in die Vorstands-Präsentation, aber der unmittelbare Umsatzeffekt ist nur ein Bruchteil dessen, was der Ausfall tatsächlich kostet. Diejenigen, die ich gesehen habe, die Organisationen regelmäßig verpassen, fallen in einige Kategorien.

Die erste ist das Vertrauen der Kunden. SLA-Strafen sind ein rechtlicher Konstrukt – sie erfassen nicht den Kunden, der stillschweigend kündigt oder den Unternehmens-Interessenten, der die Status-Seite im falschen Moment sah und einen Wettbewerber wählte. Dieser Schaden ist langsam, unsichtbar und dauerhaft auf eine Weise, die eine Rückerstattung nicht ist.

Die zweite ist die Fluktuation und Erschöpfung der Ingenieure. Die On-Call-Erschöpfung ist real. Wenn Ihre besten Ingenieure wiederholt in hochstressige Vorfälle gezogen werden – insbesondere solche, die vermeidbar gewesen wären – beginnen sie, zu fragen, ob dies der richtige Ort ist, um ihre Karriere aufzubauen. Die Ersetzung eines senior-Ingenieurs kostet irgendwo zwischen einem und zwei Jahren seines Jahresgehalts, wenn man die Rekrutierung, das Onboarding und den Verlust von institutionellem Wissen berücksichtigt. Niemand stellt das in die Post-Mortem-Analyse.

Die dritte ist die Opportunitätskosten. Jede Stunde, die ein Ingenieur-Team mit dem Löschen von Bränden verbringt, ist eine Stunde, die nicht damit verbracht wird, ein Produkt zu bauen. Das ist schwer zu berechnen, aber über Monate hinweg summiert es sich stillschweigend und bläst Ihren Fahrplan stillschweigend auf.

Ingenieure werden oft von der Erstellung neuer Funktionen abgezogen, um auf Produktions-Vorfälle zu reagieren. Wie wirkt sich diese ständige Brandbekämpfung auf die Produkt-Innovation und die langfristige Entwicklung von Entwicklungs-Roadmaps aus?

Sie schafft eine Steuer auf die Fähigkeit des Ingenieur-Teams, zu bauen. Jedes Team hat eine endliche Menge an Bandbreite, und wenn ein erheblicher Teil davon ständig in Vorfälle umgeleitet wird, ist der kumulierte Effekt auf die Produktentwicklung gravierend. Roadmap-Verpflichtungen werden verpasst. Technische Schulden werden nicht beglichen. Funktionen werden mit weniger Sorgfalt ausgeliefert, weil es Druck gibt, verlorene Zeit aufzuholen.

Was besonders schädlich ist, ist die Unvorhersehbarkeit. Ein Team kann seinen Sprint mit guten Absichten planen und dann wird ein großer Vorfall am Dienstag ausgelöst und alles andere wird zweitrangig. Diese anhaltende Unvorhersehbarkeit macht es fast unmöglich, eine Kultur der tiefen Arbeit aufzubauen – was letztendlich die besten Ingenieur-Ergebnisse treibt.

Es schafft auch einen sich selbst verstärkenden Kreis. Aufgeschobene Investitionen bedeuten mehr Vorfälle, die mehr Brandbekämpfung bedeuten, die wiederum weniger Zeit bedeutet, um die zugrunde liegenden Probleme zu investieren. Bei Strudel ist ein großer Teil dessen, was wir aufbauen, speziell für die SRE-Teams, die dies jeden Tag erleben.

Strudel verbindet Kundensupport-Daten, Protokolle, Produktions-Systeme und Code-Repositorys, um Ursachen schneller zu identifizieren. Wie bringt KI diese verschiedenen technischen Signale auf eine Weise zusammen, die herkömmliche Überwachungstools nicht können?

Herkömmliche Überwachungstools sind im Grunde Warnsysteme. Sie sind großartig darin, Ihnen zu sagen, dass etwas eine Schwelle überschritten hat – eine Latenz-Spitze, eine Fehlerquote, die steigt, ein Pod, der abstürzt. Was sie jedoch nicht können, ist, über Domänen hinweg zu argumentieren.

Sie wissen nicht, dass der Fehler-Spike in Ihrem Zahlungsservice vier Minuten nach einer Bereitstellung für eine Abhängigkeit auftrat und dass ein Kundensupport-Ticket, das über Checkout-Fehler spricht, etwa zur gleichen Zeit einging und dass das letzte Mal, als dieses Muster in Ihren Protokollen auftrat, vor sechs Monaten während einer Datenbank-Migration war.

Diese korrelative Verbindung über Domänen hinweg ermöglicht KI. Wir können ein Zendesk-Ticket, einen GitHub-Commit, einen Datadog-Trace und einen CloudWatch-Log als Teil einer einzigen Geschichte behandeln und nicht als isolierte Datenpunkte. KI zeigt nicht nur, was kaputt ist, sondern auch das wahrscheinliche Warum und Wo – und es begründet dies in Beweisen, die ein menschlicher Ingenieur tatsächlich überprüfen und darauf reagieren kann. Wir bitten Teams nicht, einem schwarzen Kasten zu vertrauen. Wir geben ihnen eine gut begründete Hypothese und einen Vorsprung.

Sie beschreiben Strudel als “Ingenieur-Intelligenz”. Was bedeutet dieses Konzept in der Praxis, und wie unterscheidet es sich von herkömmlichen Beobachtbarkeits- oder AIOps-Plattformen?

Kristin: Beobachtbarkeit ist im Grunde Instrumentierung und Sichtbarkeit – sicherzustellen, dass die Telemetrie vorhanden ist und dass Teams sie abfragen können. AIOps ist in den meisten aktuellen Implementierungen daran, Warn-Lärm durch ML-basierte Korrelation und Anomalie-Erkennung zu reduzieren. Beides ist wirklich wertvoll, und wir integrieren uns damit.

Aber Ingenieur-Intelligenz ist eine Ebene darüber. Wir nehmen, was AIOps tut, und erweitern es. Wo AIOps Ihnen sagt, dass etwas falsch ist, hilft Ingenieur-Intelligenz Ihnen, zu verstehen, warum es falsch ist, wo es begann und was Sie dagegen tun können – Signale aus Ihrem gesamten Stack ziehend, einschließlich Quellen, die herkömmliche AIOps-Tools nicht einmal betrachten, wie Kundensupport-Tickets oder Code-Änderungen. Das Ziel ist nicht nur, Lärm zu reduzieren. Es ist, Ihrem Team ein vollständiges, handlungsfähiges Bild zu geben, damit es das Problem schneller lösen und zum Bauen zurückkehren kann.

Denken Sie daran, als den Unterschied zwischen einem Rauchmelder und einem Feuer-Ermittler. Beobachtbarkeit und AIOps sind der Rauchmelder – unerlässlich, aber sie hören bei der Warnung auf. Ingenieur-Intelligenz ist, was danach kommt: Hier ist, was passiert ist, hier ist, warum, hier ist, wo es begann.

KI-Agents werden zunehmend eingesetzt, um komplexe technische Workflows zu automatisieren. Welche Rolle sehen Sie KI-Agents in der Diagnose und Lösung von Software-Vorfällen in den nächsten fünf Jahren spielen?

Ich denke, die interessantere Frage ist nicht, was Agents tun werden – es ist, was Ingenieure aufhören werden zu tun. Die besten Ingenieure, mit denen ich gearbeitet habe, sind nicht in dieses Feld eingestiegen, um ihre Nächte mit der Triage von Warnungen oder der Suche in Protokollen nach einer Konfigurationsänderung zu verbringen, die jemand am Freitag-Nachmittag vorgenommen hat. Das ist nicht der Grund, warum sie gut in ihrem Job sind. Aber das ist, wofür ein großer Teil ihrer Zeit aufgewendet wird.

In den nächsten fünf Jahren denke ich, dass Agents einen großen Teil dieser Routine- und Kontext-Assembly-Arbeit übernehmen – die repetitive, muster-erkennende Arbeit, die wichtig ist, aber nicht der Grund, warum senior-Ingenieure ihre Zeit damit verbringen sollten. Das befreit die Menschen, um sich auf komplexe Probleme, architektonische Entscheidungen und Dinge zu konzentrieren, die tatsächlich menschliche Urteilsfähigkeit erfordern.

Was aufregend ist, ist, dass dies nicht nur ein zukünftiger Zustand ist – wir sehen es bereits geschehen, einschließlich bei Strudel. Unser gesamter Fahrplan ist darauf ausgerichtet, administrative und Wartungsarbeiten von den Tellern der Ingenieure zu nehmen. Und was wir feststellen, ehrlich gesagt, ist, dass es verändert, was für ein Team möglich ist. Sie können mehr bauen, schneller bewegen und es mit weniger Leuten tun – weil die Leute, die Sie haben, auf Strategie und Komplexität fokussiert sind und nicht auf die repetitive Arbeit. Das fühlt sich wie ein bedeutender Wandel an, wie Teams aufgebaut und strukturiert werden.

Viele Ausfälle haben ihren Ursprung in kleinen Fehlern oder Konfigurationsänderungen, die durch das Testen fallen. Wie können KI-Systeme subtile Muster in Code, Protokollen oder Infrastruktur-Signalen frühzeitig identifizieren, um große Vorfälle zu verhindern?

Gut entwickelte KI hat hier einen echten Vorteil, und es ist nicht, dass sie intelligenter ist als Ihre Ingenieure – es ist, dass sie nie vergisst und nie schläft. Ein Mensch kann nicht immer eine subtile Protokoll-Muster-Verbindung herstellen, die heute auftritt, mit etwas, das vor sechs Monaten in einem völlig anderen Teil des Systems passiert ist. KI kann. Sie beobachtet alles, immer, und hat ein viel längeres und breiteres Gedächtnis als jeder Einzelne in Ihrem Team.

Das sagte, gibt es auch etwas anderes, das ich von Kunden oft höre: Prävention ist nur so gut wie die Daten darunter. Wenn Ihre Protokolle inkonsistent, unvollständig oder in Dutzenden von Tools siloartig sind, die nicht miteinander sprechen, arbeitet die KI mit einem fragmentierten Bild. Müll rein, Müll raus – das ist immer noch wahr. Wir verbringen viel Zeit mit Kunden, um über Datenqualität und Instrumentierung nachzudenken, weil die beste KI der Welt kein Signal aufdecken kann, das nie erfasst wurde.

Also ist die Antwort beides: Ja, KI kann Dinge früher erkennen und Verbindungen herstellen, die Menschen verpassen. Aber die Teams, die den meisten Nutzen daraus ziehen, sind diejenigen, die auch die Arbeit geleistet haben, um sicherzustellen, dass ihre Daten tatsächlich etwas wert sind, über das nachgedacht wird.

Unternehmen investieren oft stark in Erkennungstools, kämpfen aber dennoch mit der mittleren Zeit bis zur Lösung. Welche sind die größten Hindernisse, die Organisationen daran hindern, die Lücke zwischen Vorfall-Erkennung und tatsächlicher Ursachen-Lösung zu schließen?

Die Erkennung ist im Grunde ein gelöstes Problem. Die meisten Teams haben Warnungen. Sie wissen, dass etwas nicht stimmt. Die Lücke ist alles, was danach passiert.

Wenn ein Ingenieur alarmiert wird, geht er nicht in eine klare Situation mit allen relevanten Kontexten ordentlich zusammengestellt. Er geht in ein Durcheinander. Er muss herausfinden, was sich geändert hat, wann es sich geändert hat, welches System es berührt hat, ob es eine Kundenauswirkung gibt, ob es mit etwas zusammenhängt, das letzte Woche passiert ist. Er zieht aus Slack, Dashboards, Deploy-Protokollen, Support-Tickets – nur, um zu verstehen, was er tatsächlich ansieht. Das ist die Kontext-Assembly, die der Flaschenhals ist. Es ist nicht, dass Ingenieure und technische Support-Teams nicht wissen, wie man Probleme löst – es ist, dass sie die ersten 30 bis 60 Minuten jedes Vorfalls damit verbringen, nur zu verstehen, was sie tatsächlich ansehen. Das ist, wo Strudel lebt. Unsere gesamte These ist, dass, wenn Sie einem Ingenieur ein kohärentes, beweisbasiertes Bild davon geben, was passiert ist und warum – genau, wenn er es braucht – Sie den Abstand dramatisch komprimieren. Die Lösungsarbeit ist immer noch ihre. Wir bringen sie nur zum Startpunkt viel schneller.

Wenn KI-Systeme beginnen, Produktionsdaten, Codebasen und Betriebs-Protokolle zu analysieren, welche Regierungs- oder Sicherheitsaspekte sollten Ingenieur-Teams berücksichtigen, wenn sie diese Tools einsetzen?

Das, worüber ich mich am meisten sorge, ist: Menschen sollten immer noch Code überprüfen, der in die Produktion geht.

Ich habe mit vielen Ingenieuren darüber gesprochen, und eines, das ich immer wieder höre, ist, dass KI Fehler effizient und clever schreibt. Wirklich clever, eigentlich. Auf eine Weise, die tatsächlich schwer zu fangen ist – sogar für senior-Ingenieure, die den Code sorgfältig überprüfen. Die Fehler sind nicht immer offensichtlich. Sie können bei einem Blick perfekt aussehen.

Also denke ich, wir werden mehr von diesen subtilen, schwer zu entdeckenden Problemen sehen, die in die Produktion gelangen – nicht, weil jemand nachlässig war, sondern weil die Natur von KI-generierten Fehlern anders ist. Schwieriger zu erkennen bei der Überprüfung. Schwieriger zu fangen bei den Tests.

Ehrlich gesagt, ist das einer der Gründe, warum ich denke, dass der Fall für das, was Strudel tut, nur stärker wird. Wenn mehr Fehler in die Produktion gelangen, wird die Fähigkeit, sie schneller zu finden und zu lösen, wichtiger, nicht weniger. Die Regierungsfrage ist nicht nur, ob Datenzugriffskontrollen und -berechtigungen – obwohl diese wichtig sind und Teams sollten sorgfältig darüber nachdenken, auf welche Daten sie jedem KI-System Zugang gewähren. Es geht auch darum, Menschen an den richtigen Checkpoints zu halten, insbesondere bei allem, was die Produktion berührt.

Blicken Sie in die Zukunft, denken Sie, dass die Zukunft der Zuverlässigkeits-Technik in Richtung KI-erster Infrastruktur gehen wird, in der autonome Systeme überwachen, diagnostizieren und sogar Probleme beheben, bevor Menschen sich dessen bewusst sind? Wenn ja, wie sieht die zukünftige Arbeitsabläufe für Ingenieure aus?

Ich denke, wir bewegen uns in diese Richtung, aber ich bin pragmatisch in Bezug auf den Zeitplan. Vollständig autonome Systeme, die Produktions-Vorfälle ohne menschliches Bewusstsein lösen – das ist nicht, wo wir sind, und ich denke, das werden wir in den nächsten paar Jahren auch nicht sein. Und ich denke, das ist okay.

Was ich glaube, ist, dass die Schleife enger und weniger schmerzhaft wird. Die Zukunft, auf die ich mich freue, ist nicht die, in der Menschen aus der Gleichung entfernt werden – es ist die, in der die Menschen, die in den Prozess integriert sind, ihre Zeit auf die Teile verbringen, die tatsächlich menschliche Urteilsfähigkeit erfordern. KI bearbeitet das Muster-Erkennen, die Kontext-Assembly, die Routine-Triage. Ingenieure bearbeiten die Entscheidungen.

Für die Ingenieure selbst denke ich, es sieht so aus: weniger Zeit auf Abruf in der Nacht für Dinge, die sie nicht aufwecken mussten, und mehr Zeit damit, Systeme zu bauen, die nicht brechen. Das Feuerlöschen verschwindet nicht vollständig. Aber es wird zur Ausnahme statt zur Standard-Situation, ein Ingenieur in einem Unternehmen zu sein, das Software im großen Maßstab ausführt. Das ist eine Zukunft, auf die es sich lohnt hinzuarbeiten.

Vielen Dank für das großartige Interview. Leser, die mehr erfahren möchten, sollten Strudel besuchen.