Podcast: Play in new window | Download

Subscribe: Apple Podcasts | RSS

Führen auf Distanz ist keine einfache Sache. Hier habe ich darüber schon mal ausführlich gesprochen und geschrieben.

Heute geht es mir um virtuelle Teams. Es geht um die speziellen Herausforderungen bei der Führung großer Softwareprojekte. Die werden heute mit virtuellen Entwicklungs-Teams bearbeitet, bei denen die Teammitglieder verteilt über die Welt sind.Wie führt man solche Teams?

Es ist das Führen eines virtuellen, interkulturellen Teams aus der Distanz. Ja, und dann noch mit Ingenieuren.

Hierzu habe ich mir einen Experten eingeladen, nämlich meinen Ingenieur und Podcast-Kollegen Georg Lohrer.

Georg Lohrer über Virtuelle Teams

Georg Lohrer über Virtuelle Teams

Georg Lohrer kümmert sich als selbständiger Trouble-Shooter um Softwareprojekte, in denen mindestens ein Dutzend Entwickler an mehreren Standorten, meist unter hohem Zeitdruck, zusammenarbeiten.

Für ihn sind virtuelle Teams kein Schlagwort, sondern tägliche Routine. Er hat mehr als 25 Jahre Erfahrung in der Entwicklung von Embedded Software sowie im Management mittlerer und großer Projekte in verschiedenen Industrien.

In seinem Podcast Mastering Embedded Systems teilt er seine Praxiserfahrungen und er interviewt Experten rund um dieses Thema „Embedded Systems.“ Da das ein sehr internationales Thema ist, ist der Podcast auch in Englisch.

Ich wollte speziell von ihm wissen, worauf man achten muss bei virtuellen, interdisziplinären Teams und wo da die Hauptprobleme auftauchen – und was so typische, kritische Situationen sind. Wie funktioniert das Konfliktmanagement in virtuellen Teams? Hier also mein Interview mit Georg Lohrer.

Das transkribierte Interview mit Georg Lohrer

Geropp:

Georg, in deinem Podcast „Mastering Embedded Systems“ gehst du ja auf die vielfältigen Herausforderungen speziell von Ingenieuren ein, die so in der Software-Entwicklung tätig sind. Und die arbeiten ja häufig in virtuellen Teams.

Was sind erstmal eigentlich Embedded Systems, für die Leute, die da jetzt nicht so tief drin sind? Und was ist speziell bei der Entwicklung von Embedded Systems die besondere Herausforderung?

Lohrer:

Embedded Systems sind, so wie der Name eigentlich schon sagt, eingebettete Systeme. Eingebettet bedeutet in dem Fall, eine irgendwie geartete Form von Software ist in einer ganz spezifischen Hardware eingebettet.

Geropp:

Okay.

Lohrer:

Das heißt im Umkehrschluss auch, diese Systeme sind im Normalfall autark, abgeschlossen und abgekapselt.

Geropp:

Kannst du da vielleicht ein Beispiel mal geben in welchen Industrien diese Embedded Systems so speziell eingesetzt werden?

Lohrer:

Also ganz typisch sind natürlich Mobilfunkt zum Beispiel Smartphones. Ein Smartphone ist ein ganz typisches Embedded System. Man hat Software drin. Man hat eine Hardware. Aber auch zum Beispiel die dazugehörigen Mobilfunk-Basis-Stationen, die irgendwo in der Gegend rumstehen und das Mobilfunksignal aufnehmen.

Welche Anwendung natürlich auch jeder kennt ist das Auto oder der Lkw. Was auch immer: Es sind jede Menge dieser eingebetteten Systeme drin von der Motorsteuerung über die Sitzsteuerung bis zur Kommunikationselektronik, Medizintechnik.

Oder Anwendungen angefangen vom Röntgengerät bis hin zu diesen Tropf-Dosierern. Da sind mittlerweile überall kleine Computer drin. In der Rüstungs- und Waffentechnik, in der Luft- und Raumfahrttechnik. Ja, auch in der normalen Industrie und natürlich auch der Automatisierung. Überall sind Embedded Systeme mit eingebaut.

Die eigentliche Herausforderung bei diesen Systemen ist, dass sie die Quadratur des Kreises versuchen: Auf der einen Seite müssen sie klein, leicht, billig, einfach und reduziert auf das Wesentliche sein und auf der anderen Seite muss man auch an die Dinger einfach rankommen.

Das Problem: Sie sind irgendwo eingebaut. Wenn die mal draußen im Feld sind, also beim Kunden oder im Einsatz, dann sind die weg. Dann sind die abgeschlossen. Software kann oftmals nur schwer aktualisiert werden, wenn beispielsweise ein Fehler auftritt.

Jeder kennt die Rückruf-Aktionen von Automobil-Herstellern – und ich meine jetzt nicht nur den großen Norddeutschen hier. Man muss in die Werkstatt und dann bauen die kein Teil ein oder aus, sondern die machen ein Update von der Software.

