In einem Satz: Dinge brechen nicht zusammen und bleiben nicht stecken, wenn sie nicht da ist.

Alles, was eine Führungskraft tut, wird mit einer Bedeutung verknüpft.
Bevor wir Bedeutung zuweisen, findet unsere Interpretation statt. Interpretation ist nicht exakt oder objektiv, sie ist sehr persönlich.
Interpretation wird stark beeinflusst von deiner Erfahrung und deinem Glaubenssystem … und wir alle haben unterschiedliche.
Manchmal verpassen wir also die richtige Bedeutung, wenn wir in eine Situation gedrängt werden, in der wir interpretieren müssen. Anders gesagt: Wir raten.

Wie drängt man Menschen in die Interpretation?

Kommuniziere vage. Folge der politischen Korrektheit. Versuch, niemandem auf die Füße zu treten. Versteck deine Gefühle.
Ein Beispiel: Nehmen wir den Satz „Woran erkenne ich einen guten CEO?“. Ist das eine klare Frage?
Nein, die Bedeutung ist vage! Gut für was oder wen? Vielleicht wann brauchen wir einen guten; immer, nur morgens? Warum ist das überhaupt relevant? Welche Probleme würde ein guter CEO lösen?
Eine gute Antwort auf Gut für wen wäre: „für die gesamte Organisation“. Das ist die Verantwortung des CEO: sich um das gesamte System zu kümmern und sicherzustellen, dass die nötige Interaktion stattfinden kann.

Hast du Kinder? Es geht nicht darum, erwachsen zu sein – es geht darum, was wir uns für unsere Kinder in 20–30 Jahren wünschen.
Trennen wir Rahmenbedingungen von Dingen, die unter ihrer Kontrolle liegen. Wir wollen Kinder, die selbst denken und handeln. Das ist der Schlüssel zum Glück.
Deine Rahmenbedingungen oder dein soziales Umfeld sind dabei völlig irrelevant. Als Beweis: Schau dir die Geschichte von Viktor Frankl an. In einer unmenschlichen Umgebung konnte er seinen eigenen Willen und seine Gedanken gegen alle Widerstände bewahren. Er wurde unzerbrechlich.

Besonders als CEO wird alles, was du sagst und tust, interpretiert und mit Bedeutung aufgeladen. Selbst wenn der CEO nicht da ist, kommuniziert er – denn die Mitarbeiter fragen sich vielleicht: „Ist er nicht da, weil wir/unsere Themen nicht wichtig sind? Oder weil er sich nicht für uns interessiert oder wir ihm egal sind?“
Und wenn du ihn fragst „Hey, uns ist aufgefallen, dass du nicht da warst. Ist alles okay?“, bekommst du vielleicht eine völlig nachvollziehbare Antwort, die nichts mit den negativen, abstrusen Annahmen zu tun hat. Z.B.: „Ich wollte euch die Bühne überlassen, damit alle wissen, dass es euer Erfolg ist und nicht meiner.“
Sobald ihr miteinander redet, ersetzt ihr die erfundene Bedeutung durch die beabsichtigte Bedeutung.
Ein einfacher Trick, um erfundene Bedeutungen zu entlarven: Frag dich: „Kann ich das wirklich wissen?“

Der „gute“ CEO

Boni werden oft ein- oder zweimal im Jahr verhandelt. Dazwischen tauchen im Tagesgeschäft dringende Themen auf, um die man sich besser früh kümmert – bevor sie größer werden.
Stell dir eine Führungskraft vor, deren Bonus an Ziel „A“ hängt. Was wird sie priorisieren? „A“ fertigmachen, um den Bonus zu kassieren – oder den Bonus riskieren und sich um das dringende Thema kümmern?

Die Bonus-Verhandlung basiert auf der Annahme, dass zwischendurch nichts strategisch Wichtigeres passiert. Ein weiterer Beweis dafür, dass wir die Zukunft nicht vorhersagen können.
Stattdessen müssen wir flexibel bleiben – oder wenn du es so nennen willst: „agil“. Ja, die meisten von uns bewegen sich in einem VUKA-Umfeld.

Boni können sich positiv auf taktische Planung auswirken (im unmittelbaren Nahbereich), aber verheerend auf strategische Themen, die zwischendurch auftauchen.

Timeboxen begrenzen die investierte Zeit, um den Fokus zu halten. Es ist okay, die Aufgabe in der Timebox nicht fertig zu bekommen.
Ein Sprint ist eine Timebox von meistens 2 Wochen. Ist es dann okay, die eigentliche Arbeit nicht fertig zu bekommen?

