AI CTO: Wenn AI das Kernprodukt ist

Wie sich die Rolle von CTO verändert, wenn AI im Mittelpunkt des Produkts steht. „Build vs. Buy“ bei Grundmodellen, Teamstruktur rund um AI-native Systeme, Bewertungsmethodik und die technischen Entscheidungen, die diese Position prägen.

Architekturdiagramm eines AI-eigenen Produktstacks – Basismodellschicht, Abrufschicht, Anwendungsschicht, Auswertungs-Pipeline – in reinem Schwarz mit einem einzigen orange leuchtenden Akzent
Architekturdiagramm eines AI-eigenen Produktstacks – Basismodellschicht, Abrufschicht, Anwendungsschicht, Auswertungs-Pipeline – in reinem Schwarz mit einem einzigen orange leuchtenden Akzent

Das Wichtigste auf einen Blick

  • Das Unternehmen AI CTO betreibt ein Geschäft, bei dem AI das Produkt ist und nicht nur eine Funktion. Diese Rolle unterscheidet sich deutlich von einem Produktunternehmen CTO, dessen Produkt zufällig AI für bestimmte Funktionen nutzt.
  • Die technologische Strategie bei Grundmodellen lautet „Build vs. Buy“. Die meisten CTOs von AI kaufen das Basismodell und schaffen Differenzierung in den Bereichen Abruf, Feinabstimmung, Agenten und Produkterlebnis.
  • Die technische Organisationsstruktur unterteilt sich in Plattform, Produkt und Forschung. Eine auf Servicegrenzen basierende Organisationsgestaltung funktioniert weniger gut, wenn die Modellschicht funktionsübergreifend ist.
  • Evaluierung und Red-Teaming sind fest in der Engineering-Abteilung verankerte Disziplinen. Keine reinen Launch-Veranstaltungen. Die Teams, die zuverlässige AI-Produkte ausliefern, haben Evaluierungs-Pipelines auf demselben kritischen Pfad wie die Feature-Entwicklung.
  • Inferenzkosten sind die neuen Infrastrukturkosten. Die Token-Ökonomie pro Feature ist eine erstklassige CTO-Kennzahl, andernfalls liefert das Unternehmen Demos aus, die in großem Maßstab Geld verlieren.

Der CTO, dessen Unternehmen 2018 eine Empfehlungsmaschine entwickelt hat, und der CTO, dessen Unternehmen 2026 ein AI-natives Produkt entwickelt, haben nicht die gleiche Aufgabe. Das CTO von 2018 hatte eine nach Servicegrenzen gegliederte Organisationsstruktur, eine SaaS-orientierte Kostenstruktur, einen vierteljährlichen Bewertungsrhythmus, der sich auf Verfügbarkeit und Feature-Bereitstellung konzentrierte, sowie eine Lieferantenliste, die von Infrastrukturanbietern dominiert wurde. Das AI CTO von 2026 verfügt über eine Engineering-Organisation, die um den Modell-Daten-Bewertungs-Zyklus herum strukturiert ist, eine Kostenstruktur, die von der Inferenzökonomie dominiert wird, eine Evaluierungsdisziplin, die kontinuierlich auf demselben kritischen Pfad wie das Produkt läuft, sowie eine Lieferantenliste, die von Anbietern von Basismodellen dominiert wird, deren Roadmaps das CTO auf einer Detailebene verfolgen muss, die ein CTO aus dem Jahr 2018 dem Cloud-Anbieter vorbehalten hatte.

Diese Seite richtet sich an den CTO, der sich mitten im Übergang zur AI-nativen Ausprägung der Rolle befindet, sowie an den Vorstand oder den CEO, der prüfen möchte, ob ein Kandidat tatsächlich bereits eines dieser Unternehmen aufgebaut hat. Das Begleitdokument ist AI CIO, das sich mit der parallelen Entwicklung in Unternehmen befasst, in denen AI innerhalb der IT-Infrastruktur und nicht im Kern des Produkts angesiedelt ist.

Die Entscheidung

„Build vs. Buy“ beim Foundation-Modell

Die entscheidende strategische Entscheidung für ein AI CTO im Jahr 2026 ist die Haltung gegenüber der Foundation-Model-Ebene. In der Praxis nimmt diese Entscheidung drei Formen an, und fast jedes AI-native Unternehmen, das kleiner ist als ein Foundation-Model-Labor, landet in der zweiten.

