Ihr Entwickler geht ein Jahr in Elternzeit: So bleibt die Software am Laufen

Warum eine frühe Elternzeit-Vertretung für Entwickler funktioniert

Ein Entwickler, der in Elternzeit geht, ist die am einfachsten planbare Lücke, und die meisten Unternehmen handhaben sie trotzdem schlecht. Eine gute Elternzeit-Vertretung beginnt Wochen vor Beginn der Elternzeit, während eine Kündigung nur zwei bis vier Wochen Vorlauf gibt und eine Krankheit gar keinen. Das Datum ist bekannt, und in den meisten Fällen auch das grobe Rückkehrdatum. Was meist schiefläuft: Niemand trägt die Übergabe in den Kalender ein, bis zur letzten Woche, sodass eine Lücke, die jeder kommen sah, trotzdem wie eine Überraschung behandelt wird.

In Deutschland bleibt der Arbeitsplatz eines Entwicklers in Elternzeit bis zu drei Jahre pro Kind geschützt, auch wenn die meisten Eltern in einer technischen Rolle einen durchgehenden Block von üblicherweise zehn bis vierzehn Monaten nehmen. Dieser Block ist lang genug, dass „wir regeln das einfach informell" ungefähr im dritten Monat aufhört zu funktionieren, wenn die Person, die sich noch halb an den Deploy-Prozess erinnert, auf ein anderes Projekt wechselt und das Wissen mitnimmt.

Die Elternzeit-Frist: Was die Ankündigungszeit Ihnen bringt

Das deutsche Recht verlangt, dass ein Arbeitnehmer Elternzeit etwa sieben Wochen vor Beginn des Blocks formell anmeldet, wenn das Kind schon geboren ist, und dreizehn Wochen vorher, wenn die Anmeldung rund um die Geburt selbst erfolgt. Das ist das gesetzliche Minimum, und es ist auch die falsche Zahl, um danach zu planen. Die meisten Entwickler erwähnen eine geplante Elternzeit schon Monate vorher, in einem Einzelgespräch oder einem Flurgespräch, weil sie ihre eigenen Vorbereitungen im selben Zeitrahmen treffen.

Behandeln Sie diese informelle Erwähnung als Start der Übergabe-Uhr, nicht die gesetzliche Anmeldung. Sieben Wochen reichen kaum aus, um eine Codebasis ordentlich zu dokumentieren, wenn Sie bei null anfangen. Vier bis sechs Monate geben Ihnen Zeit, die Übergabe als Reihe kleiner, entspannter Schritte zu gestalten, statt als überstürzten Dump in der letzten Woche vor der Elternzeit.

Die Übergabe: Was aus einem Kopf heraus muss

Die konkreten Fakten, die es wert sind, festgehalten zu werden, stehen selten irgendwo geschrieben, weil der Entwickler, der sie im Kopf hat, nie einen Grund hatte, sie aufzuschreiben. Dazu gehört, welche Teile des Systems fragil sind und warum, welche Entscheidungen bewusste Kompromisse waren und welche Zeitdruck-Unfälle, was der Deploy-Prozess tatsächlich jenseits des README beinhaltet, und wen man kontaktiert, wenn eine bestimmte Drittanbieter-Integration ausfällt.

Ein guter Weg, das sichtbar zu machen, ist, den scheidenden Entwickler das System live, per Bildschirmfreigabe, einer Kollegin oder der eingehenden Vertretung zeigen zu lassen, und die Frage zu beantworten: „Was würdest du jemandem sagen, der das für ein Jahr übernimmt" statt „Was sollte ins Wiki." Die Live-Version bringt Dinge zutage, die ein geschriebenes Dokument übersieht, weil Menschen anders erklären, wenn sie mit einer bestimmten Person mit einem bestimmten Bedarf sprechen, als wenn sie für einen imaginären künftigen Leser schreiben.

