Experte oder nicht Experte, das ist hier die Frage

Wenn ich ein Projekt bewältigen muss, dann versuche ich möglichst viele geeignete Experten in ein Team zu bekommen, denn nur eine ausreichende Anzahl von Experten kann ein erfolgreiches Projekt sicherstellen. Lieber arbeite ich mit (noch) mehr Spezialisten, die mir zu 75% oder 50% oder nur 25% ihrer Zeit zur Verfügung stehen, als auf diese Spezialisten zu verzichten oder ich verschiebe das Projekt, bis mir ausreichend Spezialisten wenigstens anteilig zur Verfügung stehen, oder?

So überspitzt formuliert wird dem kaum einer zustimmen, in abgeschwächter Version begegnet mir diese Denk- und Herangehensweise aber immer noch und immer wieder. Da höre ich: Ich brauche einen Experten in meinem Projekt zu 80% und wenn ich ihn nicht zu 80% haben kann, dann nehme ich ihn zu 40% und einen anderen Experten auch zu 40%. Kann das funktionieren, kann man so mit Mitarbeitern arbeiten? Gibt es noch eine andere, bessere Lösung als Experten als alleinige Wissensträger auf immer mehr Projekte und Kunden aufzuteilen und sich ausschließlich auf ihr Know-how zu verlassen und immer abhängiger von ihnen zu werden?

Es gibt eine andere Lösung und die lautet schlicht: Arbeite so, dass einzelne Experten nicht mehr zwingend für den Projekterfolg benötigt werden. Und wie erreicht man das?

Verteilung des Wissens auf alle Teammitglieder

Zum einen sollte man die Experten nicht allein an einem Thema arbeiten lassen. Es kann sinnvoll sein, den Experten im Paar mit einem anderen Entwickler arbeiten zu lassen, um das Wissen zu verteilen und andere Mitarbeiter zu „Experten“ zu machen. Ziel kann die Verteilung des speziellen Wissens nach und nach auf alle Teammitglieder sein. Das eignet sich natürlich für Aufgaben, die grundlegend relevant für das Projekt sind, die alle wissen sollten um ein erfolgreiches Projekt zu erreichen, die sich durch Werkzeuge bewerkstelligen lassen (zum Beispiel Deployment-Prozesse), wenn es um Basis-Aufgaben oder Kernkomponenten geht oder wenn das individuelle Skillset einzelner Mitarbeiter mit dem des Experten zusammen passen.

Auf den Experten verzichten

Eine andere Möglichkeit klingt erst mal extrem, wirkt aber und hat weniger negative Einflüsse, als man zunächst denken mag. Einige Mitarbeiter halten sich für unersetzbar oder – was mir viel häufiger begegnet – werden von Vorgesetzten und Kollegen für unersetzbar gehalten (Experten eben). Diese Personen haben fachliches oder technisches Wissen bei sich gesammelt, sind „Code-Owner“ im schlimmsten Fall von „besser nicht anzufassendem Code“. Die Kollegen im Team warten mit der Bewältigung einzelner Aufgaben, bis der Experte kommt und sie umsetzt. Es besteht der Eindruck, dass Aufgaben ohne diese Person gar nicht oder nur sehr aufwändig umgesetzt werden kann. Es kann sinnvoll sein zu überprüfen, wie unersetzbar diese Personen wirklich sind, indem man sie bewusst im Projekt gar nicht oder zumindest nicht als Programmierer einsetzt. Vielleicht sollte man an manchen Stellen dafür sorgen, dass der Experte noch als „Berater“ zur Verfügung steht.

Beim Verzicht auf den Experten als einzig möglichen Umsetzer einer Aufgabe habe ich festgestellt, dass plötzlich eine unerwartete Energie und Lernbereitschaft bei anderen Mitarbeitern frei wurde. Sobald die anderen Teammitglieder nicht mehr auf diesen Experten zurückgreifen konnten, rückten sie stärker als Team zusammen. Plötzlich hatten sich die Mitarbeiter in das vermeintliche Expertenwissen eingearbeitet und wurden selbst zu vielen Experten.

Experten nach Projektrelevanz einsetzen

Es kommt dennoch vor, dass der eine oder andere Experte in mehreren Projekten benötigt wird und man als Unternehmen nur eine beschränkte Anzahl von Personen mit diesem Expertenwissen hat. Wenn man sich sicher ist, dass das Ausschließen des Experten nicht möglich ist (und meine Empfehlung wäre, das zumindest auszuprobieren), dann kann man prüfen, ob ein Einsatz des Experten in einer Iteration in dem einen Projekt, dann im anderen Projekt möglich ist (beispielsweise bei sehr gekapselten Aufgaben, dessen Wissen nicht verteilt werden kann oder soll). Sollte das nicht möglich sein, weil man den Experten für das gesamte Projekt braucht, dann kann aus Unternehmenssicht entschieden werden, welches Projekt eine höhere Relevanz hat, denn wichtiger ist der Erfolg des Unternehmens, als der Erfolg eines einzelnen Projekts.

Bei sehr gekapselten und nur einmalig einzusetzenden Wissen kann es auch möglich sein, einen Experten zusätzlich anzustellen (zum Beispiel als Freelancer), um eine temporäre Auslastungsspitze abzufedern bzw. um das spezielle Modul zuzuliefern. Dabei muss man nur beachten und berücksichtigen, dass es zu hohen Reibungsverlusten kommen kann, weil sich das Team neu bilden muss. Eine Lösung kann es dennoch sein.

Fazit

Ich will nicht sagen, dass wir immer auf Experten verzichten können oder müssen. Es gibt Aufgaben, die sich beispielsweise so selten wiederholen, dass eine Verteilung des Wissens sich nicht lohnt. Das Problem dabei ist: Je spezieller das benötigte Wissen in einem Projekt ist, umso weniger oft wird dieses Wissen in Projekten benötigt. Wenn es aber benötigt wird, dann braucht man auch wirklich diese eine Person, die das Experten-Wissen hat.

Die Frage ist nicht, ob man grundsätzlich auf Experten(wissen) verzichten kann, sondern wie sehr wir wirklich diese Experten brauchen. Es geht auch nicht darum, aus allen Mitarbeitern „Crossfunctional Teammembers“ zu machen – Spezialisierungen haben durchaus Sinn und keiner kann alles gleich gut können. Ein Datenbank-Administrator wird nicht ohne weiteres zum Frontend-Spezialisten und nicht alle Backend-Entwickler können gute Informationsarchitekten werden und ein Frontend-Entwickler muss nicht gleich ein guter Tester werden.

Die Erwartung aber ist, dass jeder im Team bereit ist, die Aufgaben des Anderen nach bestem Wissen und Gewissen übernehmen zu wollen um das Projektziel zu erreichen und nach Vergrößerung des Wissens zu streben. Umgekehrt ist auch die Erwartung an Experten, dass sie ihr eigenes Wissen teilen. Denn klar ist auch: je genereller Mitarbeiter in Projekten arbeiten können, umso flexibler wird ein Team.

Das Ziel ist also nicht, auf Experten zu verzichten, sondern sie auf ein Minimum zu reduzieren um eine Steigerung des Wissens, der Kompetenzen und der Fähigkeiten der Mitarbeiter und Teams zu fördern, und um eine größtmögliche Flexibilität in einer sehr schnelllebigen und volatilen IT-Welt zu bekommen.

Vielen Dank an Johanna Rothman, die mir mit ihrem Beitrag “Management Myth #2: Only ‘The Expert’ Can Perform This Work” aus dem Herzen gesprochen hat.