Versuche nicht, dich mit Engineering darum zu drücken, den Menschen zuzuhören

• Das zentrale Problem in der Softwarepraxis ist weniger ein Mangel an Gesprächen als ein Mangel an Zuhören; der Versuch, das Problem durch Begriffe wie Framework oder System umzuformulieren und so zu lösen, umgeht das tatsächlich notwendige Zuhören
• Die wörtliche Ausführung der Bitte einer Person ist etwas anderes, als den tatsächlichen Bedarf zu verstehen; der Expertise-Effekt und die technical/non-technical-Dichotomie führen dazu, dass Wissen und Kontext der anderen Seite übersehen werden
• Wenn man annimmt, alle hätten dieselbe Energie, dieselben Fähigkeiten und dieselben finanziellen Mittel, oder Eigenschaften einer einzelnen Person auf eine ganze Gruppe verallgemeinert, erfasst man die je unterschiedlichen Einschränkungen und Entscheidungskriterien nicht richtig
• Menschen und Organisationen verändern sich je nach Zeit, Rolle, Stress und Gruppendynamik; außerdem stimmt das Gesagte nicht immer mit dem tatsächlich Gedachten überein, sodass fixe Anforderungen leicht an der Softwareentwicklung vorbeigehen
• Scheitert das Zuhören, gehen die wertvollsten Einsichten verloren; das führt zu verpassten Umsatzchancen, zum Verlust von Wettbewerbsvorteilen und zu mehr Tech Debt durch sich aufstauende Missverständnisse

---

Kernaussage

• In der Softwarepraxis ist mangelndes Zuhören das größere Kernproblem als fehlende Gespräche zwischen Menschen; der Versuch, es mit Begriffen wie Framework oder System zu fassen und zu lösen, ist eine Art, der eigentlich nötigen Arbeit auszuweichen
• Designer und Product-Verantwortliche versuchen oft, Gespräche mit Menschen in Formulierungen zu übersetzen, die für Engineering leichter akzeptierbar sind; gebraucht wird aber weniger ein besseres System als vielmehr, den Menschen wirklich zuzuhören
• Ausgehend von der Annahme, dass es schwieriger ist, den Menschen zuzuhören, als einfach nur mit ihnen zu reden, werden typische Fallstricke zusammengefasst, die gutes Zuhören in der Praxis behindern

Typische Fallstricke, die gutes Zuhören behindern

• Das zu tun, was gesagt wurde, ist nicht dasselbe wie Zuhören

  • Etwas genau so umzusetzen, wie jemand sagt, dass er es wolle, ist nicht dasselbe wie dem tatsächlichen Bedarf zuzuhören
  • Als bestehende Ansätze zu diesem Thema werden Jobs To Be Done, Outcome Driven Innovation und Empathy Mapping aus dem UX-Bereich erwähnt

• Durch den Expertise-Effekt die eigene Perspektive unterschätzen

  • Wer ein Fachgebiet lange studiert oder praktiziert hat, nimmt leicht an: "Das wird doch selbstverständlich bekannt sein"
  • Selbst wenn die andere Person Expertin oder Experte auf diesem Gebiet ist, kennt sie oder er nicht zwangsläufig dasselbe Wissen — möglicherweise aber anderes Wissen
  • Um richtig zuzuhören, muss man besser verstehen, was die andere Person bereits weiß

• Technical als einheitliche Kategorie behandeln

  • Ein besonders bei Softwareentwicklern verbreiteter Fallstrick: Technical ist keine einzelne Eigenschaft, sondern ein breites Spektrum heterogener Wissensgebiete
  • Wer Menschen entlang der Dichotomie "technical / non-technical" betrachtet, verpasst Einsichten und erhöht die Wahrscheinlichkeit, nicht richtig zuzuhören

• Annehmen, dass alle über dieselben Ressourcen verfügen

  • Fehleinschätzungen entstehen, wenn man davon ausgeht, dass alle dieselbe Energie, dieselben Fähigkeiten und dieselben finanziellen Spielräume haben
  • Selbst Menschen mit vergleichbarer Gesundheit können sich in ihrer Art der Selbstorganisation und in dem, was sie tatsächlich tun können, stark unterscheiden
  • Es gibt Menschen, die stark in Mathematik sind, andere mit anderen Stärken, und Menschen mit wenig Geld oder wenig Spielraum, die daher risikoaverser handeln

