Warum Ihr Entwicklungsteam langsamer wird (obwohl Sie weiter einstellen)

Vor einigen Jahren arbeitete ich mit einem Produktteam, das fünfzehn Entwickler hatte. Sie lieferten alle zwei Wochen neue Features aus. Das Management beschloss, die Teamgröße zu verdoppeln, um schneller zu liefern. Sechs Monate später, mit dreißig Entwicklern, lieferten sie nur noch alle drei Wochen. Alle waren verwirrt. Die Entwickler waren nicht faul. Sie waren nicht weniger qualifiziert. Etwas Unsichtbares bremste sie aus.

Dieses unsichtbare Etwas nennen wir heute kognitive Belastung. Und es ist der Hauptgrund, warum Plattform-Engineering existiert.

Die versteckte Arbeit vor dem Schreiben von Code

Stellen Sie sich vor, Sie sind ein Entwickler, der ein neues Feature umsetzen soll. Bevor Sie eine einzige Zeile Geschäftslogik schreiben, müssen Sie:

• Ein neues Repository mit den richtigen Branch-Schutzregeln einrichten
• Eine Build-Pipeline und eine Test-Pipeline erstellen
• Eine Entwicklungsumgebung konfigurieren, die mit einer Entwicklungsdatenbank verbunden ist
• Herausfinden, wie Sie auf die Staging-Umgebung deployen
• Den Produktions-Deployment-Prozess des Unternehmens erlernen
• Verstehen, wie Sie bei Problemen einen Rollback durchführen
• Monitoring und Logging für Ihren Service einrichten

Jede dieser Aufgaben erfordert einen Kontextwechsel. Sie müssen sich merken, welches Tool das Team für CI verwendet, welcher Cloud-Anbieter die Staging-Umgebung hostet, welche Datenbankversion kompatibel ist und wen Sie für den Produktionszugriff fragen müssen.

Für einen Entwickler, der sich darauf konzentrieren möchte, Features zu bauen, die Benutzer tatsächlich sehen, ist das ermüdend. Und es hat nichts mit Können zu tun. Selbst erfahrene Entwickler werden langsamer, wenn sie neben der Feature-Logik auch noch Infrastruktur-Wissen jonglieren müssen.

Die wahren Kosten: Kognitive Belastung

Kognitive Belastung ist die Menge an mentaler Anstrengung, die erforderlich ist, um eine Aufgabe zu erledigen. Wenn Sie ein Feature schreiben, verarbeitet Ihr Gehirn die Geschäftslogik, den Datenfluss, die Randfälle. Das ist schon viel. Jetzt kommen Deployment-Befehle, Umgebungsvariablen, Pipeline-Konfiguration und Rollback-Prozeduren hinzu. Ihr Gehirn teilt seine Kapazität nun zwischen zwei sehr unterschiedlichen Bereichen auf.

Das Ergebnis ist vorhersehbar: Features dauern länger, Fehler passieren häufiger, und Entwickler fühlen sich am Ende des Tages ausgelaugt. Nicht, weil sie schlecht in ihrem Job sind, sondern weil sie gezwungen sind, zu viele Dinge gleichzeitig im Kopf zu behalten.

Dieses Problem verstärkt sich mit dem Unternehmenswachstum. Ein Team von drei bis fünf Personen kann Wissen informell teilen. Jeder weiß, wie die anderen deployen. Aber wenn Sie zehn Produktteams haben, jedes mit eigenen Vorlieben, vervielfacht sich das Chaos. Ein Team verwendet Jenkins. Ein anderes nutzt GitLab CI. Ein drittes setzt GitHub Actions ein. Ein Team deployt direkt in die Produktion. Ein anderes erfordert drei manuelle Freigabestufen. Ein Team betreibt Kubernetes. Ein anderes verwendet einfache virtuelle Maschinen.

Jetzt ist das Plattform- oder DevOps-Team überfordert, weil jedes Team Hilfe mit einem anderen Setup braucht. Und die Produktteams sind immer noch langsam, weil sie die Hälfte ihrer Zeit mit Infrastruktur verbringen.

Plattform-Engineering ist kein weiteres Tool

Hier kommt Plattform-Engineering ins Spiel. Aber es ist wichtig zu verstehen, was es ist und was nicht.

