Wie führt man verteilte Engineering-Teams, die mit AI arbeiten? Wir zeigen Betriebsmodelle, Routinen, Sourcing-Entscheidungen und Kennzahlen, die sich bewährt haben. Aus der Praxis mit über 150 Engineers in vier Ländern.
Technologieverantwortliche stehen im Jahr 2026 gleichzeitig aus drei Richtungen unter Druck. Der Vorstand will AI-Tempo: Er hat die Schlagzeilen über Produktivitätssteigerungen gelesen, was entsprechende Erwartungen geweckt hat. Die Aufsichtsbehörde will Kontrolle: nachweisbare Aufsicht, dokumentierte Entscheidungen, klar benannte Verantwortlichkeiten. Und das Unternehmen selbst ist verteilt: über Standorte, Zeitzonen und Beschäftigungsmodelle hinweg, was alle Koordinationskosten, die durch die ersten beiden Druckfaktoren entstehen, vervielfacht.
Die instinktive Reaktion des Managements verschlimmert alle drei Probleme. Mehr Statusbesprechungen, um den Überblick wiederzuerlangen, verschlingen die Zeit, die eigentlich für eine schnellere Umsetzung vorgesehen war. Mehr Genehmigungsebenen zur Gewährleistung der Kontrolle verlangsamen die Umsetzung, ohne Beweise zu liefern, die eine Aufsichtsbehörde tatsächlich nutzen kann. Mehr synchrone Abstimmung über Zeitzonen hinweg überfordert die Mitarbeiter, die dadurch koordiniert werden sollen. Die veröffentlichten Ergebnisse dieses Musters sind ernüchternd: Die Mehrheit der AI-Initiativen in Unternehmen gerät zwischen Pilotphase und Produktivbetrieb ins Stocken. Laut einer MIT-Studie von 2025 blieb bei rund 95 % der Initiativen ein messbarer wirtschaftlicher Nutzen aus. Die Ursache für das Scheitern liegt selten in der Technologie selbst. Entscheidend ist meist das Betriebsmodell, in das sie eingebettet ist.
Die These dieses Leitfadens in einem Satz: Geschwindigkeit, Kontrolle und verteilte Zusammenarbeit sind keine Zielkonflikte mehr, wenn Abstimmung durch Systeme statt durch Präsenz entsteht. Die nächsten fünf Kapitel sind die operative Umsetzung dieses Satzes.
Zukünftige Artikel zu diesem Unterthema werden hier verlinkt
Die meisten Unternehmen betrachten Abstimmung als ein Ereignis. Beispielsweise etwas, das in einem Meeting stattfindet und danach wieder vergessen wird. Skalierende Organisationen behandeln Abstimmung als Artefakt: schriftlich festgehalten, versioniert und jederzeit konsultierbar. Das ist um 07:00 Uhr in Zürich ebenso wie um 10:00 Uhr in Belgrad, ohne dass alle Beteiligten gleichzeitig in einem Call sein müssen verfügbar. Die Kernkomponenten: Entscheidungsprotokolle (was wurde entschieden, von wem und auf welcher Grundlage. Somit werden Entscheidungen nicht immer wieder neu verhandelt), Arbeitsvereinbarungen pro Team (Definition of Done, Review-Standards, Eskalationswege), die explizit festgehalten sind statt nur im Kopf des Teams. Dazu kommt ein fester Demo-Rhythmus: Laufende Software ersetzt Statusberichte. Grundsätzlich gilt „Async First“. Gemeinsame Termine gibt es nur wenige und gezielt, nämlich dann, wenn echte Meinungsverschiedenheiten zu klären sind, nicht für den reinen Informationsaustausch.
Ab etwa 50 Engineers funktioniert die informelleAbstimmung nicht mehr. Die Leute, die bisher einfach alles wussten, verlieren den Überblick. Ab etwa 150 Engineers gibt es mehr Abhängigkeiten zwischen den Teams als innerhalb der Teams selbst. Schnittstellen, die nirgends dokumentiert sind, werden dann zur häufigsten Ursache für Verzögerungen und Fehler. Ab etwa 300 Engineers muss auch die Kultur gewahrt werden. Neue Mitarbeitende lernen nicht mehr einfach nebenbei, wie hier gearbeitet wird.
An jeder dieser Schwellen hat die Führung dieselbe Aufgabe. Sie muss erkennen, welche Abstimmung bisher stillschweigend davon abhing, dass die richtigen Leute im Raum waren. Und sie muss diese durch etwas ersetzen, das auch ohne sie funktioniert. In einer gut geführten Organisation sind Meetings für Ausnahmen da und nicht für den Alltag.
Zukünftige Artikel zu diesem Unterthema werden hier verlinkt
Drei Modelle dominieren den Markt für externe Engineering-Kapazitäten. Diese unterscheiden sich in einem einzigen Punkt, nämlich darin, wer die Verantwortung trägt. Staff Augmentation bringt zusätzliche Leute in Ihre Stand-ups. Somit gewinnen Sie Kapazitäten hinzu, doch die Verantwortung für Ergebnisse, Standards und Wachstum bleibt vollständig bei Ihnen. So werden Ihre Leads in grossem Massstab still und leise zu Managern von Mitarbeitenden eines anderen Unternehmens. Outsourced Delivery verlagert die gesamten Ergebnisse nach aussen, wodurch Verantwortung übertragen wird. Die Verantwortung geht nach aussen, das Wissen aber auch. Und die Zusammenarbeit erfolgt dann über einen Vertrag. Das Black-Box-Risiko ist der Struktur geschuldet und kein Charakterfehler des Anbieters. Embedded Teams gehen bewusst einen Mittelweg: Die Ingenieure des Partners arbeiten innerhalb Ihrer Organisation mit Ihren Tools, Ihren Ritualen und Ihrer Produktausrichtung. Dabei verantwortet der Partner weiterhin die Engineering-Standards, die Qualität der Teamzusammensetzung und die Delivery-Disziplin.
Damit Embedded Teams funktionieren, braucht es eine klare Aufteilung der Verantwortung. Der Kunde verantwortet das Was und das Warum, also Prioritäten, Produktentscheidungen und Domänenwissen. Der Partner verantwortet, wer im Team arbeitet und wie gut gearbeitet wird. Dazu gehören die Zusammensetzung des Teams, die Engineering-Standards, die Qualitätsprüfungen sowie eine lückenlose Dokumentation.
Entscheidend ist das Onboarding. Mit einem strukturierten Sprint 0 ist ein Embedded-Team innerhalb von Wochen produktiv und nicht erst nach Quartalen. Dazu gehören Zugänge, Umgebungen, Arbeitsvereinbarungen und ein erster geprüfter Merge. Unsere zehnjährige Zusammenarbeit mit SWISS folgt genau diesem Muster.
Ein einfacher Test für jedes Modell, das Ihnen angeboten wird: Wenn etwas zu spät geliefert wird oder nicht funktioniert, ist dann vertraglich klar, wessen Problem es ist? Lautet die Antwort „Das ist kompliziert“, haben Sie Staff Augmentation mit schlechterem Marketing gekauft.
Zukünftige Artikel zu diesem Unterthema werden hier verlinkt
Wenn AI einen nennenswerten Teil des Codes schreibt, verändert sich die Rolle der Führungskräfte. Der Engpass verschiebt sich vom Erzeugen von Änderungen zu deren Beurteilung und stellt damit ein Jahrzehnt an Intuition über Seniorität auf den Kopf. Das Risiko einer Senioritätsumkehr ist real und leicht zu übersehen: Junior Engineers können mit leistungsfähiger AI plausible Codeänderungen in bisher ungekanntem Umfang produzieren. Ohne verbindliche Review-Strukturen gelangt plausibel wirkender Code in Produktion. Die kontraintuitive Konsequenz: AI macht das Urteilsvermögen erfahrener Engineers wertvoller, nicht weniger, denn ihr Urteilsvermögen ist nun der Engpass und zugleich die Sicherheitsvorkehrung. Planen Sie Ihre Teamstruktur nach Senioritätsstufen entsprechend, bevor der Markt dies für Sie tut.
Drei Managementmassnahmen folgen. Erstens: Machen Sie „Gates“ zu einem Managementprinzip, nicht zu einem Tooling-Detail: „AI beschleunigt, Menschen übernehmen Verantwortung“ hat nur dann eine Bedeutung, wenn die Überprüfung technisch durchgesetzt und die Überprüfungsqualität tatsächlich stichprobenartig kontrolliert wird. Zweitens: Schützen Sie „Deep Work“ – AI-generiertes Volumen erzeugt AI-generiertes Rauschen, und Ingenieure, die in maschinell erzeugten Diffs zur Überprüfung versinken, benötigen dafür explizite Kapazitäten, Reviews dürfen dafür nicht nebenbei erledigt werden. Drittens: Behalten Sie die Lernpipeline im Auge: Wenn Nachwuchskräfte immer nur AI-Vorschläge akzeptieren, woher kommen dann die nächsten erfahrenen Mitarbeiter? Gezielte Übungen ohne AI, begleitete Reviews und wechselnde Verantwortung für die Qualitätsprüfungen sind deshalb kein nettes Extra für die Teamkultur mehr. Sie sichern das Urteilsvermögen, auf das sich Ihre Qualitätsprüfungen auch in Zukunftstützen.
Zukünftige Artikel zu diesem Unterthema werden hier verlinkt
Die meisten Engineering-Kennzahlen messen Aktivität, nicht Fortschritt. Und AI hat Aktivität billig gemacht. Dadurch werden die falschen Kennzahlen richtig gefährlich. Die erste Kennzahl, die abgeschafft werden sollte: AI-generierte Codezeilen. Sie misst genau das, was nichts mehr aussagt. Als Nächstes folgt die Auslastung. Eine voll ausgelastete Organisation hat keine Kapazität zum Nachdenken, und Nachdenken ist mittlerweile die eigentliche Aufgabe.
Was sich in der Praxis bewährt, ist ein kleines, belastbares Dashboard: Flow (Lead Time von der Entscheidung bis zur Produktion, die Kennzahl, die jedes organisatorische Hindernis sichtbar macht), Qualitätssignale (Change Failure Rate und Wiederherstellungszeit nach Ausfällen: Ging die höhere Geschwindigkeit zulasten der Stabilität?), Review-Tiefe (Werden Gates tatsächlich genutzt oder nur abgenickt? Stichproben zur Review-Qualität sind die Ergänzung für das AI-Zeitalter, die in den meisten Dashboards fehlt) und Outcome-Bezug (Was wurde ausgeliefert und was sollte damit erreicht werden? Das ist die einzige Kennzahl, die einen Vorstand wirklich interessiert). Vier Kategorien auf einer Seite, die gegenüber Engineers und Auditoren gleichermassen standhalten. Alles darüber hinaus ist Reporting-Theater. Bei AI-Tempo wird Reporting inzwischen schneller produziert, als es jemand lesen kann.
Zukünftige Artikel zu diesem Unterthema werden hier verlinkt
Bei der Sourcing-Entscheidung geht es im Kern um drei Fragen, die nacheinander beantwortet werden müssen. Ist die Kompetenz strategisch wichtig und dauerhaft erforderlich? Dann bauen Sie sie intern auf, aber berechnen Sie die Gesamtkosten ehrlich: Die Rekrutierung erfahrener Engineers auf dem Schweizer Markt dauert Monate, die Rekrutierung und Einarbeitung verursachen echte Kosten, und das Fluktuationsrisiko verstärkt dies noch; ein Einstellungsplan ist eine Wette auf zwei Jahre, kein Kauf. Handelt es sich um ein Produkt, das jemand anderes bereits besser betreibt? Dann kaufen Sie es. Nicht differenzierende Kompetenzen selbst aufzubauen, ist ein sicherer Weg, Engineering-Budgets zu verbrennen. Ist die Fähigkeit strategisch wichtig, aber die Kapazität oder die spezialisierten Kompetenzen fehlen? Dann ist ein Partner sinnvoll, aber eingebettet statt ausgelagert. So bleibt das Know-how am Ende bei Ihnen und nicht beim Anbieter.
Eine Anforderung gehört in jede Partnerschaftsentscheidung und taucht doch selten in Einkaufs-Checklisten auf: Exit-Freundlichkeit. Ein Partner, der von seinem Wert überzeugt ist, macht den Ausstieg einfach: Dokumentation als Lieferbestandteil, Wissenstransfer als Gewohnheit und keine proprietären Lock-ins in Ihrer eigenen Codebasis. Fordern Sie dies von vornherein ein; die Reaktion eines Partners auf diese Frage sagt mehr aus als seine Referenzen. Abhängigkeit durch Intransparenz ist keine Partnerschaft – sondern Lock-in mit Rechnung.
Zukünftige Artikel zu diesem Unterthema sind hier verlinkt
Wochen, nicht Quartale – vorausgesetzt, das Onboarding wird systematisch geplant und nicht improvisiert. Ein strukturierter Sprint 0 (Zugriff, Umgebungen, Arbeitsvereinbarungen) sowie ein erster geprüfter Merge innerhalb von zwei Wochen sind der Standard, an den wir uns halten; Kapitel 3 beschreibt die Vorgehensweise. Die entscheidende Variable ist nicht das Talent, sondern die Frage, ob beide Seiten das Onboarding als Projekt betrachten.
Ganz im Gegenteil. AI überschwemmt die Pipeline mit plausiblem Code. Dadurch werden das Urteilsvermögen, das Architektur-Review und die Risikobewertung zum Standard der Sicherheitsvorkehrungen. Dies ist per Definition eine Aufgabe für erfahrene Entwickler. Was AI reduziert, ist das Tippen, nicht das Denken. Kapitel 4 behandelt die Senioritätsumkehr und was sie für die Teamstruktur nach Senioritätsstufen bedeutet.
Weit weniger als bisher – sofern die Abstimmung in Artefakten verankert ist. Entscheidungsprotokolle, Arbeitsvereinbarungen und ein Demo-Rhythmus übernehmen die Routineaufgaben asynchron; synchrone Zeit wird für echte Meinungsverschiedenheiten sowie Architektur- und Designfragen reserviert. Der Test aus Kapitel 2: Wenn ein Meeting nur Informationen weitergibt, hätte es ein Dokument sein müssen.