• Eigenschaften einer Person auf die ganze Gruppe verallgemeinern

  • Nur weil man eine Person mit einer bestimmten Eigenschaft getroffen hat, darf man nicht annehmen, dass alle anderen genauso sind
  • Als Beispiel wird die Haltung genannt, pauschal zu unterstellen, ältere Menschen verstünden nichts von Computern
  • Ebenso fehlerhaft ist es, alle Frauen auf Bilder aus den eigenen familiären Beziehungen zu reduzieren

• Annehmen, dass Menschen und Organisationen statisch sind

  • Auf der Makroebene verändert sich Persönlichkeit im Lauf der Zeit
  • Auf der Mikroebene unterscheiden sich die Persona im Beruf und das Verhalten zu Hause; auch unter Stress oder unter bestimmten Bedingungen verändert sich das Urteilsvermögen

• Annehmen, dass Gesagtes und Gedachtes dasselbe sind

  • Manche Menschen meinen genau das, was sie sagen, andere nicht
  • Viele glauben von sich, ehrlich zu sprechen, obwohl das in der Realität nicht immer der Fall ist

• Menschen beurteilen

  • Wer jemanden ablehnt oder verächtlich abtut, weil diese Person schlecht dokumentierte Inhalte missverstanden hat, senkt die Chance erheblich, ihr oder ihm wirklich zuzuhören
  • Auch die Haltung, der andere könne nicht richtig arbeiten oder führe sein Leben falsch, blockiert gutes Zuhören

• 80 Menschen nicht als 80 einzelne Personen, sondern als eine Gruppe behandeln

  • B2B hat oft sogar stärkere menschliche Aspekte als B2C; Beziehungen, Dynamiken und Soft Power außerhalb des Organigramms spielen eine Rolle
  • Durch Gruppendynamik entstehen zusätzliche Variablen, die noch komplexer sind als auf der Ebene einzelner Personen

Warum fixe Anforderungen und Software oft nicht zusammenpassen

• Gerade weil sich Menschen und Organisationen verändern, passt fixed project management nicht gut zur Softwareentwicklung
• Selbst wenn Anforderungen zu Beginn festgeschrieben werden, verändern sich die Menschen in der Zwischenzeit; wenn das Ergebnis fertig ist, passt es im besten Fall noch zu dem, was zu Projektbeginn gewünscht wurde
• Zum Zeitpunkt des Releases ist es womöglich schon nicht mehr das, was tatsächlich gewollt ist; außerdem ergänzen Menschen während der Wartezeit jeweils ihre eigenen Erwartungen, sodass die Realität am Ende mit all diesen Erwartungen nicht übereinstimmt

Folgen und Auswirkungen

• Wenn man den Menschen nicht richtig zuhört, verpasst man die wertvollsten Einsichten; das führt zu verpassten Umsatzchancen und zum Verlust von Wettbewerbsvorteilen
• Je mehr Missverständnisse sich ansammeln, desto mehr neue Elemente werden später dem Code hinzugefügt, an dem gemeinsam gearbeitet werden muss; gutes Zuhören hängt daher auch damit zusammen, zumindest einen Teil der Ursachen von Tech Debt zu verringern
• Je eher man die Momente erkennt, in denen man nicht richtig zuhört, desto größer ist die Chance, tatsächlich besser zuzuhören

[GN⁺]

Hacker-News-Kommentare

