Kristin Isaac, CEO und Mitgründerin von Strudel – Interview-Serie

Kristin Isaac, CEO und Mitgründerin von 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 Bereich Team-Skalierung, Go-to-Market-Strategien und Wachstumsförderung bei globalen Organisationen hat dazu beigetragen, Strudels schnellen frühen Erfolg und starke Positionierung im Bereich Unternehmens-KI und Entwickler-Tools zu gestalten.

Strudel ist eine KI-Plattform, die darauf ausgelegt ist, fortgeschrittenen technischen Support zu automatisieren, indem sie Protokolle, Produktionsdaten, Code-Repositorys und die Vergangenheit von Support-Anfragen analysiert, um Ursachen zu identifizieren und Lösungen vorzuschlagen. Ihr Ziel ist es, die Zeit und den Ingenieur-Aufwand, der zum Lösen schwieriger Support-Fälle erforderlich ist, zu reduzieren, insbesondere bei solchen Eskalationen, die normalerweise senior-technische Ressourcen verbrauchen. 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-getriebener “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 die Skalierung unerbittlich. Es gab Tausende von Diensten, die alle Rauschen erzeugten, und sogar die besten Teams kämpften darum, mitzuhalten. Bei Udemy sah ich ein schmales Team, das Heldentaten mit begrenzter Werkzeugausstattung vollbrachte.

Was alle drei und meine Mitgründer, Shai Rubin und Brian Kaufman, die Erfahrung 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 mit der Diagnose beginnen kann, muss er durch Slack-Threads, Dashboards, Jira-Tickets, Deployment-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 häufig?

Die Umsatzzahl kommt in die Vorstands-Präsentation, aber die unmittelbare Umsatzeinbuße ist nur ein Bruchteil dessen, was der Ausfall tatsächlich kostet. Diejenigen, die ich gesehen habe, dass Organisationen häufig übersehen, fallen in einige Kategorien.

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

Die zweite ist die Fluktuation und Erschöpfung der Ingenieure. Die On-Call-Müdigkeit ist real. Wenn Ihre besten Ingenieure wiederholt in hochstressige Vorfälle verwickelt werden – insbesondere solche, die hätten verhindert werden können – 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, 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 quantifizieren, aber über Monate hinweg summiert es sich stillschweigend und bläst Ihre Roadmap 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 aus?

Es 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 auf 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 explodiert ein großer Vorfall am Dienstag 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 Kreislauf. Aufgeschobene Investitionen bedeuten mehr Vorfälle, was mehr Brandbekämpfung bedeutet, was wiederum weniger Zeit bedeutet, um in die zugrunde liegenden Probleme zu investieren. Bei Strudel bauen wir 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?

Traditionelle Überwachungstools sind im Grunde Alarm-Systeme. 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 die Fehlerquote-Spitze in Ihrem Zahlungs-Service vier Minuten nach einer Bereitstellung für eine Abhängigkeit auftrat und dass ein Kundensupport-Ticket, das über Check-out-Fehler spricht, etwa zur gleichen Zeit einging und dass das letzte Mal, als dieses Muster in Ihren Protokollen auftrat, sechs Monate zuvor während einer Datenbank-Migration war.

Diese cross-Domänen-Korrelation ist es, was KI ermöglicht. Wir können ein Zendesk-Ticket, einen GitHub-Commit, eine Datadog (DDOG ) -Spur und ein CloudWatch-Protokoll als Teil einer einzigen Geschichte behandeln, anstatt isolierte Datenpunkte. Die KI zeigt nicht nur, was kaputt ist, sondern auch die wahrscheinliche Ursache und den Ort – und sie begründet dies in Beweisen, die ein menschlicher Ingenieur tatsächlich überprüfen und darauf reagieren kann. Wir bitten die 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 Observability- oder AIOps-Plattformen?

Kristin: Observability ist im Grunde Instrumentierung und Sichtbarkeit – sicherstellen, dass die Telemetrie vorhanden ist und dass Teams sie abfragen können. AIOps, in den meisten aktuellen Implementierungen, ist daran interessiert, Alarm-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 bauen auf dem auf, was AIOps tut. 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, handelbares Bild zu geben, damit sie das Problem schneller lösen und wieder zum Bauen kommen können.

Denken Sie daran, wie der Unterschied zwischen einem Rauchmelder und einem Brand-Ermittler ist. Observability und AIOps sind der Rauchmelder – unerlässlich, aber sie hören beim Alarm 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 Triagierung von Alarmen 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 viel von diesem Grind übernehmen – die wiederholten, muster-erkennenden, Kontext-assemblierenden Arbeiten, die wichtig sind, aber nicht der Grund, warum senior-Ingenieure ihr Geld verdienen. Das befreit die Menschen, um sich auf komplexe Probleme, architektonische Entscheidungen, die Dinge zu konzentrieren, die tatsächlich menschliches Urteilsvermögen erfordern.