Planen Sie zwei oder drei Sitzungen von jeweils neunzig Minuten über den letzten Monat verteilt, nicht ein langes Meeting am Tag vor der Elternzeit. Ein erschöpfter Brain-Dump am letzten Nachmittag im Büro liefert schlechtere Dokumentation als drei fokussierte, früher verteilte Sitzungen, und er setzt jemanden unnötig unter Druck, der in dieser Woche ohnehin andere Dinge im Kopf hat.

Zugänge und Dokumentation statt einer Wiki-Seite, die niemand liest

Bevor die Elternzeit beginnt, gehen Sie jedes System durch, auf das der Entwickler Zugriff hat, und entscheiden Sie bewusst, was die Vertretung braucht und was warten kann. Dazu gehören der Hosting-Anbieter, die CI-Pipeline, alle Admin-Panels, das Error-Tracking-Tool und alle Accounts, die an eine private statt eine Firmen-E-Mail gebunden sind. Teams, die diesen Schritt überspringen, entdecken oft erst drei Monate in die Elternzeit, dass niemand eine Produktionskonfiguration zurücksetzen kann, weil der einzige Account mit dieser Berechtigung jemandem gehört, der nicht in seine Arbeits-Mails schaut.

Auch Dokumentation ist hier wichtig, aber das Ziel ist enger als eine vollständige Wissensdatenbank. Was die Vertretung tatsächlich braucht, ist: wie man die Anwendung lokal zum Laufen bringt, wie ein Deploy von Anfang bis Ende abläuft, was die aktuellen Backlog-Prioritäten sind, und eine kurze Liste bekannter Problemzonen mit genug Kontext, um nicht versehentlich hineinzutreten. Wenn das auf zwei oder drei Seiten passt, sind zwei oder drei Seiten richtig. Es künstlich aufzublähen, um gründlich zu wirken, verschwendet die verbleibende Zeit des scheidenden Entwicklers und macht die nützlichen Teile schwerer auffindbar.

Was die Vertretung besser nicht anfasst

Der Instinkt eines neuen Entwicklers, der in die Codebasis eines anderen einsteigt, ist oft, aufzuräumen. Widerstehen Sie diesem Instinkt hier noch mehr als bei einem normalen Onboarding. Eine Vertretung in einem befristeten, zeitlich begrenzten Engagement sollte standardmäßig die kleinstmögliche Änderung wählen, die das vorliegende Problem löst, nicht die Änderung, die sie vornehmen würde, wenn sie die Codebasis langfristig besäße. Ein großes Refactoring, durchgeführt von jemandem, der den Code in zehn Monaten an jemanden zurückgibt, der es nicht gewählt und nicht dazu befragt wurde, erzeugt bei der Rückkehr oft Reibung, selbst wenn das Refactoring für sich genommen sinnvoll war.

Dieselbe Vorsicht gilt für Architekturentscheidungen. Wenn die Vertretung eine Entscheidung treffen muss, bei der die zurückkehrende Person mitreden wollen würde, kostet es fünf Minuten, sie zum Zeitpunkt der Entscheidung aufzuschreiben, und spart später ein viel längeres Gespräch. Ein kurzes Entscheidungsprotokoll, eine Zeile pro Entscheidung mit Datum und Begründung, erledigt hier den größten Teil der Arbeit. Es bedeutet auch, dass die zurückkehrende Person sich durch das Lesen einer Seite statt durch das Nachfragen nach einem Dutzend einzelner Änderungen auf den aktuellen Stand bringen kann.

Entscheiden, wer die Arbeit übernimmt

Manche Teams verteilen die Arbeit intern, auf bestehende Entwickler, die die Codebasis schon kennen, aber jetzt weniger Zeit für ihre eigenen Projekte haben. Das funktioniert gut, wenn die Lücke kurz ist oder die Arbeitslast gering, und schlecht, wenn es sich still in den zweiten Job für alle verwandelt, ohne dass irgendetwas davon besonders gut läuft.