• Ich wähle meine Worte ziemlich präzise, und wenn ich eine bestimmte Formulierung benutze, dann meine ich genau das auch so. Viele Menschen sprechen meiner Ansicht nach jedoch eher wie ein Tone Poem, kreisen mit greifbaren Wörtern um etwas herum und erwarten, dass man sie über eine gemeinsame Nuance versteht, sodass schon das Interpretieren anstrengend wird. Wenn ich schreibe, wähle ich jedes Wort absichtlich, aber selbst bei der Arbeit wird das fast immer wieder so ausgelegt, als hätte ich mich ungenau ausgedrückt, was ziemlich belastend ist. Vielleicht liege ich irgendwo auf dem Spektrum, diagnostiziert wurde ich aber nie. Vor etwa einem halben Jahr habe ich ein kleines RPC gebaut und dokumentiert, damit ein anderes Team mit einer längeren Aufgabe beginnen konnte. Es war weniger als eine Seite, aber vollständig, exakt und knapp. Mein Manager hat dieses Dokument dann jedoch ohne jede Erklärung durch eine AI geschickt und weitergeleitet, ohne dass ich überhaupt davon wusste. Nicht einmal einen Tag später hagelte es unsinniges Feedback, und als ich mir konkrete Request-Beispiele ansah, stellte ich fest, dass Endpoint-Manipulation stattgefunden hatte. Es war kein Tippfehler, sondern eine komplett erfundene Adresse; im Dokument waren der Endpoint und alle Pflichtparameter falsch, und es wurden sogar Funktionen erfunden, die es gar nicht gab. Normalerweise bin ich eher geduldig, aber ich war selten so wütend wie damals und bin es noch immer. Wenn der Arbeitsmarkt nicht so wäre, wie er ist, hätte ich vermutlich sofort gekündigt. Wenn Menschen Sprache, die sie selbst lesen und interpretieren müssten, an AI delegieren, fühlt sich das für mich an wie der Tod präziser Sprache, und seit Monaten frage ich mich ernsthaft, ob generative AI vielleicht so eine Art Great Filter ist, die unsere Zivilisation zugrunde richtet

  • Diese Sichtweise fühlt sich für mich etwas fremd an. Ich glaube nicht, dass Sprache die Grenzen des Denkens sauber abschneidet und exakt einfängt; Sprache ist ein Werkzeug, um Welt und individuelles Verständnis auszudrücken, daher ist es nur natürlich, ähnliche Konzepte mit unterschiedlichen Worten zu beschreiben. Für die Person, die den Gedanken in Worte übertragen hat, wirkt alles klarer, als es für die zuhörende Person tatsächlich ist. Deshalb kann man die Arbeit der Interpretation nicht einfach leichtnehmen. Wenn man mit der anderen Seite dieser Situation sprechen würde, würden sie am Ende vermutlich etwas sehr Ähnliches sagen: dass auch für sie deine Worte schwer zu interpretieren waren
  • Dieses Setup ist so stark, dass mir sofort ein Roman dazu eingefallen ist. Die Idee, den Great Filter mit generativer AI zu verbinden, ist hervorragend, und das fühlt sich an wie eine Geschichte, die Cory Doctorow sofort schreiben sollte
  • Ich denke, als Erstes sollte man den Manager fragen, warum er das Dokument in eine AI eingegeben hat. Manchmal leidet die Lesbarkeit gerade dann, wenn die Präzision steigt, und je stärker Sprache komprimiert ist, desto höher sind die kognitiven Kosten für den Leser bei jedem einzelnen Wort. Lesen ist der Prozess, das Modell im Kopf des Autors in das Modell des Lesers zu übersetzen, und das geschieht nicht automatisch nur über Wörter, sondern erfordert einen Akt der Interpretation. Wenn etwas zu knapp ist, können Hilfen für den Leser fehlen. Es ist denkbar, dass ein einseitiges Dokument für normale Leser schlicht zu kurz war, um das Verständnis zu stützen, und deshalb ein Umweg wie eine AI-Zusammenfassung gewählt wurde. Für Leser zu schreiben ist etwas völlig anderes als eine präzise Notiz für Leser mit maximalem Kontext; besonders wenn man für eine unbestimmte Menge von Menschen schreibt, braucht es Wiederholung, einfache Beispiele, vertraute Kontexte, kleinteilige Abläufe und manchmal sogar Humor und Hintergrund, um das Verständnis zu erleichtern
  • Ich habe vor Kurzem etwas Ähnliches erlebt. Ich hatte eine vierseitige Spezifikation geschrieben, aber die empfangende Person hat sie nicht gelesen und stattdessen mit einem LLM nur ein paar Bullet-Zusammenfassungen erzeugt; das Ergebnis war ein Vorschlag, der nicht zu den Anforderungen passte. Als ich widersprach, sagte er, das hätte in der ursprünglichen Spezifikation stehen müssen, dabei stand es dort bereits — nur eben nicht in seiner LLM summary. Ich bin nicht jemand, der an jedem einzelnen Wort hängt, aber ich habe nicht das Gefühl, dass sich die Information eines vierseitigen Dokuments vollständig in zehn Bullets unterbringen lässt
  • Für mich ist das eher ein Paradebeispiel für einen speziellen Prompt oder ein Custom-LLM, das so etwas in normie speak übersetzt