Entwickeln Sie Ihr eigenes Basismodell von Grund auf. Die Kosten für ein wettbewerbsfähiges Spitzenmodell liegen weiterhin im Bereich von Hunderten von Millionen Dollar, die Talente, die in der Lage sind, auf Spitzenniveau zu trainieren, konzentrieren sich weltweit auf eine Handvoll Labore (OpenAI, Anthropic, Google DeepMind sowie eine kleine Gruppe gut finanzierter Herausforderer), und jedes Basismodell, das Sie heute trainieren, hinkt zum Zeitpunkt der Auslieferung sechs bis neun Monate hinter dem aktuellen Stand der Technik hinterher. Dieser Weg ist sinnvoll für Foundation-Model-Labore selbst, für regulatorische Kontexte, in denen externe Abhängigkeit unhaltbar ist, und für eine kleine Gruppe von Unternehmen, bei denen das Modell selbst das Produkt und nicht nur eine Komponente ist. Für fast jedes andere AI-native Unternehmen geht die Rechnung nicht auf.

Kaufen Sie das Basismodell und bauen Sie darauf Ihre Differenzierung auf. Das Muster, das sich bei den meisten AI-nativen SaaS-Unternehmen etabliert hat. Das CTO wählt einen oder zwei Anbieter von Basismodellen aus, behandelt diese als strategische Lieferanten auf der Ebene von Cloud-Anbietern in einem traditionellen SaaS-Unternehmen und konzentriert die Investitionen in die Entwicklung auf die Abrufebene, die Feinabstimmungs-Pipeline, das Agent-Gerüst, die Evaluierungsdisziplin und das Produkterlebnis. Die Differenzierung liegt darin, was das Unternehmen mit dem Modell macht, nicht im Modell selbst. In diese Form fließt der größte Teil der Zeit der AI- und CTO-Unternehmen.

Alles kaufen, nur die Produktoberfläche entwickeln. Richtig für AI-native Unternehmen in der Frühphase, die noch die Produkt-Markt-Passung validieren, bei denen die Teamkapazität zu begrenzt ist, um in die Abruf- und Evaluierungsschichten zu investieren, und bei denen die unmittelbare Frage lautet, ob jemand für das bezahlen wird, was das Produkt hervorbringt. Die meisten Unternehmen, die die Validierung überstehen, wechseln innerhalb von 12–18 Monaten von diesem Modell zum vorherigen.

„Bei einem AI-nativen Unternehmen sind die Technologiestrategie und die Strategie für den Anbieter des Basismodells ein und dasselbe Thema. Wer das Modell nur als eine weitere Lieferantenbeziehung betrachtet, hat die Situation noch nicht verstanden.“

Thomas Prommer Ehemaliger SVP Engineering, adidas · Berater für CTAIO-Portfoliounternehmen
Die Organisation

Gestaltung der Engineering-Organisation rund um AI-native Produkte

Die Organisationsstruktur, die sich 2026 bei den meisten AI-nativen Unternehmen etabliert hat, gliedert sich in drei Funktionen auf oberster Ebene, was sich von der nach Servicegrenzen gegliederten Struktur unterscheidet, die in traditionellen SaaS-Engineering-Organisationen vorherrscht.

Modellplattform-Team

Verantwortlich für die gesamte Modellschicht: die Inferenzinfrastruktur, die Modell-Routing-Logik, die Caching-Ebene, die Evaluierungspipeline sowie die Beobachtbarkeit und Telemetrie rund um das Modellverhalten in der Produktion. Die Größe skaliert eher mit der Produktkomplexität als mit der reinen Mitarbeiterzahl des Unternehmens. Eine schlankere Besetzung (5–10 Prozent der Entwickler) ist bei AI-nativen Unternehmen in der Frühphase die Norm; Unternehmen, deren Produktkomplexität tiefere Plattforminvestitionen erfordert, werden eine größere Besetzung haben, manchmal 15–25 Prozent einer Organisation, wenn die Plattformauslastung die einschränkende Bedingung für die Produktgeschwindigkeit ist.

Produktentwicklung

Organisiert nach vertikalen Anwendungsfällen oder Produktoberflächen, die die Modellplattform nutzen. Jedes Team ist für seinen Teil des Produkts verantwortlich, integriert sich in die Plattformebene und liefert Funktionen aus. Die Teamstruktur kommt jedem aus einem traditionellen SaaS-Unternehmen bekannt vor, aber die Ergebnisse sind anders. Anstatt einen Dienst auszuliefern, der einen CRUD-Workflow abwickelt, liefert das Team einen AI-gesteuerten Workflow aus, der davon abhängt, dass sich die Modellplattform in Randfällen, die das Team nicht einfach isoliert testen kann, gut verhält.

