Fast jeder CTO erlebt früher oder später dieselbe Situation. Die Roadmap gerät unter Druck. Deadlines verschieben sich. Kunden warten auf Features. Investoren erwarten schnelleres Wachstum. Interne Teams werden unruhig.
Die erste Reaktion klingt meistens logisch: „Wir brauchen mehr Entwickler.“
Manchmal stimmt das auch. Doch erstaunlich oft verschlechtert zusätzliches Personal die Situation sogar. Mehr Engineers bedeuten häufig:
- Mehr Abstimmungen
- Mehr Abhängigkeiten
- Mehr Meetings
- Mehr Konflikte im Code
- Mehr Onboarding
- Mehr Unsicherheit bei Verantwortlichkeiten
Das Ergebnis ist oft ein grösseres Team, das trotzdem langsamer arbeitet.
Genau dieses Muster sehen wir bei ADUK GmbH regelmässig in Projekten rund um Embedded Systems, IoT und vernetzte Produkte.
Das eigentliche Problem ist oft nicht fehlende Engineering-Kapazität, sondern fehlende Klarheit, Struktur und stabile Prozesse.
Warum mehr Entwickler zunächst sinnvoll wirken
Die Annahme ist nachvollziehbar. Wenn fünf Entwickler die erste Produktversion in sechs Monaten gebaut haben, müssten fünfzehn Entwickler die nächste Version doch deutlich schneller liefern können.
In der Praxis funktioniert Engineering jedoch nicht linear. Mit jedem neuen Teammitglied steigt auch die organisatorische Komplexität:
- Mehr Kommunikation
- Mehr Koordination
- Mehr Abhängigkeiten
- Mehr technische Diskussionen
- Mehr Wissenslücken
Irgendwann verbringt das Team mehr Zeit mit Abstimmungen als mit echter Entwicklungsarbeit.
Besonders sichtbar wird das in Embedded- und Hardware-Projekten, wo Firmware, Software, Cloud, Mobile Apps, Produktion und Testing eng miteinander verbunden sind.
Mehr Leute in ein bereits überlastetes System einzubringen erzeugt oft zusätzliche Reibung.
Die versteckten Kosten wachsender Teams
Eine der grössten Fehlannahmen im Engineering ist die Gleichsetzung von Produktivität und Teamgrösse. Produktivität hängt viel stärker von Struktur, Klarheit und Kommunikation ab.
Ein kleines, gut abgestimmtes Team kann deutlich leistungsfähiger sein als eine grosse Organisation mit unklaren Verantwortlichkeiten. Typische Warnsignale dafür sind:
1. Entwickler warten ständig auf Entscheidungen
Wenn Engineers durch fehlende Freigaben, unklare Prioritäten oder Architekturfragen blockiert werden, löst mehr Personal das Problem nicht.
Der Engpass liegt dann bei Entscheidungen, nicht bei Kapazität.
2. Anforderungen ändern sich permanent
Wenn Produktanforderungen jede Woche angepasst werden, verlieren Teams ihren Fokus. Anstatt vorwärts zu entwickeln, bauen sie ständig bestehende Lösungen um. Das deutet oft auf Probleme im Produktmanagement oder in der internen Abstimmung hin.
3. Niemand besitzt das Gesamtsystem
In wachsenden Organisationen werden Verantwortlichkeiten häufig fragmentiert. Ein Team verantwortet Firmware. Ein anderes Cloud-Infrastruktur. Ein weiteres QA oder Integrationen.
Doch niemand trägt Verantwortung für das Verhalten des Gesamtsystems. Wenn Probleme auftreten, zeigen Teams schnell auf Abhängigkeiten statt auf Lösungen.
4. Technical Debt bremst alles aus
Viele Unternehmen priorisieren neue Features dauerhaft höher als Wartbarkeit. Kurzfristig wirkt das effizient. Langfristig wird jede Änderung langsamer und riskanter. Mehr Entwickler auf instabilen Grundlagen beschleunigen oft nur das Chaos.
Brooks’s Law gilt noch immer
Der Informatiker Fred Brooks formulierte bereits vor Jahrzehnten das bekannte Prinzip „Brooks’s Law“: „Adding manpower to a late software project makes it later.“
Der Grund dafür ist einfach. Neue Entwickler benötigen Einarbeitung, Kontext, Mentoring und Integration in bestehende Prozesse. Senior Engineers verbringen dadurch weniger Zeit mit eigentlicher Entwicklung.
Wenn Kommunikation und Struktur bereits schwach sind, verstärkt zusätzliche Teamgrösse die Probleme weiter. Moderne Entwicklungsumgebungen sind heute sogar noch komplexer:
- Cloud-Plattformen
- CI/CD-Pipelines
- Security-Anforderungen
- Verteilte Teams
- Compliance
- Hardware-Abhängigkeiten
- Multi-Plattform-Systeme
Die Kosten für Koordination sind höher als je zuvor.
Worauf CTOs stattdessen fokussieren sollten
Die stärksten Engineering-Organisationen skalieren zuerst ihre Systeme, nicht nur ihre Teamgrösse. Das bedeutet: Prozesse und Zusammenarbeit verbessern, bevor aggressiv eingestellt wird.
Mehr Klarheit im Engineering schaffen
Viele Lieferprobleme entstehen durch Unsicherheit. Teams wissen nicht genau:
- Was Priorität hat
- Welche Ziele erwartet werden
- Welche technische Richtung gilt
Gute technische Führung reduziert Unsicherheit frühzeitig.
Dazu gehören:
- Klare Verantwortlichkeiten
- Stabile Prioritäten
- Transparente Entscheidungen
- Gemeinsame Architekturprinzipien
Klarheit schafft Geschwindigkeit. Unklarheit erzeugt versteckte Verzögerungen.
Koordinationsaufwand reduzieren
Mit wachsender Teamgrösse wird Kommunikation schnell zum grössten versteckten Kostenfaktor. CTOs sollten aktiv versuchen, unnötige Abstimmungen zu reduzieren. Zum Beispiel durch:
- Kleine autonome Teams
- Klare Schnittstellen
- Definierte API-Verträge
- Dokumentierte Prozesse
- Weniger Freigabestufen
Das Ziel ist nicht mehr Bürokratie. Das Ziel ist reibungslosere Umsetzung.
In technische Grundlagen investieren
Instabile technische Grundlagen verlangsamen jedes zukünftige Projekt. Erfolgreiche Organisationen investieren kontinuierlich in:
- Test-Infrastruktur
- Deployment-Automatisierung
- Observability
- Dokumentation
- Interne Tools
- Architekturverbesserungen
Diese Themen wirken in Präsentationen oft weniger spektakulär, erzeugen aber langfristige Geschwindigkeit.
Bei ADUK sehen wir regelmässig, wie stark stabile technische Grundlagen die Lieferfähigkeit beeinflussen.
Zeit der Senior Engineers schützen
Senior Engineers verbringen häufig zu viel Zeit in Meetings, Firefighting oder Support-Aufgaben. Gleichzeitig wundert sich das Unternehmen über sinkende Architekturqualität.
Starke technische Führung schützt gezielt Fokuszeiten für erfahrene Entwickler. Ohne diese Zeit verliert die Organisation langfristig ihre technische Richtung.
Produkt und Engineering besser abstimmen
Viele technische Probleme sind eigentlich organisatorische Probleme. Wenn Produkt, Business und Engineering unterschiedliche Ziele verfolgen, wird Delivery chaotisch. CTOs sollten sicherstellen, dass:
- Business-Prioritäten verstanden werden
- Produktumfang realistisch bleibt
- Timelines technische Komplexität berücksichtigen
- Trade-offs früh sichtbar werden
Dadurch entstehen realistischere Planungen und stabilere Abläufe.
Wann mehr Entwickler tatsächlich sinnvoll sind
Natürlich gibt es Situationen, in denen zusätzliche Engineers absolut sinnvoll sind. Zum Beispiel wenn:
- Die Nachfrage tatsächlich höher ist als die Kapazität
- Teams bereits effizient arbeiten
- Verantwortlichkeiten klar definiert sind
- Prozesse skalierbar aufgebaut wurden
- Technische Grundlagen stabil sind
Dann kann zusätzliches Personal Wachstum massiv beschleunigen. Doch gesunde Skalierung funktioniert meist erst dann gut, wenn organisatorische Klarheit bereits vorhanden ist.
Gute CTOs skalieren Systeme, nicht nur Teams
Starke technische Führung zeigt sich nicht daran, wie gross ein Team ist. Sie zeigt sich daran, wie zuverlässig eine Organisation Ergebnisse liefern kann. Dafür braucht es funktionierende Systeme:
- Technische Systeme
- Kommunikationssysteme
- Planungssysteme
- Entscheidungsprozesse
- Ownership-Strukturen
Hiring ist nur ein Teil davon. Die besten CTOs verstehen, dass sich Engineering-Komplexität nicht einfach mit mehr Personal lösen lässt. Manchmal entsteht Geschwindigkeit nicht durch mehr Menschen, sondern durch weniger Reibung.
Fazit
Engineering-Organisationen scheitern selten daran, dass Entwickler nicht hart genug arbeiten. Viel häufiger verhindern ineffiziente Strukturen eine gute Umsetzung.
Mehr Engineers in ein schlecht abgestimmtes System einzubringen kann Probleme kurzfristig verdecken, langfristig werden sie jedoch grösser zurückkommen.
Unternehmen, die nachhaltig skalieren, fokussieren sich zuerst auf Klarheit, Architektur, Ownership und stabile Prozesse. Erst dann wird Hiring wirklich zum Multiplikator.