Es ist mit einem großen Aufwand verbunden, solche Systeme zu aktualisieren. Und es ist auch mit einem großen Aufwand verbunden, Fehler zu finden oder zu beheben, weil die Dinger eben per se abgeschlossen sind.

Am Smartphone zum Beispiel: Ja wie soll man da letzten Endes rankommen an das Ding. Man sieht nur die Bedien-Oberfläche und man kann damit telefonieren, ins Internet gehen oder sonst was.

Aber die sonst typische Reparatur-Situation, wie man sie als Ingenieur bräuchte – das heißt man hat quasi so eine Art Schnorchel in das System hinein – gibt es da nicht. Und das ist die große Herausforderung bei Embedded Systemen.

Geropp:

Das heißt, schon bei der Entwicklung muss man da extrem drauf achten, weil man nachher nicht mehr mit dem „Schnorchel“ reinkommt.

Lohrer:

Exakt. Ja. Das heißt also auch, man muss sich schon im Vorfeld überlegen, wie könnte hinterher eine entsprechende Analyse aussehen.

Ein typisches Beispiel: Ich habe so eine App auf meinem Smartphone von der Bank und hin und wieder hat es mal einen Fehler. Dann stürzt es ab oder macht sonst was und dann fragen die dann, ob man nicht von der und der Stelle irgendwelche Dateien mit in die Mail reinkopieren könnte, damit sie da mal draufschauen konnen.

Man merkt schon, dass es für die Leute schwierig ist, an die Software ranzukommen und wenn sie dann auf der anderen Seite einen Kunden haben, der mit der Sache oder mit der Thematik gar nicht umgehen kann, dann ist es vorbei. Dann kommen die gar nicht ran.

Geropp:

Ich verstehe das so, dass diese Art von Entwicklung heutzutage immer mehr auch nicht mehr nur von einem Team an einem Standort entwickelt wird. Du begleitest ja solche Software- und Hardware Projekte mit weltweit verteilten Teams.

Worauf muss man da besonders achten, wenn also jetzt gerade an so einem System Leute von verschiedenen Standorten dran arbeiten?

Lohrer:

Also als Erstes Problem ist da die räumliche Distanz. Ja. In manchen Unternehmungen ist es ja so, dass die räumliche Distanz schon bedeuten kann, der nächstgelegene Flur oder die nächstgelegene Etage. Und da ist dann häufig schon ein riesen Graben zwischen den Team-Mitgliedern.

Aber das meine ich gar nicht: Sondern virtuelle Teams werden meistens zusammengeführt, wenn die Standorte verschieden sind. Wenn die jetzt auch noch international verteilt sind, kommt das noch verschärft hinzu.

Durch die räumliche Distanz hat man im Normalfall keinen persönlichen Kontakt zu den Leuten. Also keinen Face-to-Face-Kontakt.

Ich muss dann besonders auf die BIldung von Vertrauen achten. Was sich normalerweise, wenn man jemandem persönlich begegnet, relativ schnell einstellen kann, nämlich ein Zutrauen, Vertrauen, ist etwas, was sich durch die räumliche Distanz nur ganz langsam und schwer bildet.

Vielleicht sehe ich den Anderen ja noch nicht mal, noch nicht mal über Video, sondern höre einfach nur die Stimme und das auch nur selten. Vielleicht sogar noch in einer Fremdsprache. Das ist schwierig. Das heißt, man muss diesen Mangel an Nähe durch Reden, Erklären und Zuwendung verbessern.

Aber was ich noch als viel wichtiger erachte oder was ich noch viel wichtiger finde ist, dass man sehr viel zuhören muss. Und sich selbst dabei gleichzeitig reduziert.

Hierzu mal ein Beispiel, nämlich der Umgang mit japanischen Kollegen:

Japanisch ist eine Kontext getriebene Sprache, das heißt, die sagen Dir oftmals nur 20 Prozent, weil sie davon ausgehen, 80 Prozent sind dir bekannt.

Das weiß ich jetzt aber nicht. Also stelle ich mich hinein und sage

„Pass mal auf, ich bin nur ein Geiko-Kudjin, also ein Fremder. Bitte erklär mir das ganz genauso wie du es einem Kind erklären würdest.“

Damit habe ich oft gute Erfolge erzielt, da ich mich selbst sehr zurücknehme in meiner Position und in meiner Haltung. Ich oute mich als unwissend, dann gibt es die Möglichkeit, dass die Leute da drauf einsteigen und mir eben helfen.

Um jetzt Vertrauen zu bilden, um in dem virtuellen Team voranzukommen, muss ich aber auf der anderen Seite auch Kompetenz ausstrahlen. Ich kann nicht nur mich als dumm hinstellen oder als unwissend, sondern ich muss auch mit Erfahrung auf der anderen Seite kommen.