Angewandte Forschung

Befasst sich mit der Feinabstimmung, der Arbeit an benutzerdefinierten Modellen, der Experimentierpipeline und den tiefergehenden technischen Entscheidungen zum Modellverhalten. Die meisten AI-nativen Unternehmen verfügen über eine kleine Abteilung für angewandte Forschung (5–15 Mitarbeiter in den meisten Unternehmen mit weniger als 500 Mitarbeitern), die eng mit der Produkt-Roadmap verzahnt ist, anstatt unabhängige Forschungsagenden zu verfolgen. Die Aufgabe besteht darin, Spitzenforschung in lieferbare Technik umzusetzen, nicht darin, wissenschaftliche Artikel zu veröffentlichen.

Die Disziplin

Bewertung und Red-Teaming als erstklassige Technik

Die Disziplin der Evaluierung ist der konsistenteste Unterschied zwischen AI-CTOs, deren Produkte das zweite Jahr überstehen, und AI-CTOs, deren Produkte still und leise an Qualität verlieren. Drei spezifische Praktiken finden sich in den Unternehmen, die dies richtig umsetzen.

Evaluierungssuiten auf dem kritischen Pfad. Diese werden mit derselben technischen Strenge gepflegt wie die Testsuite. Eine Modelländerung, die die Evaluierung nicht besteht, wird etwa so oft ausgeliefert wie eine Codeänderung, die die Testsuite nicht besteht – also so gut wie nie. Die Suite deckt Kernfunktionen, bekannte Fehlermodi aus Produktionsvorfällen und die seltenen Randfälle ab, die sich im Laufe der Produktreife angesammelt haben. Die Abdeckung wächst mit der Produktoberfläche, nicht mit der Modellschicht.

Red-Teaming als fortlaufende operative Praxis. Ein dediziertes Team (manchmal innerhalb der Plattformorganisation, manchmal eine Schwesterorganisation, die direkt an den CTO berichtet) führt kontinuierliche Tests auf Prompt-Injection, Jailbreaks, Halluzinationsmuster, Bias-Oberflächen und andere Modellfehlermodi durch. Die Häufigkeit beträgt wöchentlich oder täglich, je nach Unternehmensphase. Die Ergebnisse des Red Teams fließen als Standardprobleme in die Evaluierungssuite, in die Modell-Routing-Logik und in das Backlog des Produktteams ein.

Online-Evaluierungspipelines. Die Ausgaben der Produktionsmodelle werden stichprobenartig erfasst und kontinuierlich mit Referenztraces, zurückbehaltenen Goldstandards oder LLM-as-Judge-Evaluierungen verglichen. Stille Regressionen – also Fälle, in denen das Produkt zwar noch funktioniert, die Qualität sich jedoch in einer Weise verschlechtert hat, über die sich noch kein Nutzer beschwert hat – werden markiert, bevor sie sich zu einem Abwanderungsproblem aufstauen. Dies ist der Unterschied zwischen Unternehmen, die aus Produktionsdaten lernen, und solchen, die einfach nur ausliefern und auf das Beste hoffen.

Das OpenAI-Evals-Framework, die von Anthropic veröffentlichten Bewertungsmuster und die Bewertungskurse von DeepLearning.AI haben sich in den letzten zwei Jahren alle auf ähnliche Disziplinen konvergiert; die veröffentlichten Muster sind so ausgereift, dass es für einen AI CTO keine Entschuldigung gibt, diese Arbeit zu überspringen.

Die Ökonomie

Inferenzökonomie als erstklassige CTO-Kennzahl

Bei den meisten AI-nativen Unternehmen im Jahr 2026 sind die Inferenzkosten der größte Einzelposten bei den variablen Kosten, oft größer als die Infrastrukturkosten und oft vergleichbar mit den Personalkosten, sobald man die Vertriebskosten berücksichtigt. Wer dies nicht als erstklassige Kennzahl behandelt, trifft Preisentscheidungen im Dunkeln und lässt die Marge mit steigender Nutzung stillschweigend schrumpfen.

