Onboarding, das funktioniert

Derselbe Entwickler, zwei unterschiedliche Ergebnisse

Vor einigen Monaten haben wir mit zwei Unternehmen gesprochen, die in derselben Woche Entwickler mit fast identischem Profil eingestellt haben. Gleiches Level, ähnlicher Stack, vergleichbare Erfahrung.
Im einen Unternehmen hat die neue Person nach zwei Wochen Code live gebracht. Im anderen fragte sie nach drei Monaten immer noch, wo die API-Dokumentation ist und wer für Zahlungen zuständig ist.
Der Unterschied lag nicht am Entwickler. Er lag am Prozess, der ihn ins Team bringen sollte.

Warum das mehr kostet, als es aussieht

Eine neue Person im Team ist keine Kostenposition, die verschwindet, sobald der Vertrag unterschrieben ist. Es ist eine Kostenposition, die jeden Tag wächst, an dem diese Person keinen Wert schafft. Das Gehalt läuft, die Zeit erfahrener Kolleg:innen für Erklärungen läuft, das Produkt bewegt sich nicht.
Dazu kommt ein leiserer zweiter Kostenfaktor. Neue Mitarbeitende entscheiden genau in diesen ersten Wochen, ob sie langfristig bleiben. Fühlen sich diese Wochen wie ein Tappen im Dunkeln an, schauen sich manche schon um, bevor überhaupt jemand gesehen hat, was in ihnen steckt.

Neue Mitarbeitende entscheiden in den ersten Wochen, ob sie bleiben, nicht erst nach dem ersten Jahr.

Diesen Effekt sieht man nicht sofort. Man sieht ihn erst Monate später in der Fluktuation, wenn sich ein Weggang kaum noch auf den ersten Monat zurückführen lässt.

Was Teams, die es richtig machen, tatsächlich tun

• Der erste Tag ist geplant, nicht improvisiert
  Zugänge, Accounts und Entwicklungsumgebung funktionieren, bevor sich die neue Person hinsetzt. Kein halber Tag Warten, bis jemand Zeit findet, den Repo-Zugang freizuschalten.
• Code geht in Woche eins live, nicht im ersten Monat
  Teams mit schnellem Onboarding haben eine fertige Liste kleiner, gut beschriebener, risikoarmer Einstiegsaufgaben. Ein erster Pull Request in Woche eins gibt etwas, das keine Onboarding-Präsentation liefern kann: das Gefühl, etwas zu können und gebraucht zu werden.
• Es gibt eine klar zugewiesene Person, nicht "das ganze Team
  "Frag einfach jemanden" bedeutet in der Praxis, dass sich niemand verantwortlich fühlt. Eine feste Bezugsperson mit real reservierter Zeit im Kalender ist der Unterschied zwischen "irgendwann antwortet mir schon jemand" und "ich weiß genau, an wen ich mich jetzt wenden kann."
• Dokumentation ist aktuell, nicht nur umfangreich
  Dokumentation, die ein System von vor einem Jahr beschreibt, ist schlimmer als gar keine, weil sie falsche Sicherheit vermittelt. Starke Teams behandeln sie wie Code: jemand ist verantwortlich, veraltete Abschnitte werden gelöscht.
• Feedback geht in beide Richtungen, und zwar schnell.
  Ein kurzes, informelles "Wie läuft's?" jede Woche fängt Probleme ab, bevor sie größer werden. Auf das erste Mitarbeitergespräch nach drei Monaten zu warten bedeutet, etwas zu reparieren, das schon wehgetan hat.

Was es wirklich kostet, wenn man das überspringt

Schwer, eine genaue Zahl zu nennen, aber die Richtung ist klar. Wenn eine erfahrene Fachkraft drei Monate statt drei Wochen lang täglich eine Stunde mit Erklären verbringt, sind das Dutzende Stunden der teuersten Person im Team, die nicht ins Produkt fließen.
Dazu kommen die Kosten der Fluktuation. Rekrutierung, Einarbeitung, verlorenes Wissen, erneute Rekrutierung – das ist immer teurer, als den Prozess zu verbessern, der jemanden in den ersten Monaten zum Gehen gebracht hat.
Ein gut gestalteter Onboarding-Prozess ist keine Investition in eine nette Willkommensgeste. Es ist eine operative Investition, die sich in Wochen amortisiert, nicht in Jahren.

Was ein guter Onboarding-Plan enthalten sollte

Ein guter Onboarding-Plan ist keine Liste von Schulungen, die man absitzt. Es ist eine Reihe konkreter, zeitlich festgelegter Meilensteine: erster Tag mit funktionierender Umgebung, erste Woche mit erstem Pull Request, erster Monat mit eigenständigem Feature, zweiter Monat mit erster begleiteter Bereitschaftsschicht.
Jeder Meilenstein braucht eine verantwortliche Person und eine Möglichkeit zu prüfen, ob er tatsächlich stattgefunden hat. Ohne das wird Onboarding zu einer Wunschliste, die niemand Zeit hat umzusetzen.

Ein Satz zum Schluss

Dein Team weiß wahrscheinlich schon genau, wo neue Mitarbeitende sich verlieren, nur hat sich noch niemand hingesetzt, um es aufzuschreiben und zu beheben.