Ich muss viel stärker auf die Erfahrung gehen. Ich muss den Leuten zuhören. Muss klarmachen, dass ich ein bisschen Ahnung habe.

Virtuelle Teams zu führen, meiner Erfahrung nach, ohne eine gewisse Erfahrung oder Know-how auf dem jeweiligen Spezialgebiet zu haben, ist schwierig, weil man ansonsten nicht akzeptiert wird. Man wird als Unwissender abgehakt, als jemand, dem erzählt man halt ein bisschen was und das war es dann. Nein, ich will ja in eine Kommunikation kommen. Ich will ja mit den Leuten arbeiten, ich will ja Vertrauen gewinnen.

Geropp:

Du musst auf einer Ebene wahrgenommen werden.

Lohrer:

Ja. Genau. Genau.

Geropp:

Ja, das kann ich mir vorstellen. Das heißt, jemand, der gar nicht in dem Thema drin ist, sondern wirklich nur die reine Projektleitung hat, ohne wirkliche Systemerfahrung, der wird gar nicht für voll genommen?

Lohrer:

Er wird schon für voll genommen, aber für eine andere Rolle. Wenn es aber darum geht, und das ist meistens mein Thema, dass irgendwelche Projekte in der Klemme stecken, dann geht es darum ein Problem zu lösen und Fehler zu finden und das Stocken zu beenden.

Und dazu muss man verstehen, was einem die Leute sagen, auch im Sinne von, was sie selber behaupten, warum es nicht funktioniert oder warum es nicht geht. Nur so kann ich bewerten und sagen, das ist jetzt in Ordnung oder hat Hand und Fuß, was der oder die mir erzählt.

Oder ist es einfach nur so ein Gebrabbel, das irgendwie für das Management abgesondert wird, damit man wieder weg kommt vom Telefon.

Das heißt, ich muss auf der einen Seite einen großen Vertrauensvorschuss geben. Das heißt, wenn mir die Leute was sagen und was behaupten, dann glaube ich das erstmal.

Ich nehme das mit, gehe dann aber hin und validiere es. Das heißt, ich frage andere, Leute meines eigenen Vertrauens, die ich schon länger kenne, ob das alles Hand und Fuß hat. Und wenn das Hand und Fuß hat und alles funktioniert und ich das auch selber verstanden habe, dann geht es voran.

Wenn es nicht geht, dann geht da erstmal für mich so eine gelbe Lampe an. Ich sage mir dann, da muss ich nochmal genau draufschauen. Dann hake ich noch ein bisschen nach. Dann stellt sich meist raus, ob mir der jetzt nur was erzählen will, irgendeinen Bären aufbindet oder ob es tatsächlich so ist oder ob er es vielleicht selbst nicht genau weiß. Das kann ja auch sein. Der ist vielleicht auch bloß ein Sprachrohr oder so.

Geropp:

Wenn ich dich richtig verstehe ist das Entscheidende eigentlich viel Zeit mit den Teammitgliedern zu verbringen und durch Fragen wirklich die Sache verstehen zu wollen.

Das stelle ich mir gar nicht so einfach vor, weil normalerweise, wenn ich also nicht ein virtuelles Team habe, bin ich gewohnt weniger Zeit in solche Sachen zu investieren. Da kann ich ja schon allein an der Art, wie jemand sich verhält, etwas erkennen. Kann man das so sagen?

Lohrer:

Ja. Auf jeden Fall.

Geropp:

Wie groß sind denn diese virtuellen Teams, von denen du sprichst? Ich stelle mir das gar nicht einfach vor, wenn da jetzt 50 Entwickler an irgend so einem Projekt arbeiten. Ich kann ja nicht mit allen 50 Leuten sprechen oder?

Lohrer:

Das geht dann auf gar keinen Fall. Also man braucht letzten Endes Konzentratoren in irgendeiner Form. Ich habe es als besonders produktiv erlebt, an dem jeweiligen Standort so zwei, drei, vier Buddies zu haben, die tatsächlich dann mit mir zusammen arbeiten. Das sind praktisch die Vervielfältiger, die Multiplikatoren hier auf dieser Ebene.

Geropp:

Wie suchst du dir die aus, diese Buddies?

Lohrer:

Die werden sehr oft ausgesucht.

Geropp:

Okay.

Lohrer:

Also ich kann das eben nicht bestimmen.

Geropp:

Steuern ja.

Lohrer:

Das heißt, meine Aufgabe ist es dann, aus dem, was ich bekomme, das Beste zu machen. Im Normalfall geht das auch: Mit dem einen mehr, mit dem anderen weniger.

Aber es gab auch schon Fälle, wo ich dann nach ein paar Wochen feststellen musste, es funktioniert gar nicht. Dann wird eben eskaliert und dann wird man in einem offenen Gespräch sagen müssen:

„Nein, das funktioniert nicht, ich habe mir andere Sachen vorgestellt. Das und das fehlt.“