Viel Spaß beim Diskutieren!

Kürzlich habe ich einen Kollegen gecoacht, der versucht hat, in eine andere Position zu wechseln. Leider kann sein aktueller Projektleiter es sich nicht leisten, ihn zu verlieren – was es schwer macht, zu seiner Anfrage „Ja“ zu sagen.

Die Coaching-Session endete mit einem Rollenspiel, in dem ich einige entscheidende Punkte hervorgehoben habe:

• In einem hierarchischen System ist Kommunikation von oben nach unten eine Anweisung, von unten nach oben eine Bitte um Unterstützung.
• Die Reihenfolge, in der du deinem Chef Informationen präsentierst, ist enorm wichtig.
• Statt eine „finale“ Entscheidung oder Lösung zu suchen, rege ein Brainstorming an, um gemeinsam mit deinem Chef theoretische Ideen zu erkunden, die das Problem lösen könnten.

Zur Reihenfolge: Es ist entscheidend, damit zu beginnen, wie du dich im Projekt fühlst, im Unternehmen und möglicherweise in deiner aktuellen Lebenssituation. Stelle eine Verbindung her, die vermittelt, wie wichtig dir sinnvolle Arbeit ist und welchen Nutzen das für das Unternehmen hat. Schließe damit ab, wann du und dein Chef gemeinsam (kreative) Lösungen für die anstehenden Themen erarbeiten werdet.

Kürzlich hat ein Kunde gefragt, ob ich meinen Stundensatz nach sechs Monaten Zusammenarbeit an einer organisatorischen Transformation senken würde. Was mich überrascht hat: Es gab keinen konkreten Grund für die Anfrage.

Zuerst war ich unsicher, wie ich reagieren sollte. Ich wusste, was ich nicht wollte: rechtfertigen, warum meine Arbeit den Preis wert ist.

Meine Annahme war, dass der Kunde Geld sparen wollte – was nichts mit der Qualität meiner bisherigen Arbeit zu tun hatte.

Das brachte mich zum Nachdenken: Welches Signal würde es senden, wenn ich meinen Satz senke? Würde das nicht meine Glaubwürdigkeit untergraben? Eine Reduktion um 10% wäre ohnehin unbedeutend, Peanuts. Und eine größere Reduktion könnte den Kunden denken lassen: „Das war ja einfach – ich hab gefragt und er hat gleich 30% nachgelassen. Hat er mich vorher etwa abgezockt?“ Ich bin fest davon überzeugt, dass meine Arbeit den Preis wert ist und er dem Markt entspricht. Wenn man die Einsparungen durch gesteigerte Produktivität und Lean-Methoden berücksichtigt, liegt der Return bei: „Gib einen Euro für mich aus und du bekommst 5–8 Euro zurück.“ Das quantitativ zu beweisen ist allerdings schwierig.

Meiner Einschätzung nach war der Kunde zufrieden mit meiner Arbeit, und die Anfrage war primär kostenmotiviert. Er hatte vermutlich erkannt, dass transformative Veränderungen Zeit brauchen und meine Expertise über einen längeren Zeitraum nötig war als ursprünglich gedacht.

Ich hatte folgenden Dialog in meinem Kopf vorbereitet (K = Kunde, Ich = Ich):

K: Haben Sie über Ihren Stundensatz nachgedacht?
Ich: Ja, habe ich. Aber bevor wir weitermachen – könnten Sie mir Ihre Intention verraten? Geht es rein ums Sparen?
K: Ja.
Ich: In Ordnung. Was, wenn ich Ihnen einen effektiveren Weg vorschlage, Geld zu sparen – einen, der über eine bloße Senkung meines Satzes hinausgeht?
K: Ich höre zu. Weiter!
Ich: Den größten Hebel zum Sparen haben Sie in der Geschwindigkeit, mit der sich Ihr Unternehmen anpasst. Ich würde meinen Kunden einen Bärendienst erweisen, wenn ich durch eine Senkung meines Satzes signalisiere, dass es okay ist, langsamer zu machen. Stellen Sie sich vor, meine Arbeit spart 50 Mitarbeitern circa 2 Tage im Monat (und bei Ihrer Unternehmensgröße ist das konservativ geschätzt). Wir verstehen beide das Konzept von Investition: Sie geben einen Euro aus, und wenn Sie mehr als einen Euro zurückbekommen, ist es eine kluge Investition, oder?
Mir liegt der Erfolg dieser Transformation genauso am Herzen wie Ihnen. Lassen Sie uns auf die Faktoren konzentrieren, die unseren Fortschritt bremsen. Wenn Sie es schaffen, meine Dienste so schnell wie möglich nicht mehr zu brauchen, heißt das, dass ich meinen Job gut gemacht habe.