• Allein in diesem Kommentarbereich sehe ich schon ironischerweise viele Menschen genau das Problem reproduzieren, auf das der Text hinweist. Ich möchte noch ein paar Dinge ergänzen. Erstens: So viel Wissen und Debatte man auch aufbaut, Menschen nehmen Dinge, die sie nicht annehmen wollen, nicht leicht an. Zweitens: Echtes Zuhören bedeutet, sich geistig und körperlich in einen verletzlichen Zustand zu versetzen. Man hört Dinge, die mit den eigenen Erfahrungen, Überzeugungen und dem eigenen Weltbild kollidieren können, und die Haltung, andere Menschen zu beurteilen, ist oft ein Selbstschutzmechanismus, der gerade deshalb gutes Zuhören verhindert. Drittens: Zuhören heißt oft, nicht sofort zu einer Lösung zu springen, sondern den Schmerz aufzufangen und zu verarbeiten, den die andere Person ausdrückt. Ein Product Manager neigt zum Beispiel leicht dazu, alles sofort in ein neues Feature oder Ticket zu übersetzen, dabei müsste er eigentlich den Use Case hören, den Schmerzpunkt finden und diesen lösen, statt nur den vom Nutzer genannten Funktionsnamen zu verstehen

  • Ich halte es für gefährlich, diese Behauptung vorab als Prämisse zu setzen. Bei den meisten Dingen gibt es Verhandlungsspielraum, und wenn man nur richtig verhandeln kann, lässt sich vieles verändern
  • Gerade Punkt 2 hat sich für mich sehr tief angefühlt. Ich würde das gern einem mir wichtigen Menschen schicken und hoffe, dass er dann auch wirklich zuhört
  • Ich stimme zu, dass Zuhören ein Sich-Verletzlich-Machen ist, denke aber auch, dass ich mir gerne immer Zeit dafür nehmen würde, richtig zuzuhören, wenn nur sichergestellt wäre, dass diese Verletzlichkeit nicht jedes Mal ausgenutzt wird
  • Mich interessiert wirklich, was es praktisch bedeutet, den Schmerz anderer aufzufangen, und wie man von dort auf natürliche Weise zur Definition von Features oder zum Schreiben von Tickets übergeht
  • Für mich beschreibt das exakt das Wesen von Presales Discovery. Das ist weniger Technik als vielmehr beinahe Kunst

• Ich stimme dem Problembewusstsein zu, aber diese Liste las sich für mich etwas wie ein Jammern. Effektive Kommunikation ist fast schon ein Kernproblem der gesamten Menschheit, und dieser Text hatte den Unterton, Entwicklern Vorwürfe zu machen, sie könnten nicht zuhören, was auf mich etwas herablassend wirkte. Das Grundproblem ist, dass Menschen nicht wissen, was sie nicht wissen. Die besten Kommunikatoren sind wie Übersetzer, und Menschen hören erst dann wirklich zu, wenn eine Botschaft in ihrem eigenen Verständnis selbstverständlich wird. Ich glaube nicht, dass hier einfach alles kollabiert, weil sich alle wie Kleinkinder mit zugehaltenen Ohren verhalten. Deshalb suchen wir nach Systemen und Engineering, damit Systeme von sich aus Lückenerkennung und Übersetzungs-Frameworks enthalten. Auch wenn das nie perfekt ist, halte ich es für wichtiger, Umgebungen auf Team-, Firmen- und Systemebene zu verändern, als Einzelne einfach zu ermahnen, besser zuzuhören

  • Das erinnert mich an einen älteren Mann, der einmal sagte, man solle das als ein Noisy System betrachten. Das Signal ist immer schwächer als das Rauschen, und darin bewegen sich begrenzte Menschen. Jeder hat Grenzen dessen, was er leisten kann, und auch die Geschwindigkeit, mit der sich das Denkmodell eines Menschen aktualisiert, ist begrenzt; die Grenzen von Gruppen sind noch enger als die von Einzelnen. Gerade große Organisationen können Jahrzehnte brauchen, um ihre Modelle zu ändern, selbst wenn sich die Realität vollständig gewandelt hat. Darum scheint es mir wichtig, diese Beschränkungen anzuerkennen und dann zu entscheiden, wofür ich meine Zeit und Energie einsetzen will
  • Für mich wirkte dieser Text einfach wie ein gewöhnlicher Self-Help-Artikel, und mangels Beispielen sogar noch etwas enttäuschender als das
  • Ich bin Entwickler, habe aber auch etliche andere Dinge gemacht, deshalb weiß ich gut, wie wichtig Kommunikation ist und wie oft Entwickler darin schwach sind. Ein häufiges Muster ist, dass Entwickler sich wie schlechte Ärzte verhalten: Sie tun so, als würden sie zuhören, stellen aber viel zu früh eine Diagnose. Sie erklären, sie wüssten bereits, was gebraucht wird, noch bevor die andere Seite alles Wichtige gesagt hat. In Software ist oft wichtiger als das, was der Kunde will, das, was der Kunde tatsächlich braucht. Es gibt nur wenige Kunden, die wirklich wissen, wie man ein Problem elegant mit Software löst; meistens kommt jemand mit einer Idee, der sich über Software nie besonders tief Gedanken gemacht hat. Das heißt nicht, dass die Idee wertlos ist, sondern nur, dass Anforderungsanalyse und Lösungsfindung noch nicht abgeschlossen sind. Vollendet wird das durch Beobachtung, Erklärung und Gespräch. Meiner Erfahrung nach hören viele Entwickler wirklich nicht gut zu, und bei Ärzten oder anderen technischen Berufen ist es ähnlich. Sie wollen schnell kompetent wirken, indem sie zeigen, wie viel sie wissen, und ordnen die andere Person einem Problemtyp zu, den sie schon oft gesehen haben. Manchmal funktioniert das, aber irgendwann kommt zwangsläufig der Moment, in dem es nicht mehr funktioniert
  • Im Scherz könnte man sagen: Wenn Kommunikation wirklich das zentrale Problem der Menschheit wäre, müsste doch in der Bibel irgendwo wenigstens ein Vers dazu stehen

