Lasst mich meinen ersten Blogeintrag mit einem Thema füllen, das mich schon ganz, ganz lange begleitet. Zu Beginn meiner Consultant-Zeit habe ich mich voll auf das Vermitteln von technischen Inhalten konzentriert. In einzelnen Vorträgen oder in mehrtägigen Workshops habe ich Entwicklergruppen gezielte Themen aufbereitet und vermittelt.
Üblicherweise erkundigt man sich einige Zeit später beim Kunden, ob alles läuft oder ob ggf. weitere Hilfe benötigt wird. Nicht selten war hier die Antwort, dass bisher nichts weiter geschehen sei.
Als Dienstleister stellst du dir natürlich im ersten Schritt die Frage, ob an deinem Angebot etwas nicht stimmt. Handelte es sich vielleicht um die falschen Inhalte? Wurden die Entwickler nicht richtig abgeholt? War ich nicht überzeugend genug? Man forscht also nach…
Es stellte sich heraus, dass in jenen Fällen eine Reihe von Rahmenbedingungen nicht so recht passten und sich Firma und Mitarbeiter beim lang ersehnten Technologiewechsel selbst im Wege standen. Was war also passiert? Lasst mich einige der typischen Probleme beschreiben.
Vorarbeit
Bevor man die Mitarbeiter in eine Schulung schickt oder einen Berater ins Haus holt, gibt es reichlich Vorarbeit zu tun, die man sich in vielen Fällen recht einfach gemacht hat. Und diese Vorarbeit muss auf vielen Ebenen passieren: fachlich, organisatorisch und vor allem menschlich!
Wird der Plan gefasst, grundlegende (technische) Veränderungen an einem Produkt durchzuführen – sei es eine neue Produktsparte oder die Transformation eines vorhandenen Produkts – ist das weit mehr, als bei der Auswahl der Zieltechnologie auf das zu zeigen, was gerade bei Google ganz oben steht. Selten ist die aktuell „beste“ Technologie auch automatisch die beste Wahl für das eigene Produkt.
Das klingt logisch, weil ja kein Produkt und keine Produktanforderung gleich ist. Aber ein nicht zu unterschätzender Anteil dieser Entscheidung liegt in der Zusammenstellung des Teams, das anschließend die Umsetzung durchführen soll. Das umfasst nicht nur die naheliegende Frage nach dem vorhandenen Skillset, sondern auch die nicht zu unterschätzende Begeisterung und vor allem die persönlichen Interessen der Mitarbeiter.
Arbeitet man bei der Planung vollständig am Team vorbei, riskiert man den Verlust einer sehr mächtigen Triebfeder: die Akzeptanz der eigenen Mitarbeiter. Das lässt sich dann auch nicht mit „das müssen sie halt lernen“ oder „es geht nicht anders“ kompensieren. Der eingeladene Trainer hat in solchen Fällen keine Chance, das Team vom Gegenteil zu überzeugen.
Training
Kommt es dann zum Training, gibt es weitere Fallstricke. Neben den offensichtlich vorhandenen Niveauunterschieden, Lerngeschwindigkeiten, Sprachschwierigkeiten (besonders bei mehrsprachigen Teams) oder Begeisterungsfähigkeiten, mit denen jede heterogene Lerngruppe zu kämpfen hat, ist auch hier der Faktor Mensch in seinen emotionalen Eigenheiten eine starke Größe. Hier einige Beispiele:
- Der Pessimist: Dieser Teilnehmer ist von Anfang an der Meinung, dass das Projekt in seiner Gänze nicht funktionieren kann und wird dementsprechend nur halbherzig am Fortschritt mitarbeiten. Diese Einstellung wird meist durch die fehlende Überzeugungskraft im Einzelnen und einer glaubwürdigen Projektvision im Ganzen verursacht oder bestärkt.
- Der technische Gegner: Dieser Teilnehmer ist davon überzeugt, dass der gewählte Weg der falsche ist. In seinen Augen wurden bereits fundamentale Fehlentscheidungen bei der Wahl der Basistechnologie oder der Zielarchitektur getroffen. Dass ein Mitarbeiter anderer Meinung ist, ist ein wichtiger Bestandteil des Diskurses. Aber in solchen Fällen scheitert es meist daran, diesem Mitarbeiter zu vermitteln, dass die finale (gemeinsame) Entscheidung nach Abwägung aller Parameter die beste Wahl ist.
- Der Streber: Diesem Mitarbeiter ist es besonders wichtig, dem restlichen Team eine Nasenlänge voraus zu sein. Das muss nicht immer schlecht sein, führt aber in Trainingssituationen manchmal dazu, dass der entsprechende Teilnehmer durch diverse andere Quellen Vorarbeit geleistet hat und daher Parallelen zwischen den Lösungen des Trainers und den selbst gefundenen sieht, wo keine sind. Damit kommt es zu verheerenden Missverständnissen bei den Lerninhalten.
- Der Überflieger: Jener Mitarbeiter, der durch Selbststudium bereits fest im Sattel der gelernten Technologie sitzt. Das ist erst einmal eine sehr gute Sache, denn eine Gruppe wird nicht durch eine initiale Unterrichtsstunde zum Profi, sondern durch Training. Wird das von jemandem begleitet, der zur rechten Zeit die richtigen Hinweise geben kann, ist das Gold wert. Stellt sich jener Mitarbeiter aus mangelndem Teamgeist über die Gruppe, wird er zum Eigenbrödler.
Treffen diese Dinge in einem Team aufeinander, dessen Teamzusammenhalt wankt oder sogar durch tägliches Gegeneinander geprägt ist, verstärken sich die entsprechenden Störfaktoren.
Umsetzung
Die Mitarbeiter sind geschult, fühlen sich fit und haben Bock, das neue Projekt anzugehen. Jetzt ist das Projektmanagement gefragt. Nicht selten habe ich beobachtet, wie nach einer Schulung die Welt des Daily Business wieder auf die Teilnehmer einfällt.
Eine nicht unwesentliche Anzahl Entwickler ist für mehrere Tage aus dem normalen Alltag verschwunden und inzwischen hat sich ein Berg von Arbeitstickets angehäuft. Bugs und dringende Features für wichtige Kunden warten. All dies muss aufgearbeitet werden. Die Euphorie aus der Schulung verpufft erst einmal.
Dauert dieser „wir müssen erstmal die dringenden Sachen wegarbeiten“ Modus dann noch etwas länger, ist auch das Know-how aus der Schulung bald vergessen. Und das Team steht effektiv wieder nahezu am Anfang.
Es ist fast schon verständlich, dass bei der Zeitplanung des nächsten Sprints keine Zeit für das neue Projekt eingeräumt wurde. Die Mitarbeiter tun sich verständlicherweise schwer, ihre Arbeiten abzuschätzen, der Weg ist noch nicht klar (es muss also experimentiert werden) und im schlimmsten Fall fehlt sogar eine solide Roadmap, sodass auch vollkommen die Perspektive fehlt. Also bleiben wir lieber bei den Arbeiten, von denen wir wissen, dass wir produktiv sind.
Fazit
Mit ein bisschen Schulung auf Mitarbeiter werfen löst keinerlei Probleme! Vielmehr verpuffen die aufgewendeten Ressourcen sogar. Schwerwiegende technische Veränderungen im Projekt bedürfen umfangreicher Vorarbeit, denn solche Entscheidungen haben einen großen Einfluss auf die tägliche Arbeit der Entwickler.
Möglicherweise hat sich der eine oder andere Entwickler für das Unternehmen entschieden, weil zuvor eine entsprechende Technologie zum Einsatz kam. Tauscht man diese nun aus, sollte das mit bedacht werden.
Lösungsansätze
Die ganze Arbeit beginnt also lange vor der eigentlichen technischen Entscheidung. Es braucht ein gesundes und starkes Team, in dem Mitarbeiter nicht nur wohlwollend aufeinander achten, sondern sich in ihrem Sein sicher und wertgeschätzt fühlen. Eine solche Gruppe von Menschen ist nämlich in der Lage, schwerwiegende Veränderungen sinnvoll zu entscheiden, herbeizuführen und anschließend gemeinsam zu tragen.
Sicher gibt es unterschiedliche Meinungen zu einzelnen Themen – und das ist gut so. So können unterschiedliche Sichtweisen beleuchtet, diskutiert und abgewogen werden. Am Ende wird eine Entscheidung getroffen. Wenn dieser Diskurs respektvoll geschieht, wird die Teamentscheidung nachher auch von jenen Mitgliedern gestützt, die ursprünglich dagegen waren.
Aber auch bei der Projektplanung müssen die Weichen richtig stehen: Für neue Projekte müssen Freiräume geschaffen werden, in denen das Team experimentieren und scheitern darf, ohne ein „in der Zeit hättest du lieber Bug X gefixt“ kassieren zu müssen. Und dieser Punkt ist oft leichter gesagt als getan. Denn steckt das Leisten-Müssen tief im Entwickler selbst – hier sind also eher unterschwellige Themen wie Wertschätzung und Leistungsdruck die Stellschrauben.
Zuletzt braucht das gesamte Team eine Vision und eine Roadmap. Erscheint das Ziel eines Projektes in weiter Ferne, fällt es schwer, Motivation dafür aufzubringen. Gibt das Management aber kleinere, erreichbare Ziele vor (und feiert diese!), sieht das Ganze schon viel schaffbarer aus. Auch hier schwingen oft technische Entscheidungen mit, die es ermöglichen, eine Lösung in Zwischenschritten zu realisieren.
Was tun?
Mir ist klar, dass das alles bekannt klingt und man das schon irgendwie weiß. Schließlich will tief drinnen jeder seine Mitarbeiter und Kollegen mit Respekt behandeln, aber das gelingt in der Realität oft nicht. In solchen Situationen hilft es immer, einen neutralen, externen Moderator hinzuzuziehen. Ist dieser dann noch empathisch, versteht etwas von Technik und Projektplanung, kann es nicht besser laufen.