Plattform-Engineering bedeutet nicht, ein schickes Dashboard zu bauen oder ein neues Tool zu kaufen. Es ist ein Mindset-Wechsel: Infrastruktur und Pipelines sind keine Nebenprojekte mehr, die Teams erledigen, wenn sie Zeit haben. Sie werden zu internen Produkten, die mit derselben Sorgfalt entworfen, gebaut und gewartet werden müssen wie die Produkte, die Ihre Kunden nutzen.

Die Kernidee ist einfach: Anstatt dass jedes Team seine eigene Pipeline von Grund auf neu baut, stellt das Plattform-Team einen gebrauchsfertigen Pfad bereit. Anstatt dass jedes Team lernt, wie man in die Produktion deployt, stellt die Plattform einen getesteten, sicheren Deployment-Mechanismus bereit. Produktteams konzentrieren sich auf Code und Features. Die Plattform übernimmt den Infrastruktur- und Pipeline-Overhead.

Das reduziert die kognitive Belastung drastisch. Entwickler müssen sich nicht mehr merken, wie man Umgebungen einrichtet, Monitoring konfiguriert oder Rollbacks durchführt. Die Plattform erledigt das. Sie schreiben einfach Code und führen die bereits vorhandene Pipeline aus.

Die Falle der Einheitslösung

Aber hier scheitern viele Plattform-Bemühungen. Sie versuchen, jedes Team in denselben Workflow zu zwingen. Das funktioniert nicht, weil Teams unterschiedliche Anforderungen haben. Manche brauchen schnelle Deployment-Zyklen. Manche benötigen strenge Freigabeprozesse. Manche verwenden spezifische Datenbanken oder Programmiersprachen, die eine besondere Behandlung erfordern.

Wenn die Plattform zu starr ist, werden Teams sie umgehen. Sie bauen ihre eigenen Workarounds, und Sie sind wieder beim ursprünglichen Problem fragmentierter Infrastruktur und hoher kognitiver Belastung.

Eine gute Plattform berücksichtigt Unterschiede, ohne Teams dazu zu zwingen, wieder alles selbst zu verwalten. Sie bietet einen Standardpfad, der die häufigsten Fälle abdeckt, erlaubt Teams aber, dort Entscheidungen zu treffen, wo es wichtig ist. Hier kommt das Konzept des Goldenen Pfads ins Spiel, das wir später im Detail untersuchen werden.

Was das für Ihr Team bedeutet

Wenn Ihr Engineering-Team wächst, aber die Liefergeschwindigkeit nicht, schauen Sie sich die unsichtbare Arbeit an. Fragen Sie Ihre Entwickler: Was müssen Sie wissen oder tun, bevor Sie mit der Entwicklung eines Features beginnen können? Die Antworten zeigen Ihnen, wo die kognitive Belastung am höchsten ist.

Das Ziel von Plattform-Engineering ist nicht, Teams zu kontrollieren. Es geht darum, die Reibung zu beseitigen, die sie ausbremst. Wenn es gut gemacht ist, können Entwickler in ihrem Flow-Zustand bleiben, Features bauen, die wichtig sind, während die Plattform den Rest erledigt.

Praktische Checkliste

Bevor Sie mit dem Bau einer Plattform beginnen, stellen Sie diese Fragen:

• Welche Aufgaben wiederholen Entwickler bei jedem Feature oder Service?
• Welche Infrastrukturaufgaben erfordern die meiste Zeit zum Lernen oder Troubleshooting?
• Wo bauen Teams eigene Workarounds, weil der bestehende Prozess nicht passt?
• Was müsste ein Entwickler heute wissen, um einen neuen Service von Grund auf zu deployen?
• Welche Teile der Pipeline verursachen die meiste Angst oder Verzögerungen bei Releases?

Das Fazit

Ihr Team wird nicht langsamer, weil es seinen Job schlecht macht. Es wird langsamer, weil es unsichtbares Gewicht trägt. Plattform-Engineering bedeutet, dieses Gewicht zu entfernen, nicht weitere Werkzeuge hinzuzufügen. Beginnen Sie damit zu verstehen, womit Ihre Entwickler tatsächlich kämpfen, und bauen Sie dann den Pfad, der diese Kämpfe verschwinden lässt.