Der erste Skalierungsbruch im Software-Outsourcing ist selten der Code, sondern die Schnittstelle zwischen Entscheidung, Vertrag und Lieferung. Meine unbequeme Position: Ein CTO sollte eher standardisierte Lieferfähigkeit einkaufen als vorschnell intern aufbauen, solange die Domäne nicht das Differenzierungszentrum ist, weil interne Teams bei wachsender Unsicherheit langsamer lernen als ein eingespieltes Liefermodell.
Bei Skalierung bricht zuerst die Entscheidungskette, nicht das Entwicklerteam
Viele CTOs fragen zuerst, ob externe Entwickler gut genug sind; die bessere Frage lautet, wie viele ungeklärte Entscheidungen pro Woche das Modell aushält. Ein einzelnes ausgelagertes Team kann Unschärfe noch durch direkte Kommunikation kompensieren, aber ab zwei oder drei parallelen Streams entstehen Wartezeiten, weil Product Owner, Architekturverantwortliche und Security-Freigaben nicht proportional mitwachsen.
Wie Outsourcing die Entwicklungskosten nachhaltig senkt unterschätzt als These oft den Preis von unklaren Entscheidungsrechten, weil niedrigere Tagessätze durch Blocker, Rework und Kontextwechsel aufgezehrt werden können. Das ist kein Argument gegen Outsourcing, sondern gegen naives Skalieren über zusätzliche Köpfe.
Ich würde nicht mit einem großen internen Hiring-Programm starten, nur um Kontrolle zu demonstrieren, weil Recruiting, Onboarding und Architekturfindung gleichzeitig eine Latenz erzeugen, die in der Regel später sichtbar wird als die ersten Vendor-Rechnungen. In einem gemessenen Programm mit drei Teams stieg die durchschnittliche Zeit von Story-Start bis Merge von 2,1 auf 6,4 Arbeitstage, obwohl die Zahl der Entwickler von 9 auf 21 wuchs; der Engpass lag in Review- und Produktentscheidungen, nicht in der Implementierung.
Skalierbares Outsourcing braucht deshalb ein Operating Model mit expliziten Grenzen: Domain Ownership, Definition of Done, API-Verträge, Security-Gates und Eskalationszeiten. Jira oder Linear allein lösen das nicht, weil ein Ticket-System nur Arbeit sichtbar macht, aber keine Entscheidung trifft. Sinnvoller sind Decision Records nach dem ADR-Format, Pull-Request-Regeln in GitHub Enterprise oder GitLab 16.11, CODEOWNERS-Dateien und ein Architekturforum mit maximal 30 Minuten Entscheidungsfenster pro strittigem Punkt; die 30 Minuten sind ein bewusst zu justierender Richtwert, weil längere Diskussionen häufig verdeckte Produktunsicherheit statt technische Tiefe anzeigen.
Der erste Skalenschaden zeigt sich meist in vier Symptomen: Backlogs werden feiner, aber nicht klarer; Sprint Reviews erzeugen neue Interpretationen statt Abnahmen; externe Teams optimieren auf Auslastung statt Durchsatz; interne Stakeholder verwechseln Kontrolle mit Detailfreigabe. Diese Symptome sind teuer, weil sie die DORA-Metriken verschlechtern: Lead Time for Changes steigt, Deployment Frequency sinkt, Change Failure Rate wird politisiert, und MTTR bleibt unklar, solange niemand die Produktionsverantwortung eindeutig besitzt.
Die falsche Standardfrage lautet: bauen oder kaufen?
Die nützlichere Standardfrage lautet: Welche Unsicherheit will ich besitzen? In-house gewinnt, wenn das technische System selbst die strategische Differenzierung erzeugt, weil Architekturentscheidungen dann Produktentscheidungen sind. Buying oder Outsourcing gewinnt, wenn die Unsicherheit vor allem in Kapazität, Geschwindigkeit oder Standardintegration liegt, weil ein externer Partner dort Wiederholungsvorteile mitbringt.
Der direkte Vergleich ist weniger romantisch, aber ehrlicher. Option A: internes Produktteam gewinnt bei proprietären Kernalgorithmen, langfristiger Plattform-IP und sensibler Architekturhoheit; es kostet bei sechs Senior Engineers, einem Engineering Manager und einer QA/Automation-Rolle schnell etwa 80.000 bis 105.000 Euro pro Monat inklusive Arbeitgeberkosten, Tools, Recruiting und Fluktuationspuffer, wobei diese Spanne aus marktüblichen Vollkostenannahmen abgeleitet ist. Option B: eingekauftes Dedicated Delivery Team gewinnt bei klar umrissenen Roadmap-Paketen, Integrationen und Modernisierungsvorhaben; es kostet bei sieben Rollen und 45 bis 75 Euro pro Stunde ungefähr 44.000 bis 73.500 Euro pro Monat, wenn man 140 produktive Stunden je Rolle ansetzt, wobei dieser Wert ein Kalkulationsmodell und kein Naturgesetz ist.
Die zweite Option ist nicht automatisch billiger, weil Vendor Management, Architekturarbeit und interne Produktverantwortung bleiben. Sie skaliert aber oft früher, weil ein Anbieter bereits Routinen für Staffing, Delivery Management, Testautomatisierung und Übergaben hat. Genau deshalb kauft man nicht „Entwickler“, sondern ein wiederholbares System aus Rollen, Artefakten und Qualitätsgrenzen.
Ein CTO sollte hier hart unterscheiden: Kaufen Sie Output, wenn Sie Input nicht sinnvoll führen können; bauen Sie intern, wenn Sie die Lernkurve selbst besitzen müssen. Wer diese Grenze ignoriert, bezahlt doppelt, weil externe Teams dann interne Unklarheit ausprogrammieren sollen und interne Teams später externe Kompromisse zurückbauen müssen.
Konkreter: Eine interne Plattformgruppe sollte Standards setzen, nicht jedes Feature selbst schreiben. Sie definiert OpenAPI 3.1 für REST-Schnittstellen, AsyncAPI 3.0 für Event-Verträge, Protobuf v3 für gRPC-Kommunikation, OAuth 2.1 oder OIDC für Identität, SLSA Level 2 als Mindeststandard für Build-Provenance und OWASP ASVS 4.0.3 als Prüfraster für kritische Anwendungen. Das ist kein Governance-Theater, weil solche Standards die Zahl der Rückfragen reduzieren und externe Teams unabhängig entscheidungsfähig machen.
Agilität skaliert erst, wenn Verträge weniger agil werden
Wie agile Methoden das Outsourcing in der Softwareentwicklung revolutionieren klingt mir zu optimistisch, weil agile Rituale ohne harte Schnittstellen bei mehreren Teams nur die Meetinglast erhöhen. Daily, Refinement und Sprint Review helfen, wenn die Produktgrenze stabil ist; sie verdecken Chaos, wenn jedes Team gleichzeitig Architektur, Priorität und Abnahme neu verhandelt.
Der kontraintuitive Punkt: Bei skalierendem Outsourcing müssen einige Dinge unagil werden. Abnahmekriterien, Service-Level, Security-Anforderungen, Ownership und API-Kompatibilität gehören nicht in permanente Neuverhandlung, weil externe Teams sonst nicht autonom liefern können. Beweglich bleiben sollten Prioritäten, Reihenfolge und Lösungsdetails innerhalb dieser Leitplanken.
Ein gutes Setup nutzt Scrum oder Kanban nicht als Kulturversprechen, sondern als Durchsatzmechanik. Für Produktarbeit mit hoher Unsicherheit kann Scrum mit zweiwöchigen Sprints gewinnen, weil Review-Zyklen Lernkosten begrenzen. Für Betriebs- und Integrationsarbeit gewinnt Kanban mit WIP-Limits, weil Durchlaufzeit wichtiger ist als Sprint-Symbolik. Ein WIP-Limit von 2 parallelen Stories pro Entwickler ist ein zu kalibrierender Startwert, weil zu viel Parallelität Review-Staus erzeugt und zu wenig Parallelität bei externen Abhängigkeiten Leerlauf verursachen kann.
Messung muss dabei banal und operationalisierbar sein. Ein p95-Ziel von 800 Millisekunden für eine zentrale API ist ein Tuning-Wert, der in vielen B2B-Systemen als erster Performance-Korridor reicht, aber bei Echtzeit-Workloads zu hoch wäre. Eine Change Failure Rate unter 15 Prozent ist als DORA-orientierte Zielmarke brauchbar, weil sie Qualität und Deployment-Mut zusammen betrachtet. Ein dokumentierter Kubernetes-Default wie terminationGracePeriodSeconds: 30 ist wichtig, weil Rolling Updates bei langsamen Shutdowns sonst scheinbar zufällig fehlschlagen.
Externe Skalierung braucht außerdem technische Verträge, die ausführbar sind. Pact 4 kann Consumer-Driven Contracts prüfen, Schemathesis kann OpenAPI-Spezifikationen testen, k6 v0.49 kann Lastannahmen reproduzierbar machen, und Playwright 1.43 kann kritische User Journeys im Browser absichern. Ohne solche prüfbaren Artefakte werden Sprint Reviews zu Meinungsrunden, weil niemand objektiv zeigen kann, ob eine Lieferung kompatibel, schnell und stabil genug ist.
import http from 'k6/http';
import { check, sleep } from 'k6';
export const options = {
vus: 20,
duration: '2m',
thresholds: {
http_req_duration: ['p(95)<800'],
http_req_failed: ['rate<0.01']
}
};
export default function () {
const res = http.get('https://test.k6.io');
check(res, { 'status is 200': r => r.status === 200 });
sleep(1);
}
Dieses Beispiel ist bewusst klein, weil ein Test, den jedes Team lokal ausführen kann, mehr Skalierungswert hat als ein perfektes Performance-Labor, das nur ein Spezialist versteht. Die Werte 20 virtuelle Nutzer und 2 Minuten Laufzeit sind keine Produktionsaussage, sondern ein Startprofil für Pull-Request-nahe Regressionen.
Die Toolchain bricht, wenn sie als Vendor-Ersatz missverstanden wird
Viele Organisationen kaufen Tools, wenn sie eigentlich Verantwortlichkeit kaufen müssten. GitHub Actions mit required_status_checks, GitLab CI mit rules:changes, SonarQube 10.4 mit Quality Gates, Snyk CLI mit –severity-threshold=high, Trivy 0.50 für Container-Scans und Dependabot für Updates sind nützlich, weil sie Qualitätsgrenzen automatisieren. Sie ersetzen aber kein Delivery Ownership, weil ein grüner Build nicht entscheidet, welches Risiko geschäftlich akzeptabel ist.
Bei Skalierung bricht zuerst die Anschlussfähigkeit der Toolchain. Ein einzelnes Team kann lokale Skripte, manuelle Deployments und implizite Umgebungsvariablen tolerieren; fünf Teams verwandeln dieselben Praktiken in Produktionsrisiko, weil jede Abweichung zur Integrationsfrage wird. Terraform 1.7 mit Remote State, Helm 3.14 für Kubernetes-Manifeste, Argo CD 2.10 für GitOps und Vault 1.15 für Secrets sind deshalb keine Luxusausstattung, sondern eine gemeinsame Sprache für Infrastrukturänderungen.
Ich würde nicht zulassen, dass jeder Vendor seine eigene CI/CD-Variante mitbringt, weil die kurzfristige Bequemlichkeit später Auditierbarkeit, Incident Response und Kostenkontrolle beschädigt. Der bessere Kompromiss ist ein zentrales Golden Path Repository mit erlaubten Templates, etwa für Node.js 20, Java 21 oder .NET 8, und kontrollierten Ausnahmen über Architecture Decision Records. Das wirkt bürokratisch, spart aber Zeit, weil neue Teams nicht bei Null anfangen und Security nicht jedes Projekt einzeln erziehen muss.
Observability ist der zweite Bruchpunkt. Logging allein reicht nicht, weil verteilte Fehler selten in genau dem Service sichtbar sind, der die Ursache setzt. OpenTelemetry 1.32, Prometheus 2.51, Grafana 10.4, Loki 2.9 und Sentry können zusammen sinnvolle Signale liefern, wenn Correlation IDs über HTTP, gRPC und Message Broker hinweg erhalten bleiben. Ohne Trace-Kontext nach W3C Trace Context werden externe Teams bei Incidents raten, weil sie nur ihren Ausschnitt sehen.
Auch Kosten brechen hier. Ein vendor-veröffentlichter Preis von 0,008 US-Dollar pro GitHub Actions Linux-Minute wirkt harmlos, bis monorepo-weite Testläufe bei jedem Push starten. Ein gemessener CI-Lauf von 18 Minuten ist akzeptabel für nächtliche Regression, aber zu langsam für Pull Requests, weil Entwickler dann Kontext verlieren. Ein Ziel von unter 10 Minuten für PR-Feedback ist ein sinnvoller Steuerwert, weil schnelle Rückmeldung Rework senkt und externe Teams weniger Leerlauf produzieren.
Der erste Schritt ist ein Skalierungsvertrag, nicht ein Rahmenvertrag
Ein klassischer Rahmenvertrag beschreibt Preise, Laufzeiten und Haftung; ein Skalierungsvertrag beschreibt, wie Arbeit größer werden darf, ohne Qualität und Entscheidungsgeschwindigkeit zu zerstören. Er sollte festlegen, ab welcher Teamgröße zusätzliche Architekturkapazität entsteht, wer Produktionsrisiken abnimmt, wie technische Schulden budgetiert werden und welche Metriken eine Eskalation auslösen.
Praktisch heißt das: Definieren Sie vor dem zweiten externen Team ein Delivery Operating Agreement. Darin stehen Merge-Regeln, Testpflichten, API-Versionierung, Incident-Rollen, SLOs, Datenzugriffe und Exit-Artefakte. Ein externer Partner sollte Repositories, Pipelines, Dokumentation und Runbooks so liefern, dass ein anderes Team übernehmen kann, weil echte Skalierbarkeit immer auch Austauschbarkeit enthält.
Die Exit-Frage ist kein Misstrauenssignal, sondern ein Qualitätsfilter. Ein Anbieter, der saubere Übergabe ablehnt, verkauft Abhängigkeit, weil er wirtschaftlich von Intransparenz profitiert. Ein Anbieter, der ADRs, OpenAPI-Dateien, Terraform-Module, Testberichte und Observability-Dashboards selbstverständlich hinterlässt, verkauft Lieferfähigkeit, weil seine Leistung auch ohne Geheimwissen überprüfbar bleibt.
Für den CTO ist die härteste Entscheidung nicht Vendor ja oder nein, sondern welche internen Rollen niemals ausgelagert werden. Product Accountability, Architekturprinzipien, Security-Risikofreigaben und Budgetpriorisierung gehören intern verankert, weil sie Geschäftsentscheidungen mit technischer Wirkung sind. Implementierung, Testautomatisierung, Migrationspakete und Integrationsarbeit können extern skaliert werden, wenn die Grenzen maschinenprüfbar und organisatorisch klar sind.
Starten Sie mit einem 10-tägigen Skalierungs-Audit, bevor Sie Stellen ausschreiben oder ein großes Lieferpaket kaufen. Prüfen Sie je ein Repository, eine Pipeline, eine API, ein Incident-Protokoll und fünf abgeschlossene Tickets auf Entscheidungswartezeit. Danach wissen Sie, ob Sie ein Teamproblem, ein Vertragsproblem oder ein Architekturproblem haben.
