Wie sieht das Onboarding für einen neuen Engineer in deinem Team aus?

Ziel ist eine echte Änderung in Produktion in Woche eins und echte Verantwortung zum Ende des ersten Monats. Gib der Person einen Buddy, der nicht du bist, eine Setup-Dokumentation, die sie beim Nutzen repariert, eine Einstiegsaufgabe mit klarer Definition of Done und schriftliche Erwartungen für dreißig, sechzig und neunzig Tage. Führ Kontext in Schichten ein: erst Produkt, dann Architektur, dann Historie.

Das Ziel ist eine echte Änderung in Produktion in der ersten Woche, egal wie klein, denn bevor jemand einmal durch die ganze Pipeline gelaufen ist, arbeitet er hier nicht wirklich. Damit das geht, halte ich ein kleines Backlog echter Einstiegsaufgaben bereit, keine Beschäftigungstherapie, so geschnitten, dass sie Build-, Review- und Deploy-Pfad berühren. Jede neue Person bekommt einen Buddy, der nicht ich bin und dessen ausdrückliche Aufgabe es ist, die Fragen zu beantworten, bei denen man sich vor der Führungskraft dumm vorkommt. Die Setup-Dokumentation gehört immer der zuletzt eingestiegenen Person, damit sie jedes Mal repariert wird, statt ein Jahr zu verrotten. Beim Kontext kommt Produkt vor Architektur, denn ein Systemdiagramm sagt nichts, solange du nicht weißt, was Kunden damit tun, und die Geschichten warum haben wir das so gebaut hebe ich mir für Woche drei auf. Ich schreibe auf, was ich nach dreißig, sechzig und neunzig Tagen erwarte, teile es an Tag eins und gehe es dann tatsächlich mit ihnen durch, denn ein Plan, den niemand wieder anschaut, ist Deko.