Fokus-Zeit für Software-Engineers
Software-Engineers und andere Knowledge-Worker kennen es. Du arbeitest an etwas, hochkonzentriert, hältst diverse Kontext relevante Informationen in deinem Kopf und es kommt von links jemand und fragt “Hast mal eben ne Minute?”. Flups. Alles weg. Du bist raus. Darfst du dich neu einarbeiten? So oder so ähnlich hat es jeder von uns erlebt. Eine klassische Unterbrechung.
Doch wie geht man damit um? Was kann man dagegen tun? Das ist wohl die 1 Millionen Euro-Frage. In dieser Episode besprechen wir genau diese Frage. Nicht nur aus der Perspektive der Person, die unterbrochen wird, sondern auch aus dem Blickwinkel von jemandem, der etwas fragen möchte. Und wie geht man als Engineering Manager⋅in mit diesen Unterbrechungen im Team um?
Bonus: Dies ist kein theoretisches Problem, sondern eine Frage aus unserer Community!
Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Das schnelle Feedback zur Episode:
Links
- Community Frage von derTom zum Thema Fokus: https://discord.com/channels/955556204124454933/1080210415721660496/1195265925826498640
- Why developers hate being interrupted: https://www.reddit.com/r/ProgrammerHumor/comments/2rmir6/why_developers_hate_being_interrupted/
- Makers Schedule, Managers Schedule: https://www.paulgraham.com/makersschedule.html
- Cancel your meetings if you can live with the outcome: https://andygrunwald.com/blog/cancel-your-meetings-if-you-can-live-with-the-outcome/
Sprungmarken
Hosts
- Wolfgang Gassler (https://mastodon.social/@woolf)
- Andy Grunwald (https://twitter.com/andygrunwald)
Feedback (gerne auch als Voice Message)
- EngKiosk Community: https://engineeringkiosk.dev/join-discord
- Email: stehtisch@engineeringkiosk.dev
- Mastodon: https://podcasts.social/@engkiosk
- Twitter: https://twitter.com/EngKiosk
- WhatsApp +49 15678 136776
Transkript
Wolfi Gassler (00:00:04 - 00:01:14) 
Kannst du mir mal erklären, wie das mit eurer API funktioniert? Eine typische Frage, die man als Entwickler oder Entwicklerin immer wieder erhält. Egal ob bei Slack oder Teams oder von einer Person, die plötzlich neben einem steht. Und genau dann natürlich, weil man doch gerade im Flow ist und den Fokus für ein hartes Programmierproblem bräuchte. Aber wie geht man damit um, mit diesen Ablenkungen? Ist es die Aufgabe vom Engineering Manager oder von mir selbst, diese Ablenkungen zu verhindern? Wie könnte man diese Probleme angehen und muss man diese Ablenkungen überhaupt verhindern? Wir besprechen einmal unsere Sicht auf die Dinge, wie unsere Teams damit umgehen und der Input aus unserer Community darf natürlich auch nicht fehlen. Und los geht's! Andi, du bist ja extrem gut im Zahlenraten. Du bist ja so gut, dass du sogar in unserer Episode, wo wir ja ganz viele Zahlen geraten haben, so knapp dran warst, dass sogar Patrick und Claudia aus dem Wartungsfenster-Podcast dich so gelobt haben, dass du so gut an den Zahlen dran warst. Darum starte ich jetzt mal mit einer Schätzfrage. Wie viele Leute haben wir in unserer Discord-Community? Und du darfst jetzt nicht nachschauen.
Andy Grunwald (00:01:14 - 00:01:14)
185.
Wolfi Gassler (00:01:14 - 00:01:19)
Moment, das muss ich jetzt nachprüfen.
Andy Grunwald (00:01:19 - 00:01:19)
194.
Wolfi Gassler (00:01:19 - 00:01:24)
Aber du warst sehr knapp dran. Muss man zugeben. Wieder mal sehr knapp dran. Gratuliere.
Andy Grunwald (00:01:24 - 00:01:51)
Zugegeben, ich habe die Tage unsere Statistiken, wie sich unsere Social-Media-Kanäle und Co entwickelt haben, gemacht. Also da kam ich über diese Zahl, weil ich habe halt nachgeguckt, okay, was ist das Wachstum in der Discord-Community? Weil wir ja natürlich datengetrieben sind, erheben wir sowas natürlich immer wieder und machen daraus schöne Grafen. Und deswegen hatte ich das noch ungefähr im Sinn. Du kannst mich auch nach unserer TikTok-Followerschaft fragen, weil da haben wir nämlich genau ein Follower auf TikTok.
Wolfi Gassler (00:01:51 - 00:01:52)
Ja, das bin ich.
Andy Grunwald (00:01:52 - 00:01:58)
Das bist du, genau. Wir sind also sehr erfolgreich auf TikTok oder bereits einfach zu alt, ich weiß es nicht.
Wolfi Gassler (00:01:58 - 00:02:02)
Du solltest unbedingt dir einen TikTok-Account zulegen, eindeutig, damit wir wenigstens zwei Leute haben.
Andy Grunwald (00:02:03 - 00:02:12)
Aktuell werde ich mir keinen TikTok-Account zulegen, weil ich kenn mich. Ich werd da in diesem Loch versinken. Der Sucht, wie dann Leute da rumtanzen oder was man da inzwischen macht.
Wolfi Gassler (00:02:13 - 00:02:21)
Also, wer uns auf TikTok folgen will, findet, glaube ich, die... Haben wir den Link in den Shownotes überhaupt? Wir werden den in die Shownotes packen, sollte er nicht schon dort sein.
Andy Grunwald (00:02:21 - 00:02:24)
Wir werden ihn nicht in die Shownotes packen, der wird irgendwo auf der Webseite im Footer sein.
Wolfi Gassler (00:02:24 - 00:02:58)
Oder da, aber man kann ja auch auf TikTok suchen. Auf jeden Fall in unserer Discord-Community, die sehr floriert, was wirklich schön ist und was mich persönlich super freut. Da haben wir auch so einen Selbsthilfe-Channel, würde ich mal sagen, wo man einfach um Feedback fragen kann. Und da gibt's superinteressante Diskussionen wirklich um teaminterne Sachen. Es sharen teilweise auch Leute sehr private Dinge, wenn sie irgendwie Probleme im Team haben. Also es ist wirklich superoffene Community, freut mich wirklich sehr. Und da haben wir kürzlich mal eine Frage gehabt, die ich superinteressant finde. Und zwar wird uns der Andi die jetzt zum Besten geben.
Andy Grunwald (00:02:58 - 00:03:23)
Und zwar wurde der Channel gefragt, nicht Wolfgang und ich, sondern der Channel, Wurde gefragt, hallo, wie stellt ihr sicher, dass sich euer Team, eure Directs, voll und ganz auf seine Arbeit konzentrieren kann, ohne dass es dazu zur Ableckung durch Google Chat kommt? Habt ihr irgendwie Guidelines, zum Beispiel Focus Time Every Day oder strikte Systeme, Tools im Einsatz, die das unterstützen? Vielen Dank.
Wolfi Gassler (00:03:23 - 00:03:24)
Und von wem ist die Frage?
Andy Grunwald (00:03:24 - 00:03:31)
Vom Tom, von dem Tom, der Tom eigentlich ganz genau. Die Frage ist anscheinend vom Tom. Thomas, man weiß es nicht.
Wolfi Gassler (00:03:32 - 00:03:58)
Und ich vermute mal, der Tom ist Engineering Manager oder leitet zumindest in irgendeiner Form ein Team, vermute ich mal. Weil als Team Lead bekommt man eigentlich sehr oft diese oder eine ähnliche Frage, wenn es so um den Fokus oder um das Zeitmanagement von Teams geht, wie man eben fokussierter arbeiten kann im Team. Hast du das mal schon erlebt, dass sich irgendein Teammitglied beschwert hat darüber, dass es schwierig ist und dass irgendwie die Fokuszeit fehlt?
Andy Grunwald (00:03:59 - 00:04:25)
Man hat immer mal wieder Beschwerden bekommen, dass Leute aus anderen Abteilungen dich direkt anschreiben im Slack und im Büro, wenn man dann auch nicht geantwortet hat, weil man fokussiert war, dann vielleicht mal direkt am Tisch vorbeigekommen sind und das dich dann natürlich aus deiner Fokussierung rausreißt. Man kennt dieses XKCD-Comic, wo du ganz tief drin bist und dann kommt jemand, stört dich und dann fängst du danach wieder ganz von vorne an. Ja, auch schon bekommen, natürlich.
Wolfi Gassler (00:04:25 - 00:04:57)
Jetzt gibt es natürlich da viele Antworten und Antwortmöglichkeiten, würde ich mal sagen. Und wer noch nicht bei uns im Discord-Server ist, kann gerne vorbeikommen. Da hat es eigentlich schon viele Antworten von anderen Teamleads und Personen gegeben, die da ihre Meinung abgegeben haben, was es für Möglichkeiten gibt und Approaches gibt. Aber meine konkrete Frage wäre jetzt eigentlich an dich, Andi. Wenn du jetzt als Engineering Manager so eine Frage bekommst in einem 101, jemand, beschwert sich bei dir, ich habe keine Zeit, da kommen ständig Messages rein und ich werde ständig unterbrochen. Was machst du?
Andy Grunwald (00:04:57 - 00:05:26)
Okay, ich beantworte jetzt gleich deine Frage. Dennoch möchte ich sagen, du triffst schon sehr viele Annahmen, die aus der Frage gar nicht hervorgehen. Denn die Frage sagt nicht, ob die Beschwerde oder ähnliches von einem Individual Contributor zum Manager kommt. Und die Frage sagt auch nicht, ob Tom ein Engineering Manager ist und beobachtet hat, dass der Fokus von den Direct Reports genommen wird. Du triffst schon sehr viele andere, und das möchte ich nur mal ganz kurz so sagen.
Wolfi Gassler (00:05:27 - 00:05:45)
Okay, guter Punkt, den du da einwirfst. Dann gehen wir mal in die andere Position. Wir können ja sowieso nur raten, weil wir wissen ja nicht genau die Umstände. Aber nehmen wir mal an, du bist gar kein Engineering Manager und bist jetzt in einem Team und siehst in irgendeiner Form dieses Problem. Was machst du dann? Gehst du zu deinem Engineering Manager? Willst du probieren, was selber zu lösen?
Andy Grunwald (00:05:46 - 00:05:51)
Nur damit ich das richtig verstehe, ich beobachte, dass andere Leute aus dem Fokus gerissen werden.
Wolfi Gassler (00:05:51 - 00:05:55)
Genau, du bekommst irgendwie mit, dass das halt ein Problem im Team ist, vielleicht auch für dich selbst.
Andy Grunwald (00:05:55 - 00:06:56)
Es ist ja schon ein enormer Unterschied, ob das für mich selbst ein Problem ist und ich dann nach Hilfe frage oder nach einer Lösung oder vielleicht auch nach der Erlaubnis mehr Sachen zu ignorieren und Leute wegzuschicken. oder ob ich als individuell Contributor das bei meinen Peers beobachte und mich dann vielleicht einmische oder sie darauf anspreche, weil im Endeffekt kann ich ja nicht wissen, ob meine Peers ein Problem damit haben. Machen wir uns mal nichts vor, wenn du unterbrochen wirst, dann will jemand was von dir und wenn du eine hilfsbereite Person bist, dann hilfst du. Und dann kriegst du vielleicht ein Danke. Und vielleicht sogar so ein Shout-out in deiner internen Social-Plattform. Hey, vielen lieben Dank, Christian, dass du mir bei dem dringenden Kundenproblem geholfen hast. Und das ist ja auch Wertschätzung. Das ist ja auch ein tolles Gefühl, psychologisch gesehen. Deswegen, wenn ich als Peer jetzt sehe, meine Kollegen werden immer rausgerissen, kann ich ja erst mal gar nicht wissen, ob die das wirklich stört. Oder ob die nicht auch einen Vorteil daraus ziehen und sagen, hey, das fühlt sich gut an, weil da hatte jemand ein akutes Problem und ich konnte helfen.
Wolfi Gassler (00:06:57 - 00:07:01)
Okay, dann nehmen wir mal an, du hast das Problem. Wie würdest du damit umgehen?
Andy Grunwald (00:07:01 - 00:07:32)
Ich als Direct Contributor, Individual Contributor, würde mich erstmal zu meiner Vorgesetzten wenden und die Situation beschreiben. Sagen, hey, pass mal auf, die Erwartung an mich ist, dass ich dieses Feature oder dieses Projekt vollständige und abschließe kann ich nicht. Grund ist, dass jede Stunde mindestens eine Person bei mir am Tisch steht und nach Hilfe fragt und direkt meine Aufmerksamkeit in Anspruch nimmt. Als Softwareentwickler brauche ich lange Fokuszeit, um sinnvolle Arbeit abzugeben. Was können wir da tun?
Wolfi Gassler (00:07:33 - 00:07:47)
Okay, perfekt. Dann sind wir bei der ursprünglichen Ausgangsfrage. Wenn du jetzt auf die Engineering Manager Seite wechselst, und ich glaube, du warst ja auch Engineering Manager von einem sehr serviceorientierten Team, also von einem, wird euer Team damals geheißen, Software Operations, oder?
Andy Grunwald (00:07:48 - 00:08:12)
Also Teamnamen sind ja auch immer Schall und Rausch. Am Anfang hieß es Process-Team, dann hieß es Software-Operations-Team, irgendwann hieß es Cloud-Operations-Team. Also immer irgendein Team, was sich halt um die Reliability von anderen Teams kümmert und um Servicebereitstellungen wie Caching-Systeme, Caching-Server und all so was. Also ja, sehr serviceorientiert und wir mussten andere Leute, andere Teams anblocken, wenn du so möchtest.
Wolfi Gassler (00:08:13 - 00:08:29)
Also in dem Fall ja prädestiniert dafür eigentlich, dass von außen sehr viel reinkommt an irgendwie Fragen und sonstige Dinge. Wahrscheinlich noch mehr als bei einem Developer-Team, aber bei Developer kommt das natürlich genauso vor, weil du arbeitest mit fremden APIs von anderen Teams, musst irgendwas wissen, die POs wollen was.
Andy Grunwald (00:08:30 - 00:08:53)
Also im Endeffekt jeder, der irgendwie in einer Art DevOps-Infrastruktur oder ähnliches arbeitet, der ist in einer Art Dienstleistungsteam, weil du selbst erstellst ja in der Regel nicht das Produkt, wofür Geld verlangt wird, sondern du erstellst oder managt ein internes Produkt, was andere befähigen soll. Und deswegen ist das ja sehr dienstleistungsnah natürlich.
Wolfi Gassler (00:08:53 - 00:09:15)
Okay, also dann kommt da kleine Individual-Contributor Andi zum kleinen Engineering-Manager Andi, oder ist es dann der große Andi, keine Ahnung, der andere Andi, Andi 2, Andi 1 zu Andi 2, und sagt, wir haben das Problem im Team. Was würde dann der Engineering-Manager Andi sagen? Du hast schon gesagt, du würdest Gegenfragen stellen. Du würdest nichts sagen, sondern Gegenfragen stellen. Was wären diese Fragen?
Andy Grunwald (00:09:15 - 00:09:29)
Genau, ich würde in so einer Art Coaching nicht Mentoring-Rolle, sondern in eine Coaching-Rolle verfallen und verfallen hört sich auch so, ich kann dagegen nichts tun an, so mache ich es nicht. Ich würde da aktiv reingehen und versuchen mit Gegenfragen die Situation zu verstehen.
Wolfi Gassler (00:09:29 - 00:09:42)
Wie willst du das? Moment, bevor du das beantwortest, du hast jetzt gesagt, du würdest nicht in die Mentoring-Rolle verfallen, sondern in der Coaching-Rolle bleiben. Woran legst du das fest? Wann du in die Mentoring-Rolle oder was ist für dich der Unterschied überhaupt?
Andy Grunwald (00:09:42 - 00:10:28)
Spannende Frage und ich werde jetzt glaube ich von diversen Coaches und Mentoren geschlagen, aber mein Verständnis von Coaching und Mentoring ist wie folgt. Coaches helfen Personen selbst das Problem zu lösen mittels Gegenfragen, Reflexion und Co. Zumindest wird die Reflexion angeleitet und getriggert. Bei Mentoren ist es eher so, dass aktiv nach Hilfe gefragt wird und die Mentoren dann sagen können, also ich war in so einer Situation auch mal, damals habe ich das so und so gelöst. Ja, dass man dann wirklich aktive Lösungsvorschläge sucht, wie der Mentor es gelöst hat. Das heißt nicht, dass man die Lösung kopieren sollte, aber ein Coach gibt in der Regel, sagt nicht, mach das, mach das. Mentoren sagen das auch nicht, aber Mentoren verweisen dann oft auf sich, weil sie in der Regel ja mehr Erfahrung haben als als der Mentee.
Wolfi Gassler (00:10:28 - 00:10:30)
Und wie entscheidest du das jetzt, was du machst?
Andy Grunwald (00:10:30 - 00:11:14)
Also bei der Frage ist das für mich relativ klar, zumindest im ersten Ansatz. Und zwar denke ich, dass Fokuszeit auch enorm viel Arbeit von dem Individual Contributor ist. Also ich denke, bis zu einem gewissen Grad kann ein Individual Contributor die Fokuszeit selbst steuern. und auch selbst erlauben und auch selbst andere Anfragen ignorieren. Wenn dieser Grad ausgereizt wird, dann kommt die Hierarchie und die politische Seite und die Organisationskultur und Coal, wo dann wirklich dann der die Vorgesetzte auch helfen kann. Aber da ich die ganze Situation noch nicht kenne, wie viel der Individual Contributor wirklich denn schon selbst tut, würde ich erstmal in eine Coaching-Rolle verfallen.
Wolfi Gassler (00:11:14 - 00:11:32)
Während du geantwortet hast, habe ich mir eigentlich überlegt, wie ich das entscheide, weil ich hätte es auch nicht auf Anhieb sagen können. Aber ich glaube, ich würde festmachen, erstens, wie viel Zeit ich habe, natürlich in irgendeiner Form. Also wenn man natürlich ausführlich Zeit hat, darüber zu sprechen in dem 101, dann kann man immer mehr coachen, meiner Meinung nach.
Andy Grunwald (00:11:32 - 00:11:36)
Moment mal, und wenn du die Zeit jetzt gerade nicht hast, dann nimmst du die dir am nächsten Tag, oder Wolfgang?
Wolfi Gassler (00:11:37 - 00:11:52)
Es kommt auch darauf an, wenn man sich jetzt am Gang trifft und jemand ist zum Beispiel schon gut vorbereitet oder auch im 101 ist eigentlich egal und kommt her und sagt, Wolfi, ich habe mir überlegt, es gibt A, B und C als Möglichkeit mit den, den und den Vorteilen. Was denkst du? Dann brauche ich nicht lange coachen.
Andy Grunwald (00:11:52 - 00:11:57)
Okay, stopp, Moment. Das ist ja eine ganz andere Herangehensweise. Das war ja nicht die Frage.
Wolfi Gassler (00:11:57 - 00:12:44)
Genau, also ich glaube auch, also ich würde es abhängig davon machen, wie viel hat sich die Person schon überlegt und ist die Person überhaupt fähig, also fähig im Sinne von hat die Person alle Informationen, um zum Beispiel eine Entscheidung zu treffen, weil wenn es irgendwas ganz oben in der Hierarchie ist und die Person überhaupt keine Ahnung hat, was da eigentlich abläuft und du als Engineering Manager vielleicht schon, dann brauche ich auch nicht coachen, weil da fehlen einfach die Grundinformationen, um was entscheiden zu können. Also, wenn das Wissen nicht da ist, dann ist es schwer zu coachen. Aber alles andere, würde ich sagen, würde ich schon mit Coaching versuchen, zumindestens, wenn die Person offen dafür ist. Und ich würde sagen, in 90 Prozent der Fällen ist eigentlich Coaching die bessere Variante, weil die Person dann einfach lernt, mit den Patterns umzugehen und vielleicht das nächste Mal selber die Entscheidung zu treffen, ohne mit dir durchzuspielen das Ganze.
Andy Grunwald (00:12:44 - 00:13:31)
Genau, mein Entscheidungsbaum war jetzt wirklich auf diese Frage mit dem Fokus bezogen. Wäre es irgendwas, wie soll ich das umsetzen oder welche Business Requirements haben wir, da muss ich jetzt nicht coachen. Natürlich kann man auch coachen, wie findest du heraus, welche Business Requirements man hat und so weiter und so fort. Natürlich, das geht auch. Da kommst du natürlich dann auf den Projektkontext an, was für eine Deadline haben wir und so weiter und so fort. Meine Entscheidung, wann Coaching und wann Mentoring angesetzt wird, auf diese Frage, war jetzt ganz spezifisch, weil ich denke, bei dieser Frage kann man als Individual Contributor sehr, sehr viel selbst machen. Und in meiner bisherigen beruflichen Laufbahn habe ich auch schon sehr, sehr viele Leute gesehen, die meines Erachtens nach auch wirklich die Basics noch nicht mal machen. Und deswegen erst mal Gegenfragen stellen. Wie wird man gestört?
Wolfi Gassler (00:13:31 - 00:13:34)
Ja, bleiben wir mal bei den Fragen. Was würdest du fragen?
Andy Grunwald (00:13:34 - 00:13:52)
Ja, ich würd mir einfach mal ne klassische Situation beschreiben lassen. Wie wird der Fokus interrupted? Was passiert dann? Was hast du erwartet? Was war deine Erwartungshaltung? Ja, ich code jetzt vier Stunden durch oder zehn Stunden oder wie lange auch immer. Und was ist dann passiert? Und dann einfach nur mal, okay, worum geht's hier eigentlich?
Wolfi Gassler (00:13:52 - 00:14:18)
Okay, dann nehmen wir mal an, es kommen ständig irgendwie Slack-Messages oder Teams oder was auch immer, vielleicht sogar echte Personen, wenn es noch sowas gibt am Schreibtisch und wollen irgendwas wissen, API oder keine Ahnung, wie irgendwas funktioniert von einer API von einem anderen Team, dass die API verwendet von deinem Team und da gibt es halt ständig irgendwie Kleinigkeiten, die man beantworten muss und man wird halt ständig aus seinem Flow herausgerissen.
Andy Grunwald (00:14:18 - 00:14:29)
Genau, da fängt's ja schon an. Ist ja schon komplett unterschiedlich. Wenn Slack-Nachrichten, Teams-Nachrichten, Google-Chat-Nachrichten kommen, meine erste Frage ist, hast du denn auch schon mal den Chat ausgemacht? Also das Programm geschlossen?
Wolfi Gassler (00:14:29 - 00:14:42)
Denn für mich... Ja, das kann ich ja natürlich nicht, weil die anderen Teams können ja dann womöglich gar nicht mehr weiterarbeiten. Wenn die POs mir da irgendwas fragen, dann sind ja zehn andere Teams, zehn andere Leute womöglich geblockt und können nicht weiterarbeiten. Ich muss ja antworten möglichst schnell.
Andy Grunwald (00:14:42 - 00:14:59)
Also meine Erfahrung ist immer, wenn ich eine Frage kriege, die ganz dringend ist, wenn man eine Viertelstunde nicht antwortet und dann erst antwortet, dann kommt meistens, ah, hat sich erledigt. Und wenn meine berufliche Laufbahn auch nur 50 Prozent stimmt, dann ist das schon okay, wenn man einfach mal für vier Stunden Slack ausmacht oder Teams und ähnliches.
Wolfi Gassler (00:15:00 - 00:15:06)
Ja, aber ich bin da nicht ein böser Programmierer. Ich will ja meinen Freunden, meinen anderen Programmierern in den anderen Teams helfen.
Andy Grunwald (00:15:06 - 00:15:07)
Wie oft liest du und beantwortest du E-Mails?
Wolfi Gassler (00:15:08 - 00:15:21)
Ja, weil E-Mails ist alte Tradition, alte, ist komplett Oldschool-Technologie und Kommunikation. Das machen noch irgendwie, das macht die deutsche Bahn oder so vielleicht. Aber wir im jungen, modernen Start-up machen das natürlich nicht.
Andy Grunwald (00:15:21 - 00:15:29)
Welche Erwartungshaltung hast du, wenn du eine E-Mail versindest? Keine. Das bedeutet auch, die Antwort kann in einer Stunde kommen oder in einer Woche, oder?
Wolfi Gassler (00:15:29 - 00:15:34)
Kommt natürlich immer auf die Frage drauf an. Mir wäre es natürlich immer am liebsten, wenn ich sofort eine Antwort bekommen würde.
Andy Grunwald (00:15:34 - 00:15:38)
Klar, aber die Realität ist, eine Woche, wenn du überhaupt eine E-Mail, eine Antwort bekommst.
Wolfi Gassler (00:15:39 - 00:16:03)
Ja, innerhalb der Firma erwarte ich mir das natürlich schon. Aber die Frage, die ich mir natürlich auch immer stelle, um mal die Seite jetzt zu wechseln, ist, was ist, wenn die Person auf Urlaub ist oder krank ist? Dann bekomme ich auch keine Antwort und heißt es dann, dass mein Team komplett geblockt ist und steht irgendwie zwei Tage lang, weil jemand gerade Covid hat zum Beispiel. Wenn das der Fall ist, dann habe ich, glaube ich, wirklich ein Problem in meiner Firma.
Andy Grunwald (00:16:03 - 00:18:38)
Ja, dann hast du aber nicht ein Problem mit Fokus, dann hast du ein ganz anderes Problem. Dann hast du ein Buzzfactor-Bottleneck-Problem, dann hast du viele Dokumentationen, dann hast du Knowledge-Silos aufgebaut. Aber ich habe dieses provokante Beispiel mit den E-Mails gebracht, weil ich der Meinung bin, ein Google-Chat, ein Microsoft Teams, ein Slack ist das neue E-Mail. Man drückt halt nur nicht wirklich A mit Betreff und allem drum und dran, es ist genau das Gleiche, weil der Betreff ist der Channel. Also du kannst alles eigentlich so übersetzen, Und ich verstehe nicht, woher die Erwartungshaltung kommt, dass auf eine Slack-Nachricht binnen Sekunden geantwortet werden muss. Deswegen, in der Hinsicht würde ich erst mal fragen, okay, mach doch einfach mal Slack oder Microsoft Teams aus. Ja, aber was ist denn, wenn ich meinen Teammitgliedern antworten möchte? Dann sag ich, ja, okay, dann mach das bitte morgens. Oder du merkst schon, so wie ich jetzt grade rede, ich verfall schon wieder in Lösungsmodus. Das ist natürlich nicht das, was ich möchte, weil ich möchte, dass die Person selbst draufkommt. Ich würd das als Frage formulieren. und dann würde ich fragen ja aber wäre es denn auch möglich dass du das zu gewissen zeiten machst morgens wenn du an den rechner gehst und dann kurz bevor du zum mittagessen gehst oder ähnliches ja halt so so fokus sein du schaust zwei bis dreimal da rein irgendwie morgens um acht wenn du deine arbeit beginnt dann mittags um zwölf, Und dann nochmal abends um vier oder um fünf Uhr. So, dann hast du drei Spots. Und der Rest, stell dich auf, du bist im Meeting oder mach deinen Status so nach dem Motto Focus Time, Answer Delayed oder ähnliches. Und deswegen, also wenn die Nachrichten remote kommen via Chat, würde ich erstmal halt mit Fragen und Coaching in diese Richtung gehen. Und erfahrungsgemäß, sehr viele Leute machen das nicht. Sehr viele Leute haben sogar aktiv dieses Bing, aktiv bei jeder nachricht kriegen dieses bing ich denke mir was das denn das ist ja noch schlimmer als slack auf haben und dann so ein roten so eine rote fünf für ich habe fünf neue nachrichten ja das ist ja schon okay wenn man das bing aus hat, aber beim tap switchen sieht man es halt trotzdem a fünf nachrichten ich kann ja mal eben gucken und wenn es halt aus hast dann hast du es halt wirklich aus und deswegen sage ich das ist ja schon ein großer unterschied eine virtuelle nachricht zu bekommen oder da steht jemand bei mir am tisch jetzt switche ich hier gerade zwischen diesem netten Coaching-Approach, den ich gerade völlig versaut habe, weil ich einfach nur irgendwelche Lösungen, mögliche Lösungen rausgehauen habe. Also verzeiht mir in der Hinsicht. Deswegen, Wolfgang, wie sieht denn dein Coaching-Aspekt aus, beziehungsweise Mentoring-Aspekt? Wie siehst du die ganze Frage?
Wolfi Gassler (00:18:39 - 00:18:46)
Das heißt, du verfällst jetzt in die andere wichtige Richtung von dem Engineering-Manager ins Delegieren. Du delegierst das jetzt an mich weiter.
Andy Grunwald (00:18:47 - 00:19:05)
Ja, aber das ist jetzt hier, weil ich mich gerade so wieder in Rage geredet habe, ja, mit diesem Bing und so. In dem One-on-One bin ich natürlich anders, weil da sitze ich ruhig und allem und dann nehmen wir Zeit und dann fokussiere ich mich, aber hier, da habe ich mich jetzt ein bisschen in Rage geredet, deswegen tut mir wirklich leid. Also, wie sieht es auf deiner Seite aus?
Wolfi Gassler (00:19:05 - 00:21:07)
Ja, also ich stelle auch immer ganz gerne Fragen. Vor allem bringt es mir dann Zeit, dass ich mir Gedanken darüber mache, über das ganze Thema. Das ist immer super. Es bringt mir die Zeit und der anderen Person hoffentlich bringt auch was. Also auch ganz klassisch der Coaching-Ansatz. Was ich mir natürlich auch überlegen würde, jetzt so vom Scope eigentlich von dieser Frage, woher kommt die Erwartungshaltung, so wie du jetzt schon gesagt hast? Aber gibt es vielleicht jetzt in der ganzen Company irgendwie die Erwartungshaltung, dass Leute antworten müssen sofort oder dass das andere einfach alle machen und dadurch so eine implizite Erwartungshaltung entsteht, was glaube ich ein großes Problem ist, wenn das in der Company natürlich der Fall ist. Also dann muss man da glaube ich auf einem ganz anderen Level ansetzen und was natürlich schwierig ist, dass Engineering-Manager nach oben hin irgendwie was machen, aber das ist halt auch die Aufgabe von Engineering-Managern, dass man einfach dann mit den eigenen Leads rede, Direktors, CTOs, was es auch immer ist und auf der Ebene was ändert. Und sonst würde ich mir auch eben die Frage stellen, hat dieses Problem nur eine Person oder mehrere Personen im Team? Also wenn jetzt eine Person auf mich zukommt und sagt, Wir haben, meistens ist es ja so, wir sind alle, weil sagt ja nie jemand, ich habe das Problem. Ganz oft ist es, wir alle haben das Problem automatisch. Dann würde ich das auch mal probieren rauszufinden, hat das Problem wirklich jeder im Team oder ist das ein teamweites Problem? Weil dann würde ich probieren, diese Coaching-Session aufs Team überzustülpen. Also, dass man wirklich einen Termin ausmacht mit den Teammembers und dann alle befragt, okay, scheinbar gibt es dieses Problem, wir werden zu oft gefragt. Wir bekommen ständig irgendwelche Messages rein. Gerade so wie du es gehabt hast, als serviceorientiertes Team hat man wahrscheinlich ständig den Input. Und dann kann man sich als Team in der Gruppe überlegen, was kann man dagegen tun und was für Möglichkeiten gibt es, darauf zu reagieren. Zum Beispiel der Klassiker ist halt, dass man einen Channel hat. Ich glaube, ihr hattet das dann am Ende auch. wo alle Anfragen gestellt werden können und dann gibt es halt immer eine verantwortliche Person pro Tag oder so, die die ganzen Fragen annimmt. Dann hat der Rest zum Beispiel vom Team die Ruhe. Also sowas kann ja unter Umständen auch der Fall sein.
Andy Grunwald (00:21:07 - 00:22:05)
Ich hab grad so viele Antworten in meinem Kopf. Also, erste Thematik ist diese implizite Erwartungshaltung. Ich mein, was erwartest du? Die meisten Firmen führen irgendwie so was wie Slack, Microsoft Teams ein, um dynamischer, um agiler zu sein, um schneller zu kommunizieren, ja? Und irgendwann denkt sich halt die Personalabteilung oder interne Kommunikationsabteilung aus, oh, wir müssen Kommunikationsregeln festlegen. Ich find's immer schwierig, diese Kommunikationsregeln festzulegen, denn das ist Kultur, ja? wenn jetzt unter eine spaßige nachricht die ganzen emojis fliegen und jeder hat die möglichkeit neue emojis in slack einzufügen dann ist das halt schon eine gewisse art von kultur und diese freiheit auch zu lassen und jetzt jedes mal diese regel ja ihr müsst nicht sofort antworten es ist schön wenn man diese regel setzt und aufschreibt aber es ist halt immer noch so okay wie lebst du das ja und die meisten leute leben ist halt schnell zu antworten da muss man einfach ganz offen und ehrlich drüber stehen, Also da muss man einfach hart bleiben.
Wolfi Gassler (00:22:05 - 00:22:59)
Ja, wie es so schön heißt, die Kultur ist das, was jeder macht. Aber ich muss schon sagen, also gerade im Tech-Umfeld, wo halt auch anders gearbeitet wird, wo Fokus extrem wichtig ist, finde ich auch, dass es die Aufgabe zum Beispiel von dem CTO ist, genau darauf zu achten und wenn er merkt, bei den Dev-Teams ist das ein Problem, dass er zum Beispiel auch kommuniziert, das muss ja keine geschriebene Regel sein, aber dass der zum Beispiel sagt, okay, unser Chat, unser Slack ist asynchron und asynchron heißt auch, dass Developer in den Flow kommen müssen und dass das einfach wichtig ist und das ist ein Unterschied, ob das ein CTO an oberster Ebene sagt, oder eben nur irgendein Engineering Manager oder überhaupt nur jemand im Team probiert, das voranzutreiben, wenn halt in der Firma einfach normalerweise ganz schnell Nachrichten herumfliegen. Also ich glaube, das ist schon die Aufgabe vom Management, das dementsprechend in die richtigen Wege zu lenken, ohne da jetzt irgendwie harte Regeln oder sowas aufzustellen.
Andy Grunwald (00:23:00 - 00:25:02)
Guter Punkt in der Remote First Company ist asynchrone Arbeit. Ich sag mal so ein First Citizen. Also da ist das gelebt. Da geht's gar nicht anders, weil jeder sitzt gegebenenfalls sogar zu anderen Zeitzonen. Das ist die eine Baustelle. Die zweite Baustelle, wenn man das nicht irgendwo aufschreibt, dann hat man das Problem, der CTO sagt das irgendwie beim All Hands. Und alle New Joiner, alle Leute, die nach dem All Hands anfangen, kennen diese Regel nicht. Und umso schneller du neue Leute anstellst, je mehr und mehr verwässert sich diese Ansprache, Slack ist asynchron. Das ist ein Riesenproblem, weil du sagst es ja in diesem Moment und somit nur für diese Leute, die jetzt zuhören, aber nicht für alle Leute, die dir nachkommen. Das ist die eine Baustelle. Und was du jetzt gerade mit dem Channel gesagt hast, dass du einen Channel hast, Leute kommen dahin, stellen die Fragen und du hast dann einen, ich sag mal einen Channel-Beauftragten, der für eine Woche dann die Fragen beantwortet, kann man machen. Geht natürlich in den Lösungsansatz, irgendwie diese Anfragen zu kanalisieren und halt zu strukturieren. Es ist genauso wie ein IT-Helpdesk, weil ein IT-Helpdesk ist eigentlich nichts anderes. Da kommt jemand, der will einen neuen Laptop haben oder hat Probleme mit seinem Outlook, weil das Fenster nicht geschlossen kriegt oder ähnliches, weil es ist ja nichts anderes. Das bedeutet, da kann auch ein Jira-Ticket erstellt werden und dann geht das alles in eine Queue und jemand arbeitet das ab. Das Tolle an diesen Arten ist natürlich, dass man je nachdem, nach dem Fragenvolumen, wie viele Fragen man bekommt, dass man natürlich dann hinterher hingehen kann. Nach einem monat und durchschaut okay wie oft kommt denn die selbe frage und da kann daraus das irgendwie ein feature in das produkt einbauen als self service oder dokumentation schreiben oder oder oder das ist natürlich eine tolle sache aber es ist natürlich auch immer so eine wie soll man sagen so eine so eine schmerzenswoche weil niemand. ist gerne dieser channel beauftragte für eine woche weil du kannst ja in der regel nicht wirklich viel machen weil du hast ja nicht so viel fokuszeit weil du kriegst ja öfters fragen und so also das macht ja keinen spaß das ist so wie eine woche on call inklusive nachts wo du sechs incident die woche hast also das macht halt auch keinen spaß egal wie viel geld du kriegst.
Wolfi Gassler (00:25:02 - 00:25:26)
Der Vorteil, den du jetzt gerade erwähnt hast bei so einem Channel, wenn da vielleicht schon Sachen drinstehen, die man schon mal beantwortet hat, das ist das Paradebeispiel, wenn da irgendein Bot oder ein LLM im Hintergrund irgendwie mitläuft, das dann darauf hinweist, hey, diese Frage gab es schon einmal. Hast du das mal in der Realität erlebt oder in der Praxis? Es gibt ja schon so Plugins. Hast du irgend so was schon mal erlebt, wie die funktionieren oder ob die irgendwo im Einsatz sind?
Andy Grunwald (00:25:27 - 00:25:41)
Wenn ich jetzt an aktuelle, an aktuelle Large Language Models denke, dann denke ich nicht daran, hey, diese Frage gab es schon mal, sondern, dass der eher dann versucht, eine Antwort auszuspucken, die ich dann sehr gefährlich finde, weil diese LLMs ja eher die Worte generieren, anstatt die Fakten rauszuholen.
Wolfi Gassler (00:25:41 - 00:25:48)
Ja, aber das kann ja auch mit, das kann ja mitlernen, das LLM. Oder eben auch nur darauf hinweisen, da gab es eine Frage schon, die so ähnlich war.
Andy Grunwald (00:25:49 - 00:26:24)
Genau, also wenn man die Funktionalität darauf begrenzt, hey, eine ähnliche Frage wurde dargestellt. Ich glaube, das kriegen LLMs gut hin. Direkt die Antwort zu generieren und dabei sicherzustellen, dass es die richtige Antwort ist, ist, glaube ich, immer noch ein bisschen schwierig. Aber nein, habe ich so noch nichts, mindestens nicht im internen Chat oder ähnliches gesehen. Was man natürlich schon gesehen hat, ist, wenn du irgendwo eine Frage eintippst und dir dann ein Bot automatisch irgendwie einen Link zu so einer FAQ oder ähnliches schickt. Also sowas schon und ja, das hat an hier und da auch mal ganz gut funktioniert. Aber das macht Google auch ganz gut, muss ich zugeben. Dafür brauche ich jetzt kein LLM.
Wolfi Gassler (00:26:25 - 00:26:46)
Ja, es geht ja wirklich um Internetchats normalerweise. Ich kann mich auch nur erinnern, ich habe das schon ein paar Mal erlebt, aber das war sehr rudimentär und natürlich noch vor der LLM-Zeit. Würde ich sehr spannend finden. Also wenn jemand das in der Praxis irgendwie verwendet, so ein Bot oder sowas in der Richtung, bitte meldet euch bei uns mal und lasst uns wissen, wie das funktioniert. Am besten in unserer Discord-Community.
Andy Grunwald (00:26:47 - 00:27:36)
Also ich glaube halt schon, dass dies in Zukunft auch schon so ein gewissen Standard wird. Doch auf der anderen Seite denke ich, dass ziemlich viele deutsche Firmen oder auch internationale Firmen gerade immer noch mit den Datenschutzrichtlinien ein bisschen kämpfen. Okay, inwieweit kann man denn so eine KI oder so ein LLM auf meine Daten loslassen? Habe ich da eine Hosted Version oder so eine Secure Version oder nutze ich dann das Public Chat GPT? Wie viel kostet das? Und so weiter und so fort. Ich glaube, da beißen die meisten Firmen sich gerade noch die Zähne aus, bevor das dann wirklich in der breiten Masse ankommt. Aber kommen wir mal wieder zurück zum Thema. Was würdest du denn machen, wenn wir jetzt in einer Bürosituation sind und jede Stunde steht mindestens jemand vor deiner Tischgruppe von deinem Team? Das ist ja schon eine andere Situation, als wenn das virtuell passiert. Wie würdest du da versuchen, den Fokus beizubehalten?
Wolfi Gassler (00:27:37 - 00:28:30)
Ja, als Individual Contributor würde ich auf jeden Fall mal das probieren, im Team zu besprechen. Man muss ja auch gar nicht unbedingt sofort zum Engineering Manager gehen, sondern kann das ja auch mal im Team besprechen, ob das andere auch so sehen. Und ich glaube, dann ist gar nicht so viel Unterschied zwischen physikalisch und online. Du hast halt nur andere Mechanismen. Online kannst du halt einen Status setzen, du kannst in Slack sagen, die nächsten drei Stunden bin ich auf Away oder auf Focus Time oder sonst irgendwas. Und du musst im Prinzip nur in der echten physikalischen Welt eine ähnliche Message finden. Und die ist vielleicht jetzt nicht so klar kommunizierbar, aber im Prinzip kannst du dasselbe machen. Du kannst Kopfhörer aufsetzen und vielleicht intern wenigstens die Regel aufstellen, wenn man Kopfhörer auf hat, dann will man ungestört sein. Du kannst einfach probieren, dich möglichst nicht ablenken zu lassen mit Kopfhörern und in einem Bild zu starren. Teilweise funktioniert das auch, dass Leute dann sich nicht trauen, dich anzusprechen. Das kann durchaus auch funktionieren.
Andy Grunwald (00:28:30 - 00:28:37)
Ja Moment mal, obwohl man natürlich, wenn man da jetzt versucht zu starten und jemanden im Augenwinkel sieht, dann hat man den Fokus ja schon verloren. Also dann ist es ja auch egal.
Wolfi Gassler (00:28:38 - 00:28:56)
Ja, aber vielleicht wird es dann mit der Zeit weniger, weil es sind ja doch immer dieselben Personen meistens. Und sonst muss man halt noch noch härtere Geschütze auffahren. Also man kann ja irgendwelche schon erlebt, dass irgendwelche Fahnen oder Do Not Disturb Me Schilder quasi aufgestellt werden. Also auch sowas habe ich schon in der Realität miterlebt.
Andy Grunwald (00:28:56 - 00:28:58)
Hast du das jemals funktionieren sehen?
Wolfi Gassler (00:28:59 - 00:29:48)
Also das Beste, was eigentlich funktioniert hat, ist eigentlich die Kopfhörer, weil sich das auch da wieder Kultur, Firmenkultur irgendwie so rumgesprochen hat oder fast so Standard war, dass wenn Kopfhörer oben sind, dass man nicht gestört werden will. Und wenn man dann Noise-Cancellation-Kopfhörer hat, funktioniert das eh relativ gut. Also wenn man dann nicht aus dem Augenwinkel die Leute wirklich sieht oder so oder die nicht so rankommen. Also das hat Meines Wissens sehr gut funktioniert. Also ich habe die Rückmeldung bekommen, dass es eigentlich am besten funktioniert hat. Also so Schilder sind natürlich hardcore, aber unter Umständen können die auch was bringen. Oder einfach, dass man halt die Tische so anordnet, dass es vielleicht schwieriger ist, einfach auf einen zuzukommen. Und die andere Variante ist einfach auch, den PO zum Beispiel vorzuschicken. Dass man einfach immer die Leute weiterleitet an den PO und vielleicht schleift es sich dann irgendwann ein, dass der PO verantwortlich ist für sowas. Also da würde ich den PO einfach auch einspannen.
Andy Grunwald (00:29:48 - 00:30:32)
Was ich auch schon erlebt habe, viele Firmen haben ja dieses Flexi-Desk-System, dass man gar keinen festen Sitzplatz mehr hat, sondern sich eigentlich überall hinsetzen kann oder sich vielleicht sogar jeden Morgen einen Tisch buchen muss, weil gar nicht mehr genug Tische für alle Mitarbeiter vorhanden sind. Und ich habe auch schon erlebt, dass jemand kommt zu unserem Team, weil die Person was fragen möchte und alle sitzen da total fokussiert. Noise-Canceling-Headphones sind am Coden oder am was auch immer machen. Die Person hat sich dann in die Nähe gesetzt, an einem leeren Schreibtisch, hat gearbeitet und hat gewartet, bis die Person, die er kontaktieren wollte, aufgestanden ist und in die Küche gegangen ist oder ähnliches, um sich einen Kaffee zu holen. Und ist dann hinterher, um dann die Frage zu stellen. Was hältst du von diesem Approach?
Wolfi Gassler (00:30:33 - 00:31:08)
Superhöflich. Also, wenn man das machen kann, ist es natürlich super. Aber es ist natürlich auch hardcore, wenn man so viel Zeit investieren muss. Aber auch da bin ich wieder der Meinung, wenn man den Approach aus der Online-Welt in die physikalische überträgt, dass man so einen Channel hat, dann muss man halt auch wieder ein Schild haben oder so, ich bin der Verantwortliche, der für Fragen da ist. Weil ich kenne das selber, das ist verdammt unsympathisch. Du gehst zu einem Team hin und jeder dreht den Kopf weg. Nur nicht zu mir. Bitte. So in der Richtung. Und du denkst dir, oder teilweise auch eine Einzelperson. Du sitzt dich zu einer Einzelperson hin und die ignoriert dich einfach.
Andy Grunwald (00:31:08 - 00:31:11)
Wie früher der Lehrer, wenn er eine Frage gestellt hat in der Schule.
Wolfi Gassler (00:31:11 - 00:31:30)
Also das ist teilweise wirklich extrem hart und ich finde das auch sehr unsympathisch. Also umso strukturierter das Ganze ist und das Team für sich strukturiert und eben vielleicht eine Anlaufposition schafft in der physikalischen Welt irgendeinen, ich bin da, wie habt ihr das immer genannt online? Der Mensch, der zuständig ist an dem Tag.
Andy Grunwald (00:31:30 - 00:31:45)
In der aktuellen Firma nennt das Kafka-Team, weil wir haben für jedes Datenbankprodukt so ein Ask-Kafka-Channel, und das Kafka-Team nennt die Person, die den Ask-Channel Ask-Kafka-Maintained, den Zookeeper.
Wolfi Gassler (00:31:45 - 00:32:08)
Ja, genau. Also, I'm the zookeeper. Please approach me. Happy to help. Du kannst ja alles hinschreiben und auch auf einen Tisch kleben oder ein kleines Schild. Das kannst du dir einfach ausdrucken. Das ist komplett egal. Das muss ja kein sophisticated Ding sein. Also ich glaube, man muss da einfach probieren, Lösungen zu finden und einfach Sachen auszuprobieren. Darum finde ich das so cool, wenn man das im Team bespricht, weil da kommen garantiert ein paar Ideen, wie man das lösen kann.
Andy Grunwald (00:32:09 - 00:32:16)
Du hattest aber gerade so ein bisschen so abwertend gesagt, ja dann schicke ich halt den Product Owner vor. Wieso nimmst du eigentlich an, dass der Product Owner keine Fokustime benötigt?
Wolfi Gassler (00:32:16 - 00:32:47)
Ja, das war jetzt nicht so abwertend gemeint, aber der Product Owner, eine Aufgabe vom Product Owner sehe ich schon auch, die ganzen Stakeholder in Zahm zu halten und zu kommunizieren mit denen und das ist schon eine gewisse Aufgabe von dem. Natürlich, der kann genauso Fokustime haben, der kann sich auch in den Meetingraum setzen, Man kann es auch durchcodieren, wenn es ein Problem ist. Aber ich sehe es schon eher bei einem Product Owner als bei einem Developer grundsätzlich an, so klassische Support-Anfragen auch von anderen POs vielleicht einfach aufzufangen oder zu beantworten. Also das sehe ich schon eher bei der PO-Rolle.
Andy Grunwald (00:32:48 - 00:33:29)
Du sagtest gerade rot-ton, ja ein Product Owner kann auch schon Fokuszeit haben. So ein Product Owner ist verantwortlich für die Produktstrategie, für die Roadmap, fürs Planning, für die Industry Insights. Wohin geht die Industrie, was wollen die Kunden, wie verhält sich eigentlich gerade der Markt und so weiter und so fort. Das ist ein Knowledge Worker wie Wie Softwareentwickler auch, wie kommst du darauf, dass das, also wenn ich mir jetzt den Artikel von Paul Graham, Makers Schedule und Managers Schedule in den Kopf rufe, dann hört sich das so an, als würdest du sagen, dass der Product Owner eher in die Managers Schedule passt, anstatt in die Makers Schedule.
Wolfi Gassler (00:33:30 - 00:33:44)
Ja, ich würde auf jeden Fall sagen, dass der Product Owner in seiner Rollenbeschreibung Stakeholder-Management drin hat. Hingegen ein Developer hat kein Stakeholder-Management oder Communication mit Stakeholdern. Bitte? Standardmäßig in der Job-Description.
Andy Grunwald (00:33:44 - 00:33:51)
Also du willst mir sagen, ein Senior-Entwickler hat kein Stakeholder-Management drin? Aber hallo! Sogar umso wichtiger.
Wolfi Gassler (00:33:52 - 00:34:51)
Ja klar, umso höher, umso mehr, das stimmt schon. Aber ich würde sagen, PO ist immer auf einem anderen Level diesbezüglich. Also ein PO, der ist verantwortlich für das Produkt, der muss mit externen Teams kommunizieren, also der hat das schon sehr stark in seiner Rolle drin. Und auf der Developer-Seite ist das schon weniger. Natürlich haben die auch viel Kommunikation, das kann aber dann eher auf der technischen Seite sein. Und ich würde mal sagen, weniger klassische Support-Anfragen oder Produkt-Anfragen oder so von anderen Teams. Da sehe ich schon einen Product Owner mehr eigentlich in dem Umfeld. Das heißt nicht, dass der 24-7 verantwortlich ist für einen Channel, aber dass der gewisse Sachen abfängt und bündelt, würde ich schon auf seiner Seite ansiedeln. Aber klar, der hat natürlich genauso Fokus-Time. Developer hat auch nicht immer Fokus-Time, auch nicht 8 Stunden Fokus-Time. Natürlich muss der mal Sachen beantworten. Aber umso koordinierter das Ganze abläuft natürlich für die meisten Developer umso besser. Es gibt auch Developer, denen ist das komplett egal und die können Kontext switchen, so viel es nur geht.
Andy Grunwald (00:34:51 - 00:34:58)
Das ist aber auch nur eine Lüge, weil jeder Kontext switch schlägt auf die Produktivität. Da sind manche Leute nicht immun gegen.
Wolfi Gassler (00:34:58 - 00:35:02)
Ja, aber es gibt Leute, die können besser damit umgehen und Leute, die können weniger gut damit umgehen.
Andy Grunwald (00:35:02 - 00:35:20)
Du bist korrekt, aber der Output leidet trotzdem darunter. Und gehen wir mal auf die originale Frage vom Tom. Da geht es ja wirklich darum, wie man sicherstellt, dass die Directs oder sich das Team voll und ganz auf die Arbeit konzentrieren kann, ohne dass Ablenkungen durch Google Chat kommen. Bei Context Switchen kann man sich halt nicht voll und ganz auf die Arbeit konzentrieren.
Wolfi Gassler (00:35:21 - 00:35:40)
Ja, aber wenn jetzt zum Beispiel ein Developer das gerne macht und der einfach glücklich ist in dem, dass er mit vielen Leuten redet, also so der Anlaufpunkt ist, dann ist es vielleicht für den seine Produktivität besser, wenn er diesen Job übernimmt, als wenn er mehr Fokus da im hat, wenn ihm persönlich das mehr liegt. Also ich glaube, das kommt schon sehr auf die Charaktere auch an.
Andy Grunwald (00:35:40 - 00:35:43)
Ketzerische Frage, sollte der Developer dann Product Owner werden?
Wolfi Gassler (00:35:43 - 00:35:44)
Könnte man natürlich auch sagen, ja klar.
Andy Grunwald (00:35:45 - 00:36:00)
Jetzt sprechen wir aber die ganze Zeit von Ad-Hoc-Kommunikation. Wir sprechen von jemand steht bei dir am Schreibtisch, wir sprechen von einer Slack oder Microsoft Teams oder Google Chat Nachricht. Aber wie sieht es denn aus, wenn ich dir, du Wolfgang, alter Mid-Level-Software-Ingenieur...
Wolfi Gassler (00:36:00 - 00:36:04)
Aber immerhin bin ich schon Mid-Level. Früher war ich nur Junior-Developer bei dir.
Andy Grunwald (00:36:05 - 00:36:06)
Auch du wurdest promotet über 100 Episoden.
Wolfi Gassler (00:36:07 - 00:36:08)
Danke.
Andy Grunwald (00:36:08 - 00:36:16)
Was ist denn, wenn ich dir diverse Meetings über einen 8-Stunden-Tag, alles immer mit so einer Dreiviertelstunde Pause dazwischen reinsetze?
Wolfi Gassler (00:36:16 - 00:36:19)
Warum kannst du mir überhaupt Meetings reinsetzen?
Andy Grunwald (00:36:19 - 00:36:31)
Weil ich dein Manager bin. Die rollen hier im Podcast nicht klar. Müssen wir darüber noch mal iterieren. Also ich meine, dein zerfetzter Kalender ist ja keine Art Hock-Kommunikation, aber sie zerstört ja auch den Fokus. Wie gehst du da ran?
Wolfi Gassler (00:36:32 - 00:37:11)
Ich würde fast sagen, dass das genau die gleiche Fragestellung ist wie bei den Slack-Messages, nur halt auf einer anderen Ebene und vielleicht ist es halt nicht nur eine Message, sondern ein langes Meeting. Aber im Endeffekt muss man sich überlegen, lasse ich mir das gefallen und was kann ich dagegen tun? Und auch da würde ich eigentlich wieder denselben Approach wählen, wenn es ein Teamproblem ist, im Team darüber sprechen, auch mit dem Manager, mit der Managerin, was können wir dagegen tun. Und in dem Fall ist es natürlich ein bisschen anderes, weil man Teams, weil man Meetings wirklich ablehnen muss und das muss man vielleicht dann auch anders kommunizieren, weil im Normalfall Messages beantworte ich immer, wenn ich ein Meeting ablehne, ist es halt weg.
Andy Grunwald (00:37:11 - 00:37:15)
Aber welche konkreten Lösungsansätze fallen dir denn jetzt gerade mal ein?
Wolfi Gassler (00:37:15 - 00:38:22)
Wenn ich es mir so richtig überlege, ist es noch mehr eigentlich Team-Effort bei dem Ganzen. Weil eigentlich, was ich sicherstellen muss, üblicherweise ist, bei Meeting-Anfragen, dass es in irgendeiner Form, wenn es teamrelevant ist zumindestens, dass es schon vom Team irgendwie übernommen wird. Also dass vielleicht eine Person vom Team hingeht, sofern es relevant ist natürlich für das Team. Also das ist eine Grundsatzfrage, ist es relevant oder nicht. Aber ich habe das schon sehr oft erlebt, dass sich da so ein Prozess einschleicht, dass man immer das gesamte Team einlädt. Und dann erwartet man oder das Team denkt sich, es müssen möglichst viele Leute hingehen. Und das ist schon ein Grundproblem. Also da würde ich sagen, ist halt dann sinnvoll, dass man eine Person schickt, zum Beispiel nur als Team. Finde übrigens auch ein Problem bei E-Mails, wenn man einfach immer alle CC setzt, weil auch das kann in extreme Probleme enden, dass man dann so viele E-Mails hat und keiner liest sie mehr und es killt eigentlich mehr Zeit, als es irgendwie bringt, die Informationen so zu distribuieren. Also mit Maß und Ziel macht es sicher Sinn, also wenn es um Teams geht. Und ganz allgemein hast du ja gerade einen super tollen Blogartikel geschrieben zu dem Thema.
Andy Grunwald (00:38:22 - 00:38:49)
Ich wollte gerade darauf ansprechen, irgendwie war das, ich weiß jetzt nicht, ob das geskriptet war, von dir Wolfgang, weil bei mir war es nicht geskriptet, aber in der Tat, diese inflationäre Nutzung von, ich lade mal einfach jeden ein, damit einfach jeder Bescheid weiß, da kann sich niemand rausreden, dass er oder sie nicht Bescheid wusste, da kriegt ihr die Kretze. Und jeder hat immer zu viele Meetings. Also ich denke, dass wenn du in deinen Kalender gehst, gut, du bist jetzt Freelancer, aber angenommen, du bist Arbeitnehmer, Angestellter.
Wolfi Gassler (00:38:49 - 00:38:52)
War ja schon auch mal, also kannst du schon auch annehmen.
Andy Grunwald (00:38:52 - 00:39:02)
Und du cancelst einfach 50% deiner Meetings pro Woche. Ich denke, für dich, für deinen Arbeitsalltag, ändert sich sehr, sehr wenig.
Wolfi Gassler (00:39:02 - 00:39:03)
Ja, das würde ich unterschreiben, ja.
Andy Grunwald (00:39:04 - 00:39:55)
Und deswegen habe ich bei einem früheren Arbeitgeber, Mitte 2013 war das, Anfang 2013 habe ich da angefangen, Mitte 2013 wurde mir eine tolle Regel gelehrt, die auch von der Firma getragen wurde. Und zwar hieß sie, du kannst jedes Meeting absagen, solange du mit dem Ergebnis leben kannst. Das hört sich total simpel an, aber sei doch mal ehrlich, wie viele Meetings sagst du denn wirklich ab, wenn du eine Einladung bekommst? Und ich rede jetzt nicht von diesem Standardgeschwafel. Bei uns muss jedes Meeting eine Agenda haben und Meeting-Notes und klar. Und wenn in der Einladung keine Agenda drin ist, dann sage ich das ab. Ach hör doch auf. Ja, das ist eine tolle Regel, die wird irgendwie gesetzt, aber im Endeffekt macht sie eh keiner. So. Punkt ist, wie viele Meetings sagst du wirklich ab? So nach dem Motto, hey, du brauchst meinen Input hier nicht. Ich kann mit dem Ergebnis leben, was ihr entscheidet.
Wolfi Gassler (00:39:55 - 00:40:27)
Ich habe da auch mal eine sehr coole Vorgehensweise erlebt von einem CEO, der hat einfach jedes Meeting abgelehnt, standardmäßig. Also den hast du nochmal persönlich anschreiben müssen, warum er wirklich gebraucht wird und warum er unbedingt mit dabei sein muss und hat das dann meistens auch gechallenged, muss er wirklich dabei sein und nur dann hat er ein Meeting akzeptiert. Also der ist sogar diese Schiene gefahren, ich lehne einfach alles ab. Und wie du richtig sagst, wenn man mit dem Resultat zufrieden ist, wenn man nicht dabei ist, ablehnen. Ganz klar.
Andy Grunwald (00:40:27 - 00:41:56)
Natürlich muss dann in irgendeiner Art und Weise so eine Grunddokumentation da sein, damit andere Leute, die nicht an dem Meeting teilgenommen haben, verstehen, was war denn jetzt das Ergebnis. Und wenn man auch trotzdem etwas Wertvolles an Informationen für das Meeting hat, für die Entscheidung, kann man das natürlich auch per E-Mail kurz vorher mit dem Meetingveranstalter irgendwie teilen. Hey, pass mal auf. hier hast du meine drei punkte die hätte ich dazu sagen wäre toll wenn er die mit in die entscheidung einfließen lässt und das reicht ja buff eine stunde gespart du hattest fünf minuten tipp arbeit und das war's und man muss sich ja auch mal ganz ehrlich fragen weil wir arbeiten ja mit menschen und überall wo menschen sind ist auch politik und ja jeder sagt immer es gibt keine firmenpolitik aber doch es gibt sehr viel firmenpolitik Also muss man sich auch mal fragen, ist die Entscheidung, die in dem kommenden Meeting getroffen werden soll, nicht eigentlich schon getroffen? Also kann ich die überhaupt beeinflussen? Also bin ich irgendwie der Entscheidungsträger oder Entscheidungsträgerin oder wird nach Input gefragt, was die Entscheidung beeinflusst? Und auch da Ich würde mal fast sagen 60, 65 Prozent eurer Meetings. Ist die Antwort nein. Die Entscheidung ist entweder schon gefallen oder du kannst sie nicht beeinflussen, weil die Entscheidung auf Basis von anderen Fakten, wirtschaftlichen Fakten, Geld, jemand war Golf spielen oder was weiß der Geier nicht getroffen wird. Und ist das traurig? Ja natürlich ist das traurig. So ist in vielen Firmen leider die Realität.
Wolfi Gassler (00:41:57 - 00:42:41)
Was man sich auch noch fragen kann, ist, kann man wirklich was beitragen zu dem Goal von diesem Meeting? Also kann ich da wirklich irgendwie Input geben? Habe ich da Wissen, was wichtig ist? Und sonst einfach rausnehmen. Und wenn der anderen Person wirklich wichtig ist, dass du wirklich trotzdem kommst, dann wird sie dich schon nochmal fragen, wenn du rejected bist. Also auch da einfach die Sinnhaftigkeit hinterfragen, wie weit man etwas beitragen kann. Oder natürlich, wenn die Information so wichtig ist, die man da rausbekommt, ist das auch was anderes. Aber es gibt schon sehr selten, muss ich sagen. Also die meiste Zeit hat man die Information dann im Nachhinein über irgendein Protokoll oder so etwas announced, was dann entschieden wurde. Und wenn man diese Regeln beachtet, dann ist man wahrscheinlich relativ schnell bei 50, 70 Prozent, die man ablehnen kann.
Andy Grunwald (00:42:41 - 00:43:46)
Man muss ja auch nicht so radikal sein, wenn man sagt, okay, pass mal auf, ich versuche mich immer mit dieser Regel, dann heißt das ja nicht, kannst du einfach mal 50 Prozent, kannst du erst mal mit 20 oder 30 Prozent anfangen. Ein tolles Feature, was zum Beispiel der Google Kalender, falls ihr irgendwie Google Workspaces in der Firma nutzt, hat, ist, wenn ihr in der Wochenansicht seid, seht ihr auf der linken Seite, wie viele Stunden du diese Woche im Meeting bist. Und ab und zu steht er bei mir halt so 25 oder 30. Das bedeutet, ich bin drei Viertel meiner kompletten Arbeitswoche in Meetings. Und dann denke ich mir, das kann es ja nicht sein, weil wenn ich in Meetings bin, muss ich das Meeting entweder vorbereiten und wenn ich es nicht vorbereite, fallen in der Regel Action Points raus, die ich nachbearbeiten muss. Und sind wir mal ehrlich, wenn ich über fünf Tage 30 Stunden Meetings habe, dann werde ich bestimmt nicht 10 Stunden am Stück Fokusarbeit haben, um die Action Points dann abzuarbeiten. Also ist das schon mal unrealistisch. Und immer wenn ich sowas habe, sage ich erstmal eine ganze Menge Meetings ab.
Wolfi Gassler (00:43:46 - 00:43:56)
Man muss natürlich dazu sagen, dass du auch Engineering Manager bist. Also das ist schon nochmal auf einer anderen Ebene. Und da kann es natürlich schon sein, dass du wesentlich mehr Meetings hast und mit den Meetings auch umgehen musst.
Andy Grunwald (00:43:56 - 00:44:12)
Ja gut, aber dann rede ich auch oft mit meinem Vorgesetzten und sage, hey, pass mal auf, ich habe jetzt hier 30 Stunden Meetings, so kann das ja nicht laufen, weil ich meine, du erwartest ja auch ein bisschen Arbeit von mir und ich fokussiere jetzt, priorisiere jetzt diese Projekte und alles andere schiebe ich erst mal zur Seite und sage ab. Das ist die eine Baustelle. Die andere Baustelle ist natürlich auch.
Wolfi Gassler (00:44:12 - 00:44:19)
Ja, aber Moment, also da muss ich gleich reingrätschen, weil du sagst ja damit, dass Meetings keine Arbeit sind. Wenn du sagst, du erwartest ja auch Arbeit von mir.
Andy Grunwald (00:44:20 - 00:44:27)
Ah doch, ich sag, dass Meetings Arbeit ist, aber das bringt ja nichts, wenn ich in einem Meeting bin, irgendwas bespreche und die Arbeit danach nicht machen kann. Aufgrund von anderen Meetings.
Wolfi Gassler (00:44:27 - 00:44:30)
Wenn du Arbeit machen musst, ja. Es kann ja auch sein, dass du nur in Meetings sitzt.
Andy Grunwald (00:44:30 - 00:44:47)
Ja gut, aber dann gehen wir zurück auf Start. Ziehen nicht 4.000 Euro ein, weil wir irgendwie über was gelaufen sind. Und dann wenden wir bitte die Cancel-Your-Meetings bitte, wenn du mit dem Ergebnis ... Also du kannst die Meetings absagen, wenn du mit dem Ergebnis leben kannst. Weil dann nehm ich die Regel.
Wolfi Gassler (00:44:48 - 00:45:08)
Ja, das stimmt, aber es kommt auch auf die Rolle drauf an. Also ich glaube, es gibt Rollen, da hast du sehr viele Meetings und das ist deine Arbeit und die Entscheidungen in den Meetings sind deine Arbeit und das Delegieren und das Weiterleiten und das Koordinieren, was natürlich in Meetings sehr viel abläuft, ist dann deine Arbeit. Aber klar, es kommt darauf an, was du für eine Rolle hast und was dein Lead und deine Chefin für eine Erwartung an dich hat.
Andy Grunwald (00:45:08 - 00:45:42)
Ich gebe ja auch zu, ab und zu bin ich auch nur in Meetings, um jemanden zu bestärken, um halt dem Argument, was zum Beispiel von meinem Team vorgebracht wird, ein gewisses Gewicht zu verleihen. Und das kann bei Tech-Leads, bei Staff-Engineers genauso sein. Da sollte nicht jedes Meeting abgelehnt werden, sondern wenn ein Staff-Engineer einen Junior-Engineer coacht, der Junior-Engineer macht eine Präsentation wegen einem Design-Dokument oder ähnliches, dann bedeutet das für den Junior sehr, sehr viel, wenn der Staff-Engineer mit in dem Meeting ist, auch wenn die Person einfach gar nichts sagt.
Wolfi Gassler (00:45:42 - 00:45:54)
Ja, vollkommen. Stimme dir vollkommen zu. Also solche Sachen sind natürlich auch wichtig, definitiv. Präsenz zeigen kann auch unter Umständen wichtig sein. Einfach in dem Meeting zu sitzen und nur anwesend zu sein, kann unter Umständen auch sehr, sehr wichtig sein, in manchen Fällen.
Andy Grunwald (00:45:55 - 00:46:15)
Und ich nutze dieses Mittel auch. Also ab und zu sage ich meinem Chef, kannst du bitte joinen, nur des Gewichtes wegen. Aber über eine offensichtliche Lösung haben wir eigentlich noch gar nicht gesprochen. Meetingfreie Tage. Bist du da ein Fan von? Hast du die schon mal funktionieren sehen? Also dass du einfach sagst, jeden Mittwoch gibt es einen Teamblocker, da ist einfach der ganze Tag verplant. Meetingfreier Mittwoch.
Wolfi Gassler (00:46:16 - 00:46:47)
Ich habe es schon oft gehört, aber ich habe es persönlich noch nie erlebt, dass es sehr gut funktioniert hat, weil es immer wieder Ausnahmen gegeben hat. Aber bei uns in der Discord-Community haben jetzt auch wieder einige geschrieben, dass es so einen Tag gibt, wo teilweise Meetings stattfinden und alle anderen Tage sind keine Meeting-Tage. Also es ist je nachdem, wie man das einteilt. Also ich glaube, es kann schon auch funktionieren, auch wenn es, klar, Ausnahmen wahrscheinlich immer gibt, aber wenn es zu 90 Prozent funktioniert, ist ja auch schon gut. Aber was ich in der Praxis erlebt habe, war weniger. Eher der Fall, dass es funktioniert hat.
Andy Grunwald (00:46:47 - 00:46:57)
Du willst mir also sagen, dieses Meeting-freie-Tage ist umgedreht, dass du einen Tag hast, wo du durchpowern musst, und dann hast du vier Tage keine Meetings?
Wolfi Gassler (00:46:57 - 00:47:09)
Ja, also der User, ich sage noch mal, der Mario, kenn ich nicht zufällig, schreibt, in seinem Team gibt es einen Meeting-Tag, der Rest bleibt bis auf dailies frei.
Andy Grunwald (00:47:10 - 00:47:35)
Auch geil, finde ich super, wenn man das wirklich hinbekommt. Aber ist natürlich auch schon dann eine sehr disziplinierte Abteilung beziehungsweise Firma, wenn man halt alle Meetings dann wirklich in einem Tag unterbekommt. Aber ich denke mir auch, ist das dann der Horrortag von diesen Leuten? Weil ich kenne keinen Softwareengineer, der es liebt, in Meetings zu sitzen, weil du musst ja auch, also ich auch, ich bin nach sieben Stunden Meetings einfach ausgelaugt.
Wolfi Gassler (00:47:35 - 00:48:31)
Also ich weiß nicht, ob die gesamte Firma synchron ist auf den Tag oder ob das nur Marios Teams machen. Und es kommt glaube ich darauf an, wie viele Meetings man überhaupt macht. Und wie gesagt, ich glaube, dass es da auch Ausnahmen gibt und wahrscheinlich zählen Meetings innerhalb des Teams gar nicht dazu, wenn sich jetzt zwei Leute zusammensetzen oder so. Das sind ja eigentlich auch Meetings. Aber es scheint zu funktionieren. Auch wenn es natürlich Ausnahmen gibt wahrscheinlich, vermute ich mal und vielleicht irgendwo ein wichtiges Meeting mal reingestreut wird. Wenn es im Allgemeinen funktioniert, kann es ja auch schon viel helfen. Es muss ja nicht zu 100% immer funktionieren und da ist halt meine Devise auch immer einfach ausprobieren. Es kommt aufs Team drauf an, auf die Firma, auf die Firmenkultur. Aber man kann es einfach mal ausprobieren. Das sind Sachen, die man super schnell umsetzen kann. Das ist einmal ein bisschen Kommunikation und man kann auch im eigenen Team schon mal losstarten, ohne dass die ganze Firma umsteigt. Und dann evaluiert man das halt einfach. Wie funktioniert das? Spielt sich das ein? Funktioniert es? Kann man was optimieren? Kann man was verbessern? Oder lasst man es einfach wieder?
Andy Grunwald (00:48:31 - 00:48:58)
Bei uns wurde das eigentlich gar nicht so kommuniziert. Also wir haben zum Beispiel die Meetingfreie Mittwoch in unserem Team und was ich gemacht habe, ich habe einfach, natürlich habe ich das mit dem Team besprochen, aber ich habe einfach dem ganzen Team ein Meetinginvite gesetzt, was einfach den ganzen Tag blockiert. Und wenn die Personen, die Teammitglieder Meetings annehmen, dann machen sie es halt explizit, weil bei uns in der Firma respektieren Leute halt deinen Kalender und auch, dass du keine Doppelbookings hast.
Wolfi Gassler (00:48:59 - 00:49:22)
Ja, also was ich halt erlebt habe als Engineering Manager, aber das ist halt nochmal eine andere Sache, ist, ich hatte Blocker in meinem Kalender und dann haben mich die Leute halt persönlich angeschrieben, hey, es ist so wichtig, da ist ein wichtiges Meeting und da sind zehn andere Manager und wir können nur an dem Tag zu dieser Zeit. Und am Ende waren meine ganzen Blocker dann mehr oder weniger immer für die Fisch auf gut Deutsch.
Andy Grunwald (00:49:22 - 00:49:23)
Für die Katz.
Wolfi Gassler (00:49:23 - 00:49:34)
Bei uns heißt es für die Fisch und die Fisch sind dann wieder für die Katz. Aber kann dir natürlich passieren, je nachdem, was deine Rolle wieder ist. Aber als IC solltest du dich schon einigermaßen durchdrücken können, würde ich mal sagen.
Andy Grunwald (00:49:34 - 00:50:46)
Ich meine, diese Anfragen kriegt man auch und die finde ich auch okay, weil im Endeffekt wird da gefragt, ja. Weil, was ja in der Regel passiert ist, jemand setzt dir einfach Termine rein. Und du kannst ja auch Termine haben. Niemand sagt, du sollst keine Termine haben. Was halt immer stört ist, du hast einen Termin von 10 bis 11 und der nächste ist von 11.30 bis 12. Also immer nur diese halbe Stunde, Viertelstunde, Dreiviertelstunde dazwischen, weil in der Dreiviertelstunde macht man halt nicht wirklich viel. Natürlich, man beantwortet ein paar Nachrichten und so weiter, aber du hast ja keine wirkliche Fokuszeit. Diesbezüglich mit diesen ganzen kleinen, ich nenne es mal Windowslots, weil das sind so kleine Fenster im Kalender, finde ich, Da habe ich die Tage ein Produkt gesehen, mir fällt der Name leider nicht mehr ein. Das ist ein Kalender oder das ist so eine AI oder so eine Scheduling Software, dem gibst du Zugriff auf deinen Kalender und der versucht diese Windows Slots, diese Zwischenzeilen da rauszuholen, indem der natürlich auch die anderen Kalender prüft. wie haben die zeit und so weiter und dann für dich die termine zusammenlegen also ich finde das genial ja die methode kann natürlich nicht sagen wie dann der andere kalender aussieht weil natürlich dann also irgendwo wird das gescattert sein.
Wolfi Gassler (00:50:46 - 00:51:47)
Ich hatte mal vor, wirklich vor über zehn Jahren oder vielleicht sogar 20 Jahren, einen Vortrag gehört, wo es genau darum gegangen ist schon, wie kann ich die Kalender möglichst synchronisieren. Und das waren dann so Wellen, die man sich vorstellen hat können, so eine Kurve, die nach oben geht. Und umso weiter die Kurve nach oben war, umso besser war der Termin bzw. der Slot. Und dann hat man die vielen Kurven übereinandergelegt und hat den besten Match für alle in den Kalendern und so weiter errechnet. Ich kann mich leider nicht mehr erinnern, wo das war und das war schon damals, haben wir gedacht, wenn das funktionieren würde, dass die AI, also damals war es noch keine AI, aber diese Kurven das einfach perfekt machen und bei mir wäre in der Früh zum Beispiel die Kurve ganz niedrig, das heißt, man könnte einen Termin setzen, aber ich wäre wenig happy darüber und so hätte die Kurve das einfach über den Tag irgendwie dargestellt. Also wenn jemand so eine Lösung kennt, mittlerweile vielleicht mit der AI und hoffentlich kommt es bald, das kann wahrscheinlich vielen Leuten, vor allem vielen Managern, die da in vielen Meetings sitzen, das Leben stark vereinfacht.
Andy Grunwald (00:51:48 - 00:52:47)
Also, im Endeffekt, zusammengefasst, ich denke, dass, um sich Fokus zu sichern, man selbst erstmal verantwortlich ist, dass man die Basis klarstellt, alle Notifications aus, vielleicht auch einfach mal kurz in den Chat schreiben, hey, ich klink mich mal für ein paar Stunden aus, programmiere und dann einfach Slack aus, E-Mail aus. und wenn wenn man all dies probiert hat und es wirklich nicht funktioniert dann kann man das glaube ich im team besprechen und dann kann man vielleicht auch irgendwann noch mal der oder die vorgesetze mit einem beziehen um da vielleicht ein bisschen back up zu kriegen ich bin jetzt kein großer freund von irgendwelchen Firmenregeln und dass die interne Kommunikationsabteilung Kommunikationsregeln vorgibt, weil im Endeffekt ist die Kultur das, was gelebt wird. Wir haben gerade ein bisschen über die Meeting-freie Tage oder vielleicht auch über die Meeting-Tage, wie der Mario das in der Community beschrieben hat, gesprochen. Finde ich auch ein sehr cooler Ansatz, Meeting-Tage. Aber ich glaube, da muss ich nochmal nachfragen, ob man da nicht geschlaucht ist, weil ich stelle mir das schon echt hart vor.
Wolfi Gassler (00:52:47 - 00:52:50)
Wir verlinken auch den Discord-Thread in unseren Show Notes.
Andy Grunwald (00:52:50 - 00:53:16)
Genau, alle Links, die wir hier benannt haben, wie zum Beispiel dieses unglaublich schöne XKCD-Comic, warum Developer es hassen, unterbrochen zu werden, die Community-Frage von der Tom, aber auch den unglaublich guten Artikel von Paul Graham über den Konflikt Maker-Schedule, Manager-Schedule. Das ist nämlich eigentlich genau der Terminkonflikt, den wir hier auch so ein bisschen gerade besprechen. Und auch den Blogpost.
Wolfi Gassler (00:53:16 - 00:53:18)
Natürlich deinen. Deinen verlinken wir natürlich auch an die.
Andy Grunwald (00:53:23 - 00:53:41)
Aber Wolfgang, die ganze Podcast-Aufnahme schwebt mir eine Frage im Kopf um. Wir sprechen immer davon, dass wir die Opfer sind, dass wir interrupted werden. Kam schon mal jemand auf dich zu und sagt, Wolfgang, es tut mir leid, könntest du bitte aufhören mich ständig zu unterbrechen, ich muss mich konzentrieren?
Wolfi Gassler (00:53:41 - 00:54:05)
Ich glaube eigentlich, wenn ich mich so zurückerinnere, dass das nie jemand gemacht hat. Es hat sich nie jemand beschwert. Das kann jetzt natürlich sein, dass sich niemand getraut hat, weil ich immer so ein böser Manager war. Aber ich hoffe mal, dass es eigentlich nicht der Fall war. Jetzt alle, die zuhören, die werden sich jetzt was denken. Aber ich hoffe, dass es nicht so war. Aber sonst hoffe ich natürlich auch, dass es Leute mir gesagt hat. Warum? Hat es dir schon jemand mal gesagt?
Andy Grunwald (00:54:05 - 00:54:36)
Ja, und im Infrastrukturbereich ist das auch eigentlich gang und gäbe, wenn man so möchte. Du hast einen Inzident, weil die Infrastruktur down ist, und du als Engineering Manager bist natürlich für die Stakeholderkommunikation verantwortlich. Und dann fragst du halt öfters mal nach einem Status und dann interruptest du die Leute, während die versuchen, die Services wieder online zu bringen. Also ja, ich wurde schon mal auch in solchen Stresssituationen streng darauf hingewiesen, dass ich mich doch bitte etwas zurückhalten sollte. Muss ich zugeben, war aber primär in der Anfangszeit, wo ich natürlich auch in solchen Situationen sehr viel Adrenalin hatte. ich nicht genau wusste, wie ich reagieren sollte.
Wolfi Gassler (00:54:36 - 00:54:41)
Ja, ich war nie so in so einem wilden Umfeld wie du unterwegs. Bei mir war das immer alles, fast immer alles gemütlich.
Andy Grunwald (00:54:41 - 00:55:06)
Genau, mit mehr Erfahrung macht man sowas auch nicht mehr. Und dann hat man auch nicht mehr so viel Adrenalin im Körper, wenn die Plattform down ist. Aber der zweite Fall, den wir noch gar nicht beleuchtet haben, und der würde mich auch mal interessieren, hattest du schon mal jemanden in deinem Team, entweder als Direct Report oder als direkten Peer, der einfach gar nicht gemerkt hat, dass er oder sie sich konstant unterbrechen lässt und dadurch die Produktivität leidet?
Wolfi Gassler (00:55:06 - 00:55:16)
Also, dass sich jemand nicht bei mir beschwert hat, ich werde ständig unterbrochen, sondern, dass man als Manager gemerkt hat, oh, der lässt sich, oder sie lässt sich gerne unterbrechen.
Andy Grunwald (00:55:16 - 00:55:17)
Du hast es beobachtet, genau.
Wolfi Gassler (00:55:18 - 00:55:35)
Ja, hatte ich. Sogar mehrmals, würde ich fast sagen, hat sich aber eigentlich immer sehr schnell beheben lassen, das Ganze, indem man einfach mit der Person gesprochen hat. Und es war eigentlich meistens zumindest so, dass diese Person es gar nicht so wahrgenommen hat und gar nicht gemerkt hat, dass das vielleicht auch im Team irgendwo ein Problem ist.
Andy Grunwald (00:55:35 - 00:55:37)
Wie hast du sagen gesprochen? Weil ich stelle mir das relativ schwierig vor.
Wolfi Gassler (00:55:38 - 00:56:33)
Ja, primär kam das natürlich über andere Team-Members, die dann irgendwie gesagt haben, die Person lässt sich ständig ablenken oder macht irgendwas anderes und wenn irgendwas reinkommt, egal was es ist, dann springt man da in irgendein Rabbit-Hole und probiert dann irgendwas zu fixen, was gar keine Relevanz hat und solche Geschichten. Und wenn man die Person dann einfach drauf hinweist, ist es ganz oft so, dass es der Person nicht klar war und wenn man dann ein bisschen darüber spricht und einen Plan macht, war das eigentlich nie ein Problem und hat sich dann auch stark gebessert, muss man auch dazu sagen, ja. Also ich hatte nie ein Problem bei der Lösung dann. Das war eigentlich immer lösbar. Aber es war natürlich den Personen nicht bewusst. Das war wirklich so. Und darum habe ich auch ja gesagt, es gibt Leute, denen das sogar Spaß macht, die sich gerne unterbrechen lassen und kann natürlich auch negative Auswirkungen haben auf die Produktivität. Aber wenn man das auch in die richtige Richtung lenkt, kann es auch jemand sein, der einfach sehr gut kommunizieren kann und vielleicht ein bisschen Adaption in der Rolle braucht oder vielleicht in eine andere Richtung gehen kann und soll.
Andy Grunwald (00:56:34 - 00:56:40)
Und das wäre jetzt meine nächste Frage gewesen. Warum hast du das denn beobachtet und angesprochen? Hat die Produktivität darunter gelitten?
Wolfi Gassler (00:56:40 - 00:56:42)
Das Team hat sich beschwert, eigentlich immer.
Andy Grunwald (00:56:42 - 00:56:50)
Und wieso hat sich das Team beschwert, wenn niemand anders sich immer unterbrechen lässt? Also was hat das Team dann davon gehabt?
Wolfi Gassler (00:56:50 - 00:57:08)
Weil schon die Produktivität natürlich in irgendeiner Form gelitten hat. Also gerade, wenn man sich dann mit Sachen lang beschäftigt, die gar nicht so wichtig sind, weil sie halt gerade reindroppen, oder vielleicht auch Sachen, die gar nicht relevant sind fürs Team. Ob das dann stimmen mag am Ende, rein stundentechnisch, ist natürlich schwer zu sagen, aber üblicherweise kamen die Beschwerde über das Team.
Andy Grunwald (00:57:09 - 00:57:12)
Also die Person hat jetzt nicht den Teamsoll erfüllt, wenn man so möchte.
Wolfi Gassler (00:57:12 - 00:57:15)
Zumindest nicht das Gefühl gegeben, ja.
Andy Grunwald (00:57:15 - 00:57:31)
Ist aber natürlich auch schwierig, wenn sich mehrere Leute im Team so, ich will nicht sagen gegen die stellen, aber, also es ist toll, dass das Team dann die Stimme ergriffen hat und die es angesprochen hat, sofern das für die Person kein Problem war, aber ist natürlich auch immer so ein bisschen eine schwierige Situation, fünf Leute gegen einen, ne.
Wolfi Gassler (00:57:32 - 00:57:43)
Klar, ja, also man muss das natürlich auch im richtigen Kontext machen und aber wenn man das sauber bespricht und offen bespricht, dann hat es bisher bei mir zumindestens immer funktioniert.
Andy Grunwald (00:57:44 - 00:57:58)
Aber auch das wird an einen Engineering Manager und an eine Engineering Managerin herangetragen und damit muss man sich dann auseinandersetzen, weil sowas kann, sollte und darf man nicht unter den Tisch kehren.
Wolfi Gassler (00:57:58 - 00:58:22)
Und sind so die täglichen Probleme, mit denen man einfach zu kämpfen hat als Engineering Manager. Auch als IC natürlich, aber als Engineering Manager sind das eigentlich so ziemlich die Klassiker. Und du bist verantwortlich als Engineering Manager, in dass das Team einfach produktiv arbeiten kann und vorankommt. Und da ist halt Ablenkung ein großes Problem, mit dem man ständig eigentlich irgendwie konfrontiert ist.
Andy Grunwald (00:58:22 - 00:59:17)
Was natürlich aber auch ein Klassiker ist, dass viele Engineering-Manager sich irgendwann fragen, bin ich denn eigentlich hier der Kindergärtner und die Kindergärtnerin? Weil ab und zu bekommt man natürlich auch Fragen, da denkt man sich, das kannst du auch selbst lösen. Wenn ihr auch mal eine solch ähnliche Frage habt, oder vielleicht eine schwierigere, oder eine leichtere, oder ihr wollt einfach nur mal ein bisschen Feedback zu eurer Situation haben, kommt doch einfach mal in unsere Discord-Community. Den Link findet ihr natürlich in den Show Notes, kostet euch nix. Und circa 190 Leute, wie ich heute gelernt habe, sind bereits drin. Wir wissen natürlich auch nicht, ob wir die Weisheit mit Löffeln gefressen haben. Und mit hoher Wahrscheinlichkeit haben wir dies nicht. Denn zu diesem Problem gibt es nicht die eine Lösung. Wenn ihr aber auch andere Lösungen habt, kommt doch einfach vorbei in die Community und gebt uns eure Lösung. Oder nicht uns, sondern dem Tom eigentlich, der die Frage gestellt hat. Das war's von mir und auch von Wolfgang. Deswegen bis zum nächsten Mal. Ciao, ciao.
Wolfi Gassler (00:59:21 - 01:00:02)
Und nachdem du immer noch hörst, möchten wir einmal Danke sagen. Und wenn du uns unterstützen willst, bitte empfiehl uns weiter, Kollegen, Kolleginnen in deinem internen Firmenchat. Auch wenn du das schon mal gemacht hast, doppelt hält immer besser. Wir alle sind auf Recommendations angewiesen. Such dir eine coole Episode aus oder auch diese Episode und empfiehl die einfach mal weiter. würde uns extrem helfen, würde auch unserer gesamten Community helfen. Und falls du noch nicht dabei bist bei unserer Discord-Community, schau doch mal wirklich vorbei. Wir sind offen und auch froh über jeden Input, über Meinungen, über die Diskussionen, die stattfinden, damit wir da wirklich einen coolen Wissensaustausch schaffen können. Danke dir und ciao.