Entscheidend ist die Wirtschaftlichkeit pro Funktionseinheit. Für jede wichtige Produktfunktion gibt es drei Kennzahlen: den Token-Verbrauch pro Abruf (Input plus Output, einschließlich aller Agent- oder Abruf-Scaffolding-Kosten), die Bruttomarge pro Abruf bei der aktuellen Preisstufe und die prognostizierte Skalierungskurve bei steigender Nutzung. Die AI-CTOs, die diese Zahlen für die zehn wichtigsten Funktionen im Kopf haben, treffen Preis-, Routing- und Architekturentscheidungen, die sich gegenseitig verstärken. Diejenigen, die dies nicht tun, müssen dem CFO nach 18 Monaten erklären, warum die Margen unter Druck geraten sind.

Einige Architekturmuster tauchen immer wieder in Unternehmen auf, die die Inferenzökonomie richtig hinbekommen haben. Modell-Routing: Verwendung kleinerer, kostengünstigerer Modelle für die Anfragen, die sie bewältigen können, und Reservierung von Spitzenmodellen für die Anfragen, die diese erfordern. Caching-Ebenen für wiederkehrende Abfragemuster, für Embeddings, für Teilvervollständigungen. Feature-Gates pro Preisstufe, die inferenzintensive Funktionen auf Umsatzstufen abstimmen, die die Kosten auffangen können. Die meisten Unternehmen integrieren zudem eine LLM-as-Judge-Observability, damit die Routing-Entscheidungen überprüft werden können, anstatt ihnen blind zu vertrauen. Nichts davon ist im Jahr 2026 neu, aber die Disziplin, diese Aspekte als Kernaufgabe der Entwicklung zu behandeln und nicht als Optimierungen, die später noch einmal überdacht werden, ist es, was die CTOs von AI, deren Unternehmen die Skalierung von Produkt und Markt überstehen, von denen unterscheidet, deren Unternehmen dies nicht schaffen.

Verwandte Themen

Die Säule „Technologie-Führungskraft“ deckt die umfassendere Rolle ab, von der der AI CTO eine Variante ist. Die Schwesterseite zu AI CIO behandelt die parallele Entwicklung in Unternehmen, in denen AI innerhalb der IT-Landschaft angesiedelt ist. Für die Sicht auf Portfolioebene oberhalb der Engineering-Organisation siehe AI Strategy Executive. Für den Rollenvergleich zwischen CTO, CAIO und CDAO finden Sie unter CAIO vs. CTO vs. CDAO. Für ein Gespräch über eine konkrete „Build-vs-Buy“- oder Organisationsstrukturentscheidung vereinbaren Sie bitte einen Termin mit einem Experten.

Der Teilzeitweg zu AI CTO ist real. Siehe fractional Chief AI Officer für die Teilzeitvariante desselben Sitzes oder AI Strategieberatung für die projektbezogene Alternative, wenn die Arbeit einen definierten Beginn und ein definiertes Ende hat.

Häufig gestellte Fragen

Was kann ein AI CTO eigentlich, was ein herkömmliches CTO nicht kann?

Vier Arbeitsstränge, die in einer traditionellen Produktrolle nicht in gleicher Weise zum Tragen kommen. Erstens die Entscheidung „Build vs. Buy“ hinsichtlich des Basismodells selbst: Welcher Anbieter, welche Lizenzierung, welche Feinabstimmung und welcher Migrationsplan, wenn in sechs Monaten ein besseres Modell auf den Markt kommt? Zweitens die technische Organisationsstruktur, die ein AI-natives Produkt unterstützt und sich von der serviceorientierten Organisationsstruktur unterscheidet, die bei traditionellem SaaS funktioniert. Drittens die Evaluierung und die Red-Team-Disziplin, die auf demselben kritischen Pfad liegen wie die Bereitstellung von Features, da sich die Modellschicht auf eine Weise stillschweigend verschlechtern kann, wie es bei herkömmlichen Serviceeinbußen nicht der Fall ist. Viertens die Inferenzökonomie: Die Kostenstruktur eines AI-nativen Produkts wird eher durch verbrauchte Token als durch gemietete Infrastruktur bestimmt, und der CTO, der dies nicht als erstklassige Kennzahl behandelt, liefert Produkte aus, die in großem Maßstab Geld verlieren.

Sollte ein auf AI basierendes Unternehmen eigene Grundmodelle entwickeln oder auf externe zurückgreifen?

