Arbeitswelt: Das fachliche Onboarding ist kontraproduktiv

Moin.

Escape the Feature Factory: Stefan Mintert

Stefan Mintert arbeitet mit seinen Kunden daran, die Unternehmenskultur in der Softwareentwicklung zu verbessern. Das derzeit größte Potential sieht er im Leadership; unabhängig von einer Hierarchieebene. Die Aufgabe, dieses Potential zu heben, hat er sich nach einem beruflichen Weg mit einigen Kurswechseln gegeben. Ursprünglich aus der Informatik kommend, mit mehreren Jahren Consulting-Erfahrung, hatte er zunächst eine eigene Softwareentwicklungsfirma gegründet. Dabei stellte er fest, dass Führung gelernt sein will und gute Vorbilder selten sind. Es zeichnete sich ab, dass der größte Unterstützungsbedarf bei seinen Kunden in der Softwareentwicklung nicht im Produzieren von Code liegt, sondern in der Führung. So war es für ihn klar, wohin die Reise mit seiner Firma Kutura geht: Führung verbessern, damit die Menschen, die die Produkte entwickeln, sich selbst entwickeln und wachsen können. Für Heise schreibt Stefan als langjähriger, freier Mitarbeiter der iX seit 1994.

Wenn neue Kollegen oder Kolleginnen zum Team kommen, findet ein Onboarding statt. Klar. Alle brauchen Zugänge zu den verwendeten Systemen. Mailadressen, LDAP, Ticketsystem, Wiki, Repo und so weiter. Das ist unverzichtbar. Gleiches gilt dafür, Neue persönlich und menschlich an Bord zu holen. Mein Eindruck ist, dass Letzteres oft zu kurz kommt, aber das ist ein anderes Thema.

Was dann noch bleibt, ist das fachliche Onboarding. Wie arbeiten wir? Wie sind die Prozesse? Welche Meetings gibt es? Und viele weitere Fragen dieser Art.

Auf den ersten Blick ist es selbstverständlich, dass wir neue Kolleginnen und Kollegen damit vertraut machen. Aber ist das wirklich sinnvoll? Wozu dienen diese Maßnahmen?

Im Wesentlichen dienen sie dazu, die Erfahrungen, Kenntnisse, Good Practices, Lessons Learned, die das neue Teammitglied im Gepäck hat, plattzumachen. Eine Gehirnwäsche der Art “so wird das hier gemacht, vergiss alles andere”.

Wenn wir nun aber in einer Feature Factory (siehe Titel des Blogs) arbeiten, wollen wir doch Veränderung, oder? Unter dem Aspekt sind das Know-how und die Erfahrung der Neuen wertvolle Quellen für einen Perspektivwechsel.

Mein Vorschlag: Wer aus der Feature Factory ausbrechen will, beteiligt sich nicht an dieser Art von Onboarding. Stattdessen laden sie neue Kolleginnen und Kollegen ein, zu beobachten und zu hinterfragen. Und sie stellen Fragen, die die Erfahrung der neuen Teammitglieder anzapft. Etwa: Wie hast du bisher Code Reviews durchgeführt? Unsere Dailies sind langweilig; hast du eine Idee, was wir anders machen könnten? Welche Erfahrung hast du mit Peer Programming? Wir produzieren viele Bugs, woran kann das liegen? Oder einfach: Wenn du nur eine Sache in unserer Arbeitsweise ändern könntest, welche wäre das?

Unabhängig von den konkreten Fragen ist die Grundidee immer die gleiche: Ein neues Teammitglied ist eine hervorragende Gelegenheit, Betriebsblindheit und “wir machen das immer so”-Haltungen zu hinterfragen und durch etwas Besseres zu ersetzen. Nutzt die Gelegenheit, so früh und so lange es geht. Es geht schnell, dann hat die neue Kollegin oder der neue Kollege die etablierten Verhaltensweisen übernommen. Der Anpassungsdruck ist groß und ein neues Umfeld kann einschüchternd sein. Es gehört viel Mut dazu, sich gegen die geltenden Regeln zu positionieren. Ein Team, das ausdrücklich dazu einlädt, schafft eine Voraussetzung dafür.

(rme)