Warum traut sich niemand, mal die wirklich dummen Fragen zu stellen?
Fragst du dich manchmal auch, warum im Daily plötzlich Funkstille herrscht, statt gemeinsam Probleme zu lösen? Stell dir vor, die spannendsten Innovationen und die besten Teamentscheidungen gehen oft auf eine simple Frage zurück – oder auf den Mut, überhaupt zu fragen.
In dieser Episode vom Engineering Kiosk nehmen Andy und Wolfgang dich mit in die Welt der Fragetechniken. Es geht nicht um Altklugheit, sondern um echte Neugier – und warum „Fragen statt Behaupten“ viel mehr mit Tech-Kultur, Open Source, guter Führung und deinem eigenen Networking zu tun hat, als du vielleicht denkst. Du erfährst, warum Consultants mit dem Fragenstellen beginnen, wie Karriere-Booster für Juniors aussehen, was Suggestivfragen und Five-Whys-Analysen bringen, wie du selbst innerhalb eines SRE-Incident-Reports Fehler aufdeckst – und welche Rolle Offenheit, Teamkultur und manchmal schlichtes Durchatmen dabei spielen.
Wir sprechen offen darüber, wann Fragen einfach nur nerven, warum Abkürzungen für maximale Verwirrung sorgen können, und verraten natürlich unsere persönliche Lieblingsfrage.
Bonus: Wer Fragen stellt, bleibt frei nach Sesamstraße: niemals dumm – sondern macht’s allen einfacher.
Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Das schnelle Feedback zur Episode:
Anregungen, Gedanken, Themen und Wünsche
Dein Feedback zählt! Erreiche uns über einen der folgenden Kanäle …
- EngKiosk Community: https://engineeringkiosk.dev/join-discord
- LinkedIn: https://www.linkedin.com/company/engineering-kiosk/
- Email: stehtisch@engineeringkiosk.dev
- Mastodon: https://podcasts.social/@engkiosk
- Bluesky: https://bsky.app/profile/engineeringkiosk.bsky.social
- Instagram: https://www.instagram.com/engineeringkiosk/
Unterstütze den Engineering Kiosk
Wenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer
- Buy us a coffee: https://engineeringkiosk.dev/kaffee
Links
- Matthias Endler - Asking Better Questions: https://endler.dev/2024/asking-better-questions/
- 101 Questions to Ask in One on Ones: https://jasonevanish.com/2014/05/29/101-questions-to-ask-in-1-on-1s/
- Engineering Kiosk Episode #127 Imposter-Syndrom & Peter-Prinzip mit Dr. Fanny Jimenez: https://engineeringkiosk.dev/podcast/episode/127-imposter-syndrom-peter-prinzip-mit-dr-fanny-jimenez/
- Walt-Disney-Methode: https://www.me-company.de/magazin/walt-disney-methode/
- Never Mind – Psychologie in 15 Minuten - Kommunikation in der Beziehung: Wenn der eine zu viel redet und der andere zu wenig: https://pod.link/1607293594/episode/1f4d5bb98b634bfb274849ad7cca70a3
- Sokratischer Dialog: https://www.landsiedel-seminare.de/coaching-welt/wissen/coaching-tools/sokratischer-dialog.html
Sprungmarken
Hosts
- Wolfgang Gassler (https://gassler.dev)
- Andy Grunwald (https://andygrunwald.com/)
Community
Diskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord
Transkript
Andy Grunwald (00:00:03 - 00:01:49)
Warum? Warum? Warum? Oder wann sind wir endlich da? Viele Eltern kommt dies? Oder so ähnlich bekannt. Neugierige Kinder, die einfach alles wissen wollen und ganz unverblümt fragen sie einfach. Und das ist das Thema in dieser Episode. Herzlich willkommen zum Engineering Kiosk. Heute sprechen wir über Fragen stellen bzw. Die Komplexität von Fragen stellen bzw. Warum wir mehr fragen sollten. Klingt im ersten Augenblick etwas philosophisch, aber der Wolfgang ist fest davon überzeugt, dass er primär für das Stellen von Fragen bezahlt wird. Deswegen schauen wir uns das Thema mal ganz genau an. Wir schauen uns an, warum wir eigentlich so wenig Fragen wie das Stellen von Fragen die tech Kultur beeinflusst. Warum man sich oft nicht traut, dumme Fragen zu stellen. In welchem Kontext das warum Beispiel von gerade angebracht ist. Wie Fragen als Führungsinstrument genutzt werden können, welche Fragentypen es eigentlich gibt, aber auch, wann Fragen einfach nur auf die Nerven gehen. Zum Ende hin geht es dann nochmal um die beste Frage, die uns je gestellt wurde. Also mal eine Meta Episode zum Nachdenken. Viel Spaß, los geht's. Der Engineering Kiosk ist ja schon ein seriöser Podcast. Wir behandeln ja schon ernste Themen und wir versuchen auch echt viel Wissen zu vermitteln und Evergreen Folgen zu produzieren. Also wir sind ja jetzt nicht irgendwie ein Comedian, der jetzt hier so einen Laber Podcast macht. Aber ich denke, wir sollten alle mal ein bisschen weniger ernst sein. Deswegen habe ich drei Granaten Witz mitgebracht, Wolfgang, die wir diese Episode einmal starten, um einmal so ein bisschen den Tag aufzulockern. So einfach die nächste halbe Stunde, dreiviertelstunde, sechzig Minuten mal so ein bisschen lockerer zu starten. Bist du bereit?
Andy Grunwald (00:01:52 - 00:02:01)
Wo geht ein Programmierer morgens hin? Auf die Arbeit. Okay, du verziehst dein Gesicht, vielleicht kommst du noch nicht drauf, aber vielleicht macht.
Andy Grunwald (00:02:05 - 00:02:18)
Der nächste Witz kommt so ein bisschen in die ein Programmierer geht zum Metzger und kauft sich ein Kilo Rinderhack. Eine Stunde später kommt er wieder und meint, es fehlen noch vier und zwanzig Gramm. Okay, Wolfgang ist auch nicht amused, aber.
Andy Grunwald (00:02:22 - 00:02:27)
Vielleicht kommst du beim dritten Witz drauf. Der letzte Wunsch eines Programmierers bitte ein Bit.
Wolfi Gassler (00:02:27 - 00:02:37)
Oh, das verstehe ich. Aber da muss man ja. Das versteht in Österreich ja niemand. Bit normal. Der ist gut. Das verstehe ich. Mit dem Bier, oder? Verstehe ich es überhaupt richtig?
Andy Grunwald (00:02:41 - 00:02:51)
Ja, ja, ganz genau. Aber ich meine, die anderen Witze mit dem Metzger, der ging auch ein Kilo Rinderhack kommt noch eine Stunde später, es fehlen noch vier und zwanzig Gramm. KB, ein tausend, vier und zwanzig und so.
Andy Grunwald (00:03:02 - 00:03:12)
Vielleicht liegt es auch an meiner Aussprache, bin ich ja auch ehrlich. Aber deswegen, da wir jetzt ein bisschen lockerer sind und du wenigstens ein Grinsen im Gesicht hast, bitte Wolfgang, leg mit dieser Podcast Episode los.
Wolfi Gassler (00:03:12 - 00:03:35)
Es hat jetzt eigentlich schon gezeigt, warum du eigentlich dieses Thema nicht so cool findest, das wir heute besprechen, weil du bist ja jemand, der gerne Sachen von sich gibt und weniger Fragen stellt oder mal leise ist. Deswegen hast du ja gleich losgestartet mit so ganz vielen Witzen. Und darum werden wir heute mal eine harte Episode für dich machen, weil es geht um Fragen stellen und nicht um immer nur Sachen ausplaudern.
Andy Grunwald (00:03:35 - 00:03:43)
Wir nehmen hier gerade zusammen einen Podcast auf. Wenn ich immer leise wäre und nicht das Bedürfnis hätte, etwas von mir zu geben, wäre dieses Format, glaube ich, das falsche.
Wolfi Gassler (00:03:43 - 00:04:54)
Ja, da sind wir vielleicht in einem Boot. Vielleicht ist drum das Thema auch für uns alle ganz wichtig. Aber wie ich auf das Thema eigentlich gekommen bin, ist, dass ich vor einiger Zeit einen Blogpost gelesen habe von einem Kollegen von uns, von Matthias Endler, den wir auch schon im Podcast mal hatten, der einen Blogbeitrag geschrieben hat, wo es ums richtige Fragen stellen und so weiter gegangen ist. Und was er eigentlich in der Einleitung erwähnt hat, war für mich so eine coole Perspektive, die ich bisher noch nie hatte, weil er hat gesagt, dass ganz viele Jobs eigentlich bezahlt werden fürs Fragenstellen. Das heißt jetzt nicht nur ganz klassisch Consultants, die von außen kommen, aber auch ganz normale Engineers oder Entwickler innen. Du stellst dir den ganzen Tag Fragen, du schaust, dass du an die richtigen Informationen kommst, damit du am Ende coden kannst. Also ein ganz großer Anteil an deiner Arbeit ist ja Fragen stellen. Und wenn man Product Owner ist, stellt man natürlich auch extrem viele Fragen. Wenn man Engineering Manager ist oder in einer Manager Position ist, dann würde ich überhaupt sagen, ist neunzig Prozent der Arbeit eigentlich die richtigen Fragen stellen. Und darum habe ich mir gedacht, wäre es eigentlich gut, mal sich diesem Thema zu widmen und da genauer reinzuschauen, wie man eigentlich so Fragen nutzen kann, wie man die richtigen Fragen stellt, um dann am Ende einen besseren Job zu machen.
Andy Grunwald (00:04:54 - 00:05:04)
Ich weiß jetzt nicht, ob ich ganz mit der Aussage mitgehen würde, dass ich fürs Fragenstellen bezahlt werde, denn ich als Softwareentwickler oder als Engineering Manager werde primär dafür bezahlt, Probleme zu lösen.
Andy Grunwald (00:05:11 - 00:05:23)
Viele Probleme werden mit Code gelöst. Deswegen sind wir Softwareentwickler und Softwareentwickler. Aber ja, Fragen ist ja ein Element davon, wie ich dann zur Problemlösung komme. Aber auf der anderen Seite Kaffee trinken ja auch deswegen.
Wolfi Gassler (00:05:23 - 00:05:33)
Ja, dafür wird man ja auch bezahlt. Wir sind ja da auch immer bezahlt worden. Wenn du in Managerposition bist, wirst du fürs Kaffeetrinken bezahlt. Ist doch so, oder? Oder habe ich das falsch verstanden damals?
Andy Grunwald (00:05:33 - 00:06:03)
Ne, das stimmt schon. Socializing und Kultur, das stimmt natürlich schon. Man muss aber natürlich auch sagen, dass manche Leute einen höheren Frageanteil in ihrer Arbeit haben als andere. Du hast jetzt gerade einen Berater oder eine Beraterin mit einer Softwareentwicklerin in einen Pott geschmissen. Also dass jemand, der von extern reinkommt, prinzipiell mehr Fragen stellen muss, um den Kontext zu verstehen, als jemand, der bereits intern ist. Das würde ich ja mal fast sagen. Ist ja irgendwie logisch, oder? Also deswegen bin ich mir nicht sicher, ob der Vergleich fair ist.
Wolfi Gassler (00:06:03 - 00:06:14)
Wobei ja üblicherweise, wenn man Consultants holt, dann holt man ja die, um Antworten zu bekommen. Das heißt ja immer, oder ich suche nach Antworten, ich suche nach Problemlösungen, ich hole mir einen Consultant. Warum stellt der jetzt da die dummen Fragen?
Andy Grunwald (00:06:14 - 00:06:25)
So die Theorie. In der Praxis habe ich öfters gehört, dass die Führungsebene Consultants reinholt, um das Risiko abwälzen zu können. So nach dem Motto ja, aber das haben ja die Consultants gesagt und wir haben es nur ausgeführt.
Wolfi Gassler (00:06:25 - 00:06:36)
Deswegen bin ich ja gar nicht schuld, internen Leute zu überzeugen. Das ist ja auch gern, wir haben eine Idee, schaffen es das aber nicht intern irgendwie richtig zu kommunizieren. Jetzt holen wir einen Consultant, weil wenn der das von außen sagt, dann ist es anerkannter in der Firma.
Andy Grunwald (00:06:36 - 00:07:02)
Ja, oder andersrum, dass die internen Leute was ins Management sagen, das Management es nicht glaubt, die dann einen Consultant holen und der Consultant da genau dasselbe sagt. Und dann fragt sich jeder interne warum brauchte das einen Berater oder eine Beraterin, um das zu sagen? Also das gibt es ja auch. Und ich muss zugeben, das habe ich bis heute nicht verstanden, warum das so ist. Aber ich weiß nicht, ob diese Episode mir da jetzt endlich mal eine Antwort gibt.
Wolfi Gassler (00:07:02 - 00:07:05)
War das jetzt eine Frage von dir? Ob ich dir das beantworten kann?
Andy Grunwald (00:07:05 - 00:07:18)
Weiß ich gerade selbst nicht. Aber passend zur Episode kann man jetzt gehört zum richtigen Fragenstellen auch die Tonlage so wie ich sie gerade versaut habe eigentlich? Weil wir waren uns beide nicht sicher, ob das jetzt eine Frage war.
Wolfi Gassler (00:07:18 - 00:07:39)
Ja, da sind wir dann glaube ich schon bei einem Typ der Fragen, der suggestiv frage, wenn es eigentlich gar keine Frage ist, sondern eine Aussage oder du eigentlich irgendwas injecten willst und weniger eine echte Frage stellst, was ja auch oft eigentlich ein großes Problem ist, dass man so irgendwas als Frage framed, aber ganz was anderes eigentlich damit sagen will und gar keine Frage stellt.
Andy Grunwald (00:07:39 - 00:07:51)
Warum machen wir diese Episode? Hast du das Gefühl, dass du in einer aktuellen Beraterfunktion, dass die Leute, mit denen zusammenarbeitest, dass die zu wenig Fragen stellen oder dass die Leute, mit denen du zusammengearbeitet hast, als du Engineering Manager warst, zu wenig gefragt haben?
Wolfi Gassler (00:07:51 - 00:09:39)
Ja, ich würde ja sowieso die steile these aufstellen, dass wenn die Welt mehr Fragen stellt, es eine bessere Welt wäre. Und es geht dann natürlich immer weitere Stufen nach unten, bis man dann auch bei irgendwelchen Engineering Managern oder auch normalen Engineers ankommt. Weil was ich ja schon oft beobachte, ist, dass ziemlich schnell geschossen wird. Also du hast irgendwo ein Problem, sofort eine Antwort, du springst rein, programmierst, hast eine Lösung oder du hast irgendwo einen Konflikt, Engineering Manager springt rein, ah, ist eh klar, der macht immer so diese Probleme, zack, Lösung, bam, ohne irgendwie mal Fragen zu stellen und schnell Lösungen zu finden. Und das wird ja auch ganz oft im Consultant Umfeld erwartet, dass du einfach dort bist und schnell schießt und schnell eine Lösung herankern kannst, ohne da irgendwie lang zu überlegen. Und wenn man mehr in diesen Prozess Zeit investiert, dass du eine bessere Lösung am Ende hast. Das ist glaube ich, gut investierte Zeit. Und da die Fragen zu stellen, also mehr Zeit zu investieren ins Frage stellen, das bringt dir glaube ich, auf ganz, ganz viele Ebenen was. Und nicht nur als Engineering Manager, Consultant oder sonst was, sondern vielleicht auch als Newcomer in der Firma. Wenn du als Newcomer in der Firma viele, viele Fragen stellst, kannst du glaube ich, deine Karriere wesentlich schneller vorantreiben, weil du dann den Überblick bekommst und du bist in dieser frischen Position als Newcomer in der Firma, dass du die Fragen auch stellen darfst. Weil es ist ein klassisches Problem, dass man sich dann irgendwie schlecht fühlt, wenn man eine Frage stellt, weil man irgendwie das Wissen nicht hat. Man ist ja vielleicht gerade umso weiter oben. Übrigens umso schlimmer das Gefühl, glaube ich, du bist angestellt worden als Spezialist oder auch als Consultant und jetzt stellst du die Fragen, darfst du überhaupt eine Frage stellen? Und das hast du als Junior ja noch weniger. Und darum kannst du da wirklich alle mit Fragen löchern und das Wissen aufsaugen.
Andy Grunwald (00:09:39 - 00:11:03)
Ich glaube, du hast jetzt ganz viele Themen miteinander vermixt. Auf der einen Seite sagst du, Berater werden geholt und von denen wird erwartet, dass sie dann relativ schnell Lösungen haben. Und ich kann jetzt mal meine Sichtweise nennen, warum Berater zum Beispiel geholt werden, weil ich bin ja kein Berater. Auf der einen Seite haben Berater natürlich den Incentive, ihren Vertrag in die Länge zu ziehen, um mehr Fragen zu stellen, weil sie natürlich dann mehr entlohnt werden, zumindest wenn der Vertrag zeitbasiert ist und nicht value basiert, also wertschöpfungsbasiert, also projektbasiert. Das ist die eine Geschichte. Also sie haben natürlich Incentive, mehr Informationen zu holen, nicht nur für den einen Job, natürlich auch für alle zukünftigen Jobs in anderen Firmen, weil kann man oh ja, diese Firma macht das so. Und die zweite Thematik, warum Berater geholt werden, ist natürlich oft, weil sie ein Playbook haben. Berater sind in der Regel nicht an eine Firma gebunden, sondern an drei, vier, fünf, sechs Firmen, wo sie gegebenenfalls ähnliche Probleme sehen, wo sie gegebenenfalls Synergien entwickeln können, wo sie dann gegebenenfalls sogenannte Playbooks entwickeln können, wie das zum Beispiel Ernst Young, Deloitte und so weiter und so fort, die großen. Deswegen ist es, glaube ich, gar nicht so unfair zu sagen, dass für Berater relativ schnell, ich sag mal, Action erwartet wird, dass sie rangehen. Natürlich ist der Kontext wichtig, aber in der Regel wird natürlich von Beratern erwartet, du hast das Problem schon mal gesehen, okay, weiter geht's hier, jetzt lösen wir das.
Wolfi Gassler (00:11:03 - 00:12:44)
Ja, ich würde gar nicht sagen, dass sich das nur auf Berater bezieht. Wenn du einen erfahrenen Senior, eine Entwicklerin einstellst, dann erwartest du dir das ja auch. Die Person hat es schon gesehen, die kennt die Frameworks, die weiß, wie Kubernetes funktioniert und kann jetzt Kubernetes super schnell an den Start bringen. Das erwartest du dir ja auch. Aber auch da ist wieder die Gefahr, du hast ein Tool, du kennst dich gut aus, du hast Erfahrung, aber du musst es in den neuen Kontext mit reinbringen. Und ich glaube, auch da macht man oft den Fehler, und das sieht man ja bei Leuten, die neu in einer Firma reinkommen, die dann immer erzählen, bei meiner Firma XY, also die Firma davor, haben wir das immer so gemacht. Und ich finde, das ist das Schlimmste, was man immer so hören kann, wenn immer alles ja, in der Firma XY haben wir das so gemacht, bei Google haben wir das so gemacht, bei Google haben wir das so gemacht, das sollten wir so machen, weil bei Google haben wir das so gemacht. Und da sieht man ja schon, dass der Kontext komplett ausgeblendet wird, dass da eben keine Fragen gestellt werden. Was haben wir eigentlich für ein Problem? Was wollen wir lösen, was sind die konkreten Probleme? Und ist da jetzt wirklich dieses Lösungsmodell, was Google verwendet hat oder Die alte Firma XY, ist es jetzt wirklich das Richtige? Stülpt man da wirklich Kubernetes jetzt einfach drüber? Ist es die beste Wahl? Oder ist ein Dumas Docker Compose auch leicht ausreichend? Zum Beispiel? Also ich glaube, da sind Fragen super wichtig. Und umso mehr Erfahrung hat, umso erfahrener sollte man auch sein, dass man eben genau diese Fragen auch stellt. Und das betrifft nicht nur Consultant, sondern ganz allgemein, glaube ich, Leute, die Erfahrung von woanders mitbringen. Und das ist ja auch gut. Darum stellt mir diese Leute an, egal ob ein Consultant oder eine erfahrene Entwicklerin. Aber dann das in den richtigen Kontext zu bringen, da braucht es wieder die die fragen, um den Kontext zu verstehen.
Andy Grunwald (00:12:44 - 00:13:00)
Verstehe ich. Was ich nicht immer ganz verstehe, ist, warum dieses Ja, das haben wir schon immer so gemacht, immer im negativen Kontext gesehen wird. Denn du hast natürlich gerade ein extrem erwähnt. Ja, bei Google haben wir das so gemacht. Und ja, nicht jeder ist Google. Also eigentlich keiner ist Google, außer Google.
Wolfi Gassler (00:13:00 - 00:13:08)
Also es muss nicht Google sein, kann eine beliebige Firma sein. Aber ich habe das oft erlebt, dass das Leute so wirklich in jedem Satz sagen, das haben wir dort so gemacht, haben wir dazu gemacht.
Andy Grunwald (00:13:08 - 00:14:28)
Ja, das ist fair. Aber jetzt kommt's. Was ist denn, wenn es einfach funktioniert hat? Und was ist denn, wenn das in der neuen Firma auch funktioniert? Nur weil es so gemacht wurde und schon immer so gemacht wurde, heißt es nicht, dass es automatisch schlecht ist. Nehmen wir mal eine Spieleschmiede, zwanzig Mitarbeiter, selbes Segment. Und ein Softwareentwickler wechselt zum Konkurrenten, ebenfalls fünf und zwanzig Entwickler, Spieleschmiede, beide spezialisiert auf Mobile. Das bedeutet, selbe Industrie, selbes Segment, in der Regel selbe Problemstellungen. Und wenn man dann sagt, hey, pass mal auf, da drüben haben wir das so gemacht. Ja, wo ist denn das Problem? Wenn es doch da drüben funktioniert hat, dann ist das ja gar nicht so falsch. Natürlich, wenn du diese extreme miteinander vergleichst, Google mit dieser zwanzig Personen spiele Schmiede, ja, das ist vielleicht ein bisschen mit Kanonen auf Spatzen geschossen, das stimmt. Aber was ist denn einfach, wenn es funktioniert und wenn es einfach gut ist? Und ich meine, im Endeffekt zeigt das ja auch, muss man auch sagen, Bias for action. Und weil du kannst nämlich auch ganz einfach mit deinem Approach in so eine Analyse Paralyse gehen. Du stellst Fragen, analysierst drei Wochen, fünf Wochen für einen Task, der vielleicht in zwei Tagen einfach durch ist. Ich will nicht sagen, du sollst keine Fragen stellen, aber es gibt eine Zeit, da ist einfach mal genug gefragt. Und da können wir einfach mal die Hände dreckig machen.
Wolfi Gassler (00:14:28 - 00:15:47)
Das ist korrekt. Und ich glaube, das ist genau ein Punkt, der in der Praxis ganz oft unterschätzt wird. Du hast eine Lösung, für dich ist alles klar. Du sagst, das haben wir bei der Firma XY immer so gemacht, jetzt los, Hände dreckig machen, jetzt können wir losstarten. Und genau da ist das Problem, habe ich eben sehr oft erlebt, wenn die Leute so reinkommen, gerade in neue Positionen, auch in höheren Positionen. Wir haben das bei Firma XY so gemacht, bam, bam, möglichst viel ändern, Trump Style in den ersten neunzig Tagen und und dann nimmst du das Team nicht mit. Und genau da musst du aber eigentlich die Fragen stellen. Sogar wenn du die Lösung hast, musst du meiner Meinung nach die Fragen stellen im Team. Was sind die Probleme? Was wollen wir wirklich lösen? Und dann kannst du das ganze richtig framen, um die Lösung in das Team reinzubringen, so dass das Team damit einverstanden ist und merkt, okay, du hast dich damit beschäftigt und bringst jetzt da eine Lösung, die für alle sinnvoll ist und die sich auch im richtigen Kontext bewegt, diese Lösung. Und das wird, glaube ich, oft vergessen und das wird wahrscheinlich, du wirst recht haben, es ist schneller, wenn du es einfach machst. Das Problem ist die Akzeptanz. Und da sind die Fragen eben ganz wichtig, dass man die zu Beginn stellt, meiner Meinung nach. Und das wird in der Realität viel zu wenig gemacht. Und gerade diese Personen, die neu reinspringen irgendwo, machen ganz oft diesen Fehler, meiner Meinung nach.
Andy Grunwald (00:15:47 - 00:16:13)
Also du hast nicht unrecht. Auf der anderen Seite würde ich auch sagen, es kommt auf den Impact deiner Änderung an. Wenn du jetzt die komplette Infrastruktur von FDP Deployments auf Kubernetes umstellen möchtest, das hat natürlich einen Einfluss auf die Arbeit von jedem, von jedem in dem Team, vielleicht sogar außerhalb der Teams. Das ist natürlich eine Größenänderung, da bin ich voll bei dir. Wenn man jedoch eine kleinere Änderung hat, dass man das Jira Board vielleicht umbenennt. Ich weiß jetzt nicht, ob ich da die Akzeptanz von jedem brauche.
Wolfi Gassler (00:16:13 - 00:16:27)
Klar, es ist immer natürlich eine Abwägungssache, ganz klar. Aber auch beim g Report, das könnte sogar so was sein, wo du Probleme in dem Team hast, wenn du da nicht Disagreement eingeholt hast. Die Kleinigkeiten sind ja öfter die größten Probleme.
Andy Grunwald (00:16:28 - 00:18:13)
Jetzt habe ich ja extra das Beispiel erwähnt vom Jira Board umbenennen und nicht umstrukturieren. Aber du hast einen tollen Punkt angesprochen, ich hatte die Tage den Fall. Und zwar folgendermaßen leite ich zwei Teams. Das eine Team macht tägliche Stand up dailies, oder beziehungsweise nicht täglich, aber viermal pro Woche. Und das andere Team macht es nicht. Und ich bin relativ neu in dem Job, relativ neu in beiden Teams und habe einfach mal mir die Prozesse angesehen, unter anderem auch das Jira Board. Wie sieht das Jira Board eigentlich aus? Wie ist das strukturiert? Wie ist das Content konfiguriert? Und so weiter. Wie arbeiten die Leute damit? Jetzt habe ich in dem einen Team gemerkt, in den Stand ups, da wird sich sehr viel Gedanken gemacht über die Struktur des Jira Boards. Okay, wie arbeitet man? Wie kann man das gut ölen? Wie kann man das schön und smooth hinkriegen? Die Ticketverwaltung und so weiter. Und das andere Team hat gar keine Stand ups. Und dann habe ich einfach mal gefragt oder habe ich mir so bei dem einen Team sehe ich sehr viel Fortschritt, die kümmern sich um ihre Prozesse und so weiter. Bei dem anderen Team, da kriege ich das gar nicht so mit, dass die sich so über die Prozesse so viel Gedanken machen. Habe ich einfach nur mal gefragt hey, hattet ihr schon mal Stand ups oder Dailies? Wenn ja, wie lief das so? Oder warum habt ihr keine? So einfach. Ich habe Fragen gestellt, um den Kontext zu kriegen. Ich habe sehr kurze Antworten bekommen. Ja, wir hatten das mal, hat keinen Wert geliefert und so weiter und so fort. Und von einem Teammitglied wurde ich dann im One on One angesprochen, in so einer Art, als hätte die Person Angst, dass Stand ups und Dailies wieder zurückkommen, weil die Person das als Overhead angesehen hat und so weiter. Und das ist natürlich auch eine spannende Entwicklung. Ich habe eigentlich das versucht, was du jetzt hier gerade übermitteln mö stell mir Fragen, Kontext und allem drum und dran. Und die Frage wurde so aufgenommen mit einer kleinen Angst, beziehungsweise wie hast du.
Wolfi Gassler (00:18:13 - 00:18:39)
Die Frage denn gestellt? Das ist eigentlich immer spannende und du sagst ja genau, was richtig ist, weil das habe ich ja auch gemeint mit Suggestivfragen. Wenn du glaubst du nicht, dass es eigentlich sinnvoll wäre, solche Stand ups zu haben? Das ist was anderes als wie ist denn euer Prozess? Oder wie macht ihr denn aktuell den Abgleich in Projekten? Oder wie haltet ihr euch gegenseitig am Stand, wer an was arbeitet? Also das sind ja unterschiedliche Fragen, das.
Andy Grunwald (00:18:39 - 00:19:23)
Kann ich dir sofort sagen. Ich habe gesagt hey, das andere Team da drüben hat tägliche Stand ups und ich habe mich gefragt, ob dieses Team hier auch schon mal Stand ups ausprobiert hat. Hattet ihr sowas schon mal in der Vergangenheit? Wenn ja, wie hat es funktioniert oder auch nicht? Ein bisschen Kontext wäre hilfreich. Man muss dazu sagen, in Englisch und über ich glaube, in dem in der ganzen Konversation sind sechs oder sieben verschiedene Kulturen involviert. Also da würde ich mich aus dem Fenster lehnen, wenn du jetzt mit der Argumentation kommst, oh ja, geht das schon in diese subjektiv, also geht das schon in die, du möchtest in die Richtung drücken, offen gesprochen, in geschriebener Kommunikation, non native Sprache, verschiedene Kulturen, würde ich sagen, wie valide ist dein Argument, womit du mich jetzt gerade challenge möchtest?
Wolfi Gassler (00:19:23 - 00:19:40)
Deswegen weiß ich sehe es natürlich sowieso nicht genau, was du gefragt hast, aber der Vergleich macht natürlich eine gewisse Sache aus. Aber ich glaube, da sieht man schon, wie schwer das auch ist und wie viel man eigentlich mit Fragen bewirken kann, positiv oder auch negativ. Also das geht ja in beide Richtungen.
Andy Grunwald (00:19:40 - 00:20:04)
Der Vergleich jetzt hier mit dem einen Team oder mit anderen. Ich habe ja extra geschrieben, ich sehe also die machen das und ich habe mich gefragt, warum die anderen das nicht machen. So und der Vergleich, du nennst das jetzt Vergleich und ja, im Endeffekt ist es ein Vergleich, aber auf der anderen Seite ist das auch mein ich gebe Kontext mit, woher ich diese Frage habe und woher diese gerade stammt und worüber ich auch gerade so ein bisschen nachdenke.
Wolfi Gassler (00:20:04 - 00:21:26)
Aber es klingt für mich jetzt so wie du es auch gesagt hast, bisschen vorwurfsvoll, muss ich zugeben, durch den Vergleich, also jetzt nicht irgendwie extrem, aber dadurch du sagst hey Moment, das andere Team macht aber sowas, warum macht ihr das jetzt eigentlich nicht? Oder habt ihr das mal probiert? Ich weiß schon, ich habe das jetzt ein bisschen extremer formuliert, aber es schwingt schon so ein bisschen bisschen was mit. Und daher ist ja glaube ich auch die die Fragetechnik, dass man möglichst offen immer fragt, glaube ich extrem wichtig. Es ist schwierig, man kann immer Sachen rein interpretieren und man kennen wir alle, wir interpretieren teilweise in irgendwelche Aussagen oder fragen ganz viel rein und dabei war es gar nicht so. Oder man denkt sich da irgendwelche Sachen, die hinten und vorn nicht stimmen. Und darum sollte man meiner Meinung nach Fragen möglichst offen formulieren und möglichst wenig suggestiv Sachen drehen. Natürlich, du lieferst Kontext mit, das macht absolut Sinn, aber da würde ich mich jetzt fragen, der eigentliche Kontext, der mich interessieren würde, warum fragst du das Ganze? Also siehst du womöglich das andere Team performanter als mein Team? Oder hast du von irgendwem eine auf den Deckel bekommen, dass irgendwas Team langsamer ist? Und jetzt schaust du dir die Prozesse genauer an. Also die eigentliche Intention, warum du dir die Prozesse jetzt ansiehst, die fehlen mir als Kontext. Und das wäre vielleicht dann interessant gewesen für mich, wenn du mir die Frage stellst.
Andy Grunwald (00:21:27 - 00:21:57)
Wunderbare Konversation, denn Kommunikation ist sowieso hart. Man kennt das Modell mit diesen vier Seiten einer Nachricht, wer das nicht kennt, kann jetzt gerade mal pausieren und kurz googeln. Sehr spannendes Modell. Aber jetzt schlage ich dich mal mit deinen eigenen Waffen. Du nimmst nämlich jetzt gerade sehr viel an. Und was ich eigentlich von erfahrenen Leuten bzw. Leuten mit Berufserfahrung erwarten würde, ist, dass die mir eine positive Absicht unterstellen. Denn deine Aufgaben oder deine Fragen, die du gerade gewählt hast. Du hast schon wieder böse Annahmen.
Andy Grunwald (00:21:58 - 00:22:06)
Okay, es ist wie beim Aktienmarkt. Historische Performance sagt nichts über die zukünftige Performance aus. Und nur weil du mich kennst und weil ich meinen Fehler.
Wolfi Gassler (00:22:09 - 00:22:34)
Also ich möchte da jetzt nichts Böses unterstellen, aber der Firmenkontext macht es ja aus. Also wie ist die Firmenkultur? Ich glaube, du bist ja auch eingebettet. In der Firmenkultur ist gar nicht du als Person, sondern in der Kultur. Und da habe ich keinen Einblick. Aber es könnte natürlich sein, dass solche Fragen auch in der Vergangenheit gestellt worden sind. Genau, wenn es Probleme gegeben hat. Also du weißt ja nie. Kultursachen ist auch noch ein großes Thema. Es ist natürlich super schwierig, da hast du vollkommen recht.
Andy Grunwald (00:22:34 - 00:22:47)
Genau, du weißt es nicht und deswegen nimmst du jetzt gerade etwas negatives an, obwohl du eigentlich als Senior Podcaster in dieser Rolle aktuell oder Senior Engineer mir eigentlich eine positive Absicht unterstellen solltest.
Wolfi Gassler (00:22:47 - 00:22:56)
Oder ich könnte dir eigentlich eine Frage stellen, könnt ihr nachfragen, warum? Warum ist das eigentlich relevant? Oder warum fragst du das? Oder gibt es da eine Intention dahinter?
Andy Grunwald (00:22:56 - 00:23:47)
Genau, das kannst du auch tun. Du kannst auch sagen, auch der schaut sich einfach die Prozesse an und können wir was optimieren? Denn wir haben das schon immer so gemacht, dass wir kein Daily hatten. Das geht ja in dieselbe Sparte, wie du es vorher genommen hast. Also deswegen, was ich nur sagen möchte, ist, unabhängig davon, wie eine Frage gemeint ist, wie der Gegenüber diese entgegennimmt und dann das Gedankenspiel auch losgeht. Ich bin mir gar nicht sicher, ob die Frage Formulierung da so viel Effekt hat, ohne dann so ein riesen Pamphlet zu machen, warum und wieso, weshalb? Weil das ist ja auch schon irgendeine Art eine Rechtfertigung. Denn ich finde einfach nur eine Frage stellen, über die du dir beim Duschen Gedanken gemacht hast, ohne irgendwie einen Hintergrund, weil vielleicht einfach nur, weil du neugierig warst. Vielleicht will ich auch einfach nur wissen, warum dieses Team keine Dailies hat. Der neugier Wesen, weil in vorhandenen Firmen alle Teams immer Dailies gemacht.
Wolfi Gassler (00:23:47 - 00:25:01)
Ja, aber in der Realität ist es so, dass sich alle Gedanken machen. Also vor allem, wenn du eine gewisse Rolle hast. Also der Klassiker ist ja so, irgendwie in einer großen Firma habe ich auch öfters erlebt, der CEO kommt am Abend vorbei zufällig und sagt irgendwie hallo oder hey, da brennt ja noch Licht oder so irgendwas. Und alle machen sich plötzlich Sorgen. Was hat er jetzt gemeint mit dem, dass noch Licht brennt, dass wir noch arbeiten? Ist er jetzt froh, dass wir noch arbeiten? Ist er böse, dass wir noch arbeiten? Hätten wir das Licht ausschalten sollen? Also ist unglaublich, was sich Leute dann für Gedanken machen teilweise. Und der ist einfach nur vorbeigelatscht und hat mal Hallo gesagt. So in der Richtung. Also auch je nachdem, was du für eine Rolle hast, musst du natürlich auch das Ganze mit bedenken. Und darum ist ja die Kultur auch so wichtig. Hast du eine Kultur, wo Fragen stellen jetzt zum Beispiel erlaubt ist, wo das regelmäßig gemacht wird? Hast du es vielleicht sogar in Prozessen drinnen, weil keine Ahnung, wenn du Code Review zum Beispiel hast, fix in deinem Prozess ist ja auch eine gewisse Fragestellung, die du dann immer in deinem Prozess hast. Du fragst nach Feedback und solche Dinge. Da werden vielleicht dann auch Fragen gestellt, warum du Code schnipsel so und so gemacht hast. Also du hast ja überall Fragen dann drin. Und je nachdem, wie deine Kultur funktioniert, wie aufgeladen die ist, wird es dann natürlich auch unterschiedlich interpretiert.
Andy Grunwald (00:25:01 - 00:25:40)
Meine nächste Frage an dich geht auch so in die Richtung Kultur, denn das habe ich mich schon immer gefragt, warum das so ist. Als Newcomer oder als Junior sagt man eigentlich immer, diese Leute können sich erlauben, in Anführungszeichen dumme Fragen zu stellen. Und wenn du dann drei, sechs, neun Monate da bist, dann hast du dieses Attribut, nenne ich es mal, nicht mehr. Gefühlt wurde die Erlaubnis, dumme Fragen zu stellen, dir entzogen bzw. Stellt man dann eigentlich keine dummen Fragen mehr, weil man Angst hat, als du bist ja dumm oder das solltest du eigentlich schon wissen, abgestempelt zu werden. Meine Frage warum ist das eigentlich so?
Wolfi Gassler (00:25:40 - 00:27:06)
Ja, da könnte dir jetzt die Episode ein hundert, sieben und zwanzig empfehlen vom Engineering Kiosk Podcast mit Fanny, wo wir über das Impostor Syndrom gesprochen haben, dass sich jeder irgendwie schlecht fühlt und glaubt, er kann etwas nicht. Und das ist bei den Fragen ja dasselbe. Und ich verstehe das auch nicht. Und das ist eigentlich immer mein pro Tipp Nummer oder pro Tipp Nummer eins vielleicht nicht, aber Nummer drei oder so für Engineering Manager innen, dass man dumme Fragen stellt. Und das war eigentlich meine Lieblingsbeschäftigung, mache ich immer noch gerne dumme Fragen stellen. Man muss da einfach bisschen dann drüber stehen, dass man sich dumm darstellt, unter Anführungszeichen, dass man dieses Wissen nicht hat. Aber irgendwann wird es einem egal, kommt mir vor. Und wenn man das einmal macht in einem Meeting irgendwie so eine dumme Frage stellen, teilweise irgendwelche Abkürzungen oder so. Was bedeutet das? Einfach so was nachfragen und sich nicht drüber schwindelt, weil es wird ja dann immer noch schlimmer irgendwie, dann versteht man gar nichts mehr und irgendwann steigt man dann aus und kriegt eine Frage gestellt und dann hat man keine Ahnung, um was es eigentlich geht, weil man irgendw vor fünf Sätzen ausgestiegen ist. Darum sofort nachzufragen, wenn man irgendwas nicht versteht und dumme Frage teilweise auch zu stellen. Vielleicht sogar, wenn man was versteht als Engineering Manager, man weiß, das könnte vielleicht etwas sein, was manche nicht verstehen, da einfach nachzufragen. Und wenn man dann so die Grinser in der Runde sieht oder das Aufatmen überall sieht, weil die Frage gestellt worden ist, dann weiß man, dass man die richtige Frage gestellt hat. Und darum finde ich, es gibt nichts Wichtigeres, als dumme Fragen zu stellen, auch im Leben, würde ich allgemein sagen.
Andy Grunwald (00:27:06 - 00:27:43)
Ich hatte das schon so oft, dass ich mich auch nicht getraut habe, eine dumme Frage zu stellen, weil ich dieses Recht nicht mehr hatte. Recht in Anführungszeichen, weil ich da schon zwei, drei Jahre war und hat jemand anders das gestellt. Und ich war so ein bisschen so innerlich erleichtert, so wie du das gerade sagtest, aufatmen. Ich habe aber irgendwann vor zwei, drei Jahren die ganze Sache umgedreht und ich frage jetzt einfach, auch wenn ich zwei Jahre schon da bin, frage ich einfach Moment mal, aber mein Verständnis war das. Ist das so oder was bedeutet diese Abkürzung? Ich glaube, bei Abkürzung ist das immer ganz schnell, dass man da nicht weiß, was es heißt. Zum Beispiel die Abkürzung Po, wofür steht die, Wolfgang?
Andy Grunwald (00:27:45 - 00:27:51)
Ja, in meinem Kontext steht die oft für Purchase order, wenn du halt ziemlich viel als Engineering Manager auch im Softwareeinkauf unterwegs bist und so.
Wolfi Gassler (00:27:52 - 00:27:57)
Also P oder dein waren glaube ich immer die Translation Dateien auch oder auch.
Andy Grunwald (00:27:57 - 00:29:00)
Als Abkürzung nur x live als Format. Aber das ist halt auch so eine Sache, einfach mal nachfragen. Und das Lustige ist, ich wurde noch nie schräg angeguckt oder noch nie kam jemand zu mir und hat gesagt, das hättest du aber eigentlich wissen müssen. Also diese Angst, als dumm erkannt zu werden, weil du das hättest du eigentlich wissen müssen. Ich habe noch nie festgestellt, dass meine Reputation darunter gelitten hat, sondern ich habe eigentlich immer nur was gelernt. Und Letztens hatte ich einen Fall, da ging es genau darum. Ich hätte eigentlich etwas wissen müssen, habe die Frage trotzdem gestellt. Und irgendwann kam mein Vorgesetzter zu mir und Andi, die Frage war richtig, richtig gut, auch um andere Leute zu challengen und sagen OK, nimm das einfach nicht immer so hin, sondern frage warum ist das so? Und das hat mir so gezeigt, dass diese Angst eigentlich nur in mir drin ist. Also du hast die Angst ja gar nicht, weil du weißt das ja gar nicht, dass ich mich gerade zurückhalte, um diese Frage zu stellen. Also und ich weiß gar nicht, ob es eine dumme Frage gibt. Da gibt es auch dieses Sprichwort nur der nicht fragt, bleib dumm oder sowas, ne. Wer wie was?
Wolfi Gassler (00:29:01 - 00:30:08)
Auf jeden Fall hast du absolut recht, wem Podcast stellen ja auch oft Fragen, obwohl wir eigentlich die Antwort wissen. Aber wir sind natürlich in einer anderen Situation. Ich glaube auch früher haben wir öfters gesagt, wie wir so neu waren im Podcast Business, dass wir so gesagt haben, ja, wir stellen uns jetzt nur irgendwie dumm oder oder Devil's Advocate oder sowas. Und ich habe das Gefühl, dass wir das jetzt weniger dazu sagen, weil es uns einfach egal ist, auch wenn wir dann vielleicht als unter Anführungszeichen wieder dumm wirken, weil wir so klassische Sachen nicht wissen. Aber auch da wieder, vielleicht wird man einfach irgendwann schlauer und weiß, dass man auch selber Sachen wieder vergisst, wenn man Leben lang Abkürzungen gehört hat und einfach sich in anderen Kontexten befindet, dass man dann einfach wieder gern die Fragen stellt. Und ich glaube, dass das grundsätzlich in Teams, in Meetings, in Podcasts, wo es auch immer ist, wenn man da hin und wieder einfach so Sachen nachfragt, dass es der gesamten Runde allen hilft, auch im Verständnis vielleicht sogar, dass es nur eine Pause gibt, dass jemand, der einfach durchlabert, einfach mal kurz innehaltet und irgendwas anderes erklärt, dass da eine Pause drin ist. Also ich glaube, das ist ein Werkzeug, so eine Frage, das extrem mächtig ist.
Andy Grunwald (00:30:08 - 00:30:18)
Noch ein Kommentar zu der Rolle eines Podcasters. Ich glaube, du hast mal zu mir gesagt, dass ein guter Interviewer eigentlich bereits alle Antworten auf die Frage kennt, die er stellt.
Wolfi Gassler (00:30:18 - 00:30:28)
Ja, das habe ich mir vom Armin Wolf geklaut, von unserem Anchorman von dieser News TV Sendung, aber ja, der Meinung bin ich im Idealfall zumindest.
Andy Grunwald (00:30:28 - 00:30:48)
Aber ich mein, damit man vielleicht nicht immer alle Antworten kennt auf die Fragen, die man bereits stellt, da gibt es natürlich auch verschiedene Fragetechniken. Also ich kann natürlich relativ geschlossene Fragen stellen, wie zum Wolfgang, verwendest du bei deinen Projekten eigentlich Continuous Integration? Und da wird mit hoher Wahrscheinlichkeit dann ein Ja oder ein Nein zurückkommen.
Wolfi Gassler (00:30:48 - 00:31:01)
So wie du es formuliert hast, ist schon wieder fast Suggestivfrage, zumindest vorwurfsvoll formuliert, würde ich fast sagen. Oder es ist, weil ich nirgends sowas verwende, vielleicht ist es das, was ich im Hinterkopf habe, dass ich so reagiere?
Andy Grunwald (00:31:01 - 00:31:10)
Ja, ich kann auch nutzt du aktuell Mono Repo? Geht das auch in die negative Richtung? Wenn ja, dann liegt das vielleicht an unserer Beziehung und nicht an der einzigen Fragestellung.
Wolfi Gassler (00:31:10 - 00:31:18)
Das klingt neutraler, aber das ist eigentlich eine rhetorische Frage, weil es verwendet eh niemand Modorepos außerhalb von Google und den großen.
Andy Grunwald (00:31:18 - 00:31:33)
So, du nimmst schon wieder sehr viel an. Das sollte man außerdem nicht tun, wenn man Fragen ab und zu sollte man die Frage einfach akzeptieren, durchatmen, eine positive Annahme unterstellen und dann antworten. Und nicht immer so gehässig, wie du das hier machst.
Andy Grunwald (00:31:35 - 00:31:44)
Ja, das gibt aber auch so eine Regel. Ich habe mal gehört, man beantwortet keine Frage mit einer Frage und das soll unhöflich laut. Das war jetzt nicht der Knigge, aber warte mal, ich lasse mich mal kurz googeln.
Wolfi Gassler (00:31:44 - 00:32:02)
Ja, man kann es ja auch bisschen smarter formulieren, aber ich glaube, dass es schon oft bei Fragen durchaus sinnvoll ist, um den Kontext bisschen klarer zu verstehen von der Frage, in welche Richtung die Frage sich bewegt. Und je nachdem natürlich, in welchem Setting man ist, kann man da schon mal eine Rückfrage meiner Meinung nach draufsetzen.
Andy Grunwald (00:32:02 - 00:32:09)
Google sagt in schwierigen Situationen. Das hier war jetzt gerade keine schwierige Situation, deswegen solltest du das bitte unterlassen, lieber Wolfgang.
Wolfi Gassler (00:32:09 - 00:32:16)
Aber bei Monorepo zum Beispiel könnt ihr fragen, was verstehst du unter Monorepo? Weil es ist ja nicht so klar definiert eigentlich so.
Andy Grunwald (00:32:16 - 00:32:24)
Also theoretisch müssten wir da jetzt in dieser Podcast Episode weiter runtergehen, was du unter Monarepo verstehst, weil eine Monorepo ist ein Monorepo, das ist ein GitHub Repository.
Wolfi Gassler (00:32:26 - 00:32:48)
Ja, aber für ein Projekt, für die ganze Firma, für ein Modul, das ist ja. Die Frage ist ja, wie viel steckt man in ein Monorepo? Und das ist ja dann eigentlich das Entscheidende. Wenn ich sowieso nur ein Mini Projekt habe, dann habe ich ein Monorepo, aber eigentlich ist es einfach ein Repo. Also die Schwierigkeiten entstehen ja dadurch, dass wenn dann verschiedene Module, verschiedene Systeme in ein Repo gepackt werden. Aber wir driften ab.
Andy Grunwald (00:32:48 - 00:32:56)
Genau. Da könnte man dir jetzt unterstellen, dass du wieder viel zu komplex denkst und jetzt als Consultant den Vertrag ein bisschen ausweiten möchtest. Deswegen gehen wir weiter.
Wolfi Gassler (00:32:56 - 00:34:05)
Eine andere Art von Fragen, oder vielleicht ist es nicht wirklich eine Art, aber eine Einsatzmöglichkeit von Fragen, die ich persönlich extrem gerne verwende, ist, wenn ich mir Zeit verschaffen will. Das heißt, wenn ich mir Zeit verschaffen will in einem one on one, in einem Gespräch, dann stelle ich gern eine Frage. Wenn ich etwas genauer verstehen will, natürlich auch, aber es verschafft mir persönlich dann mehr Zeit, darüber nachzudenken. Wenn jetzt irgendwer in meinem ein hundert eins sagt okay, er hat einen Konflikt mit einer anderen Programmiererin und es gibt da irgendwie ein Problem, dann frage ich mal nach. Natürlich, klarerweise. Aber ich habe mehr Zeit, um darüber nachzudenken und mir dann Bild zu machen, anstatt nur schnell mal loszufeuern oder wirklich eine Antwort zu geben. Oder bei einem Monorepo, da verschaffe ich mir persönlich mehr Zeit, darüber nachzudenken über das Problem und eine Antwort zu finden. Und das ist glaube ich, jetzt keine bösartige Technik, weil man bekommt ja dann auch mehr Kontext, aber man muss nicht immer sofort antworten auf eine Frage. Man kann da auch probieren, einfach mehr Informationen rauszuholen aus dem Ganzen und dann selber mehr Zeit haben, um darüber nachzudenken. Das ist, glaube ich, eine gute Technik, die man auch immer anwenden kann.
Andy Grunwald (00:34:05 - 00:34:46)
Also wenn man das so aufnimmt, wie du das gerade gesagt hast, ich verschaffe mir Zeit, dann klingt das ja schon sehr negativ. Dann klingt das ja schon eigentlich so, als würdest du eine Frage stellen und dich die Antwort gar nicht interessieren. Ich sage nur, es klingt so. Ich sage nicht, dass es so ist, aber dass die Antwort dich gar nicht interessiert, weil du dir wirklich nur Zeit verschaffst. Aber mich würde auch was stellst du denn dann für Fragen? Nehmen wir mal eine Konfliktsituation. Stellst du dann irgendwie offene Fragen, wie zum Beispiel was macht das mit dir? Oder welche Gefühlslage löst es in dir aus? Oder stellst du Verhaltensfragen, wie zum Erzähl mir doch mal, hattest du schon mal einen solchen Konflikt, den du im Team lösen müsstest etc. Also welche Art von Fragen stellst du denn dann?
Wolfi Gassler (00:34:46 - 00:36:05)
Ich glaube, bei so klassischen Konflikten probiere ich einfach mal besser zu verstehen, was da genau passiert ist, wann das passiert ist, wo das passiert ist, in welchem Kontext sowas passiert ist. Also stelle ich eher so solche Fragen und vielleicht sind mir da manche Antworten schon klar, wie du richtig gesagt hast. Also das kann man mir auch unterstellen und ich glaube, ich stelle auch solche Fragen oft, damit die über eine Antwort besser nachdenken kann. Oder auch im Consulting Umfeld, wenn ich da eine Frage stelle, weil da kommt dann öfters was denkst du, ist das eine gute Lösung? Und da musst du irgendwie ja, nein, so schnell kannst du teilweise gar nicht urteilen. Und dann stelle ich natürlich noch eine Frage, um vielleicht irgendeinen Kontext zu bekommen, der mir dabei hilft, aber wo ich dann auch Zeit habe, darüber nachzudenken, das einzuschätzen. Ist das System jetzt gut? Auch bei Konflikten, wenn du da in einer Dreierbesprechung sitzt zum Beispiel und einer sagt Hey Andy, was meinst du dazu? Oder wie siehst du das dann? Ist natürlich schwierig, wenn du da jetzt noch kein klares Bild hast oder dir eine Meinung gebildet hast und da kannst du dann natürlich noch mal zurückfragen. Und das macht meiner Meinung nach dann schon Sinn. Es ist gar nicht bösartig, das ist einfach, um mehr Informationen zu bekommen, aber gleichzeitig auch Zeit. Und das kann man natürlich auch gut nutzen. Und im schlimmsten Fall, wenn du wirklich Zeit brauchst, stellst du eine Frage, wo du die Antwort vielleicht schon weißt, finde ich auch OK. Das Gegenüber muss noch mal nachdenken, muss noch mal genauer irgendwas formulieren und du bekommst die Zeit.
Andy Grunwald (00:36:05 - 00:36:18)
Und warum sagst du nicht ganz einfach, ich brauche da ein bisschen Zeit, um darüber nachzudenken. Ich komme auf dich morgen zurück. Also warum sagst du nicht einfach offen und ehrlich transparent, dass du, dass es eine komplexe Situation ist, wenn es wirklich.
Wolfi Gassler (00:36:18 - 00:37:21)
So komplex ist, dass du jetzt länger brauchst, um nachzudenken. Klar, du kannst ja auch sagen, ich kann das aktuell nicht einschätzen. Wie ist denn diese Schnittstelle, diese Architektur, was macht ihr dort, um das dann besser einschätzen zu können? Also du kannst ja auch das transparent spielen, das ist ja kein Problem, wenn es wirklich um diese Informationen geht. Aber mir geht es darum, dass es einfach so in Gesprächen, auch in One on One oft wirklich so um zwanzig Sekunden geht, wo du einfach noch mal irgendwie Zeit brauchst, um was zu formulieren, was nachzudenken oder auch die Info dann wirklich mit integrierst in deine Antwort. Und da stelle ich einfach gerne eine Frage. Darum glaube ich, dass Fragen stellen auch einfach recht mächtig ist. Man könnte es noch in was manipulativeres richten. Wenn du zum Beispiel willst, dass Leute dir keine Fragen stellen, dann kannst du einfach den anderen Fragen stellen, dann werden die nie in diese Frageposition kommen und dir Fragen stellen. Also wenn dir irgendwas unangenehm ist, kannst du dich mit Fragen auch verteidigen, aber das geht dann schon in eine sehr manipulative Richtung. Aber ist auch eine Möglichkeit. Also bevor du die dummen Fragen gestellt bekommst, stellst du sie lieber selber. Angriff ist die beste Verteidigung.
Wolfi Gassler (00:37:24 - 00:37:52)
Jetzt waren wir gerade im manipulativen Trim. Die Suggestivfragen hatten wir eh schon. Das ist natürlich auch noch manipulativ. Also man kann viele manipulative Sachen machen. Wobei manipulativ, da gibt es ja auch eine Bandbreite. Also manipulativ kann ja auch positiv genützt werden, einfach indem du eben zum Beispiel dir ein bisschen Zeit rausholst oder Zusatzinformationen gewinnst. Das muss nicht alles wirklich manipulativ mit einem bösen Gedanken sein in dem Sinne, weil wenn du in die Coaching Richtung gehst, ist es ja auch in gewisser Weise manipulativ, wenn man das so framen will.
Andy Grunwald (00:37:52 - 00:37:57)
Du sprichst ein gutes Thema an. Ich mein, Coaching ist nochmal eine spezielle Situation.
Andy Grunwald (00:38:06 - 00:39:03)
Ne, sehr, sehr gut. Sehr, sehr gut. Also im Endeffekt, Coaching ist ja so, du leitest das bzw. Der Coach versucht ja das Gespräch unter anderem durch viele Fragen in die richtige Richtung zu leiten bzw. Den Coach mittels Fragen selbst auf die Lösung, ich sage jetzt nicht mal zu bringen, aber zumindest in die Richtung zu stupsen. Coaches selbst sind ja nicht wie Mentoren, die oder auch Consultants oder Consultants, die auf, bei Mentoren nehme ich mal das Beispiel, die auf Basis von historischen Erfahrungen mit ihren Lösungen kommen. Also deswegen sagt man ja in der Regel auch, wenn du einen Mentor hast, dein Mentor oder deine Mentorin sollte in der Regel mehr Erfahrung haben als du in dem Bereich, in dem du Rat suchst, nenne ich es mal so, können Mentoren sagen, ich hatte ein ähnliches Problem, ich habe es damals so gelöst und nicht sagen, okay, löst das so.
Wolfi Gassler (00:39:04 - 00:39:59)
Coaches sind ja meistens auch nicht aus deiner Domäne. Also Coaches sind ja allgemeine Coaches, systemische Coaches zum Beispiel, das sind keine ITler, trotzdem können sie IT Leute coachen, weil die einfach allgemeine Fragen stellen. Wobei auch da, ihr kennt schon den Trend, vor allem im höheren Managementbereich, dass viele eigentlich nicht mehr so dieses klassische Coaching wollen, wo ganz viele Fragen gestellt werden, sondern ganz oft auch hey, ihr habt dieses Problem, keine Ahnung, in der Teamführung, gib mir jetzt deine Sicht darauf. Also das wird dann auch klar kommuniziert und die wollen dann nicht wieder zwanzig Gegenfragen hören, sondern einfach mal eine andere Meinung haben. Also das gibt es auch ganz oft und das machen dann auch Coaches. Aber das klassische Coaching und das ist meistens dann auch so definiert, wir mach machen jetzt Coaching, das heißt, es ist das Frame gesetzt, dann werden die Fragen gestellt, um den Coachee in verschiedene Richtungen zu bringen, zu manipulieren, könnte man fast sagen, aber dem zumindestens andere Perspektiven zu zeigen.
Andy Grunwald (00:39:59 - 00:41:24)
Ja, das stimmt. Und ich glaube, bei diesem c Level Coaching, was du genannt hast, da bin ich mir gar nicht sicher, ob die Coaching nach dem Buche machen oder ob das nicht so ein Mix aus Mentoring ist oder aus Barrings Partner oder Brainstorming. Aber ich meine, in diesem Fall wird das relativ klar kommuniziert, wie du sagtest, aber Coaches gehen ja oft mit Reflexionsfragen an den Start, wie zum Beispiel, was hättest du rück in deinem letzten Projekt anders gemacht? Oder welche technischen Entscheidungen aus der Vergangenheit würdest du heute anders treffen? Zum Beispiel, oh, ich würde kein Mesos mehr deployen, sondern direkt ein Kubernetes, keine Ahnung, so nach dem Motto, dass man halt ein Gefühl für die Situation kriegt. Oder Skalierungsfragen gehen da auch irgendwie sehr schnell in die Richtung, okay, wie würdest du denn dein Verhalten jetzt auf einer Skala von eins bis zehn bewerten, wo eins sagt, okay, war nicht so ganz angebracht und zehn war angebracht, dann sagst du, okay, war eine vier, okay, aber warum denkst du denn so? Direkt wieder eine offene Frage hinterher und so weiter. Also es geht halt schon in die Reflexion, um diese Person, ich sag mal, ein bisschen aus der Komfortzone zu triggern und ich sag mal, vielleicht auch Gehirnareale in Bewegung zu setzen, wo man im täglichen Doing keine Zeit für hat, wenn man immer busy ist, immer beschäftigt und so weiter, dann steckt man ja immer in der aktuellen Aufgabe drin. Und Coaching mit Reflexionsfragen, mit Skalierungsfragen, mit offenen Fragen, die helfen dir natürlich, ah, okay, du nimmst dir jetzt mal Zeit und denkst über dein Verhalten nach und dann siehst du vielleicht das Problem mit einer mit anderen Augen.
Wolfi Gassler (00:41:24 - 00:43:02)
Es ist im Prinzip diese Betriebsblindheit, die man da entwickelt. Oder auch wenn man sich mit einem Problem ganz lang beschäftigt, dann ist man so eingefahren und vergisst eigentlich so andere Pfade, die es vielleicht auch noch gäbe. Und das ist eigentlich so die Herangehensweise, die ja alle Coaches haben und die man mit diesen Fragen eigentlich bewirken will, dass man diese Leute aus diesem steckengebliebenen Status eigentlich rausbringen will. Also es gibt da im Coaching Bereich zum Beispiel dieses, ich glaube, da merkt man das nicht, Tetralemma heißt das Ganze auf Deutsch, heißt oft auch hinter die Litfaßsäule führen oder so, wo man einfach ein Problem so von rundherum betrachtet, andere Perspektiven einnimmt, wo man einfach fragt, was gibt es Positives, Negatives, was spricht dafür, was spricht dagegen? Können zwei Lösungen aus auch parallel funktionieren? Was müsste gegeben sein, damit die eine Lösung funktioniert und die andere nicht? Oder gibt es ganz andere Lösungen? Also man stellt dann einfach so Fragen, wo man sich dann mal mit was anderem auch beschäftigt, mit einer anderen Lösung, mit einem anderen Weg, den man vielleicht gehen kann und das ganze bisschen hinterfragt, wo man eben drinsteckt. Und das ist sehr banal eigentlich und klingt banal, aber man braucht einfach eine andere Person. Man kann das auch über Peer Coaching machen. Also dass man, wenn man Leute hat auf gleicher Ebene, wo man sich vielleicht trifft in der Runde, wo man ein Problem bespricht, man tragt das Problem vor und dann ist eigentlich die Aufgabe der anderen Personen im Peer Coaching einfach Fragen zu stellen, um das zu verstehen, Kontext und da auch Feedback zu geben. Und eigentlich geht es immer darum, aus seinem Tunnel irgendwie rauszukommen. Und das ist die Grundsatzidee von Coaching.
Andy Grunwald (00:43:02 - 00:44:30)
Also hinterher die Litfaßsäule führen. Kannte ich jetzt noch nicht. Das, was du gerade beschrieben hast, ist vielleicht nicht das gleiche, kenne ich aber nur so als Walt Disney Methode, dass man ein Problem oder beziehungsweise, dass man innerhalb eines Rollenspiels das Problem aus unterschiedlichen Standpunkten beleuchtet, um dann die Ideen aus mehreren Perspektiven durchzudenken, wie man das Problem löst. Nennt sich Walt Disney Methode, auch ganz interessant. Ist meines Erachtens nach relativ schwer alleine durchzuführen, sondern du brauchst da schon einen Buddy Coach oder jemanden anders, der dir da ein bisschen hilft, dich in die eigenen Standpunkte oder die anderen Standpunkte zu Dr. Was aber auch super hilfreich ist, wo andere, ja ich nenne es sogar vielleicht Rollen oder Leute, die mit deinem Problem gar nicht vertraut sind, helfen können, ist und jetzt kommen wir wieder zu meinem Steckenpferd beim Set Reliability Engineering, beim Incident Management, bei der Root Cause Analysis. Ihr habt einen Ausfall und gute Software Teams schreiben dann immer einen sogenannten Incident Report oder nicht nur gute Softwareteams, denn denn mit hoher Wahrscheinlichkeit wird bei dem Stromausfall in Spanien und Portugal, der vor kurzem stattgefunden hat, ebenfalls ein Incident Report geschrieben, auch sehr detailliert. Und eine Fragetechnik, die da sehr hilft, sind die sogenannten Five wise. Dabei geht es eigentlich darum, dass man auf eine Aussage vom Incident Report, warum das aufgetreten ist, nochmal ein warum hinterher schmeißt.
Wolfi Gassler (00:44:30 - 00:44:35)
Also die Kindermethode. Oder ich frage einfach warum, warum, warum, warum?
Andy Grunwald (00:44:35 - 00:46:34)
Ja, kann man so sehen. Ich meine, im Endeffekt spielen wir das mal durch. Das Problem ist, Wolfgang, du bist jetzt mit dem Fahrrad über eine rote Ampel gefahren. Und da frage warum bist du über eine rote Ampel gefahren? Ja, du warst zu spät zur Arbeit oder beginn zur Arbeit, aber warum warst du zu spät dran? Du bist zu spät aufgestanden. Warum bist du zu früh aufgestanden? Ja, weil mein Wecker nicht geklingelt hat. Warum hat der Wecker nicht geklingelt? Ja, die Batterie war leer. Und warum war die Batterie leer? Ja, du hast vergessen, den Batteriestatus zu überprüfen. Also du merkst schon, du bist zu spät zur Arbeit. Das ist der Cause bzw. Der Effekt. Und der Root Cause ist eigentlich, dass du vergessen hast, den Batteriestatus zu checken bzw. Die leere Batterie nicht gewechselt hast. Und das ist diese Kinder Methode. Warum, warum, warum, warum, warum? Hilft da natürlich sehr. Und jetzt kannst du sagen, wenn wir mal ein Engineering Beispiel nennen, oh ja, der Docker Container wurde vom Operating System gekillt. Warum? Weil er zu viel RAM verbraucht hat. Und deswegen kam der OOM Killer out of memory Killer um die Ecke. Warum hat dieser Docker Container zu viel RAM gebraucht? Viele Teams stoppen hier und weil der einfach mehr RAM braucht und schmeißen dann mehr RAM auf dieses Problem. Man könnte aber auch noch weitergehen und okay, aber warum lief denn der Docker Container drei Wochen lang mit zwei GB Memory Allocation und warum braucht braucht er jetzt auf einmal drei GB? Was hat sich geändert? Und dann geht man immer weiter runter. Hat sich die Usage geändert? Gab es einen Commit, der mehr Memory braucht? Und so weiter. Also mehr RAM nachschmeißen hilft jetzt nicht. Das hilft vielleicht, das Problem zu lösen, aber es ist nicht die Lösung des Problems. Es ist einfach nur, wie sagt man im Englischen, kicking a can down the road. Also eigentlich die Dose, die Straße runtertreten und du verschiebst das Problem mit dem Memory eigentlich nur, anstatt den Memory increase selbst zu beheben. Die Five why Methode kann dir da helfen, auf, ich sag mal, den Grund der Ursachen zu gehen.
Wolfi Gassler (00:46:34 - 00:47:33)
Was die five Wise Methode auch schön darstellt, ist meiner Meinung nach, dass man sich nicht mit einer Antwort zufrieden geben sollte. Das heißt, man stellt eine Frage, bekommt eine Antwort, nächste Frage oder nächstes Thema, sondern dass man wirklich dort bleibt und dann Fragen aufeinander aufbaut, um tiefer zu gehen. Also das müssen ja nicht immer why Fragen sein, man kann die ja auch bisschen komplexer dann natürlich formulieren, aber dass man wirklich tiefer reingeht und Frage auf Frage nacheinander setzt und dann wirklich zum Beispiel zum Root Cause oder zu anderen Problemen wirklich vordringt. Und das wird halt auch ganz gerne gemacht. Man stellt da irgendwie eine klassische Frage, bekommt eine Antwort, that's it. Und dann springt man weiter, weil man hat ja sowieso keine Zeit, das Meeting ist bald fertig. Das heißt, man kann sich damit gar nicht beschäftigen. Und das ist aber gerade bei solchen Dingen, wie du jetzt auch gesagt hast, beim Post mortem wichtig, dass man eben den echten Root Cause auch findet, den man dann meistens leichter beheben kann, anstatt dass man bei irgendwelchen Symptomen ansetzt und diese behebt.
Andy Grunwald (00:47:33 - 00:47:49)
Es gibt natürlich aber auch kritische Stimmen in der Five why Methode, also weil das, was der Wolfgang gerade besprochen hat, trifft auch nicht immer zu bzw. Wird nicht immer angewandt. Also der Erfolg dieser Five wise hängt zu einem gewissen Grad von der Kompetenz ab, mit der die Methode angewendet wird.
Wolfi Gassler (00:47:49 - 00:47:56)
Also wenn du immer nur warum? Fragst, irgendwann bekommst du eine Ohrfeige oder so. Wenn du warum, warum, warum?
Andy Grunwald (00:47:57 - 00:50:00)
Das ist die eine Thematik. Man kann aber auch genau das sagen, dass viele Leute annehmen, dass eine warum Frage immer nur eine hinreichende Ursache hat, was nicht immer der Fall ist. Deswegen ist ein hilfreicher Trick nicht einfach zu warum? Mein Docker Container wurde vom Operating System mit einem out of Memory gekillt. Warum? Also wenn du die Kompetenz nicht hast, würdest du dann nur auf eine Ursache gehen? Und wenn du diese Ursache hast, gehst du einfach weiter. Deswegen macht es schon sehr viel Sinn zu okay, warum hat das Operating System deinen Docker Container mit out of Memory getötet? Also immer die ganze Frage wiederholen in der Warum? Das ist die eine Thematik. Dann ist natürlich die Wiederholbarkeit dieser Methode auch fraglich. Drei verschiedene Personen, die five Whys auf dasselbe Problem anwenden können zu drei völlig unterschiedlichen Antworten, was nicht unbedingt falsch ist, aber es stellt eine Limitierung dar, wirklich immer die Root Cause zu finden bzw. Die reale Root Cause, wenn nämlich verschiedene Gruppen auf verschiedene Root Causes kommen. Es kann natürlich auch sein, dass es mehr Root Causes gibt, aber da kommen wir wieder zur Kompetenz, mit der die Methode angewendet wird. Und die nächste Thematik ist natürlich auch, dass die Methode selbst ist nicht in der Lage, zwischen Kausalfaktoren und der Grundursache zu unterscheiden. Und da kommen wir wieder auf die Kompetenz derjenigen, die die Methode anwenden, zurück. Deswegen ist es der heilige Gral. Ne, wahrscheinlich nicht. Gute Root Cause Analysis ist einfach unglaublich schwer. Also ich wiederhole es, unglaublich schwer. Wenn ihr denkt, ihr seid da gut drin, dann schlage ich schaut euch mal an, wie andere Teams Root Cause Analysis machen. Ich habe gedacht, ich wäre gut da drin. Dann habe ich vor kurzem den Arbeitgeber gewechselt und habe gemerkt, scheiße, ich bin nicht gut da drin. Es gibt Leute, die sind einfach deutlich besser da drin. Und ich habe mir da auch ein paar. Wenn ich jetzt sage Ohrfeigen abgeholt, dann heißt das eigentlich klingt das so negativ in der in der Kultur.
Andy Grunwald (00:50:03 - 00:50:30)
Ich wurde eines Besseren belehrt. Ich wurde sehr gechallenged und sehr positiv deswegen. Jetzt fragt ihr euch natürlich, wie kann ich anderen Teams dabei zusehen, ohne den Arbeitgeber zu wechseln? Ja, das gibt es. Wir haben früher mal so Engineering Pairing mit anderen Firmen gemacht. Wir sind einfach zu anderen Engineering Teams von anderen Firmen gegangen und habe hey, ihr nutzt doch auch Kubernetes oder sowas. Wollt ihr nicht mal ein, zwei Stunden mit uns einen Call machen und einen Austausch machen? Und dann haben wir da über solche Themen auch gesprochen. Ist nun mal so ein Tipp.
Wolfi Gassler (00:50:30 - 00:52:01)
Jetzt haben wir so lange über Fragen stellen gesprochen, aber ich möchte noch auf zwei Sachen eingehen, die damit meiner Meinung nach auch stark verbunden sind. Und die eine Sache ist, wenn man Fragen stellt, dann muss man auch die Antwort aus und auch die Zeit, bis man eine Antwort bekommt. Und auch da habe ich in Meetings ganz oft erlebt, so stille warten auf eine Antwort, da tun sich ganz viele Leute schwer, weil es muss immer geredet werden. Es kann nicht mal kurz irgendwie still sein. Das haben wir auch lange trainiert im Podcast übrigens. Das hört ihr alle nicht, weil unsere Pausen rausgeschnitten werden und viele glauben, dass wir uns ständig ins Wort fallen wahrscheinlich. Aber Stille und einfach mal abwarten, bis da eine Antwort kommt, kann ganz viel bringen. Und vor allem, wenn man daran denkt, dass es eben auch Leute gibt, die vielleicht nicht so wie der Andi einfach vor sich hin sprudeln und alles raus plappern, was geht, sondern es gibt halt auch ganz schüchterne Leute. Gerade in Meetings ist es wichtig oder andere Gruppen, die vielleicht nicht so laut sind. Darum am besten die Leute auch ansprechen und sonst auf jeden Fall auch die Zeit geben, um zu antworten. Es hat jetzt gerade kürzlich von der Fanny, die wir auch mal in einer Episode hatten, eine Podcast Episode gegeben. Da ist es um Beziehungen gegangen und Stille auszuhalten in Beziehungen habe ich auch sehr nett gefunden, weil es im Prinzip genau in die gleiche Richtung schlägt, dass man da einfach gerade bei Personen, die nicht so raussprudeln, einfach mal auch die Stille akzeptiert und wartet auf eine Antwort, weil sonst bekommt man die Information einfach gar nicht und man bekommt vielleicht gar keine Antwort, wenn man einfach immer vor sich hin plappert.
Andy Grunwald (00:52:01 - 00:52:32)
Ja gut, allein bei dem Titel Kommunikation in der Beziehung, wenn der eine zu viel redet und der andere zu wenig, fühle ich mich leider sehr ertappt. Naja gut, ist halt so. Aber du hast einen wichtigen Punkt angesprochen, wenn man die Antwort nicht aushalten kann. Ich kenne das nur aus einem anderen Kontext und zwar folgendermaßen. Stelle nie eine Frage, wo du nicht bereit bist, auf Basis der Antwort einer Aktion zu tätigen. Kommen wir mal zu einem praktischen Beispiel. Stelle nie die Frage, ob deine Belegschaft mit der Essensqualität in einer Kantine zufrieden ist, wenn du nicht bereit bist, in höher qualitatives Essen zu investieren.
Wolfi Gassler (00:52:32 - 00:52:58)
Ist ein guter Punkt, ja. Auf der anderen Seite ist gar nicht anzusprechen, das ist halt der Pink Elephant der dann wieder im Raum herumschwirrt, jeder weiß, dass die Kantine schlecht ist, aber niemand spricht sie an. Oder auch bei kleineren Problemen in Teams, da ist man glaube ich dann auch wieder als Manager, Managerin gefragt, eben genau diese Dinge anzusprechen, den pinken Elephant, den jemand ansprechen will, einfach die Frage stellen und ihn dann auf den Tisch bringen, den Elefanten, oder zu visualisieren quasi.
Andy Grunwald (00:52:58 - 00:53:17)
Und ich glaube deswegen, weil es da so viele Nuancen gibt, ist auch zum Beispiel Fragebogen Design unglaublich kompliziert. Also was möchtest du eigentlich mit deiner Frage bewirken? Und wir hatten ja in einer anderen Episode kürzlich auch das Phänomen einer, wie hattest du das genannt? Kontrollfrage, glaube ich.
Andy Grunwald (00:53:19 - 00:53:49)
Also Kontrollfrage, du möchtest eigentlich genau das gleiche wissen, was du vorher schon gefragt hast, doch stellst es mit einer anderen Frage. Damit überprüfst du natürlich diverse Dinge, ob die Person vielleicht lügt oder die Frage falsch verstanden hat oder sich nicht einig in der Antwort ist. Aber sowas gibt es natürlich auch im Fragesteller. Und ab und zu, muss ich zugeben, tue ich das natürlich auch in one on one, um zu gucken, OK, Verständnis abzuklären oder ob die Person vielleicht irgendwie zwei verschiedene Perspektiven hat oder oder.
Wolfi Gassler (00:53:49 - 00:55:04)
Also ich möchte gar nicht zu sehr in dieses Design reingehen, ich bin da auch kein Spezialist und ich habe da auch schon mit Spezialistinnen öfters diskutiert und das ist auch gar nicht so klar, weil was man zum Beispiel ganz oft sieht in letzter Zeit in Fragebogen und die war gerade kürzlich in ein Projekt involviert, wo es wieder darum gegangen ist, wo ein Statement gestellt wird und die Auswahlkriterien sind, ich stimme nicht zu oder ich stimme sehr zu oder stimme gar nicht zu. Aber die Frage an sich drängt dich ja schon voll in eine Richtung, wenn du bist du super glücklich? Ich stimme gar nicht zu, ich stimme sehr zu. Oder bist du super unglücklich? Ich stimme sehr zu, ich stimme gar nicht zu. Also mit der eigentlichen Frage kannst du schon ganz viel bewegen oder Leute in eine Richtung drängen. Darum finde ich persönlich dieses Fragendes extrem schlecht, aber es wird überall angewandt. Also vielleicht, falls ihr da draußen Spezialist innen seid, klärt uns mal auf, ob das immer noch ein sinnvolles Design ist. Es wird in offiziellen, wirklich großen Studien auch so gemacht. Meiner Meinung nach drängt es in eine Richtung, aber vielleicht ist es auch nur meine Ansicht. Aber bevor wir langsam zum Ende kommen, ich habe zuerst gesagt, es gibt zwei Sachen, die nicht direkt mit Fragen verbunden sind. Also einerseits die Stille und das andere, was ich jetzt entscheiden fragen wollen würde, wann sind denn Fragen gar nicht angebracht? Also wann sind Fragen kontraproduktiv?
Andy Grunwald (00:55:04 - 00:56:00)
Ja, es gibt Elemente, da nerven Fragen einfach nur und da nerven mich Fragen einfach nur. Und ab und zu haben wir dieses Element auch für alle Leute, die uns gerade zuhören. Wolfgang und ich schreiben natürlich auch sehr viel in Slack. Und ab und zu möchte ich einfach nur eine Antwort. Wir haben das Thema schon acht und dreiig mal besprochen. Es gilt jetzt einfach nur, die ganze Sache einfach mal umzusetzen. Und ich stelle eine simple Frage und Wolfgang kommt wieder mit einer Gegenfrage. Und das treibt mich so in den Wahnsinn. Ich will einfach jetzt mal hier was schaffen, mal ein bisschen was auf die Straße bringen. Und der Consultant, der denkt, er wäre gerade immer noch in seiner Beratungsrolle hier, obwohl er jemand ist, der seine Hände dreckig machen muss in diesem Podcast Projekt, stellt mir eine Gegenfrage. Wolfgang, jetzt halt den Bubble. Jetzt gib mir einfach die Antwort. Ich will jetzt hier einfach weitermachen. Wolfgang, das ist eine Situation, da verbrennst du Nervenstränge bei mir und da sind Fragen unangebracht.
Wolfi Gassler (00:56:00 - 00:56:13)
Ich habe gerade in kürzester Zeit von verschiedenen Leuten gehört, dass ich so gerne Fragen stelle, also in unterschiedlichen Kontexten. Ich kann dir nur beipflichten. Also ein Freund von mir hat gerade kurz warum willst du immer alles so genau wissen? Ist unglaublich mit dir.
Wolfi Gassler (00:56:18 - 00:56:23)
Ja, aber da kommen Leute und erklär mir irgendwas. Natürlich will ich da die Details wissen. Das ist immer dieses Oberflächliche.
Andy Grunwald (00:56:24 - 00:56:33)
Aber auch du als Consultant bist dazu angehalten, Wert zu stiften und andere Leute zu enablen. Also nächste keine Frage mit einer Gegenfrage beantworten.
Wolfi Gassler (00:56:33 - 00:57:33)
Okay, ich werde mich bemühen. Eine andere Situation, was auch noch ganz oft so in der Literatur erwähnt wird und was man auch so in der Praxis oft mitbekommt, ist eben, wie du gesagt hast, wenn ich in der Consulting Rolle bin oder wenn Coaches in der Coaching Rolle sind, also wenn man immer so Coaching machen will, obwohl es vielleicht einfach nur ein normales Gespräch ist oder man gar keine tieferen Fragen haben will. Und das hört man immer, zumindest von Coaches, ich bin ja kein professioneller Coach, dass die gerade in privaten Beziehungen und so weiter dann so ein Modus etabliert haben, dass sie sagen, okay, ich gehe jetzt in den Coaching Modus oder ich gehe nicht in den Coaching Modus. Und in One Once kann man das ja auch machen, wenn man sagt, okay, ich gehe jetzt in den Coaching Modus. Das heißt, ich werde dir ganz viele Fragen stellen, damit dieses Setting klar ist. Und wenn das Setting eben nicht gegeben ist, dann sind Fragen vielleicht kontraproduktiv, oder wenn man eben einfach nur eine Antwort haben will und nicht selber gecoacht werden will, sondern man will einfach eine zweite Perspektive haben, eine zweite Meinung und interessiert sich jetzt einfach für die Meinung von einer anderen Person und will sich da nicht mit Fragen löchern lassen.
Andy Grunwald (00:57:33 - 00:57:40)
Genug mit dem ganzen Metathema jetzt mal hier. Nachdem wir unsere Eheprobleme besprochen haben, möchte ich jetzt etwas Neues über dich erfahren, Wolfgang.
Andy Grunwald (00:57:42 - 00:57:47)
Schon wieder eine Frage. Schön. Was war die beste Frage, die dir je gestellt wurde?
Wolfi Gassler (00:57:54 - 00:57:58)
Eigentlich würde jetzt gerne irgendwelche Fragen stellen, um mir ein bisschen Zeit rauszuholen.
Andy Grunwald (00:57:59 - 00:58:11)
Das finde ich wunderschön. Und zwar hat der Wolfgang eine Strategie, die er gerade genannt hat, wo ich ihn gechallenged habe, einfach mal transparent zu sagen, dass er mehr Zeit benötigt. Offen ausgesprochen. Also der Wolfgang.
Wolfi Gassler (00:58:11 - 00:58:17)
Ich habe gerade zuerst der Frage Kontext gestellt, aber dann sind mir die Fragen ausgegangen, um die Zeit reinzuholen.
Andy Grunwald (00:58:17 - 00:58:57)
Komm, ich bin ja kein Arschloch, deswegen starte ich einfach mal. Die beste Frage, die mir je gestellt wurde, die überrascht mich immer wieder. Was hindert dich daran? Meist geht es halt irgendwas um ich beschwer mich oder ich habe direkt Lösungen oder ich fühle mich unfair behandelt und möchte was ändern oder ich möchte irgendwas haben, keine Ahnung, Ferrari kaufen oder so und so weiter und so fort. Und dann immer die was hindert mich daran? Natürlich, dann geht es in die Thematik, ja, das Geld für den Ferrari, Ferrari und so weiter und so fort. Und im Endeffekt komme ich dann da ja, ich möchte nach Bali auswandern. Und dann die was hindert dich daran? Also das finde ich immer schön, dass du, dass du diese mentalen Blockaden einfach hinterfragt.
Wolfi Gassler (00:58:57 - 00:59:08)
Es ist eine meiner Lieblingsfragen, wenn sich Leute immer beschweren, irgendwo in ihrem Job und ich sage immer warum änderst du es nicht? Oder hast du schon mal xy gefragt? Was hindert dich daran, dagegen zu arbeiten?
Andy Grunwald (00:59:08 - 01:00:55)
Geht genau in die was hast du schon gemacht, um das Ziel zu erreichen? Was hindert dich daran? Oder was blockiert dich? Oder ähnliches? Und wenn man sagt ja, ich würde gerne in die Schweiz auswandern. Was hindert dich daran? Ja, du hast Eigentum in Deutschland, das macht das Ganze ein bisschen komplizierter. Du kannst ja alles verkaufen, vermieten und so weiter und so fort. Aber was hindert dich daran? Das finde ich immer so eine schöne Frage, die dich immer so aus seiner Komfortzone rausholt, die dir dann auch immer zeigt, du bist irgendwie dein eigener Meister, du designst dein eigenes Leben. Und das finde ich immer ganz schön. War das jetzt genug? Zeit für dich. Ich kann noch mal Zeit rausholen. Und zwar habe ich vor kurzem eine sehr schöne Interviewfrage gehört, und zwar vom Starinvestor Peter Thiel. Kennt man vielleicht aus Film und Fernsehen, gerade wer sich so ein bisschen hinter die Big tech Machenschaften von Trump und so weiter mal ein bisschen analysiert. Da hat Peter Thiel auch so seine Finger im Spiel. Finger im Spiel, genau. Auf jeden Fall hat Peter Thiel auch ein sehr populäres Buch geschrieben, nennt sich zero to one, geht zum Startup und so weiter und so fort. Und da gibt es eine Frage, die er jedem Interview Kandidaten stellt, die ich sehr, sehr smart finde. Und zwar heißt die welche wichtige Wahrheit glauben nur sehr wenige Menschen mit dir gemeinsam? Oder auf englisch what important truth do very few people agree with you on? Und das die Frage, also ich habe da keine Antwort drauf, ich denke da mal immer mal wieder drüber nach, aber die soll die Fähigkeit testen, kontrafaktisch zu denken, also originelle Einsichten zu haben und sich von konventionellem Denken zu lösen. Also eigentlich genau das, was irgendwie Gründer und Visionäre und Start ups brauchen. Und ich finde die halt so schön, weil die in diesem Kontext so ist.
Wolfi Gassler (01:00:55 - 01:01:08)
Also in dem aktuellen Kontext mit den ganzen Weltverschwörungen um Peter Thiel und was es so auf der Straße bringt. Findet ihn noch schlimmer, diese Frage. Aber gut, ist nochmal ein anderes Thema. Fällt keine gute Frage.
Andy Grunwald (01:01:09 - 01:01:14)
Ich finde es höchst amüsant, dass du das Thema aufgebraucht hast und keine das finde ich grandios.
Wolfi Gassler (01:01:14 - 01:01:49)
Aber eine Frage, die ich persönlich eigentlich sehr gerne habe, spielt mit dem Thema, dass wir oft in irgendeiner Form geblockt werden, eingeschüchtert werden, irgendwas spezielles zu machen, weil wir vielleicht scheitern könnten oder sonst was. Also die was hättest du in der letzten Woche, im letzten Monat gemacht, wenn du mutiger gewesen wärst oder wenn du wüsstest, dass du nicht scheitern kannst? Finde ich eine gute Frage, weil es sich genau mit diesen Limitierungen beschäftigt, die man ständig hat, wenn man irgendwas entscheidet und warum man etwas entscheidet. Und wenn man das transparenter macht, kann es sein, dass man in Zukunft die Entscheidungen anders trifft, wenn man da in die Tiefe geht.
Andy Grunwald (01:01:50 - 01:02:00)
Sehr tief. Sehr tief. Naja, vielleicht genauso tief und genauso meta wie diese Episode, die Wolfgang heute mitgebracht hat. Vielleicht waren wir heute etwas philosophisch unterwegs.
Wolfi Gassler (01:02:00 - 01:02:41)
Ohne das Wort philosophisch überhaupt erwähnt zu haben. So gerade das haben wir auch nicht erwähnt, der ja eigentlich eine klassische Technik hat, eben in die Tiefe zu fragen, ganz ohne irgendwelche Philosophen ausgekommen. Aber nachdem das ja ein sehr praktisches Thema ist, würde uns natürlich auch interessieren, ob ihr irgendwie gute Fragen mal erlebt habt in ein hundert eins oder Firmenkontext oder auch woanders. Einfach so, dass wir vielleicht in unserer Community, in der Discord Community Beispiele sammeln, einfach von coolen Fragen, die man stellen kann in One On One oder in ganz klassischen Meetings, Gesprächen, was es auch immer ist. Würde uns sehr interessieren und würde wahrscheinlich auch allen anderen helfen, wenn man da so paar Beispiele und Ideen bekommt, was man in Zukunft fragen kann.
Andy Grunwald (01:02:41 - 01:03:05)
Und wo könnt ihr diese Fragen droppen? In der Discord Community oder auf Spotify unter dieser Episode. Da gibt es Kommentaren, packt doch einfach mal die Frage rein. Die beste Frage, die ihr jemals gestellt bekommen habt oder eure Lieblingsfrage, die ihr anderen stellt. Ich bin mal gespannt. Vielleicht ist es auch einfach die ganz klassische warum, warum, warum, die leider sehr.
Wolfi Gassler (01:03:05 - 01:03:22)
Viel bringt, muss man sagen. Aber man kann es ja auch kreativer formulieren. Also wir sind offen da für Vorschläge und Ideen und man darf die sogar in Spotify post, obwohl ich natürlich erwarte, dass alle coole ITler ihre eigene individuelle Plattform verwenden und nicht Spotify. Aber da habt ihr die Hoffnung schon aufgegeben.
Andy Grunwald (01:03:22 - 01:03:27)
Und wenn ich mir was wünschen dürfte, was du aus dieser Podcast Episode mitnimmst.
Andy Grunwald (01:03:34 - 01:04:11)
Dann wünsche ich mir natürlich nicht, dass du jetzt das what the fuck habe ich denn da jetzt gerade gehört? Sondern dass du vielleicht dir für die nächste Woche einfach mal vornimmst, hier und da ein paar dumme Fragen stellst von Dingen, die du wirklich nicht weißt, in Teammeetings, wo du vorher gesagt hättest, boah, ich trau mich gar nicht, diese Fragen zu stellen. Wenn du das machst, dann würde ich sagen, kannst du dir selbst auf die Schulter klopfen, denn deine Teammitglieder oder die Leute in dem Meeting, da ist mindestens immer einer dabei oder eine dabei, die dieselbe Frage hat und sich nicht getraut hat. Das bedeutet, du bringst einen Dienst für alle. Das war's von uns. Vielen lieben Dank. Wir hören uns nächste Woche und tschüss.