• Ich denke, man sollte nicht zu schnell annehmen, dass das, was Menschen sagen, identisch mit dem ist, was sie tatsächlich denken. Umgekehrt überschätzen Sprecher leicht, inwieweit Zuhörer beim Verstehen dasselbe Objekt vor Augen haben. Deshalb ist es wichtig, Dinge so detailliert und unmissverständlich wie möglich aufzuschreiben. Wenn in einem Meeting jemand versucht, ein Ziel mit einem Bullet aus sechs Wörtern zu erklären, dann ist das für mich praktisch ein Signal dafür, dass niemand das Ziel versteht. Wenn jemand ohne ein einseitiges Dokument in ein Meeting kommt, hat diese Person es selbst noch nicht ausreichend verstanden, und wenn mein Fortschritt vom Ergebnis abhängt, würde ich ein klareres Bild verlangen

  • Ich muss Kollegen oft mehrmals am Tag about what? fragen. Häufig muss ich vier- oder fünfmal nachhaken, bis sie konkret sagen, um welchen Kunden, welches Feature oder welches Produkt es geht. Selbst dann, wenn ich eigentlich genau weiß, wovon sie sprechen, muss ich das manchmal trotzdem tun
  • Ich finde, auch die Berechtigung von Anforderungen muss immer geprüft werden. Der einfachste Weg, Unklarheit über den tatsächlichen Bedarf zu verbergen, sind überzogene Anforderungen. Meiner Erfahrung nach ist es völlig üblich, das Zehnfache des Nötigen zu verlangen, und ich habe sogar schon gehört, man müsse sich für die maximale Ausstattung entscheiden, damit man sich um die Zukunft keine Sorgen machen müsse, obwohl zwischen zwei Optionen ein Kostenunterschied um den Faktor 500 lag
  • Detailliert und unmissverständlich zu schreiben mag eine Voraussetzung für tiefes gegenseitiges Verständnis sein, aber ich habe in den letzten Jahren den Eindruck gewonnen, dass Menschen kaum noch mehr als den ersten Satz einer Nachricht, eines Tickets oder einer E-Mail lesen. Deshalb muss man Informationen oft in sehr kleine Stücke zerlegen und portionsweise verabreichen, und das hasse ich ziemlich
  • Ich habe das in der Realität viel zu oft erlebt. Wenn ich sage, etwas sei nicht produktionsreif, dann versteht das Management darunter oft, man könne es dem Kunden als Acceptance Testing verkaufen
  • Plötzlich musste ich hier an den sowjetischen Film Kin-dza-dza denken. Darin beschreibt eine Figur eine andere Person sinngemäß so, dass sie etwas sagt, das sie nicht denkt, und etwas denkt, das sie nicht denkt — und das passt erstaunlich gut zu der Verwirrung in dieser Unterhaltung