Im Jahr 2026 dürfte kaum noch ein AI-Unternehmen, das nicht die Größe eines Foundation-Model-Labors hat, Basismodelle von Grund auf selbst trainieren. Die Kosten für das Vortrainieren eines wettbewerbsfähigen Basismodells liegen nach wie vor im Bereich von mehreren hundert Millionen Dollar, und die Entwicklung in diesem Bereich schreitet immer noch so schnell voran, dass jedes Modell, das man heute trainiert, zum Zeitpunkt der Veröffentlichung bereits sechs bis neun Monate hinter dem aktuellen Stand der Technik zurückliegt. Das Modell, das für die überwiegende Mehrheit der AI-nativen Unternehmen funktioniert, besteht darin, das Basismodell zu kaufen und die Differenzierung in der Abrufebene, der Feinabstimmung, dem Agent-Gerüst, der Evaluierungspipeline und der Produkterfahrung zu schaffen. Unternehmen, die ihre eigenen Basismodelle entwickeln sollten, sind solche, bei denen das Modell selbst das Produkt ist (Foundation-Model-Labore) oder bei denen regulatorische Anforderungen eine Abhängigkeit von externen Anbietern unhaltbar machen (bestimmte Bereiche der Verteidigung, des Gesundheitswesens und der Finanzdienstleistungen).

Inwiefern unterscheidet sich die Organisationsstruktur eines AI-nativen Engineering-Unternehmens von der eines herkömmlichen SaaS-Unternehmens?

Traditionelle SaaS-Entwicklungsorganisationen sind nach Servicegrenzen strukturiert: ein Checkout-Team, ein Abrechnungsteam, ein Suchteam, ein Benachrichtigungsteam. Die Grenzen entsprechen der Architektur, und das Organigramm untermauert dies. AI-native Produkte weisen eine andere Struktur auf, da die Modellschicht produktübergreifend ist und das Daten-Flywheel eine größere Rolle spielt als die Aufteilung in einzelne Dienste. Die Struktur, die sich bis 2026 in den meisten AI-nativen Unternehmen etabliert hat, umfasst drei Funktionen auf oberster Ebene: ein Modellplattform-Team, das für die Modellschicht, die Inferenzinfrastruktur und die Evaluierungspipeline zuständig ist; eine Produktentwicklungsfunktion, die sich an vertikalen Anwendungsfällen orientiert und die Plattform nutzt; sowie eine angewandte Forschungsfunktion, die sich um die Feinabstimmung, die Arbeit an benutzerdefinierten Modellen und die Experimentierpipeline kümmert. Die genauen Anteile variieren je nach Unternehmensphase, doch die Trennung zwischen Plattform, Produkt und Forschung ist bei allen Unternehmen, die zuverlässige AI-Produkte auf den Markt bringen, einheitlich.

Welche Bewertungs- und Red-Team-Kompetenzen muss ein AI CTO aufbauen?

Die Evaluierung ist das AI-spezifische Äquivalent zum Regressionstest, mit dem Unterschied, dass die Testabdeckung gezielt aufgebaut werden muss und die Fehlermodi subtiler sind. Drei Praktiken unterscheiden Unternehmen, die zuverlässige AI-Produkte ausliefern, von Unternehmen, die nur Demos liefern. Erstens: Evaluierungssuiten, die auf demselben kritischen Pfad wie die Feature-Entwicklung gepflegt werden und denselben Qualitätsstandard erfüllen – eine Modelländerung, die die Evaluierungssuite nicht besteht, kommt etwa so oft vor wie eine Codeänderung, die die Testsuite nicht besteht, also so gut wie nie. Zweitens: Red-Teaming als reguläre Betriebspraxis statt als einmaliges Ereignis bei der Markteinführung: Ein dediziertes Team untersucht wöchentlich Prompt-Injection, Jailbreaks, Halluzinationsmuster und Bias-Oberflächen. Drittens: Online-Evaluierungspipelines, die die Ausgaben von Produktionsmodellen mit zurückbehaltenen Referenztraces vergleichen und stille Verschlechterungen kennzeichnen, bevor ein Kunde sie bemerkt.

Wie sieht die Inferenzökonomie für einen AI CTO konkret aus?