Was mich begeistert, ist, dass dies nicht nur ein zukünftiger Zustand ist – wir sehen es bereits jetzt, einschließlich bei Strudel. Unser gesamter Roadmap 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 konzentriert sind und nicht auf die wiederholten Dinge. Das fühlt sich wie ein bedeutender Wandel in der Art und Weise an, wie Teams aufgebaut und strukturiert werden.

Viele Ausfälle stammen von kleinen Fehlern oder Konfigurationsänderungen, die durch das Testen geschlüpft sind. Wie können KI-Systeme subtile Muster in Code, Protokollen oder Infrastruktur-Signalen frühzeitig erkennen, um große Vorfälle zu verhindern?

Gut konstruierte 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 möglicherweise nicht ein subtiles Muster in den Protokollen heute mit etwas verbinden, 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 wir von Kunden oft hören: Prävention ist nur so gut wie die Daten darunter. Wenn Ihre Protokolle inkonsistent, unvollständig oder in Dutzenden von Tools gespalten 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 ihnen zu helfen, über Datenqualität und Instrumentierung nachzudenken, weil die beste KI der Welt kein Signal aufdecken kann, das nie erfasst wurde.

Die Antwort ist also 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 werden kann.

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?

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

Wenn ein Ingenieur alarmiert wird, geht er nicht in eine klare Situation mit all dem relevanten Kontext, der sorgfältig zusammengestellt ist. Er geht in ein Chaos. 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, Deployment-Protokollen, Support-Tickets – all diese Kontext-Assemblierungsarbeiten manuell, unter Druck, oft mitten in der Nacht.

Die Kontext-Assemblierung ist der Flaschenhals. 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, worauf sie eigentlich schauen. Das ist, wo Strudel lebt. Unsere gesamte These ist, dass, wenn Sie einem Ingenieur ein kohärentes, evidenzbasiertes Bild davon geben können, was passiert ist und warum – genau, wenn er es braucht – Sie diese Lücke dramatisch komprimieren. Die Lösungsarbeit ist immer noch ihre. Wir bringen sie nur zum Startpunkt viel schneller.

Wenn KI-Systeme beginnen, Produktions-Daten, Code-Basen 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 Gedanken mache, ist dies: Menschen sollten immer noch Code überprüfen, der in die Produktion geht.

Ich habe mit vielen Ingenieuren darüber gesprochen, und eines, was ich immer wieder höre, ist, dass KI Fehler effizient und clever schreibt. Wirklich clever, eigentlich. Auf eine Weise, die tatsächlich schwer zu erkennen 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.

Wenn also KI mehr und mehr des Codes schreibt, der in die Produktion kommt, denke ich, dass wir mehr von diesen subtilen, schwer zu erkennenden Problemen sehen werden, die in die Produktion schlüpfen – 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 erkennen bei Tests.

Ehrlich gesagt? Das ist 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 kommen, wird die Fähigkeit, sie schneller zu finden und zu lösen, wichtiger, nicht weniger. Die Regierungsfrage ist nicht nur, ob Daten-Zugriffs-Kontrollen und -Berechtigungen vorhanden sind – obwohl diese wichtig sind und Teams sollten sorgfältig darüber nachdenken, auf welche Daten sie jedem KI-System Zugriff gewähren. Es geht auch darum, Menschen an den richtigen Checkpoints zu halten, insbesondere bei allem, was die Produktion berührt.

Blickt man in die Zukunft, denkt man, dass die Zukunft der Zuverlässigkeits-Ingenieure in Richtung KI-getriebener Infrastruktur gehen wird, bei der autonome Systeme überwachen, diagnostizieren und sogar Probleme beheben, bevor Menschen sich dessen bewusst sind? Wenn ja, wie sieht diese zukünftige Arbeitsabfolge für Ingenieure aus?

Ich denke, wir gehen in diese Richtung, aber ich bin pragmatisch, was den Zeitplan angeht. Vollständig autonome Systeme, die Produktions-Vorfälle ohne menschliches Bewusstsein lösen – das ist nicht, wo wir sind, und ich denke, das ist okay.

Was ich glaube, ist, dass die Schleife viel 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 in die Prozesse integrierten Menschen ihre Zeit auf die Teile verbringen, die tatsächlich menschliches Urteilsvermögen erfordern. KI übernimmt die Muster-Erkennung, die Kontext-Assemblierung, die Routine-Triage. Ingenieure übernehmen die Entscheidungen.

Für die Ingenieure selbst denke ich, dass es so aussieht: 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. Die Brandbekämpfung verschwindet nicht vollständig. Aber sie wird zur Ausnahme und nicht zum Standardzustand des Ingenieurs in einem Unternehmen, das Software im großen Maßstab betreibt. 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: Strudel.