• Ich arbeite vor allem in kundenbezogenen Rollen und halte es für die wichtigste Aufgabe, die Erwartungen des Kunden mit der Realität in Einklang zu bringen. Wenn man sauber abstimmt, was möglich ist, wie lange es dauert, was es kostet und wann es in Production gehen kann, dann ist der Kunde am Ende glücklich, selbst wenn ihm Startdatum oder Kosten nicht gefallen. Gerade die Kosten sind oft deal-breaker, deshalb gleiche ich grobe Größenordnungen früh ab. Man kann noch so gut zuhören und empathisch sein — die Realität bleibt die Realität, und der Kunde muss diese Beschränkungen ebenfalls anerkennen oder akzeptieren. Ein Kundenansprechpartner, der bei allem nur zustimmend nickt, macht den Kunden am Ende unglücklicher; eine gute Schnittstellenperson hört sowohl dem Kunden als auch dem internen Team zu und sorgt dafür, dass das tatsächlich Lieferbare mit den Erwartungen des Kunden übereinstimmt

• Vielleicht verbringen wir mit Kommunikation auch einfach zu viel Zeit. Wenn zu viel Zeit vorgesehen ist, sinkt die Konzentration, und man schiebt Dinge leicht auf nach dem Motto, dass man sie beim nächsten Mal ja noch klarstellen kann. Wenn man unnötige Meetings reduziert und nur minimum viable time ansetzt, würden meiner Meinung nach alle sogar besser zuhören

  • Dieses Phänomen habe ich in der Praxis bisher kaum gesehen. Die meisten Meetings sind in Wahrheit keine Kommunikation, sondern eher Anweisungen und Mitteilungen, und die Fähigkeit zuzuhören ist eine eigene Kompetenz, die nichts mit der Länge eines Meetings zu tun hat. Zuhören ist etwas, das man durch Übung verfeinert; es entsteht nicht automatisch dadurch, dass man Meetings kürzt
  • Ich war in viel zu vielen Meetings, deren Ergebnis nur darin bestand, das nächste Meeting anzusetzen. Ich habe sogar Muster gesehen, in denen immer mehr Leute hineingezogen wurden, Teams mit vielen Leuten Entscheidungen zu sich zogen, um politischen Einfluss zu gewinnen, und das dann wiederum zu noch mehr unnötigen Einstellungen und Meetings führte. Der Ausweg liegt meiner Meinung nach nicht darin, die Kommunikation zu erhöhen, sondern in einer einheitlichen Vision und darin, Abhängigkeiten zwischen Teams zu verringern, damit jedes Team unabhängig arbeiten kann
  • In meiner Arbeit an Softwarearchitektur habe ich oft gesehen, dass ein einziges Diagramm mehr als 60 Minuten Diskussion und mehrere Meetings spart. Es musste nicht einmal besonders gut gezeichnet sein; ein faktengetreues Bild reichte aus, und bei komplexer oder nicht offensichtlicher Logik war ein Diagramm viel klarer als Worte. In Remote-Meetings kann man es schnell mit Ai agent und Mermaid.js zeichnen, und vor Ort reichen Whiteboard oder Papier und Stift völlig aus
  • Zeit auf Kommunikation zu verwenden und tatsächlich zu kommunizieren sind zwei völlig verschiedene Dinge
  • Ich glaube eher, dass wir nicht zu viel Zeit mit echter Kommunikation verbringen, sondern zu viel Zeit damit, so zu tun, als würden wir kommunizieren. Es werden Meetings ohne echtes Quorum erzwungen, sie laufen ohne Voraussetzungen ab, und dann wirft jemand ein gedankenloses AI slop document in den Raum und wenn andere es nicht verstehen, werden am Ende eher die Leser so hingestellt, als seien sie dumm. Die ersten 30 Minuten eines Meetings fühlen sich dann wie Gaslighting an, und erst in den letzten 10 Minuten gesteht man sich ein, dass alles Zeitverschwendung war, und versucht, den Schaden zu begrenzen. Eigentlich sollten Meetings dazu dienen, gut durchdachte Ideen und eine kohärente Richtung zu teilen und zu klaren Aussagen sinnvolles Feedback zu erhalten, aber in Wirklichkeit geht es oft darum, dass jemand versucht, seine Arbeit nach Art einer Stone Soup in ein Gruppenprojekt zu verwandeln. Wenn man früh fragt, was das Ziel dieses Meetings ist, merkt man oft schnell, dass der Organisator eigentlich nur eine Art Lerngruppe eröffnet hat. Manager mit hohem Überblick glauben leicht, dass Arbeit in Meetings geschieht, sehen aber die Denk- und Vorarbeit nicht, die gute Meetings überhaupt erst möglich macht. Wenn Kommunikation forciert wird, bevor Gedanken klar sind, wird ein Meeting einfach nur zu Rauschen. Die stärkste Gegenreaktion ist in solchen Situationen die Haltung Lass es uns jetzt gemeinsam herausfinden, und ich bestehe dann auf der Abhängigkeitsreihenfolge Why, What, How, Who, When. Wenn die vorderen Punkte leer sind, geht es nicht weiter nach hinten, und egal ob Praktikant oder VP, ein bequemes Herumlavieren wird nicht akzeptiert. Wenn ein Team sich selbst dann nicht verändert, nachdem man das Problem zerlegt und direkt vor Ort durchdacht hat, dann ist es am Ende wohl richtig, sich ein anderes Team zu suchen