Die Kosten für die Datenauswertung sind bei den meisten AI-nativen Unternehmen zum größten Einzelposten bei den variablen Kosten geworden – oft höher als die Infrastrukturkosten und, unter Berücksichtigung der Vertriebskosten, oft vergleichbar mit den Personalkosten. Die entscheidende Disziplin: die Wirtschaftlichkeit pro Funktion. Für jede Funktion gilt: Wie viele Token kostet die Bearbeitung einer einzelnen Nutzeranfrage, wie hoch ist die Bruttomarge pro Anfrage und wie skaliert sich dies bei steigender Nutzung? Wer diese Zahlen für die zehn wichtigsten Funktionen nicht parat hat, trifft Preisentscheidungen im Dunkeln. Die CTOs, die dies tun, tendieren zu einem ähnlichen Muster: aggressiver Einsatz von Modell-Routing (kleinere, kostengünstigere Modelle für einfachere Anfragen, Frontier-Modelle für die schwierigen), Caching-Ebenen für wiederkehrende Muster und funktionsspezifische Zugangsbeschränkungen pro Stufe, die die Inferenzkosten an die Umsatzstufe anpassen.

Inwiefern unterscheidet sich das Modell AI CTO vom Modell AI strategy executive oder CAIO?

Das AI CTO ist für die Produktentwicklung zuständig. Das AI strategy executive oder Chief AI Officer ist für die Portfoliostrategie in Unternehmen verantwortlich, in denen das AI eher eine von mehreren Investitionen des Unternehmens darstellt als das Kernprodukt selbst. In einem Unternehmen, das auf AI spezialisiert ist, übernimmt der AI CTO oft einen Großteil der Rolle des AI strategy executive, da die Produktstrategie des Unternehmens und seine AI-Strategie ein und dasselbe sind. In einem traditionellen Unternehmen, das AI in ein bestehendes Produktportfolio aufnimmt, legt der CAIO die Portfoliostrategie fest, und der bestehende CTO (oder das AI-CTO-Äquivalent innerhalb der Technologieorganisation) führt die Umsetzung auf der technischen Seite durch. Siehe AI Strategy Executive für die Behandlung auf Portfolioebene und CAIO vs. CTO vs. CDAO für die Rollenvergleichsansicht.

Wie hoch ist das übliche Gehalt für einen AI CTO?

Die Vergütung liegt über der eines herkömmlichen Produkts CTO bei vergleichbarer Unternehmensphase, was auf die Konzentration der Nachfrage zurückzuführen ist. Die Vergütung bei AI-nativen Unternehmen CTO liegt im Jahr 2026 in der Regel bei 400.000 bis 700.000 US-Dollar bei finanzierten Unternehmen der Serie B und darüber hinaus, wobei die Gesamtvergütung in späteren Phasen auf über 2 Millionen US-Dollar steigt und die Aktienzuteilungen stark auf den Aufwärtstrend ausgerichtet sind, wenn das Unternehmen in einer gefragten AI-Branche positioniert ist. Foundation-Model-Labore und Pionierunternehmen im AI-Bereich zahlen die höchsten Vergütungen; öffentliche Berichte für den Zeitraum 2024–2025 zeigen, dass die Gesamtvergütung für leitende technische Führungskräfte im AI-Bereich an der Spitze des Marktes 5 Mio. $ übersteigt. Der Vergütungsaufschlag verringert sich, wenn das Unternehmen reift und das AI-Label innerhalb seiner Produktkategorie zur Massenware wird.

Was ist die häufigste Fehlerursache bei den Modellen AI und CTO?

Zu wenig in die Evaluierung und zu viel in das neueste Modell investieren. Dieses Muster zeigt sich bei AI-nativen Unternehmen, die ein Produkt auf Basis des aktuellen Spitzenmodells auf den Markt bringen, starke Demo-Kennzahlen verzeichnen, auf die ersten Kunden skalieren und dann zusehen müssen, wie sich die Produktionserfahrung verschlechtert, während sich Randfälle häufen. Der Instinkt des Teams ist es, auf das nächste Spitzenmodell umzusteigen, sobald es verfügbar ist. Dies führt zu einem sechswöchigen Integrationssprint und einer weiteren Runde von Ergebnissen in Demo-Qualität, ohne das zugrunde liegende Problem anzugehen: Es gab von vornherein keine Evaluierungssuite, die die stillen Regressionen aufgefangen hätte. Die Teams, die das zweite Jahr überstehen, sind diejenigen, die parallel zum Produkt eine Evaluierungsdisziplin aufgebaut haben, nicht diejenigen, die jedem Modell-Upgrade hinterhergelaufen sind.

For CTOs & Tech Leaders

Need Expert Technology Guidance?

20+ years leading technology transformations. Get a technology executive's perspective on your biggest challenges.