Also ich hatte mal einen Fall von einer Frau, der dann in einem solchen Gespräch klar wurde, dass sie letzten Endes für diese Aufgabe nicht die Richtige ist und sich selber auch nicht glücklich darin fühlt. Die Rolle wurde ihr zugewiesen. Wir haben dann gemeinsam die Lösung mit den jeweiligen Line-Manager gefunden, in dem wir jemanden anderen gefunden haben, der das macht. Der war dann auch tatsächlich von vornherein mit beteiligt. Dann hat das auch besser funktioniert.

Geropp:

Ich hatte früher auch Teams in verschiedenen Standorten. Ich habe da die Erfahrung gemacht, dass es sehr gut ist, wenn man ein Kick-Off-Meeting veranstaltet, bei dem sich die Leute mal persönlich treffen. Einfach, um dieses Vertrauen schneller aufzubauen.

Aber wenn ich dich richtig verstehe, ist das in vielen Projekten aus Kostengründen oder sonst wie gar nicht möglich. Und dann muss man so vorgehen, wie du das gesagt hast, ja?

Lohrer:

Also über ein Kick-Off-Meeting, da würde ich immer jubeln. Das ist eine ganz tolle Sache. Aber ich habe es ganz selten erlebt.

Es ist einfach so: Die Firmen stellen oft solche virtuellen Teams auf, eben gerade aus Kostengründen. Da wird irgendwo eine Dependance in Fernost aufgemacht oder in Südamerika oder in Vorderasien oder so was und dann ist es nicht gedacht, dass die sich dann mit den ganzen Restlichen auf der Welt irgendwo treffen, um zwei Tage lang zu arbeiten, Hände zu schütteln und sich zu beschnuppern. Das wird dann oft nicht eingesehen.

Wobei die Manager selber, das natürlich für sich in Anspruch nehmen immer und überall hinreisen zu dürfen, ist klar. Aber auf der Sach- udn Bearbeiterebene passiert das meist nicht.

Wir hatten übrigens am letzten Wochenende beim Projektmanagement Barcamp in Dornbirn eine Session genau zu diesem Thema, also wie werden virtuelle Teams geführt und was ist notwendig und so.

Da war Uni Sono die Meinung, Kick-Off-Meeting wären geil. Das wäre einfach klasse, das zu haben, aber – und dann kam bei allen Möglichen das aber – es gibt sie zu selten, weil eben das Geld nicht in die Hand genommen wird.

Wenn ich so ein Kick-Off-Meeting haben kann, ist das ja kein Garant dafür, dass es funktioniert. Es können auch Antipathien auftauchen untereinander. Es können Ressentiments voll durchschlagen.

Da hat man als derjenige, der das Team leitet hinterher eine sehr große Moderationsfunktion und auch eine Zusammenführung und vertrauensbildende Position. Da geht es drum, miteinander klar zu kommen und nicht um irgendwelche technischen Belange. Man kann die Technik als Vehikel benutzen, klar, um gemeinsam Zutrauen zu finden, aber das muss nicht sein.

Und dann kommt ja noch etwas dazu. Was gerne passiert ist, dass in so einem virtuellen Team, das ein Kick-Off hatte, nach einem halben Jahr die Leute ausgetauscht werden. Und dann kannst du nicht wieder ein Kick-Off machen. Über kurz oder lang hast du da die Situation, dass die eine Hälfte sich per Kick-Off kannte und die anderen nicht. Das ist es oft recht schwierig, diese neuen Leute einzuphasen und dann reinzubringen, weil die einfach einen Nachteil dadurch haben.

Geropp:

Ja, das verstehe ich. Das ist eine besondere Herausforderung. Wenn du die Chance hast, ein virtuelles Team zusammenzustellen, worauf würdest du besonders achten?

Lohrer:

Ich würde bei mir anfangen. Nicht, weil es besonders wichtig ist, sondern weil es ein zentraler Punkt ist.

Wenn ich jemand wäre, der ein virtuelles Team zusammenstellen kann und darf, dann würde ich eine der wichtigsten Voraussetzung beachten: Der jeweilige Teamleiter darf sich nicht als das Zentrum des Universums begreifen.

Nur dadurch, dass er die Möglichkeit hat, das Team zusammen zu stellen, ist er vielleicht Primus Inter Pares, aber das war es auch schon. Er ist nicht die wichtigste Person überhaupt in der ganzen Sache.

Das Zweite: Ich würde für alle Team-Mitglieder fordern oder würde ich explizit darauf achten, dass Kommunikation essenziell ist. Ich kann keine Eigenbrötler gebrauchen. Also der gerade im Software-Bereich typische Nerd mit Kapuzenpulli und leerer Pizza-Schachtel wäre unter Umständen nicht so geeignet.

Ich würde ganz klare Regeln aufstellen – zum Beispiel für Feedback.

• Wie geben wir uns Feedback?
• Wie wollen wir das machen?
• Wie soll Kommunikation stattfinden?
• Was für virtuelle Treffen gibt es?