Andere holen sich einen Entwickler speziell für die Dauer der Elternzeit, passend zum Stack und so eingewiesen, wie dieser Beitrag es beschreibt. Diese Option kostet direkt mehr, hält aber die Kapazität des bestehenden Teams intakt, und ein Entwickler, dessen einzige Aufgabe die übernommene Arbeit ist, widmet ihr meist gleichmäßigere Aufmerksamkeit als Kollegen, die sie neben ihren eigenen Aufgaben jonglieren.

Die dritte Option, alles außer Bugfixes und Support für die Dauer der Elternzeit einzufrieren, wird unterschätzt und ist manchmal die richtige Entscheidung. Wenn das Produkt stabil ist und die Elternzeit in eine Phase fällt, in der neue Features nicht dringend sind, kann ein bewusst verkleinerter Scope für zehn Monate günstiger und risikoärmer sein als die anderen beiden Optionen. Der Fehler liegt darin, in diese Option hineinzudriften, weil niemand etwas entschieden hat, statt sie zu wählen, weil sie wirklich am besten passt.

Welchen Weg ein Unternehmen auch wählt, ein kurzes Code-Quality-Audit vor Beginn der Elternzeit lohnt sich für sich allein. Es gibt der Vertretung, intern oder extern, eine klare Karte der Codebasis statt einer live geteilten Führung als einzige Dokumentation, und es deckt oft die fragilen Stellen auf, die sonst erst mitten in der Elternzeit, unter Druck, auf die harte Art gefunden würden. Für Lücken, in denen die Vertretung ein dedizierter externer Entwickler statt einer internen Umverteilung ist, gelten ähnliche Überlegungen wie in Interim-Softwareentwickler im Vergleich zur Einstellung.

Die zurückkehrende Person wieder eingliedern

Die Rückkehr verdient fast so viel Planung wie der Abschied. Behandeln Sie die ersten zwei Wochen zurück wie eine komprimierte Version des Onboardings einer neuen Person: eine geordnete Führung durch das, was sich geändert hat, statt Zugriff auf das gesamte Changelog und einem Wunsch für viel Erfolg. Das Entscheidungsprotokoll aus der Übergabe zahlt sich hier direkt aus, weil es „was ist passiert, während ich weg war" von einem offenen Archäologieprojekt in ein kurzes, strukturiertes Gespräch mit der Vertretung verwandelt.

Geben Sie der zurückkehrenden Person in der ersten Woche kein volles Pensum. Geben Sie ihr eine kleine, echte Aufgabe, die die am stärksten veränderten Teile des Systems berührt, ähnlich der leichten ersten Aufgabe, die Sie einer neuen Einstellung geben würden, damit sie sich Kontext durch Tun statt nur durch Lesen zurückerarbeitet. Die meisten Entwickler, die nach einem Jahr zurückkommen, sind innerhalb von zwei bis drei Wochen voll leistungsfähig, wenn dieser Übergang strukturiert ist. Sich selbst überlassen, dauert es üblicherweise doppelt so lange und lässt sie im Zweifel, ob sie den Code, den sie selbst gebaut haben, noch kennen.

Wenn die Elternzeit auch echte Lücken offengelegt hat, einen undokumentierten Deploy-Prozess, eine Codebasis, die zu fragil ist, damit irgendjemand außer der Originalautorin sie sicher anfassen kann, ist das es wert, getrennt von der Elternzeit selbst angegangen zu werden. Ein Legacy-Code-Optimierung-Engagement oder ein breiterer Blick auf die Tech-Stack-Strategie kann die zugrunde liegende Fragilität beheben, damit die nächste geplante Abwesenheit, wen auch immer sie betrifft, ein Nicht-Ereignis statt eines Projekts ist. Wenn Sie vor einer Elternzeit-Lücke stehen und eine zweite Meinung zum Übergabeplan möchten, schreiben Sie an hello@wolf-tech.io oder schauen Sie auf wolf-tech.io vorbei.