Es gibt viele gute Bücher - und zu wenig Zeit, gute Bücher zu lesen.
Warum ich finde, dass "Soft Skills für Softwareentwickler" nicht zu den Büchern gehört, die man trotz allem gelesen haben sollte.
Kann man Social Skills aus einem Buch lernen? Da ich diesbezüglich schon viel aus Büchern gelernt habe, kann ich darauf mit "prinzipiell ja" antworten. Wie immer wird es Menschen geben, die dafür Bücher, und andere, die dafür andere Medien bevorzugen.
Was ich an Büchern über Psychologie und Kommunikation schätze, sind Hintergrundinformationen, warum Menschen in bestimmten Situationen zu gewissen Verhaltensweisen tendieren. Wobei es bei den Sozialwissenschaften immer um Tendenzen geht, um Wahrscheinlichkeiten, um individuelle Nuancen, und nicht um Tatsachen, Beweise und definitive wenn-dann-Schemata. Bücher, die das individuelle Handlungsspektrum erweitern wollen, sollten mir vor allem mögliche Gründe für das Verhalten meiner Mitmenschen aufzeigen, und mögliche Umgangsformen dafür.
Das alles tut "Soft Skills für Softwareentwickler" von Vigenschow, Schneider und Meyrose nicht, oder zumindest nicht ausreichend. Aus Tendenzen werden hier einfache Schemata, aus Ideen für schwierige Situationen und Gesprächspartner Rezepte für jeden Tag. Ich soll eine ganze Latte von Methoden beachten, um meiner Gesprächspartnerin zu zeigen, dass ich sie respektiere. Beim Lesen lässt mich das allerdings eher an Hilfe zur Vertuschung gegebener Respektlosigkeit denken. Die Idee, dass ich unter Menschen, die ich alle respektiere, einfach sagen kann, was ich denke, ohne den beabsichtigten Inhalt aufwändig in hübsches Papier zu verpacken, ist in dem Buch leider gar nicht zu finden.
Festmachen möchte ich das an einem Beispiel, an dem sich mein Problem mit dem Buch besonders gut erklären lässt:
"In der Besprechung gestern bist du von der Agenda abgewichen und in den Themen hin und her gesprungen. Das hat mich derart irritiert, dass ich nicht mehr folgen konnte! Das hat mich sehr verärgert."(1)
Das ist kein Beispiel für schlechtes Verhalten, von dem ausgehend eine bessere Umgangsweise mit der Situation entwickelt wird. Das ist das "gute Beispiel", wie man es machen soll. Was stört mich daran? Das Buch sagt, man möge Ich-Botschaften verwenden, wenn man Kritik äußert. "Dass ich nicht mehr folgen konnte" ist in meinen Augen aber keine Ich-Botschaft, sondern ein eindeutiger Vorwurf. Die Ich-Botschaft fände ich im ersten Satz gut aufgehoben, etwa so: "In der Besprechung gestern hatte ich das Gefühl, dass du zwischen den Themen hin und her springst. Zwischendurch konnte ich dir kaum folgen. Konnte ich den roten Faden nur nicht sehen, oder hattest du selbst in dem Moment keinen?". Hierbei gehe ich von meinem Gefühl aus, dass der rote Faden fehlt. Ich halte aber die Möglichkeit offen, das der "Fehler" in meiner Wahrnehmung lag. Und ich gebe meiner Gesprächspartnerin die Möglichkeit, selbst zu sagen, was sie behindert haben könnte. Vielleicht hatte sie (egal warum) an dem Tag Stress und konnte sich nicht konzentrieren? Oder hatte wegen eines plötzlichen anderen Meetings keine Zeit sich vorzubereiten? Vielleicht hat sie sich auch über sich selbst geärgert, weil sie mit der selbstdefinierten Agenda nicht mehr klar kam. Und sie freut sich jetzt darüber, dass jemand das anspricht und sie ihr "ich weiß auch nicht, was mit mir los war!" mit jemand anderem teilen kann. Eventuell könnte ja ein unauffälliger Hinweis beim nächsten Meeting helfen...?
Ein solches Feedback ist ein Angebot zur Reflektion. Warum habe ich wie gehandelt, was wollte ich eigentlich sagen, und was kam an? Vigenschow, Schneider und Meyrose erklären ganz richtig, dass das, was ich meine, und das, was verstanden wird, nicht deckungsgleich sein müssen. Aber sie packen in jede Kommunikation eine Hierarchie. Feedback wird gegeben - und zwar explizit so, dass kein Gespräch darüber möglich ist. Inhaltliche Gespräche über das Feedback sind ausdrücklich verboten (2). Hier wird jede Reflektion, jedes kollegiale Gespräch abgewürgt, bevor es überhaupt begonnen hat. Der Feedbacknehmer soll das Feedback "annehmen", ohne sich zu "verteidigen" (eine andere Art von Reaktion ist in dem Buch nicht vorgesehen), der Feedbackgeber kippt ihm das Feedback vor die Füße und geht.
Angenommen wird, dass Feedback nur zu Verhaltensweisen oder Ergebnissen gegeben werden darf, die der Feedbacknehmer selbst in der Hand hat. Das wiederum entscheidet aber der Feedbackgeber. Ein klassisches Beispiel aus dem Autismus-Umfeld wäre etwa: "Nie guckst du mich an, wenn ich mit dir rede. Ich habe das Gefühl, dass du mich gar nicht ernst nimmst.". Der Feedbackgeber sagt's und geht. Für ihn eine klare Sache: nicht angucken gleich nicht zuhören, und zu ändern ist das ja wohl auch. Der Feedbacknehmer kann laut der Theorie schließlich auch selbst entscheiden, ob er das Feedback annimmt. Der klassische Autist würde in der Situation wohl notgedrungen "entscheiden", es nicht anzunehmen - Leute anzugucken und ihnen gleichzeitig zuzuhören ist sehr anstrengend für die meisten Autisten. Der Feedbackgeber würde sich dadurch in seiner Auffassung bestärkt fühlen, dass der andere ihn nicht für voll nimmt. Oder es läuft noch schlimmer: der Autist fragt nach (Verständnisfragen sind erlaubt), was genau mit "angucken" gemeint ist. Die ganze Zeit? Zwingend in die Augen, oder gehen auch die Füße? Das Desaster schlechthin, dabei erfolgte die Kommunikation 1A nach Lehrbuch.
Feedback ist ein Gesprächsangebot
Wie anders sähe die Sache aus, wenn der Feedbacknehmer das Feedback kommentieren dürfte, ohne gleich der "Verteidigung" und der "Abwehr" bezichtigt zu werden? Wenn er "oh nein, das ist ja doof. Mir fällt es tatsächlich schwer, zuzuhören und den Sprecher anzusehen." sagen könnte. In dieser Situation könnte sich ein Gespräch darüber entwickeln, wer was braucht, und wie es beide hinbekommen können, dass beide bekommen, was sie benötigen. Dann ist es aber eben ein freies Gespräch und kein festgelegtes Ritual. Es lässt sich schwerer planen. Und es gibt kein Rezept dafür, das zwischen zwei Buchdeckel passt.
"Soft Skills für Softwareentwickler" enthält durchaus auch sinnvolle Informationen, hilfreiche Hinweise oder Kommunikationsmodelle. Hinter fast allem scheint aber ein impliziter Wettbewerbsgedanke zu stehen, als gäbe es in jeder Kommunikation Gewinner und Verlierer. Kommunikation ist für mich aber vor allem Kooperation. In "Soft Skills für Softwareentwickler" scheint sie eher eine Art Gefechtsstrategie zu sein. Das macht die Modelle nicht unbedingt falsch. Aber man sollte sie vielleicht nicht unbedingt so umsetzen, wie sie im Buch propagiert werden. Aber als Entwickler*in ist man in der Regel ohnehin daran gewöhnt, Gelesenes nicht 1:1 übernehmen zu können.
Allerdings werden in dem Buch auch explizit "schlechte Beispiele" vorgestellt, bei denen mir beim Lesen ganz anders wird. Eine solche Umgangsweise bin ich nicht gewöhnt, weder von meinen Kolleginnen und Kollegen bei neuland noch bei einem anderen Arbeitgeber. Wenn sich die Kommunikation im Team nur noch auf Vorwürfe und Selbstdarstellungen beschränkt, kann "Soft Skills für Softwareentwickler" ein super Anfang sein, um die Teamkultur zu verbessern. Vielleicht habe ich auch einfach nur Glück, in einem Umfeld zu arbeiten, das diesem Buch längst entwachsen ist, und in dem offene, spontane und wirklich respektvolle Kommunikation zum Alltag gehört. Mein Kollege Henrik Endl hat es mal so formuliert: "Der Umgang mit Menschen folgt nicht einem Rezept". Recht hat er.
- S. 65
- "Still zuhören. Es ist nur erlaubt, Verständnisfragen zu stellen. Keine Kommentare einwerfen und den Feedback-Geber vollständig ausreden lassen. Es ist explizit verboten, sich zu rechtfertigen oder sein Verhalten zu erklären.", S. 67