Also beispielsweise wir treffen uns einmal die Woche oder treffen uns jeden Tag oder treffen uns zweimal die Woche oder irgendwas in der Richtung.

Dazu kommt ja noch: Wenn das Team verteilt ist auf der Welt, hast du unterschiedliche Zeitzonen.

Dann kommt noch die Frage, wie sehen unsere internen Abläufe und Prozesse aus? Je nachdem, ob man die überhaupt schon zu diesem Zeitpunkt der Definition oder Zusammenführung des Teams bestimmen kann. Aber selbst dann kann man sagen, ich habe vor, das so und so zu machen.

Was ich zum Beispiel immer gemacht habe, war: Ich habe eine Mindmap gemacht über die Rollenerwartung.

• Was die Leute machen.
• Wo sie ihre Verbindungen haben.
• Mit wem sie sprechen.
• Was ihre Aufgaben sind.
• Was ihre Soft-Skills sein sollen.
• Was ihre Hard-Skills sein sollen.

Und wenn ich das den Leuten gegeben habe, dann immer kam das Feedback, ja das kann ich nicht oder das kann ich nicht oder das kann ich und das nicht und so. Und da hatte ich schon gute Anhaltspunkte, um weiterzukommen mit dem ganzen Ding.

Geropp:

Ja. Das sind gute Tipps. Jetzt, du hast vorhin ja schon erzählt, dass du zum Beispiel auch in Asien, z.B. mit Japanern zusammenarbeitest. Was sind denn so die Hauptprobleme, wenn man mit interkulturellen Teams arbeitet, also Teams aus unterschiedlichen Kulturen? Was gibt es da besonders zu beachten?

Lohrer:

Wie vorher schon erwähnt, als aller Erstes die Zeitverschiebung. Ich habe mal in einem Projekt gearbeitet, da hatte ich Mitglieder des Teams aus China, Japan, einige aus Zentral-Europa und manche auch aus Nordamerika.

Nordamerika und Japan, also immer zwei von dreien hätten irgendwie einen gemeinsamen Slot, ein Zeit-Slot zusammen gehabt. Entweder früh morgens, für den anderen spät Abends oder umgekehrt, aber niemals alle drei. Einer war immer im Bett letzten Endes.

Das heißt, du hast wirklich ein schon in der Struktur angelegtes Problem. Das ist das Erste. Da musst du schon mal irgendwie klarkommen mit. Das bedeutet sehr viel Weitergabe von Informationen und zwar ungefiltert.

Das ist sehr aufwändig, sehr schwierig und das auch in entsprechender Sichtweise weiterzubringen. Teilweise, manchmal hilft es nichts und dann muss Du halt mal nachts um 12:00 ein Meeting machen. Ich habe es meistens so gemacht, dass ich dann derjenige war, der das zur Unzeit gemacht hat.

Ich erinnere mich an Meetings Morgens um 4:00, weil die unbedingt morgens um 10:00 in Japan was machen wollten. Oder Nachts um zwei oder irgend so was. Also das ist schon ein bisschen hässlich.

Das andere ist: Als Ausländer, als Fremder kommst Du in eine unterschiedliche Arbeitskultur. Du hast es mit einem unterschiedlichen Arbeitsverständnis zu tun. Ich meine damit nicht, ob das besser oder schlechter ist, das ist gar nicht die Frage, sondern es ist einfach nur anders.

In China zum Beispiel ist es so, dass Information als eine Art Schatz begriffen wird. Das heißt, Information ist etwas sehr Wertvolles und niemand gibt die gerne freiwillig raus.

Wen Du jemanden im deutschen Arbeitsumfeld fragst, dann kriegst du im Normalfall die volle Ladung direkt vor den Kopf und das war es. Und wenn du dann weiter fragst, dann wird das als eigenartig begriffen.

„Was soll das jetzt, ich habe dir doch schon alles gesagt.“

In China ist das völlig unverständlich und du bekommst, wenn du fragst, immer erst 20 Prozent und dann musst du noch mal fragen und noch mal und noch mal. So nach dem fünften, sechsten Mal hast du ungefähr so das Bild, was alles zusammen ist.

Im Umkehrschluss ist es aber für den Chinesen so, er kriegt vom Deutschen die volle Breitseite. Er meint aber, das sind nur 20 Prozent. Das heißt, da muss doch noch was kommen und nervt dann die anderen mit seiner dauernden Fragerei.

Das wird einem in dem Moment klar, wenn man sich klar macht, welche unterschiedlichen Glaubenssätze in den jeweiligen Kulturen herrschen können.

Einen, den habe ich zum Beispiel erst neulich kennengelernt, als es ein Unverständnis gab. In diesem Fall wurde ein Arbeitspaket von Deutschland nach Polen transferiert. Der Deutsche sagte mir:

„Ich habe das übergeben, da kamen nie Fragen.“

Und der Pole sagte mir dann:

„Ja, wir haben das bekommen, aber uns hat nie jemand instruiert.“

Der eine hat erwartet, dass der andere kommt und fragt und der andere hat erwartet, dass er abgeholt wird und man es ihm erklärt. Beide standen da und haben gewartet.

Oder gerade jetzt erlebt ein Beispiel in Finnland: Da gilt viel reden, also das, was ich jetzt gerade mache, als Schwäche. Also viel reden ist Schwäche. In Finnland musste ich deshalb zum Beispiel lernen in der Kommunikation einfach zu schweigen. Nichts zu sagen. Also auch mal zehn, fünfzehn Sekunden lang. Das ist völlig normal. Daran muss man sich als Deutscher erst gewöhnen.

Geropp:

Das ist spannend, ja. Das kann ich mir vorstellen.

Lohrer:

Gestern erst war ich im Telefonat mit einem Finnen. Da habe ich dann so nach 15 Sekunden nachgefragt, weil nicht klar war, ob er jetzt tatsächlich noch dran ist oder ob jetzt gerade die Voice-over-IP-Verbindung zusammengebrochen ist. Kann ja auch sein. – Aber er war noch da.

Geropp:

Das ist cool.

Lohrer:

Mir selber hat das Buch von Richard D. Lewis sehr geholfen. Es heißt:

When Cultures Collide – Leading Across Cultures.

Soweit ich weiß ist Richard D. Lewis ein Literatur-Professor aus USA. Er beschreibt die unterschiedlichen Kommunikationsmuster der unterschiedlichen Nationen. Worauf Wert zu legen ist und so was. Für mich ist das die Bibel. Wenn ich irgendwo neu hinkomme, gucke ich mir die Abschnitte durch. Der hat also wirklich fast zu jedem Land, dass da irgendwie industriemäßig unterwegs ist, irgendwelche Absätze.

Er verwendet Bilder über die Kommunikations-Pattern und zeigt so wie sie funktionieren. Und das ist ganz spannend zu sehen, was die Ausländer oder was Außenstehende über die deutsche Kommunikationskultur denken.

Ein Aspekt bei der deutschen Kultur ist zum Beispiel, dass es nur eine Wahrheit gibt. Und das ist der Glaubenssatz über der Kommunikationsmuster der Deutschen.

Kollidiert natürlich direkt mit dem Chinesischen, wo es heißt, es gibt viele Wahrheiten. Und genau in dieser Kollision befindet man sich, wenn man mit interkulturellen Teams arbeitet, die irgendwo in der Welt verteilt sind.

Geropp:

Dieser Umgang ist schon schwer genug, wenn ich in dem jeweiligen Land bin und mit den Leuten dort umgehe. Diese Schwierigkeit potenziert sich, wenn ich nur über das Telefon kommuniziere, wenn ich gar nicht die Leute sehe und näher an denen dran bin.

Georg, was sind denn aus deiner Sicht die typischen, kritischen Situationen, die in Software-Projekten passieren können und wie geht man damit am besten um als Projektleiter?

Lohrer:

Also grundsätzlich beziehe ich mich da jetzt auf Embedded Systeme.

Man muss vielleicht noch dazu wissen, es gibt zwei grundsätzliche Strömungen in der Entwicklungsphilosophie, das agile Konzept versus des traditionelle V-Modell Wasserfall. Die Insider werden damit was anfangen können.

Mittlerweile ebbt der Glaubenskrieg ab und man beginnt sich zu verständigen im Sinne von wir fahren ein Hybrid-Modell, was passt, wird gemacht oder was förderlich ist, wird gemacht.

Grundsätzlich gilt aber immer: Haben wir ein klares Ziel? Wissen wir, wo wir hin wollen? Haben wir eine klare zeitliche Abstimmung? Und können wir Arbeitspakete abstimmen?

Das heißt, wenn ich da auf bestimmte, kritische Situationen gucke, ist es oft so, dass es keine Planung gibt. Es gibt noch nicht mal eine Abschätzung, noch nicht mal eine Falsche.

Es gibt bei Azure, gibt es eine Bewegung, die heißt, „No Estimate“. Das heißt, wir vermeiden Abschätzungen, weil sie sowieso falsch sind. Es ist aber schwierig, gerade im Embedded Umfeld, weil es eben nicht nur Software ist, sondern auch Hardware.

Und Hardware hat einfach nun mal bei vielen Sachen eine definierte Lieferzeit. Wenn ich einen neuen Prozessor brauche, weil zum Beispiel der alte einen Fehler hat, beispielsweise einen Maskenfehler, dann dauert das ziemlich genau drei bis vier Monate bis ich einen neuen Prozessor habe.

Und jetzt kann ich natürlich mich alle zwei Wochen zusammensetzen und fragen, „Okay, wie weit sind wir?“ Es ändert sich nichts daran. Es dauert drei bis vier Monate und irgendwann komme ich dem Ding näher.

