Wechsel in Entwicklungsprojekten bedeuten oft Aufwand und Unsicherheit – doch Fluktuation kann auch Vorteile bringen, Innovation fördern und die Softwarequalität langfristig erhöhen. Zumindest mit dem richtigen Mindset.
Nach einem halben Jahr Babypause zurück in Job und Projekt – und ich muss zugeben, ich war erst ein wenig enttäuscht, wie gut es ohne mich lief: Ich dachte, ich sei wichtig für das Team?! Die Erkenntnis hat ein bisschen gedauert: #PermanentExzellent heißt nicht, dass lauter unersetzliche Spezialisten Einzelkämpfer-Aufgaben konfliktfrei abarbeiten – sondern dass ein Team Aufgaben, nun ja, eben als Team löst.
Davon abgesehen: Die Ideen und Konzepte, an denen wir vor meiner Elternzeit gearbeitet haben, tragen immer noch – und das ist ja auch ein Kompliment. „Ersetzbar“ zu sein kann also auch heißen, in einem funktionierenden Team zu arbeiten, das die richtigen Konzepte in gute Software umsetzt. Oder wie wir sagen: #DevelopingDigitalChampions – das ist doch mal ein erstrebenswertes Ziel!
Dazu passend überlege ich auch immer wieder, dass eine gewisse Fluktuation in Projekten mittel- bis langfristig auch Vorteile haben kann, und zwar für alle Beteiligten. So lerne ich als Entwickler oder Architect beispielsweise häufiger neue Technologien kennen, sehe neue Konzepte und Problemstellungen, arbeite mit unterschiedlichen Kolleg*innen und lerne somit laufend dazu.
Ein weiterer Vorteil von Fluktuation: In einem Projekt mit regelmäßigen Wechseln müssen immer wieder neue Kolleg*innen eingelernt oder das Projekt übergeben werden. Schwachstellen werden dann schneller deutlich, zum Beispiel wenn die Dokumentation sinnlos oder schlecht ist oder sie womöglich ganz fehlt. Und es befeuert natürlich den Ehrgeiz, sauberen Code zu produzieren – ich will den Kolleg*innen schließlich nicht meine technischen Schulden erklären müssen.
Wenn die Projektmitarbeiter*innen immer wieder wechseln, ist der Anreiz größer, gut verständlichen (sprich: wartbaren) Code zu produzieren und eine saubere Architektur zu erarbeiten. Außerdem kommt so immer wieder frischer Wind ins Projekt. Und eine Entwickler*in mit frischem Blick oder einem anderen Hintergrund findet möglicherweise eher eine saubere Lösung für unsaubere Stellen. Als Neuling in einem Projekt fallen einem die unschönen Stellen auch leichter auf: Ich habe nur eine Chance, etwas zum ersten Mal zu sehen – und oft sind es die vermeintlich „dummen“ Einstiegsfragen, die den Finger in die Wunde legen.
Je weniger starr die Strukturen sind, desto eher tritt die Erkenntnis hervor, dass jeder von jedem lernen kann. Es muss nicht immer den einen Senior geben, der seit Jahren die Richtung vorgibt. Auch Senior Architecten können viel dazulernen, wenn sie jungen Kolleg*innen Ideen erklären muss. Von einer offenen Diskussion können beide Seiten profitieren: Der Erfahrene von den frischen Ideen und Ansichten des Juniors, und der Junior vom breiten Erfahrungsschatz des Seniors.
Ich gebe zu: Vielleicht ist mein Ansatz da etwas naiv. Einerseits bin ich es gewohnt, bei iteratec nur fähige Kolleg*innen zu haben. Klar, nicht jeder kann alles und das am besten. Aber jeder ist bereit und fähig, sich in Neues einzuarbeiten und seinen Beitrag für den Projekterfolg zu leisten – auch das bedeutet #DevelopingDigitalChampions.
Andererseits weiß ich, dass ich mich um einen kritischen Punkt nicht sorgen muss: Wenn Code verständlich und gut wartbar ist, können sich auch Andere mit wenig Aufwand einarbeiten. Damit bin zum einen ich für meinen Arbeitgeber ersetzbar, aber auch der Kunde kann unser Team leichter austauschen. Vielleicht liegt hier eine unbewusste Hemmschwelle: Denn mit jedem nachhaltig gelösten Problem des Kunden wird man etwas leichter ersetzbar. Überspitzt formuliert: Dem Kunden zum eigenständigen Erfolg zu verhelfen, reduziert dessen Abhängigkeit. Was manch einer vielleicht als Risiko empfindet, ist für uns ein Erfolgskriterium. Denn unser Geschäftsmodell bestand nie darin, Kunden durch Komplexität möglichst lange an uns zu binden, sondern unsere Kunden kontinuierlich besser zu machen – und das funktioniert nur durch Enablement anstelle von Abhängigkeiten und Intransparenz.
Um Missverständnissen vorzubeugen: Meiner Meinung nach ist Fluktuation in Projekten weder notwendig noch hinreichend für guten Code und erfolgreiche Projekte – für manche Projekte wäre es auch kontraproduktiv. Und für so manchen Entwickler würde der Stress des Wechselns sicher nicht die Vorteile frischer Projekte überwiegen.
Durch meine Auszeit habe ich aber eines gelernt: ersetzbar zu sein muss nicht heißen, dass ich nicht wichtig für das Projekt bin. Und noch weiter gedacht: Fluktuation im Projekt kann nicht nur zusätzlichen Aufwand, sondern auch unerwartete Vorteile bringen.