Warum wir auf Senior-Teams setzen — und was das wirtschaftlich bedeutet

Die Produktivitätsspanne ist empirisch — nicht meinungsbasiert

Im Boutique-Modus arbeiten wir bewusst mit kleinen, sehr erfahrenen Teams. Das ist nicht Romantik, sondern Ökonomie. Die empirische Grundlage geht auf Sackman, Erikson und Grant (1968) zurück, deren Studie an System Development Corporation ^[1] Produktivitätsunterschiede zwischen Programmierern von 1:10 bei gleicher Aufgabe dokumentierte. Boehm hat das 1981 in COCOMO als „personnel attributes" mit den höchsten Effort-Multipliers operationalisiert ^[2].

DeMarco und Lister haben in den 80er Jahren in ihren „Coding War Games" mit über 600 Teilnehmern Werte bis 1:28 gemessen, korrigiert um Aufgaben- und Sprach-Effekte ^[3]. Selbst skeptische Re-Analysen (etwa Glass, 2002) sehen Spannweiten von 1:5 bis 1:10 als robusten Befund. Jede Stunde Senior-Arbeit erspart drei bis fünf Stunden späterer Korrektur — eine Zahl, die mit unserer eigenen Mandats-Praxis seit 2014 deckungsgleich ist.

Was „senior" bei uns konkret bedeutet

Senior heißt für uns nicht „lange dabei" — es heißt: jemand hat ein vergleichbares System schon einmal in Produktion gehoben, betrieben und weiterentwickelt. Wer nur Architekturen zeichnet, ohne sie selbst zu betreiben, übersieht die Hälfte der relevanten Entscheidungen. Das deckt sich mit Brooks' Beobachtung in „The Mythical Man-Month" (1975) ^[4], dass die teuersten Fehler in der Software-Entwicklung Konzept-Fehler sind, die in der Operations-Phase sichtbar werden.

Praktische Konsequenz: jede Person in unserem Team hat mindestens fünf Jahre dokumentierte Run-Verantwortung. Das ist nicht das einzige Kriterium, aber es ist die Schwelle, unterhalb derer wir keine Hauptverantwortung in einem Mandat übergeben.

Was das für Pricing und Scope bedeutet

Das hat Konsequenzen für unser Pricing und unseren Scope. Wir nehmen weniger Mandate gleichzeitig an, dafür arbeiten wir tief. Wenn Sie ein Mandat suchen, in dem Senior-Personal an der Tastatur sitzt — nicht nur im Kickoff — sind Sie bei uns richtig. Wenn Sie 40 Köpfe für einen Sprint brauchen, ist eine Großberatung der bessere Anbieter.

Konkret heißt das: unsere Tagessätze liegen 30–50 % über dem Marktdurchschnitt, unsere Team-Größen 50–70 % unter dem Marktdurchschnitt. Das Gesamtbudget eines Mandats liegt oft trotzdem niedriger, weil weniger Personen weniger Koordination brauchen — Brooks' Gesetz wirkt symmetrisch, also auch nach unten.

In Mandaten wie Sahel Beauty oder Bestino haben drei bis vier Senior-Engineers Plattformen geliefert, für die ein klassisches Setup typischerweise zehn bis fünfzehn Köpfe vorgesehen hätte. Die Differenz ist der Hebel, den dieses Modell ermöglicht.

Was wir an einen Klienten zurückgeben — die Wissens-Übergabe

Ein Senior-Team birgt das Risiko, dass Wissen bei wenigen Personen liegt. Wir adressieren das aktiv durch Dokumentations-Pflicht: jede Architekturentscheidung wird als ADR (Architecture Decision Record nach Nygard, 2011) ^[5] schriftlich festgehalten, jede Komponente bekommt eine Run-Doku, jede sensitive Operation einen Runbook.

Bei Mandats-Ende ist die Übergabe an Ihr internes Team oder einen Nachfolge-Anbieter Teil der Lieferung. Wir setzen uns mit Ihrem Team zusammen, wir gehen den Stack durch, wir bleiben für eine Übergangsphase ansprechbar. Vendor-Lock-in ist nicht Teil unseres Geschäftsmodells — Trust durch Wiedereinladung ist es.

1. [1]
   Exploratory Experimental Studies Comparing Online and Offline Programming Performance (Communications of the ACM)

   Sackman, H., Erikson, W. J., Grant, E. E. (1968) · paper
2. [2]
   Software Engineering Economics (Boehm, 1981) — COCOMO Effort Multipliers

   Barry W. Boehm (1981) · book
3. [3]
   Peopleware: Productive Projects and Teams (3rd Edition) — Coding War Games

   Tom DeMarco, Tim Lister (2013) · book
4. [4]
   The Mythical Man-Month: Essays on Software Engineering (Anniversary Edition)

   Frederick P. Brooks Jr. (1995) · book
5. [5]
   Documenting Architecture Decisions (Relevance Blog)

   Michael Nygard (2011) · article