Das heißt, da muss ich anfangen zu planen. Das mündet dann oft in kritische Situationen, wenn es eben nicht gemacht wird. Oder wenn es nicht gemacht wird, dann weiß niemand so genau, wo man steht.

Das ist häufig ein großes kritisches Problem, wenn Planung, selbst wenn es möglich wäre, nicht gemacht wird.

Das Zweite: Features, also Eigenschaften eines Systems, werden nicht oder werden falsch definiert oder nicht ausreichend definiert. Das heißt im Umkehrschluss dann oft, dass niemand so genau weiß, was an sich genau gemacht werden soll.

Es werden zum Beispiel irgendwelche abstrakten Bezeichnungen für Features verwendet, etwa das System soll schnell genug sein oder so was. Ohne das jetzt konkret zu machen, in welcher Situation, was genau, wer, wann, wie misst, macht und so weiter. Das muss halt alles bestimmt werden. Wenn das nicht gemacht wird, dann landest du halt dann irgendwo hinten. Irgendwo, das ist ziemlich betrüblich, wenn man es erst kurz vor dem Ende feststellt.

Die agile Vorgehensweise ist an der Stelle ein bisschen besser, weil sie eben viel kürzere Zyklen hat, um das immer wieder zu überprüfen. Wo sind wir eigentlich? Wo wollen wir hin? Passt das noch? Und da merkst du es einfach schneller.

Und ein anderer Fall für kritische Situationen ist, wenn Ressourcen nicht vorhanden sind. Das heißt, es wird einfach geplant, so das und das muss gemacht werden und es achtet niemand darauf – ganz typisch in Matrix-Organisationen – wenn es über Kreuz geht mit anderen Projekten.

Du hast irgendwo eine Line, wo die Leute „verhaftet“ sind oder verortet sind in irgendeiner Form, also rein bürokratisch und managementtechnisch, und auf der anderen Seite hast du die Projekte, in denen die Leute arbeiten.

Und jetzt sind die Projekte völlig unabhängig voneinander und agieren unabhängig voneinander und plötzlich wird eine Person zu 180 Prozent belegt oder so was. Das geht natürlich nicht. Dadurch werden kritische Situation herauf beschworen und Projekte können nicht fertig werden.

Insbesondere bei Software ist auch das ein Problem, dass es keine detaillierten Pläne oder Zeichnungen gibt, wie sie in anderen Ingenieur-Sparten üblich sind. Das gibt es bei der Software nicht.

Da hast du oftmals nur so ein paar lapidare Sätze und das war es dann. Maik Pfingsten hat da zum Beispiel eine Profession draus gemacht mit seinen Lastenheften. Das ist ein Punkt.

Was ich da manchmal bei der Software sehe. Da soll dann was gemacht werden, wo ich denke, und was heißt das jetzt? Ja, irgend so ein Satz da, der da steht, was soll der? Du kannst noch nicht mal drauf ableiten, was für ein Aufwand das wohl sein mag.

Oder es steht ein Aufwand dabei, 160 Stunden oder 200 oder 2.000 Stunden und keiner weiß, ob das wirklich Substanz hat. Was ist damit? Da muss man wesentlich konkreter werden. Das heißt aber auch, ich muss wesentlich mehr kommunizieren mit den Leuten, um diese kritischen Situationen zu beheben.

Und es muss auch vom Management her klar sein, dass gerade Embedded Systeme sehr komplizierte Systeme sind. Manchmal werden diese System durch die Kompliziertheit auch sehr komplex. Sie sind schwer zu begreifen vom zeitlichen Ablauf her. Daraus ergeben sich sehr viele kritische Situationen und da braucht man schon jemanden, der ein Auge dafür hat, das Ganze zusammenzufügen und durch diesen Wust von Durcheinander irgendwie durchzubringen.

Geropp:

Das führt auch sehr schön zu meiner letzten Frage an Dich und da geht es um die Rolle des Team-Leiters. So, wie du das ja beschreibst, haben es mit einem komplizierten, teils komplexen System zu tun. Der Projektleiter muss an die Leute rankommen. Er muss dort Vertrauen schaffen. Er muss nach oben hin das Ganze auch noch erklären. Was sind denn aus deiner Sicht so die drei wichtigsten Eigenschaften, die ein guter Projekt- oder Team-Leiter, mitbringen muss?

Lohrer:

Das aller Wichtigste für mich ist ein Satz, den ich aus dem NLP kenne, der heißt:

„The map is not the territory.“

Also die Landkarte ist nicht die Landschaft. Für die Kommunikation heißt das:

„Was der andere mir sagt, wie er sich verhält, wie er agiert, ist das Ergebnis seiner Interpretation der Realität.“

Diese Realität muss nicht mit meiner Interpretation übereinstimmen. In den aller meisten Fällen tut es das auch nicht. Und daran machen sich dann oft irgendwelche Sachen fest, wie Beurteilungen meinerseits: Das ist schlecht, das ist gut, förderlich oder nicht förderlich.