Der Tag kam und ich habe es genau so gemacht. Die Verhandlung war an diesem Punkt beendet. Mein Kunde hat verstanden, dass die Macht zum Sparen in seinen eigenen Händen liegt – und mein Stundensatz nicht der Hebel ist. Ich war erleichtert, dass der Kunde diese Perspektive verstanden hat. Und ich war froh, dass ich meine Arbeit nicht rechtfertigen oder verteidigen musste, wie ich es früher vielleicht getan hätte. … und natürlich habe ich meinen Satz behalten.

Ein Experiment: Geh in dein Backlog und scanne alle User Stories nach Titel. Frag dich: „Ist das eine Problembeschreibung oder schon eine vorgeschlagene Lösung?“

Als ich das mit einem meiner Kunden gemacht habe, war die verblüffende Antwort:
Nicht eine einzige Problembeschreibung vom Nutzer existierte im Backlog (das Backlog hatte circa 150 Einträge, was für sich genommen schon ein Problem ist).

Selbst wenn die Beschreibung die Problembeschreibung des Kunden enthalten würde – warum verstecken wir sie? Allein die Lösung im Titel zu lesen, beeinflusst die Entwickler und hindert sie daran, selbst zu denken.

Das hat Auswirkungen, die meiner Meinung nach niemand will:

• In kleinere Teile zu schneiden ist viel schwerer, wenn du vor einer Lösung stehst. Wie soll man eine Lösung slicen?
• Menschen werden konditioniert, einfach die vorgeschlagene Lösung umzusetzen

Beides führt nicht dazu, dass Teams sich für die geschaffenen Lösungen verantwortlich fühlen.

Ein Beispiel aus dem echten Leben (und es gibt viele davon):

Der PO hat mit Nachdruck darauf gedrängt, dass das Team eine bestimmte Story umsetzen und innerhalb von 10 Tagen liefern soll. Die Story enthielt das Kundenproblem überhaupt nicht – nur eine Lösung. Das Team fing an zu jammern, weil es nahezu unmöglich war, das rechtzeitig zu schaffen. Und ja, es gab eine Deadline.

Also habe ich angefangen zu fragen:

ICH: Was ist das Bedürfnis des Kunden, oder was hat der Kunde als sein Problem beschrieben?
PO: Oh, er will nur sehen, wie das Redesign der UI aussieht.
ICH: Würde ein Screenshot oder Mockup reichen?
PO: Nein, der Kunde will sehen, wie man mit der UI interagiert.
ICH: Will er selbst klicken, oder würde eine Aufnahme vom Bildschirm eines Entwicklers reichen?
PO: Eine Aufnahme wäre okay.
DAS TEAM: Ok, die Aufnahme könnt ihr in den nächsten 3 Stunden haben.

Statt ein ganzes Team zum Verzweifeln zu bringen, indem man es eine fast unmögliche Sache rechtzeitig machen lässt, hat ein Entwickler kleine UI-Änderungen gemacht und aufgenommen, wie er sich durchklickt – zack, fertig!
Das Problem für das Team war, das Backend zum Laufen zu bringen – der UI-Teil war tatsächlich sehr einfach.
Kunde und PO waren glücklich: Statt 10 Tage warten, waren es jetzt 3 Stunden.

Ich tappe manchmal selbst in diese Falle, aber ich werde besser:

Dir wird ein Problem geschildert und ohne groß nachzufragen, fängt dein Kopf bereits an, mögliche Lösungen zu produzieren. Manchmal so schnell, dass du nicht mal zuhörst, bis die andere Person das Problem fertig beschrieben hat.

Als Profis müssen wir uns daran erinnern, dass kleine Details das große Ganze verändern können. Die Balance zwischen Überblick über das Problem und dem Erkennen kritischer Details erfordert Zuhören und Fragen. Wir können unseren Job nicht richtig machen, wenn wir das überspringen.

Leute, die ich als „Hacker“ bezeichnen würde, stürzen sich in eine Lösung, ohne ihre Annahmen zu hinterfragen oder zu überprüfen. Mittel- und langfristig passieren dann vermeidbare Fehler. Dafür gibt es wirklich keine Entschuldigung. Stattdessen: Zuhören und Fragen stellen.