Feedback is a gift – Feedback ist ein Gift - Teil 2
Feedback ist die heilige Kuh westlicher Führungskultur. In der agilen Welt, in IT-Unternehmen und Projektteams ist es allgegenwärtig und scheinbar unangreifbar. In der Sprint-Retrospektive heißt es "offenes Feedback", im Peer Review "konstruktive Kritik" und im Jahresgespräch präsentiert die Führungskraft das "360°-Feedback".
Selten haben die Empfänger um das jeweilige Feedback gebeten. Trotzdem (oder gerade deshalb) finden sich etliche Videos und Beiträge, die das Mantra "Feedback is a gift“ predigen:
Wir sollen Feedback als Geschenk annehmen! Insbesondere wenn Feedback uns ärgert, könnten wir in besonderem Maße wachsen. Deshalb sollen wir unseren Schmerz und unseren Ärger wegatmen und an den Erfahrungen und der Weisheit der anderen wachsen.
In dieser Artikelserie werde ich mich mit dem Widerspruch zwischen dem Mantra
"Feedback is a gift" (ein großartiges Geschenk)
und der vielfachen Wahrnehmung
"Feedback ist ein Gift“ (ein oftmals vergiftetes Geschenk)[1]
auseinandersetzen.
Folge 2: Reflections statt JoHaRi
Folge 3: Ein Geschenk bedarf der Annahme
Folge 4: Warum wir schenken
Folge 5: Emotionen und Rituale
Folge 6: Die Dosis macht das Gift?
Folge 7: Euphemismis -vs- Kontext
Folge 2: Reflections statt Johari
In der letzten Folge habe ich das Johari-Fenster vorgestellt, das noch heute die theoretische Grundlage vieler Feedback-Modelle bietet. Johari ist enorm anschlussfähig, weil es bekannte Symptome beschreibt und sich problemlos während einer Fahrstuhlfahrt erklären lässt [2].
Gleichzeitig stellt das Johari-Modell menschliche Persönlichkeitsstrukturen massiv vereinfacht dar. Seine unterkomplexe Struktur fördert meines Erachtens eine missbräuchliche Anwendung in asymmetrischen Machtstrukturen.
Auf der Suche nach einem angemessen differenzierenden Modell nutze ich die Instrumente, die mir als Software-Entwickler und Software-Architekt zur Verfügung stehen. Denn für mich ist das menschliche Gehirn ein Datenverarbeitungssystem. Unsere Psyche ist die Software, die auf diesem System läuft.
In diesem Artikel werde ich versuchen, mit Mitteln objektorientierter Software-Entwicklung menschliche Persönlichkeit zu modellieren. Es soll ein Modell entstehen, das die 4 Scheiben des Johari-Fensters abbilden kann und gleichzeitig Hypothesen zum hilfreichen Umgang mit Feedback sowohl für den Sender als auch den Empfänger anbietet.
Grundsätze objektorientierter Programmierung
Typisch für OOP ist die strukturierte Ablage von Daten, verbunden mit klaren Zugriffsregeln und funktionaler Steuerung ihres Zugriffs. OOP kapselt Funktionalität, was uns in die Lage versetzt, komplexe Gesamtsysteme zu modellieren [3].
Ich vertrete die These, dass die Anwendung von OOP-Pattern der Komplexität menschlicher Persönlichkeit eher gerecht wird als das sehr einfach strukturierte Johari-Modell. In meinem Modell verfügt jeder Mensch über Persönlichkeits-Objekte, welche im Laufe des Lebens kontinuierlich weiterentwickelt werden.
In modernen Formen der Psychotherapie wird oft davon ausgegangen, dass ein Mensch über viele Persönlichkeitsanteile verfügt, von denen jeweils ein spezifischer Anteil das Handeln dominiert [4]. Übersetzt in die OOP-Modellierung existieren somit unterschiedliche Instanzen verschiedener Persönlichkeitsklassen parallel. Abhängig von dem aktuellen Kontext wird eine passende Instanz zur Beantwortung von Anfragen genutzt.
Die Struktur und das Verhalten dieses Objektes können über seine Klassenhierarchie, Zugriffsrechte und Implementierungen beschrieben werden.
Zugriff erfolgt über Methoden, nicht über Attribute
Im Gegensatz zu einem Struct legt eine Klasse ihre Attribute nicht offen. Sie kapselt sie und stellt Methoden zur Verfügung, welche den Zugriff auf die Attribute steuern und Werte auf ihrer Basis berechnen.
class MsFine
{
protected Date dateOfBirth;
public int getAge() {
return 29; }
}Was getAge() zurückgibt, ist abhängig von seiner Implementierung.
Ein User der API mag davon ausgehen, dass eine Instanz von MsFine ihr Alter als Differenz zwischen aktuellem Datum und dem geschützten Attribut dateOfBirth berechnet. Eine Garantie gibt es hierzu aber nicht.
Externe Systeme greifen über Interfaces zu
Lose gekoppelte Systeme kennen niemals die konkrete Klasse eines Objekts, sondern nur die Interfaces, die es implementiert.
Dasselbe Objekt kann viele verschiedene Interfaces gleichzeitig implementieren: gegenüber dem Finanzamt ein anderes als gegenüber der besten Freundin.
class MsFine implements Employee, Friend, ChildOfFineFamily
{ ... }Welches Interface ein User der API benutzt, entscheidet, welchen Ausschnitt der Methoden er überhaupt zu sehen bekommt.
Die Systemarchitektur entscheidet zudem darüber, welche Interfaces aus einem bestimmten Kontext sichtbar sind.
Vererbungshierarchien
Persönlichkeiten entwickeln sich oft in Schüben [5].
Jüngere Versionen unserer Persönlichkeit haben wichtige Funktionen erfüllt und Abhängigkeiten zu anderen Systemen aufgebaut [6].
Es ist sehr wahrscheinlich, dass diese Funktionen auch für neue Versionen der Persönlichkeit hilfreich sind. Daher ist es naheliegend, die Persönlichkeitsentwicklung eines Menschen als Ableitung früherer Stadien der Entwicklung zu betrachten.
Eine solche Betrachtung erfüllt auch einen funktionalen Nutzen: Frühere Stadien der Entwicklung haben bereits Abhängigkeiten zu externen Systemen aufgebaut, die über Interfaces mit uns interagieren.
Indem ein neuer Entwicklungsschritt alle Eigenschaften und Fähigkeiten des früheren Stadiums erbt, bleibt die Abwärtskompatibilität gewahrt: Die Dependencies der Vergangenheit können weiter mit uns interagieren.
Bei geerbten Aspekten ist es eine Entscheidung der Entwicklung,
- ob diese überschrieben (
@Override) werden sollen, - ob sie unverändert liegen bleiben (meistens unbeachtet) oder
- ob sie durch neue Access Modifier offengelegt werden.
class FrancineFine implements ChildOfFineFamily
{
protected Date dateOfBirth;
public int getAge() {
return calcAge(); }
protected String getSelfImage() {
return "die Jüngste im Raum"; }
}
class MsFine extends FrancineFine implements Employee
{
@Override
public int getAge() {
return 29; }
int getRealAge() {
return super.getAge(); }
@Override
protected String getSelfImage() {
return "die Erfahrene im Raum"; }
}MsFine hat eine neue Selbstwahrnehmung implementiert. Außerdem beantwortet sie Fragen nach ihrem Alter nun pauschal mit 29.
Dabei wurde das geerbte Attribut dateOfBirth nicht verändert.
Wenn ein Aufrufer aus demselben Package wie MsFine kommt, sieht dieser die neue Methode getRealAge(). Diese Methode ermöglicht weiterhin den Zugriff auf Ergebnisse der alten Implementierung.
Wer MsFine als FrancineFine kennengelernt hat, hat sie vielleicht als Implementierung der ChildOfFineFamily-Schnittstelle in Erinnerung behalten.
Sie bedient dieses Interface weiterhin, auch wenn getAge() nun einen konstanten Wert liefert, unabhängig von ihrem Geburtsdatum.
Die vier Fensterscheiben von Johari
In meinem letzten Artikel habe ich beschrieben, dass es mir leichtfällt, die 4 Scheiben des Johari-Modells auf meine Lebenserfahrung zu übertragen. Nun möchte ich diese für das Modell der "objektorientierten Persönlichkeitsentwicklung“ anwenden:
1. Die öffentliche Person
Die öffentliche Person beschreibt jene Facetten unserer Persönlichkeit, die sowohl uns bewusst sind als auch von anderen wahrgenommen werden.
In dem OOP-Modell werden diese Facetten durch die öffentliche API der Klasse beschrieben. Ergänzt um einen Vertrag, nach dem Getter-Methoden den tatsächlichen Wert eines Attributes zurückliefern sollten.
Zudem sollte die public API über angemessene Dokumentation verfügen, damit sie im Sinne der Implementierung genutzt werden kann.
Durch die Implementierung von Interfaces ergänzt das OOP-Modell die öffentliche Person um ein zusätzliches Abstraktionslevel. Es existieren unterschiedliche Kontexte, die einen bestimmten Ausschnitt an Fähigkeiten als Funktionsumfang erfordern. Zudem ist es eine bewusste Architekturentscheidung, ob diese Kompatibilität veröffentlicht werden soll.
Eine Person kann über sämtliche Fähigkeiten verfügen, um als Schulelternratsvorsitzende zu agieren und sich gleichzeitig bewusst entscheiden, die entsprechende
Implements– Deklarierung zu unterlassen. So wird sie trotz Eignung als nicht kompatibel eingestuft.
Ein Nachteil komplexer Klassenhierarchien ist der Umgang mit Legacy Code: Die neue Klasse erbt auch solche Fähigkeiten, die für die Bewältigung der aktuellen Aufgaben nicht von Bedeutung, manchmal sogar schädlich sind [7].
Ehemals offengelegte Schnittstellen können nicht nachträglich verborgen werden. Es ist lediglich möglich, eine alternative Implementierung bereitzustellen, wie bei MsFine.getAge() geschehen.
Diese Implementierung kann in den abhängigen Systemen allerdings zu Seiteneffekten führen und Anpassungen erfordern.
Ein Effekt, der mir als 3-facher Vater sehr bekannt vorkommt.
2. Das Geheimnis
Das Geheimnis beschreibt Facetten einer Persönlichkeit, die vor anderen verborgen bleiben und denen sich der Mensch dennoch bewusst ist.
In dem OOP-Modell können diese Facetten unterschiedlich modelliert und hierdurch differenziert diskutiert werden:
Die Lüge
Ein Geheimnis kann entstehen, indem ein Vertrag gebrochen wird. Wenn MsFine.getAge() eine Konstante anstelle eines berechneten Werts liefert, hat sie eine implizit getroffene Vereinbarung gebrochen. Dasselbe ist der Fall, wenn es zu einer Diskrepanz zwischen Dokumentation und Implementierung der öffentlichen API kommt.
Das versteckte Potential
Wenn die Zugriffsrechte auf bestehende Fähigkeiten stärker eingeschränkt sind, als es der Kontext (das Interface) verlangt, ist eine Persönlichkeit zur Deklaration des Interfaces inkompatibel. Obwohl die Persönlichkeit über alle Fähigkeiten verfügt, die das Interface verlangt, ist sie für externe Systeme nicht aufrufbar.
Der gemiedene Kontext
Wie zuvor beschrieben, kann es eine bewusste Entscheidung sein, eine Implements – Deklaration auszulassen und so für externe Systeme inkompatibel zu erscheinen.
Wenn ein User der API bemerkt, dass sein Ziel wegen eines Geheimnisses mit dieser Persönlichkeit nicht erreicht werden kann, führt dies zu Enttäuschungen. Insbesondere die Lüge wird schnell verurteilt. Ein gemiedener Kontext oder verstecktes Potential werden schnell als Egoismus ausgelegt.
Erfahrene Software-Entwickler wissen, dass solche Diskrepanzen nicht aus Gehässigkeit entstehen. Meist sind sie logische Folgen akuter Situationen:
- Lügen entstehen unter Zeitdruck, wenn vergessen wurde, die Dokumentation nachzuziehen. Sie entstehen auch, wenn ein Interface bedient werden muss und irrelevante Funktionen mit Default-Werten gemockt werden.
- Wenn Ressourcen begrenzt sind, ist es sinnvoll, nur aus bestimmten Kontexten gerufen werden zu können. – Selbst, wenn die Fähigkeiten mehr ermöglichen würden.
- Solange ein Feature noch nicht ausreichend getestet wurde, schützt der Entwickler das Umfeld vor potenziell notwendigen Anpassungen und Seiteneffekten, indem unausgereifte Fähigkeiten geheim gehalten werden.
Wenn Geheimnisse zu Enttäuschungen führen, fragt sich der Software-Architekt:
Rechtfertigen die gegenwärtigen Rahmenbedingungen
die Entscheidungen der Vergangenheit?[8]
3. Der blinde Fleck
Als blinder Fleck werden jene Facetten einer Persönlichkeit bezeichnet, die wir selbst nicht erkennen, obwohl sie anderen bewusst sind.
In meinem Modell differenziere ich mindestens zwischen zwei unterschiedlichen Ausprägungen blinder Flecken:
Der unbekannte Kontext
Diese blinden Flecken sind die Gegenspieler der gemiedenen Kontexte:
Wenn eine Persönlichkeit über sämtliche Fähigkeiten eines Interfaces verfügt, ohne die Implementierung dieses Interfaces zu deklarieren, muss das kein Vorsatz sein. Es ist auch möglich, dass zum Zeitpunkt der Entwicklung dieses Interface nicht bekannt oder nicht verfügbar war.
In diesem Fall kann der bloße Hinweis auf die Existenz des Interfaces ausreichen, um einen blinden Fleck in eine Facette der öffentlichen Person zu verwandeln.
Package-protected Features
In dem OOP- Modell können verschiedene Entwicklungsstadien einer Persönlichkeit in unterschiedlichen Kontexten liegen. Jeder Kontext steuert auch den Zugriff auf Felder und Methoden seiner Klassen. In Java wird dieses Konzept mithilfe des Default-Zugriffsrechts umgesetzt, das ein Feld oder eine Methode innerhalb eines Packages veröffentlicht.
Eine solche Struktur ist äußerst sinnvoll, weil alle Member eines Packages einen gemeinsamen Zweck erfüllen sollen. Sie interagieren miteinander, bauen Vertrauensverhältnisse auf, nutzen gemeinsame Interfaces zur Kommunikation miteinander und öffentliche Interfaces zur Kommunikation in externe Kontexte.
In der Software-Architektur ist das Facade-Pattern als Entwurfsmuster etabliert. Wird dasselbe Konzept von Persönlichkeiten angewendet, wird dieses schnell als "mangelnde Authentizität" abgewertet.
Die Klassen FrancineFine und MsFine sind hauptsächlich mit der Kernfamilie verbunden. Sie wurden daher in dem Package us.family.fine implementiert. Im Hause Sheffield entwickelt sich die Persönlichkeit TheNanny, die von MsFine abgeleitet wurde. Da diese Persönlichkeit hauptsächlich mit der Familie Sheffield interagiert, wurde sie im Package us.family.sheffield implementiert.
So ist eine Struktur entstanden, die einer Instanz von TheNanny den Zugriff auf getRealAge() untersagt, da diese Methode ausschließlich von Objekten des Packages us.family.fine aufgerufen werden darf. Die Fähigkeiten sind trotzdem vererbt worden und können von Familienmitgliedern gesehen und aufgerufen werden, obwohl sie TheNanny verborgen bleiben.
4. Das Unbekannte
Als unbekannt werden jene Facetten der Persönlichkeit beschrieben, die weder uns selbst noch anderen bewusst sind.
In dem OOP-Modell ergeben sich diese Facetten organisch aus der Vererbungshierarchie der agierenden Persönlichkeitsanteile:
Werden Attribute oder Methoden als private deklariert, verlieren zukünftige Entwicklungsstufen den Zugriff auf diese Felder und Fähigkeiten.
Dennoch werden diese Felder und Fähigkeiten vererbt. Sie sind weiterhin Teil des Persönlichkeitsanteils und steuern unsere Algorithmen, ohne dass ein Zugriff mittels this oder super möglich wäre.
Reflections oder Feedback
Klassische Feedback-Prozesse verteilen die Macht der Deutungshoheit asymmetrisch an den Sender des Feedbacks [9].
Da blinde Flecken in dieser Definition nur von beobachtenden Menschen erkannt werden können, sollen die anderen Feedback annehmen. Meist bedeutet dies, dass sie die Beobachtung zur gemeingültigen Wahrheit definieren.
Das Konzept funktioniert auch in dem OOP-Modell, insbesondere für unbekannte Kontexte. Hier wird das Feedback-Gespräch im besten Fall zu einem Architektur-Review, in welchem festgestellt wird, dass eine Persönlichkeit längst über sämtliche Fähigkeiten verfügt, um eine Rolle auszufüllen.
Ein solches, wertvolles Feedback-Geschenk wurde mir einst von meinem geschäftsführenden Gesellschafter gemacht:
"Wenn das Controlling einer Abteilung wie hier strukturiert ist,
unterscheidet es sich nicht mehr substanziell von der Buchhaltung einer GmbH."
Klassische Feedback-Prozesse geraten allerdings an ihre Grenzen, weil Kontext, Rolle und Kapselung nicht berücksichtigt werden [10]. Das ursprüngliche Johari-Konzept versucht, die Persönlichkeit eines jeden Menschen mit 56 diskreten Adjektiven zu beschreiben, von denen maximal 6 zugewiesen werden sollen.
Das Antipattern: Feedback ist ein Gift
Als Vorgesetzter beobachte ich, dass eine Mitarbeiterin die Frage nach ihrem Alter pauschal mit "29" beantwortet. Ich prüfe die 56 Johari-Adjektive und assoziiere damit die Attribute "stolz" und "witzig". Die Kategorien "bescheiden" und "logisch" assoziiere ich eher nicht.
In einem Feedback Gespräch erfährt die Kollegin von mir, dass sie stolz sei. Da diese Feststellung ihrem Selbstbild nicht entspricht, muss es Teil ihres blinden Flecks sein. Ich fordere sie auf, ihren Stolz zukünftig offen zu zeigen, damit Reibung im Team minimiert wird.
Ist dies eigentlich durch mein Weisungsrecht als Arbeitgeber gedeckt [11]?
Die Angestellte folgt meiner Anweisung. Anschließend häufen sich Beschwerden aus dem Team. Die Zusammenarbeit sei gestört, insbesondere weil die Kollegin nun ihre Adjektive "akzeptierend", "anpassungsfähig" und "bescheiden" verstecke.
Die Reflexion: Feedback is a gift
Als Vorgesetzter beobachte ich, dass eine Mitarbeiterin die Frage nach ihrem Alter seit mehr als 12 Monaten mit "29" beantwortet. In diesem Zeitraum habe ich sie in der täglichen Arbeit als verantwortungsbewusst und aufrichtig wahrgenommen.
In einem Reflexionsgespräch teile ich diese Beobachtungen.
Abhängig von unserer Beziehung (Welche Interfaces stehen uns zur Kommunikation zur Verfügung?) ergibt sich nun ein Gespräch, in dem sie dieses Verhalten bestätigt und begründet.
Sie berichtet von einem beobachtbaren Muster, nach dem Frauen in ihrem Alter in unserer Organisation systematisch benachteiligt würden. Ich erkenne dieses Muster und reflektiere, dass ich die Zeichen als alter weißer cis-Mann mangels Betroffenheit bisher übersehen habe.
Das Reflexionsgespräch hat zur Folge, dass ich etwas über mich gelernt habe, dass ich das Verhalten der Kollegin besser verstehen konnte und dass unser Vertrauensverhältnis gestärkt wurde.
Ist es nicht beachtlich, dass der psychologische Selbsterkenntnisprozess "Reflexion" genannt wird [12] und die Programmiersprache Java ein "Reflections"-Framework zur Analyse von Laufzeitobjekten zur Verfügung stellt [13]?
In beiden Fällen handelt es sich um ein mächtiges Werkzeug. Es ist hervorragend geeignet, um (Sub-)Systeme zu analysieren und zu verstehen.
Auch wenn es möglich ist, mittels Reflections Werte in Felder zu schreiben, so birgt dies immense Risiken unvorhersehbarer Seiteneffekte und Laufzeitfehler.
Es ist meist eine sehr schlechte Idee, mittels Reflections-Framework Objekte zu manipulieren, die von anderen Entwicklern geschrieben wurden.
- Kluger, A. N., & DeNisi, A. (1996). The effects of feedback interventions on performance: A historical review, a meta-analysis, and a preliminary feedback intervention theory. Psychological Bulletin, 119(2), 254–284. Abgerufen am 18. September 2026 von https://doi.org/10.1037/0033-2909.119.2.254
- Luft, J. (1969). Of human interaction. National Press Books.
- Booch, G. (2007). Object-oriented analysis and design with applications (3rd ed.). Addison-Wesley.
- Watkins, J. G., & Watkins, H. H. (1997). Ego states: Theory and therapy. W. W. Norton.
- Kegan, R. (1982). The evolving self: Problem and process in human development. Harvard University Press.
- Young, J. E., Klosko, J. S., & Weishaar, M. E. (2003). Schema therapy: A practitioner's guide. Guilford Press.
- Bloch, J. (2018). Effective Java (3rd ed.). Addison-Wesley.
- Kruchten, P., Nord, R. L., & Ozkaya, I. (2012). Technical debt: From metaphor to theory and practice. IEEE Software, 29(6), 18–21. Abgerufen am 18. September 2026 von https://doi.org/10.1109/MS.2012.167
- Stone, D., & Heen, S. (2014). Thanks for the feedback: The science and art of receiving feedback well. Viking/Penguin.
- Kluger, A. N., & DeNisi, A. (1996). The effects of feedback interventions on performance: A historical review, a meta-analysis, and a preliminary feedback intervention theory. Psychological Bulletin, 119(2), 254–284. Abgerufen am 18. September 2026 von https://doi.org/10.1037/0033-2909.119.2.254
- Info: Dieser Frage werde ich – unter anderem – in der 3ten Folge dieser Serie nachgehen.
- Schön, D. A. (1983). The reflective practitioner: How professionals think in action. Basic Books.
- Forman, I. R., & Forman, N. (2004). Java reflection in action. Manning Publications.