Aber ich versuche immer davon auszugehen, dass der andere es passend zu seiner Landkarte macht. Das heißt, mein Aspekt oder meine Intension ist es dann immer rauszufinden, wie sieht dem Anderen seine Landkarte aus, bei der gleichen Landschaft.

Ich sehe die Landschaft und er sieht die Landschaft und jetzt will ich einfach nur wissen, wie sieht seine Landkarte aus? Und dadurch ergeben sich einfach bestimmte Aktionsmöglichkeiten, indem ich nämlich anfange zu verstehen.

Ich muss das nicht akzeptieren, wie der andere das macht. Aber ich beginne zu verstehen und dann können wir gemeinsam agieren. Das aller Wichtigste für mich.

Geropp:

Es geht um das Bemühen, den anderen zu verstehen.

Lohrer:

Ohne sich selber aufzugeben dabei.

Und das andere ist dann auch aus dem NLP heraus. Wenn etwas nicht funktioniert, dann mache es anders.

Was ich oft erlebe, ist so nach dem Motto, das Pferd ist tot, aber es wird immer weiter geritten. So, es wird noch mal drauf geschlagen. Das muss doch funktionieren. Das hat immer funktioniert. So will ich das weiter machen.

Das heißt, in dem Moment, wenn ich erkenne, dass es nicht funktioniert, dann sollte ich so flexibel sein meinen Weg zum Ziel zu ändern. Da muss ich eine andere Methode wählen. Etwas anderes ausprobieren. Eine andere Gelegenheit suchen oder was auch immer. Andere Prozesse einführen. Andere Hilfsmittel verwenden. Irgendetwas. Vielleicht auch andere Personen, anderes Know-how einfügen. Die Flexibilität bei der Zielerreichung ist essenziell wichtig.

Der dritte Punkt ist für mich persönlich immer frei nach Reinhard Sprenger:

„Jede Motivation ist auch Demotivation!“

Wenn ich als Team-Leiter agiere, sehe ich als meine Hauptaufgabe an, Hindernisse und Probleme aus dem Weg zu räumen. Nicht, um es dem anderen bequem zu machen, sondern weil ich die Vorstellung habe, der andere will arbeiten und ich schaue, dass er arbeiten kann.

Das heißt, ich versuche Demotivation zu verhindern. Außenrum, egal was da ist, versuche ich zu verhindern. Ein Punkt dabei ist zum Beispiel – nur um ihn exemplarisch rauszugreifen – ich versuche immer verbindlich zu sein, verlässlich zu sein, auch im Kleinen.

Wenn ich was zusage, überlege ich mir genau, was ich zusage und wenn ich es zusage, dann will ich das auch einhalten. Das funktioniert nicht immer, aber die Leute bekommen genau mit, ob ich mich darum gekümmert habe, ob ich das wirklich wollte oder ob ich nur so getan habe, als wenn ich wollte.

Und der Effekt ist dann einfach: Die Leute beginnen sich auf mich zu verlassen und mir zu vertrauen. Und damit habe ich genau das erreicht, was ich vorher schon erwähnt habe: Ich bekomme das Vertrauen und kann dann so die Leute in der Richtung führen und leiten.

Geropp:

Super. Georg, ich bedanke mich recht herzlich für das Gespräch. Sehr spannend, wie ich finde. Hat mir viel Spaß gemacht. Danke Georg.

Lohrer:

Schön. Ich freue mich auch, dass ich hier sein konnte.

Das inspirierende Zitat

„Es sind nie Kulturen, die miteinander kommunizieren, sondern immer einzelne Menschen, die ihre ganz persönliche und individuelle kulturelle Prägung haben. Darum ist auch das Aufeinandertreffen von zwei Menschen immer ein einzigartiges Ereignis!“

Jürgen H. Schmidt

Weiterführende Links

• Webseite von Georg Lohrer
• Podcast von Georg Lohrer: Mastering Embedded Systems
• Erstellung von Lastenheften (Maik Pfingsten)
• Buch: When Cultures Collide – Leading Across Cultures: Leading, Teamworking and Managing Across the Globe.
• Führen auf Distanz
• Was macht gute Teamarbeit aus?

Podcast abonnieren

Um meinen Podcast zu abonnieren und keine zukünftigen Folgen mehr zu verpassen, klicken Sie einfach auf einen der folgenden Links:

Hier klicken, um via iTunes zu abonnieren!

Hier klicken, um via RSS Feed zu abonnieren!

Ihr Feedback

Wie gefällt Ihnen diese Folge meines Podcasts? Ich freue mich über Feedback und Anregungen.

Wenn Ihnen der Podcast gefällt, bewerten Sie ihn doch bitte auf iTunes! Das hilft, den Podcast bekannter zu machen und auf iTunes sichtbarer zu werden. Für die Bewertung einfach hier klicken! Danke!