• Ich finde, der Hinweis des Textes auf den specialism effect wird ziemlich unterschätzt. Auch ich war schon frustriert darüber, dass Nutzer etwas nicht verstanden, das ich über Jahre hinweg verinnerlicht habe, bis mir klar wurde, dass das Problem nicht mangelndes Wissen ist, sondern dass sich ihr Wissen an einem anderen Ort angesammelt hat. Sie haben in derselben Zeit eben etwas völlig anderes ebenso tief gelernt

• Ich stimme nicht vollständig zu, dass die Hauptursache einfach darin liegt, dass Menschen nicht sprechen und nicht zuhören. Um eine Cartoon-Metapher zu bemühen: Viele wollten von Anfang an eher das Durchschneiden des Bandes als die Straße selbst, und genau das haben sie letztlich bekommen — deshalb passiert so etwas

• Ich habe es ziemlich komisch erlebt, dass Menschen sagen, sie meinten genau, was sie sagen, es in Wirklichkeit aber gar nicht tun. Ich habe fast wortgleich umformuliert, was die andere Person gesagt hatte, um mein Verständnis zu prüfen, und die Reaktion war eine heftige Zurückweisung: Das sei absolut nicht das, was sie habe sagen wollen

• Für mich liegt ein Kern vieler Probleme in Gesprächen mit nichttechnischen Rollen darin, dass sie einfach sagen, man solle X hinzufügen und Y ändern, ohne einen Kostenkontext zu haben. Natürlich kann man fast alles umsetzen, was verlangt wird, aber jede Anfrage hat Kosten, und wenn man das nicht versteht, ist das schwer mit einem verlässlich ausgelieferten Produkt vereinbar

  • Ich finde, gerade diese Reaktion zeigt den Kern des Textes perfekt. Es ist nicht so, dass sie die Kosten nicht verstehen; sie haben nur einen anderen Kontext, und die Aufgabe der technischen Seite besteht nicht darin zu erwarten, dass die anderen die Kosten schon kennen, sondern ihnen zu helfen, informierte Trade-offs zu treffen
  • Ich denke, in solchen Situationen sind die Whys wichtig — also die Frage, warum etwas gebraucht wird. Wenn man den nichttechnischen Prozess versteht, stellt sich vielleicht heraus, dass der Zusatz oder die Änderung gar nicht nötig ist. Ich stimme auch zu, dass man sonst am Ende bei einem Monster wie einem Turing-complete Excel/Email clone landet
  • Ich denke, in solchen Situationen besteht eine Asymmetrie: Nichttechnische Leute kennen die Kosten nicht, technische Leute kennen den Nutzen nicht. Am Ende braucht es Kommunikation auf beiden Seiten, um einen vernünftigen Punkt zwischen Kosten und Nutzen zu finden
  • Für mich ist das ein ziemlich lösbares Problem. Man antwortet bei jeder Anfrage einfach mit einer Schätzung, wie viele Monate sie dauert und wie viele Dollar sie kostet
  • Ich finde aber auch, dass man anerkennen muss, dass AI inzwischen das code thing übernimmt und dadurch die Implementierungskosten tatsächlich deutlich gesunken sind. Ob man das mag oder nicht — diese Veränderung ist real