Beratungs-Hotline

Risiko Top-Programmierer

IT Strategie

Es geistert das Klischee vom 10x developer durch die Branche. Dahinter versteckt sich der Glaube, dass besonders talentierte Entwickler um den Faktor 10 höhere Produktivität aufweisen würden. Diese Leute nennt man dann gerne auch "Rockstar" oder "Ninja" und es ist Quatsch. Nicht zuletzt, weil ich weder von Rockstars noch von Ninjas bislang überzeugende Programmierung sah. Coder coden.

Und auch wenn die zugrundeliegende Studie längst widerlegt wurde gilt es immer noch als schick, sich als vermeintliche Top-Kraft ein divenhaftes Benehmen zuzulegen. Zugegeben: Gute Entwickler schaffen auch was weg, es ist verlockend, sie einfach machen zu lassen. Da sieht man gerne über die eine oder andere Macke hinweg. Aber das Risiko ist hoch.

Wer als Mitglied eines Teams sein Wissen nicht teilt, verringert den Truck Faktor, und das ist schlecht für Projekt und Team. Die Folge ist eine hohe Abhängigkeit von einzelnen Personen, die sich eine Organisation eigentlich nicht leisten kann.

  • Wissen um Prozesse und Verfahren wird zentralisiert
  • Leistung lässt sich nicht mehr auf mehrere Personen aufteilen, keine Backup-Szenarien möglich
  • Das Team kann nicht wachsen, weil neue Mitglieder schlecht integrierbar sind
  • Risiko von Informationsverlust ist hoch, wenn Top-Mitarbeiter das Team verlassen

Das Klischee vom unnahbaren Top-Programmierer im Elfenbeinturm hat sich erledigt. Heute werden Leute benötigt, die ihr Wissen aktiv teilen und andere daran teilhaben lassen. Dazu gehört aber auch, dass es eine Kultur des Zuhörens im Unternehmen gibt, eine Diskussionskultur, die auch unterschiedliche Meinungen zulässt, ohne Menschen zu diskreditieren.

Hier bedingen mehrere Einflüsse einander: In dem Maß, indem das Team als Ganzes unwillig ist, Details des anderen aufzunehmen ("Mir egal wie der xyz das macht, Hauptsache es funktioniert…") schotten sich diejenigen ab, denen sowieso keiner zuhören möchte. Die meisten Entwickler zum Beispiel lieben es, über ihre Arbeit zu sprechen, aber sie hassen es, diese Leuten erklären zu müssen, die andauernd mit ihrer Unwissenheit kokettieren. Was kann eine Organisation also tun, um ein Klima zu schaffen, in dem alle Mitarbeiter ihr Wissen gerne teilen?

  • Ein Forum zum Austausch kann etabliert werden, dieses muss aber tatsächlich von allen gelebt werden. Wird zB ein jour fixe einmal im Monat eingerichtet, um gemeinsam über Details zu sprechen, darf sich niemand mit dem Verweis auf Tagesgeschäft davon ausnehmen. Auch und gerade nicht Geschäftsführung und Management.
  • Die persönliche Bereitschaft jedes einzelnen sollte hoch sein, über den Tellerrand zu schauen und auch Themen der anderen zu verfolgen. Das bedeutet nicht nur, dass sich jetzt alle mit IT beschäftigen: Es schadet den Entwicklern auch nicht, mal der Buchhaltung oder dem Projektmanagement aufmerksam zuzuhören.
  • Backups müssen getestet werden. Lassen sie die Arbeit eines Spezialisten mal für eine Woche von anderen aus der gleichen Abteilung machen. Spätestens dann sehen Sie, welche Information gefehlt haben.
  • Interne Mentoring Programme können dazu dienen, Funktionen gezielt doppelt auszubauen. Diese können mit individuellen Zielvereinbarungen gekoppelt werden. Auch hier gilt: Halbherzige Sonntagsprediger sind nicht gefragt. Wer Mentoring oder zB pair programming als Methode des Wissenstransfers ernsthaft ermöglichen will, muss auch die Ressourcen dafür bereitstellen.