#35 Knowledge Sharing oder die Person, die nie "gehen" sollte...

Der Dauerbrenner in jedem Team: Wie bekommt man ordentliches Knowledge Sharing hin?

Jeder kennt's: Die Kollegin ist im Urlaub und genau in dieser Zeit läuft was mit der einen Komponente schief, wo sie das größte Wissen darüber hat. Knowledge Sharing richtig hinzubekommen und das Wissen breit zu verteilen ist eine Mammutaufgabe. Aber eine wichtige, speziell in einer Remote-Umgebung.

In dieser Episode gehen wir einige Mythen und Techniken durch, die euch beim Knowledge Sharing unterstützen können: Was ist der Bus-Faktor? Muss jeder im Team alles wissen und übernehmen können? Wobei kann Mob-Programming helfen? Was sind Guilds? Und kann man eigentlich zu viel lernen? Und noch viele weitere Themen.

Bonus: Warum das C-Level-Management nicht im selben Flugzeug fliegen darf und ob Podcasts, die Mitarbeiter-Zeitung ablösen.

Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners

Sprungmarken

(00:00:00) Intro

(00:00:45) eBay Kleinanzeigen und Landing-Pages für Auto-Reifen

(00:08:20) Das Thema der Episode: Knowledge Sharing

(00:11:11) Der Bus-Faktor

(00:13:01) Warum Knowledge Sharing wichtig für die Kollaboration und Produktivität ist

(00:15:05) Mythos "Jeder im Team muss alles Wissen und übernehmen können"

(00:18:05) Möglichkeiten zur internen Dokumentation: Design Documents / Request For Comments / Discover Documents / Architecture Decision Records und Zielgruppe der Dokumentation

(00:24:43) Pair- und Mob-Programming

(00:28:32) Guilds (Community of Practice), Support vom Management und Kosten von Knowledge Sharing

(00:39:38) Interne Konferenzen, Vorträge halten und das Imposter-Syndrom

(00:49:37) Lunch-Talks

(00:52:21) Welcher Lerntyp bist du? - Viel lesen, Hands-On, Frontal-Lehre, Video-Tutorials, Audio - Das richtige Format

(00:57:28) Kann man zu viel lernen?

(00:59:09) Ist Knowledge-Sharing schwieriger in einem Remote-Umfeld?

(01:02:21) Outro

Hosts

Wolfgang Gassler (https://twitter.com/schafele)
Andy Grunwald (https://twitter.com/andygrunwald)

Feedback (gerne auch als Voice Message)

Email: stehtisch@engineeringkiosk.dev
Twitter: https://twitter.com/EngKiosk
WhatsApp +49 15678 136776

Transkript

Das Transkript wurde automatisiert per Speech-to-Text erstellt und kann daher Fehler enthalten.

Wolfi Gassler (00:00:00 - 00:00:42)

Kennt ihr die auch? Ja, genau die. Die eine Person im Unternehmen, die auf keinen Fall kündigen darf. Denn sonst ist der Ofen aus. Das ganze Wissen verloren. Aber Moment. Wir machen doch Knowledge Sharing in der Firma. Das ist doch sogar ein Schwerpunkt bei uns. Heißt es zumindestens immer. Und genau darum dreht sich diese Episode. Und damit willkommen im Engineering Kiosk. Dass der Dauerbrenner Knowledge Sharing ein heißes Eisen ist, wissen wir alle. Aber wie können wir den Buzz-Faktor erhöhen und was gibt es für Möglichkeiten, Wissen zu transferieren und zu teilen? Muss jeder im Team alles wissen und übernehmen können? Wobei kann Mob-Programming helfen? Was sind Gilden und kann man eigentlich zu viel lernen? All das und noch vieles mehr nach einer kurzen Runde kleineren Zeiten.

Andy Grunwald (00:00:45 - 00:00:51)

Starten wir diese Episode mit etwas Völkerverständigung. Wie groß ist eBay Kleinanzeigen in Österreich?

Wolfi Gassler (00:00:53 - 00:00:54)

Wie groß?

Andy Grunwald (00:00:54 - 00:00:57)

Benutzt ihr das? Benutzt ihr eBay Kleinanzeigen in Österreich?

Wolfi Gassler (00:00:57 - 00:00:58)

Nein.

Andy Grunwald (00:00:58 - 00:00:59)

Aber du kennst eBay Kleinanzeigen?

Wolfi Gassler (00:00:59 - 00:01:04)

Ich kenn eBay Kleinanzeigen, aber wir haben natürlich viel coolere Lösungen. Wir haben Willhaben.

Andy Grunwald (00:01:06 - 00:01:07)

Was habt ihr?

Wolfi Gassler (00:01:07 - 00:01:10)

Willhaben.at.

Andy Grunwald (00:01:10 - 00:01:12)

Ist also auch eine Kleinanzeigenplattform.

Wolfi Gassler (00:01:12 - 00:01:12)

Ja.

Andy Grunwald (00:01:12 - 00:01:19)

Habt ihr eBay Kleinanzeigen in den Niederlanden? Glaube ich auch nicht, da gibt es Marktplatz. Marktplatz.nl.

Wolfi Gassler (00:01:19 - 00:01:26)

Ja, genau. Gehört übrigens den gleichen, denen auch Willhaben gehört. Ist glaube ich ein französischer Konzern.

Andy Grunwald (00:01:26 - 00:01:29)

Aber du weißt schon, dass eBay Kleinanzeigen so ein echt dickes Ding in Deutschland ist, oder?

Wolfi Gassler (00:01:30 - 00:01:32)

Ja, natürlich. Ich habe lange genug in Deutschland gelebt.

Andy Grunwald (00:01:32 - 00:01:34)

Hast du da auch schon mal Geschäfte drüber abgewickelt?

Wolfi Gassler (00:01:34 - 00:01:35)

Ja, natürlich. Ständig.

Andy Grunwald (00:01:35 - 00:02:00)

Und genau das mache ich jetzt gerade auch, weil meine Frau hat ihr Bücherregal aufgeräumt und hat mir dann so 10 oder 15 Thermomix-Kochbücher auf den Tisch gelegt und hat gesagt, was machen wir damit? Da sollte ich eBay-Kleinanzeigen. Sie sagte, nee, das mache ich nicht. Da setze ich mich nicht dahin. Also habe ich mal ratzfatz zwölf Fotos gemacht, die mal eben in ein paar Minuten online gestellt. Und ich sagte, ich glaube, ich eröffne eine Bücherhandlung mit Thermomix-Büchern. Die werden mir aus den Händen gerissen.

Wolfi Gassler (00:02:00 - 00:02:06)

Was glaubst du, warum Amazon so erfolgreich war damals mit Büchern? Hast du mal geschaut, was die auf Mammox oder so wert waren?

Andy Grunwald (00:02:06 - 00:02:07)

Das sind diese Rebuy-Geschichten, ne?

Wolfi Gassler (00:02:07 - 00:02:09)

Ja, genau.

Andy Grunwald (00:02:09 - 00:02:26)

Nee, hab ich nicht, aber ich hatte noch ein paar DVDs, die hab ich da eingetragen und die waren nix mehr wert. Die stehen jetzt auch auf Ebay, also die kannst du da auch kaufen, aber die reißen sie mir nicht so aus den Händen. Naja, auf jeden Fall, worauf ich hinaus möchte. Natürlich können wir uns auch über Thermomix-Kochbücher unterhalten, aber das ist nicht worauf ich hinaus möchte.

Wolfi Gassler (00:02:26 - 00:02:33)

Sondern du willst jetzt eigentlich Werbung machen für deine eBay-Kleinanzeigen und dass wir die verlinken zu deinen uralten DVDs und zu deinen Thermomix-Büchern.

Andy Grunwald (00:02:33 - 00:02:43)

Ich kann mal gucken, ob ich die ein oder andere, die einfach nicht weggeht, in den Show Notes verlinke. Kann ich machen. Aber wusstest du eigentlich, dass eBay, der Konzern, sich von eBay-Kleinanzeigen getrennt hat?

Wolfi Gassler (00:02:43 - 00:02:46)

Ja, natürlich. Wo lebst du? Unter welchem Stein?

Andy Grunwald (00:02:46 - 00:02:50)

Mit jedem, mit dem ich spreche, sagen, nee, das wusste ich gar nicht.

Wolfi Gassler (00:02:50 - 00:02:53)

Gehörtest du sogar vielleicht diesem französischen Konzern mittlerweile?

Andy Grunwald (00:02:54 - 00:03:46)

Nein einem norwegischen konzern und zwar wurde das für 9,2 milliarden dollar nicht in geld sondern in aktien übernommen und das norwegische unternehmen ad winter hat die ganze sache gekauft diesem konzern gehört unter anderem inzwischen auch mobile.de. Und A.D. Winter ist somit der größte Kleinanzeigenmarkt in ganz Europa. Weil A.D. Winter gehören irgendwie diverse solcher Plattformen. Und das Lustige ist, die haben mit dem Kauf das Namensrecht von eBay Kleinanzeigen nur so teilweise mitgekauft. Also bis Juni 2024 darf eBay Kleinanzeigen noch eBay Kleinanzeigen heißen. Danach heißt es nur noch Kleinanzeigen. Und da bin ich mal gespannt, was mit der Top-Level-Domain passiert, weil niemand sagt Kleinanzeigen, sondern alle sagen eBay-Kleinanzeigen.

Wolfi Gassler (00:03:46 - 00:03:48)

Gibt's kleinanzeigen.de schon?

Andy Grunwald (00:03:48 - 00:04:19)

Gibt es, Link auf eBay-Kleinanzeigen. Und jetzt ist die Frage, wem gehört die Top-Level-Domain? Dem neuen Konzern oder eBay? Auf jeden Fall finde ich es wirklich, wirklich, wirklich faszinierend, was Ebay selbst aus Ebay-Kleinanzeigen gemacht hat und dass das in Deutschland eigentlich der de facto Marktplatz ist. Also ich kenne kaum noch Leute, die wirklich auf Ebay eine Auktion erstellen, sondern ich kenne meistens nur noch Privatpersonen, die auf Ebay-Kleinanzeigen irgendwas reinstellen und dann so wie auf einem Bazaar mit Verhandlungsbasis da wirklich rumhandeln.

Wolfi Gassler (00:04:20 - 00:04:45)

Ja, eBay ist halt vielmehr zu diesem Marktplatz eigentlich für professionelle Händler geworden. Einfach die, die dort das als normalen Shop-Marktplatz sehen. Ich habe jetzt übrigens gerade nachgeschaut, AD Winter. Ihr hattet es falsch im Kopf mit der französischen Firma. Das ist genau AD Winter. Die haben sowohl Marktplatz Holland, wie auch Willhaben in Österreich und massig andere Marktplätze noch. Also die scheinen wirklich ziemlich marktführend da zu sein, ja.

Andy Grunwald (00:04:46 - 00:05:59)

Und das finde ich ja immer so spannend, hinter diesen ganzen kleinen bekannten Marken und Webseiten, die dann lokal super bekannt sind, steht meist so eine Riesenfirma, die eigentlich keiner kennt. Das ist genauso wie wir haben im Studium, in meinem für dich abgebrochenen Bachelorstudium, haben wir mal eine Marktanalyse gemacht und zwar von Online-Shops, die Reifen verkaufen. Da haben wir uns glaube ich 15 16 oder 18 Shops angesehen und da gab es dann so spezialisierte Shops wie ein Shop, der hat halt nur Reifen mit der Zielgruppe Rentner verkauft oder nur Reifen mit irgendwelchen Sportfelgen für halt Leute die tunen ja so GTI Fahrer und so weiter und so fort. Also wirklich so so ich möchte mal sagen so eine Art Landingpage halt immer aufgebaut aber immer unter verschiedenen Marken. Und am Ende kam halt so ein Baum raus, und da gibt's wohl irgendwie eine Firma, die betreibt so ungefähr 70 oder 80 Prozent aller Online-Shops in Deutschland oder jetzt hier auch in Holland und so weiter und so fort, die dann Reifen verkaufen. Aber es sind halt, keine Ahnung, 33 verschiedene Website-Marken mit 33 verschiedenen Zielgruppen, ja, für Rentner und für die Sparfüchse und dann für die Leute, die nur die ganzen teuren Reifen kaufen und so weiter. Das ist schon faszinierend immer.

Wolfi Gassler (00:05:59 - 00:06:05)

Das ist auch diese Firma, die der größte B2B-Reifenhändler ist wahrscheinlich im deutschsprachigen Raum, oder?

Andy Grunwald (00:06:05 - 00:06:23)

Mich würde es wundern, wenn das nicht so ist. Ich kann es aber nicht hundertprozentig bespätigen, weil ich es nicht weiß. Ich habe den Namen nicht mehr im Kopf. Auf jeden Fall finde ich das immer interessant. Naja, Thema the more you know. Jetzt weißt du auch, beziehungsweise eure Hörerinnen und Hörer, dass in Deutschland eBay Kleinanzeigen bald nicht mehr eBay Kleinanzeigen ist, sondern.

Wolfi Gassler (00:06:23 - 00:06:32)

Kleines Funfact, ich hab mal, wie sehr jung war, eine komplette seriöse Plattform programmiert für einen Kunden, der mich dann sitzen gelassen hat und mich nicht bezahlt hat.

Andy Grunwald (00:06:32 - 00:06:37)

Das bedeutet, danach hast du Verträge eingeführt in deine Freelancing-Karriere.

Wolfi Gassler (00:06:38 - 00:06:46)

Ja, ich glaub, ich war da sogar unter 18 noch. Danach hab ich eingeführt, dass ich zum Beispiel ein Drittel einfach bei Auftragslegung schon mal vorab bekomme.

Andy Grunwald (00:06:46 - 00:06:47)

Machst du das jetzt immer so?

Wolfi Gassler (00:06:47 - 00:06:49)

Normalerweise schon, ja.

Andy Grunwald (00:06:49 - 00:07:05)

Bevor wir jetzt das Thema schließen, noch eine finale Frage. Was hast du bei eBay-Kleinanzeigen oder Willhaben oder Marktplatz mal reingesetzt, wo du dachtest, das geht doch nie weg, und am Ende hast du dann wirklich einen Preis erzielt, da dachtest du, what the fuck ist denn hier los? Ich hätt das fast weggeschmissen.

Wolfi Gassler (00:07:06 - 00:07:44)

Ich habe mal versehentlich bei Action, war das glaube ich, so eine billige Smartlampe gekauft, wo ich mir gedacht habe, die kann ich einbinden und einfach flashen. Dem war aber nicht so. Und dann habe ich dieses Ding verkauft, war dann irgendwie 15 Euro oder so ein LED-Band oder sowas, glaube ich. Und ich dachte, das will niemand, das kann jeder in Action gehen und das selber kaufen. Ich hatte Anfragen, Unmengen aus allen möglichen Teilen im Land und ob ich es ihnen per Post sende und es sind alle auf dieses Ding abgeflogen. Ich habe es dann irgendjemandem gesendet, der hat es seinem Sohn dann zu Weihnachten geschenkt. Der Sohn war super happy als Weihnachtsgeschenk und der Vater scheinbar auch, dass er es relativ günstig bekommen hat.

Andy Grunwald (00:07:44 - 00:07:46)

Was hat das Ding in Action gekostet?

Wolfi Gassler (00:07:47 - 00:07:52)

Ich glaube 15 Euro oder so. Ich habe es fast um den Normalpreis verkauft. Oder war es sogar der Normalpreis, keine Ahnung mehr.

Andy Grunwald (00:07:52 - 00:07:59)

Warst du dann noch so geil und hast mit dem Käufer irgendwie wochenlang nach dem Kauf geschrieben oder woher weißt du, dass der Sohn dann super happy war?

Wolfi Gassler (00:07:59 - 00:08:07)

Er hat es mir geschrieben irgendwie, dass es halt für den Sohn ist, er freut sich schon, der wünscht sich sowas und vielleicht hat es bei ihm keinen Action gegeben dort, als ich es bei Boston versandt.

Andy Grunwald (00:08:07 - 00:08:14)

Also bei eBay-Kleinanzeigen anfragen, bin ich froh, wenn ich ein Hallo kriege. Und du machst ja richtige Freundschaftsbeziehungen mit deinen Käufern und Verkäufern.

Wolfi Gassler (00:08:14 - 00:08:19)

Ja, man muss nur das richtige Material verkaufen, nicht so wie du mit deinen Thermomix-Büchern.

Andy Grunwald (00:08:19 - 00:08:24)

Okay, okay, das ist aber nicht das heutige Thema, sondern worum geht's heute immer?

Wolfi Gassler (00:08:24 - 00:08:29)

Natürlich ist es das Thema von heute. Mit deinen Thermomix-Büchern machst du was?

Andy Grunwald (00:08:29 - 00:08:29)

Kochen.

Wolfi Gassler (00:08:29 - 00:08:37)

Knowledge sharing, du verteilst ja dein Wissen an andere, die dann damit lernen können.

Andy Grunwald (00:08:37 - 00:08:45)

Wolfgang, man hat Kochbücher, damit man nachgucken kann, wie man etwas kocht, damit man es nicht wissen muss.

Wolfi Gassler (00:08:45 - 00:08:56)

Ja, ich habe schon verstanden, diese Thermomix-Geschichte geht ja in die Richtung Automatisierung des Kochens, da ist man dann nur mehr Handlanger von diesem Endgerät, was da über Wi-Fi kommuniziert und sagt, was ich noch machen soll.

Andy Grunwald (00:08:57 - 00:09:12)

Ah, ah, ah, ah, ah! Ich hab noch den alten Thermomix. Ohne Chip, ohne WLAN, analog, mit Drehrädchen und allem drum und dran. Das bedeutet, ich muss da schon noch die Kochstufe und Mixstufe und so weiter einstellen, ja. Den neuen Kram, den hab ich nicht.

Wolfi Gassler (00:09:12 - 00:09:15)

Ja, also ich nenne die Nummer Sternekoch ab jetzt.

Andy Grunwald (00:09:15 - 00:09:44)

So sieht es aus. Heutiges Thema ist ein Evergreen. Ein Evergreen, was eigentlich jeder von euch kennt. Jeder von euch, der in einer Firma arbeitet, in einem Team arbeitet, ständig als Problem ansieht oder sagt, hey, das müssen wir mal wieder machen. Und zwar geht es um das ganze Thema Knowledge Sharing. Wie kriegt man das Wissen vom Wolfgang aus seinem Kopf und wie kann ich dieses Wissen erlangen, damit wir beide besser als Team agieren?

Wolfi Gassler (00:09:44 - 00:09:48)

Warum willst du es überhaupt aus meinem Kopf rausbekommen? Bin ja eh da.

Andy Grunwald (00:09:48 - 00:09:54)

Das ist es ja. Stichwort Bassfaktor. Was würde passieren, wenn der Wolfgang vom Bus erfasst wird?

Wolfi Gassler (00:09:54 - 00:09:58)

Oder von einem Stein beim Klettern erschlagen wird. Ich glaube, die Wahrscheinlichkeit ist höher.

Andy Grunwald (00:09:58 - 00:10:17)

Oder was ist, wenn du einfach mal im Urlaub bist? Oder was ist, wenn du von heute auf morgen Corona bekommst und der Verlauf ist nicht so ganz gut? Was passiert eigentlich, wenn du von jetzt auf gleich nicht mehr da bist? Wie hoch ist das Risiko, dass das Wissen, was du in deinem Kopf hast, firmenkritisch ist?

Wolfi Gassler (00:10:17 - 00:10:25)

Ich glaube es ist sogar nicht mal nur wenn ich sofort irgendwie weg bin, aber auch ganz normales brain drain, wenn ich kündige, Leute kündigen.

Andy Grunwald (00:10:25 - 00:10:27)

Was ist brain drain?

Wolfi Gassler (00:10:27 - 00:11:01)

Ja wenn die, wenn die ganzen Köpfe das Schiff verlassen, muss nicht sinken sein, nur das Schiff verlassen. Also wir hatten das Thema mal über Portugal, dass so viele schlaue Köpfe aus Portugal ausgewandert sind und es sogar unterstützt wurde von Portugal. Und damit hast du halt einen extremen Verlust von deinem Wissen, weil das ist dann einfach weg. Und wenn die Leute kündigen bei dir, dann musst du erst mal schaffen, in diesen Wochen, Monaten, je nachdem, was du für Kündigungsfristen hast, musst du erst mal schaffen, dieses ganze Wissen irgendwie dann aus dem Kopf rauszubekommen. Das ist meiner Meinung nach auch der wichtigste Punkt heutzutage fast.

Andy Grunwald (00:11:01 - 00:11:05)

Für die Personen, die das Wort Bassfaktor das erste Mal hören.

Wolfi Gassler (00:11:05 - 00:11:15)

Die Definition meiner Meinung nach ist, wenn du einen Bassfaktor von zwei hast, dann müssen zwei Leute vom Bus erfasst werden, bis deine Firma nicht mehr weiter existieren kann.

Andy Grunwald (00:11:15 - 00:11:59)

Ich habe mal gegoogelt. Der Buzz Factor oder auch Truck Number ist eine Kennzahl aus dem Risikomanagement zur Abschätzung von Projektrisiken. Die Truck Number ist jene Zahl an Personen, die mindestens ausfallen müssen, damit ein Projekt scheitert oder zumindest nicht mehr vorangebracht werden kann. Das bedeutet eigentlich, dass ihr immer eine sehr hohe Truck Number oder einen hohen Bassfaktor haben wollt, denn umso höher die Zahl ist, umso geringer ist das Projektrisiko und umso mehr wurde das vorhandene Wissen geteilt. Ein Bassfaktor von 1 ist immer kritisch, weil das würde bedeuten, dass wenn eine Person oder nein, wenn die Person vom Bus erfasst wird, dann gerät das Projekt in Schieflage.

Wolfi Gassler (00:11:59 - 00:12:07)

Und die Erweiterung von dem Ganzen ist dann, dass die Sea-Level-Leute nicht gemeinsam fliegen dürfen, oder? Das ist dann der Bus-Flight-Faktor oder keine Ahnung, wie man das dann nennt.

Andy Grunwald (00:12:09 - 00:12:15)

Ich glaube, das Fortbewegungsmittel ist völlig egal. Du kannst das auch Lastenfahrradfaktor nennen. Ja, das ist völlig egal. Also von daher.

Wolfi Gassler (00:12:16 - 00:12:29)

Ja, wir haben noch nie gehört, dass der C-Level nicht gemeinsam in den Bus fahren darf. Aber gemeinsam fliegen ist immer irgendwie das Risiko. Das wurde teilweise sogar von börsennotierten Firmen, glaube ich, erwartet oder von Bord. Solche oder solche Regeln werden eingeführt von denen.

Andy Grunwald (00:12:29 - 00:13:12)

Also, ich kann dir sagen, weil ich in einem teilweise sicherheitskritischen Bereich arbeite, bei uns wird so was auch nachgedacht. Wenn zum Beispiel die Firma irgendwo hinfliegt, oder ganz viele Leute, dann werden teilweise auch andere Flugzeuge genommen und Co. Das ist also real. Naja, wie dem auch sei, das ist auf jeden Fall der Busfaktor. Und jetzt stellt euch mal bitte die Frage, wie viele Leute gibt es bei euch im Team, die Wissen über eine spezielle Komponente haben, und was würde passieren, wenn diese Leute auf unbestimmte Zeit von jetzt auf gleich ausfallen. Natürlich ist das meiste irgendwie nur Quellcode, aber es gibt Applikationen, die sind einfach so komplex geschrieben oder Infrastrukturen, die einfach groß sind, wo es wirklich schwierig ist, dahinter zu steigen.

Wolfi Gassler (00:13:12 - 00:13:51)

Aber man muss ja gar nicht unbedingt immer diesen negativen Fall anlegen. Ich glaube, Knowledge Sharing ist ja auch ganz wichtig, um einfach die Kollaboration zu fördern im Team oder in der Firma. Und damit auch die Produktivität zu steigern. Wenn man einfach mehr Ahnung hat, was andere Teams machen, welche Technologien die verwenden, dann steigt im Endeffekt, meiner Meinung nach zumindest, auch die Produktivität, weil die Leute wissen, okay, ich kann zum Andi zum Beispiel gehen, weil der verwendet Infrastructure as Code und wenn ich mal eine Frage habe, kann ich den fragen. Oder ich habe auch was gelernt vom Andi und kann das dann in meinem Team jeweils einsetzen. Also es hat, glaube ich, ganz praktische Vorteile, auch im ganz normalen Tagesgeschäft, in der normalen Entwicklung, würde ich sagen.

Andy Grunwald (00:13:52 - 00:14:31)

Ich bin aber auch ein großer Fan davon, umso mehr Kontext eine Person hat, umso mehr Wissen das Team über eine Infrastruktur hat, über eine Applikation, über eine Architektur, über ein Design oder ähnliches, dass man auf Basis des ganzen Wissens dann auch neue Lösungen entstehen können, beziehungsweise bessere Lösungen. Weil wenn einer nur der Knowledge Keyholder ist, dann kann diese Person eigentlich nur neue Lösungen, die wirklich ins Konzept passen, vorstellen. Wenn aber alle das wissen, dann ist es nicht so, dass mehrere Köche den Brei versauen, sondern oft kommen da einfach sehr viele verschiedene Perspektiven, sehr viele verschiedene Hintergründe zusammen, was dann im Endeffekt zu einer besseren Lösung führen kann.

Wolfi Gassler (00:14:33 - 00:15:15)

Und man verhindert natürlich auch dadurch, dass vielleicht Teams das gleiche Problem zweimal lösen, mit zwei unterschiedlichen Lösungen. Und wenn man aber weiß, hey, das hat das Team auch schon mal programmiert in der Vergangenheit, ich brauche das gar nicht oder frage einfach dort mal nach, wie habt ihr das gemacht, wie habt ihr das gelöst, habt ihr Probleme gehabt, dann kann ich da einfach auch viel verhindern und viel Zeit einsparen. Vor allem in einer großen Firma, man glaubt gar nicht, wie viele Teams das gleiche Problem zehnmal lösen. Teilweise sogar im Team, weil man einfach vergessen hat, dass man das vor drei Jahren schon mal gelöst hat. Und sei es vielleicht nur eine kleine Funktion, dass man einfach drauf kommt, okay, wir haben drei, vier, fünf Funktionen in unserem Quellcode im Team und die machen alle dasselbe. Also ich glaube, da kann man sehr viel Redundanz verhindern.

Andy Grunwald (00:15:16 - 00:15:33)

Ich habe gerade schon erwähnt, das Topic Knowledge Sharing ist ein Evergreen in jedem Team, in jeder Firma. Aber was auch ein Evergreen ist, ist für mich ein riesen Mythos. Und zwar Wolfgang, hast du jemals erlebt, dass in einem Team alle Teammember alles wissen und übernehmen können?

Wolfi Gassler (00:15:33 - 00:15:51)

Das wäre schon schön, dann hast du so irgendwie so Top 10 Developer oder ist es Top 10? 10x. 10x, ja genau. 10x Developer, die einfach alles übernehmen können, alles programmieren können, am besten auch jede Programmiersprache können. Ist ideal. Also wenn du so ein Team hast, ich würde es dir sofort abnehmen.

Andy Grunwald (00:15:51 - 00:16:00)

Aber hattest du denn auch schon mal die Ambitionen von Teammitgliedern? Ja, alle müssen alles wissen, was wir hier tun. Oder denkst du überhaupt, das ist realistisch oder machbar?

Wolfi Gassler (00:16:00 - 00:16:37)

Ich überlege gerade, ob es sowas gegeben hat, dass es jemand wirklich wissen wollte. Es gibt schon hin und wieder so Charaktere, die extrem in diesen Lernmodus sich reinstürzen und dann schwer in den produktiven Modus wiederkommen, aber das ist eigentlich eher die Seltenheit. Ich würde mal sagen, im Normalfall ist eher der Punkt, dass die Leute weniger Knowledge sharen und weniger lernen, weil sie einfach durch das Tagesgeschäft vielleicht so eingedeckt sind und man eher die Leute ein bisschen pushen muss oder eher in die Richtung stoßen muss, dass sie lernen. Oder hast du mal so irgendwelche Situationen erlebt, dass jeder, dass eine Person alles wissen wollte?

Andy Grunwald (00:16:38 - 00:17:27)

Ich denke, das ist ein Unterschied zwischen, dass eine Person alles wissen wollte und dass man das Ziel anstrebt, dass alle im Team das gleiche wissen und somit alles übernehmen können, falls mal jemand gerade nicht kann. Ich denke, das ist ein Unterschied. Dennoch halte ich es für einen riesen Mythos, dass jeder im Team alles übernehmen kann und jeder im Team jedes Detail über die Applikationen oder den Themenbereich, den das Team übernimmt, weiß. Ich habe aber schon mehrmals erlebt, dass die Teammitglieder das gefordert haben. Für mich ist das ein Riesenmythos, weil das ist genauso wie Dokumentation. Es ist gut, Dokumentation zu haben, aber wenn man die Dokumentation geschrieben hat, just in dem Moment ist sie schon out of date. Und ich denke einfach, man muss realistisch bleiben und einfach nur akzeptieren, dass Dokumentation sofort out of date ist. Und deswegen sage ich auch, dass man akzeptieren sollte, dass nicht jeder im Team alles wissen kann oder übernehmen kann. Und das ist auch okay so.

Wolfi Gassler (00:17:28 - 00:18:16)

Ich glaube, das ist schon nicht mehr möglich, wenn du Teamgröße von drei hast. Bis zwei ist es, glaube ich, möglich, drei vielleicht noch, aber ich glaube, ab drei wird es einfach unmöglich. Und es ist in der Praxis auch nicht möglich, dass wenn du wirklich drei Leute brauchst oder vier Leute brauchst, dass dann jeder Spezialist in allen Bereichen ist. Also das ist utopisch. gewisse Grundkenntnisse haben oder informiert sein über gewisse Bereiche, was abgeht. Aber wenn es dann ein Problem gibt und ich muss in einen Bereich eintauchen, in dem ich nicht zu Hause bin, dann brauche ich da einfach eine gute Dokumentation oder irgendwo eine Quelle, wo ich nachschauen kann, wenn die jeweilige Person nicht da ist. Und im Notfall kann ich dann vielleicht mich einarbeiten und ein gewisses Problem lösen in der Domäne. Aber dass man überall sich auskennt, ist einfach utopisch.

Andy Grunwald (00:18:16 - 00:18:22)

Das ist jetzt lustig. Du hast gesagt einarbeiten. Das bedeutet ja, okay, man muss nicht alles wissen, sondern man muss nur wissen, wo es steht.

Wolfi Gassler (00:18:22 - 00:18:28)

Und damit meine ich jetzt nicht Google, sondern interne sinnvolle Dokumentation.

Andy Grunwald (00:18:28 - 00:18:37)

Was für Möglichkeiten gibt es denn, interne, und jetzt kommt das wichtige Wort, sinnvolle Dokumentation zu erstellen? Was kennst du damit? Was hast du schon Erfahrungen gemacht?

Wolfi Gassler (00:18:37 - 00:19:35)

Ja, wenn wir mal bei der schriftlichen Dokumentation bleiben. Einen Punkt, da können wir gleich wieder eine Episode erwähnen. Das ist immer gut. In der Episode 14 haben wir Design Documents erwähnt, wo man gut den Entscheidungsprozess abdecken kann. Also wie hat man denn Entscheidungen getroffen? Wie ist man zu einem gewissen Design gekommen? Wie schaut das allgemeine Design überhaupt aus? Und das bietet einmal einen ersten Einstiegspunkt in irgendein fremdes System. Wo das Ganze gespeichert ist, ist dann nochmal eine andere Sache, ob das jetzt irgendwo in den Git-Repos gespeichert ist, in dem zentralen Wiki-System oder vielleicht hat man sogar wirklich ein spezielles Wissens-Management-System oder Knowledge-Database, je nachdem, das ist dann egal, aber irgendwo muss das halt sinnvoll hinterlegt sein. Was bevorzugst du da eigentlich, Andi? Dokumentation eher im Repository oder zentrales System? Was ist da deine Erfahrung? Jetzt abgesehen vom Code natürlich, denn man dokumentiert im Code, aber alles rundherum, das so ein bisschen in Richtung Design Documents geht.

Andy Grunwald (00:19:35 - 00:20:48)

Alles, was in Richtung Design Documents geht, Request for Comments, Discovery Documents, Architecture, Decision Records, ist nicht alles dasselbe, geht aber alles in die Richtung, und zwar eine Architektur, ein System, eine Änderung dokumentieren. sowas bin ich eher ein freund davon wenn das zum beispiel in dem wiki steht oder in einem google doc oder einem dropbox paper oder ähnliches warum, weil in der regel zumindest während der review phase die, Möglichkeit, an dem Dokument kollaborativ zu arbeiten, in diesen Tools deutlich besser ist. Man kann schneller kommentieren, man kann gegebenenfalls in einen Vorschlagmodus gehen, man hat vielleicht direkte Einbindung von externen Whiteboard-Tools oder Ähnliches. Klar, gibt's auch bei GitHub irgendwie so eine Art Diagrammunterstützung und so weiter und so fort. Aber in der Kollaborationsphase hab ich die gerne in wirklich in Editoren, ja, so Google Docs, Dropbox, PayPal oder Ähnliches, Wenn das dann später entschieden wurde und genauso gemacht wird, dann kann man überlegen, ob man das dann irgendwann in GitHub oder in Git überführt. Ich rede jetzt nur von Design-Dokuments und Architectural Decision Records und so weiter und so fort. Wenn es um wirkliche Dokumentation geht, da bin ich so ein Freund davon.

Wolfi Gassler (00:20:48 - 00:20:50)

Moment, was ist denn wirkliche Dokumentation?

Andy Grunwald (00:20:51 - 00:21:56)

Naja, wie funktioniert das System, wie konfiguriere ich das und so weiter, das sind ja nicht die Sachen, also wie man das konfiguriert und was zum Beispiel jeder Konfigurationstyp für eine Möglichkeit hat, ob das jetzt ein Integer ist, ein String oder was heißt der Geier nicht, das ist ja alles nicht Teil des Design-Dokuments. Natürlich kann ein Design-Dokument so tief gehen, aber wie es dann später wirklich implementiert ist, kann ja immer noch anders sein und sowas ist dann schon Dokumentation oder wie setze ich ein PG-Bouncer auf oder, oder wie backupe ich meine, meine Post-Geräte-Datenbank mit PG-Hoard oder ähnliches. da kommt's immer ganz drauf an, was, für wen ist denn die Dokumentation? Für den Entwickler? Für den Endanwender? Und da kommt's dann auch drauf an, wer ist, wer ist die Zielgruppe und wo treibt sich die Zielgruppe rum und wo pack ich die am besten hin? Man sieht es ja zum Beispiel sehr viel bei Open-Source-Dokumentationen oder bei Open-Source-Projekten. Viele Leute haben einen Doc-Folder im Git und ein paar Markdown-Dateien. Wenn es aber dann an den Endanwender geht, die erfolgreichsten Projekte haben dann nochmal eine Webpage mit Dokumentationen drauf. Das sind dann meist so zwei verschiedene Gruppen. Die Endanwender nutzen es wirklich und die Leute, die denken auch, ich mache mal einen Pull-Request oder ein Issue, die sind eh schon auf GitHub zu Hause.

Wolfi Gassler (00:21:56 - 00:23:04)

Und ich glaube, genau darum geht es, dass man dann die Daten auch in einem System zur Verfügung hat. Ob die vielleicht im Hintergrund in unterschiedlichen Repositories liegen, ist gar nicht so das Problem dann, solange man eben eine zentrale Suche vor allem hat, dass man wirklich die richtigen Dokumente auffinden kann. Weil das Problem ist, wenn ich nicht genau weiß, wo ich suchen muss, in welchen Repositories das zum Beispiel liegt, gerade wenn es um irgendein Problem geht, oder ich vielleicht mal schnell rausfinden will, in der Firma, wie handelt denn Team XY die Implementierung von dieser API, dann ist es natürlich angenehm, wenn ich da zentrale Suche habe, in einem zentralen System, in einem Wiki, um schnell an die Dokumente zu kommen. Also zuerst rauszusuchen, okay, wie viele Repositories gibt es denn? Welches Repository ist das Richtige? Welches Repository gehört diesem Team, wo genau dieses Projekt drin liegt? Dann haben die Teams vielleicht unterschiedliche Strukturen in den Repositories, wie sie dokumentieren. Insofern macht es Sinn, eine Art zentrales System zu haben. Und eigentlich, da wo ich Einblick habe, alle größeren Firmen, wo einfach mehrere Teams zusammenarbeiten, die haben normal ein zentrales System, wo man zentral suchen kann, um möglichst schnell an die Informationen zu kommen.

Andy Grunwald (00:23:04 - 00:23:34)

Bei Dokumentation, welches System du nutzt, ich denke, da kann man nur verlieren, weil jeder hat eine Meinung. Und der eine mag Confluence, der andere mag Slab.com, der dritte mag alles in Git. Weiß ich nicht. Ich denke einfach nur wichtig ist, dass man Dokumentation hat und gut ist. Ich denke, da sollte man vielleicht hier und da mal ein bisschen zurücktreten und nicht so auf seinem Standpunkt verharren, sondern seid froh, dass Dokumentation da ist. Schreibt sie hier und da mal, weil ich glaube, da müssen wir uns auch alle zu zwingen. Aber Dokumentation in geschriebener Form ist, glaube ich, schon mal eine gute Sache.

Wolfi Gassler (00:23:34 - 00:23:41)

Kannst du mir noch eine Frage beantworten, warum alle Wikis, die so herumschwirren, alle so altmodisch sind?

Andy Grunwald (00:23:41 - 00:23:42)

Was ist denn ein modernes Wiki?

Wolfi Gassler (00:23:43 - 00:23:47)

Ja, vor allem das User-Interface. Das User-Interface schaut immer aus, als wäre es aus den 90ern.

Andy Grunwald (00:23:47 - 00:23:51)

Aber was ist denn ein modernes Wiki? Was stellst du denn da vor?

Wolfi Gassler (00:23:51 - 00:23:57)

Ein schöneres User-Interface. Ich habe mir jetzt geoutet, dass ich kein Hardcore-Entwickler bin, der nicht nur Markdown falsch schreibt.

Andy Grunwald (00:23:57 - 00:24:08)

Du hast gerade ein grünes T-Shirt an. Ich würde zum Beispiel nie ein grünes T-Shirt anziehen. Warum, weiß ich auch nicht, aber sehr wahrscheinlich, weil ich es nicht schön finde. Also schön ist ja sehr subjektiv. Also was ist denn ein schönes User-Interface? Es gibt Leute, die finden die OpenSSL-Webseite schön.

Wolfi Gassler (00:24:09 - 00:24:18)

Ja, aber du hast ja auch keine Webseite aus den 90ern, wo irgendwie so ein under construction GIF, animated GIF oben ist. Die Zeiten ändern sich ja.

Andy Grunwald (00:24:18 - 00:24:21)

Meines Erachtens nach sollte auch wieder Schnee im Winter sein auf den Webseiten.

Wolfi Gassler (00:24:22 - 00:24:40)

Oder eine schöne Volltextsuche, die einfach gut funktioniert und die mir vielleicht Autocompletion-Vorschläge gibt und solche Dinge. Einfach ein modernes System, das man so gewöhnt ist aus anderen Systemen. Und irgendwie, Wikis haben sich nicht weiterentwickelt, kommt mir vor. Einfach wenn es um UX, UI geht.

Andy Grunwald (00:24:40 - 00:24:42)

Vielleicht, weil sie auch einfach funktionieren.

Wolfi Gassler (00:24:43 - 00:24:54)

Ich seh schon, du bist zu viel Backend-Developer. Ich hoffe, alle UI, UX-Developer fühlen jetzt mit mir mit, dass Wikis leider schlechte Oberfläche haben. Meiner Meinung nach.

Andy Grunwald (00:24:54 - 00:25:13)

Okay, wir wissen, wo es steht. Aber jetzt ist es so, niemand hat Zeit, lange Dokumente zu lesen. Weil wir sitzen ja eh schon den ganzen Tag vor dem Rechner, unsere Augen schreien schon, und jetzt willst du, dass ich immer noch mehr lese und noch mehr lese. Was gibt es denn nochmal für andere Formen von Knowledge-Sharing, die ich so im Team heute anwenden kann?

Wolfi Gassler (00:25:13 - 00:26:03)

Ja, wenn wir mal ganz unten bleiben, weil wir gerade bei Code jetzt schon waren. Ich glaube, eine der häufigsten Formen, die eigentlich so auch ständig angewandt wird, ist halt Pair-Programming und vielleicht auch Mob-Programming. Also Mob ist dann mehr als zwei, dass man halt wirklich in der Gruppe gemeinsam an irgendwas schraubt. Und wenn man das einfach gemeinsam macht, wissen auch alle automatisch Bescheid. Das heißt, es braucht keine Dokumentation lesen, es braucht kein aktives Sharing weitergeben. Wenn man das gemeinsam macht und auch vielleicht gemeinsam bespricht und gemeinsame Entscheidungen trifft, dann hat man da natürlich viele Leute an Bord. Da muss man natürlich dann immer abwägen, okay, wie viele Leute holt man dazu. Üblicherweise ist ja eher Pair Programming, dass es zwei Leute sind. Wir sind dann natürlich auch zwei Leute gebunden. Aber üblicherweise wird die Codequalität besser und wenigstens zwei Leute wissen sehr detailliert Bescheid über den Code.

Andy Grunwald (00:26:04 - 00:26:15)

Wie bist du denn immer als Engineering Manager damit umgegangen, wenn die Kritik von deinem Chef kam? Hör mal, wieso brauche ich denn jetzt zwei oder vielleicht sogar drei oder vier Leute für Smart Programming, damit die mir ein Feature entwickeln? Dafür bereue ich doch die Zeit.

Wolfi Gassler (00:26:15 - 00:27:19)

Ich hab's meinem Manager gar nie gesagt. Das ist das Einfachste. Aber ich glaube, dass sich das heutzutage schon herumgesprochen hat, dass dadurch die Codequalität einfach auch besser wird. Das heißt, die Lösung an sich wird besser, wenn man zu zweit an dem Code arbeitet. Man soll ja auch nicht vielleicht jede Zeile zu zweit schreiben. Aber gerade so Schlüsselstellen oder wo schwierigere Stellen im Code, da macht Backprogramming natürlich Sinn. Man spart sich dann vielleicht auch Zeit mit dem Code-Review, weil das Code-Review wegfallen kann. Wir haben da übrigens auch in Episode 16 darüber gesprochen. wie Code Reviews ausschauen können, wie man Code Reviews auch reduzieren kann im Bezug auf Zeitinvestment und per Programming wäre da eine Möglichkeit, weil da ja schon zwei Personen bzw. vier Augen über den Code drüber geschaut hat, kann man sich vielleicht dann auch Code Reviews sparen. Und dann am Ende hat man vielleicht gar keine Zeit verloren, weil bessere Qualität, weniger Iterationen, keine Code Reviews und weniger Bugs vielleicht, weniger Frust beim Kunden. Also es gibt viele Dinge, die das natürlich befürworten.

Andy Grunwald (00:27:19 - 00:27:32)

Bessere Qualität, stelle ich mal zur Frage, wenn ich jetzt mit dir Peer Programming mache und du programmierst JavaScript, ob das zu besserer Qualität führt, weiß ich jetzt auch nicht. Aber ist Peer Programming und Mob Programming nicht eigentlich eine Aktivität, die ich nur in einem Büro mache?

Wolfi Gassler (00:27:33 - 00:28:22)

Also rein von technischer Seite spricht eigentlich nichts dagegen, das auch remote zu machen. Und ich kenne auch einige, die das machen. Ist heutzutage kein Problem mehr. Du hast in den ganzen IDEs teilweise Support dafür, dass du also nicht nur den Bildschirm teilst, sondern wirklich die IDE. Zum Beispiel VS Code. Kostenlos kannst du es einfach machen, andere Leute einbinden, kannst gemeinsam an dem gleichen Code arbeiten, ohne dass du den Bildschirm sharest, was teilweise gerade wenn es um Code geht und große Auflösungen am Bildschirm dann schon ein Problem wird teilweise. Also kannst du wirklich direkt den Code sharen, deinen Cursor und kannst gemeinsam an dem Dokument arbeiten und bist dann vielleicht noch in einem Videocall verbunden oder nur Audio und kannst sprechen. Da gibt es eigentlich kein Problem mehr. Natürlich, früher war das eher, man hat gemeinsam einen Kaffee getrunken vor dem Bildschirm und hat das gemeinsam gelöst. War auch nett, aber warum nicht Remote?

Andy Grunwald (00:28:22 - 00:28:43)

Ja gut, die Kaffeinsucht kann man, glaube ich, auf Remote nicht reinziehen. Von daher, wir verlinken natürlich einmal die VS Code Extension in den Shownotes. Ja, aber jetzt habe ich dir gerade schon mal gesagt, okay, wir sitzen jetzt den ganzen Tag vorm Computer und jetzt willst du ja immer noch, dass ich vorm Computer sitze. Hast du nicht mal was Interaktives für mich? Hast du nicht mal was, wo ich mich mal weg vom Computer bewege?

Wolfi Gassler (00:28:43 - 00:28:47)

Du hast doch eh deinen Hund. Du bewegst die ganze Zeit deinen Hund mit dir herum.

Andy Grunwald (00:28:47 - 00:29:39)

Der Hund bewegt mich. Ich bin ein Freund von geschriebener Dokumentation. Ich bin ein Freund von Pair- und Mobprogramming. Ich fand das immer cool, weil ich da immer sehr, sehr viel gelernt hab. Man muss aber auch sagen, man muss das ganze Team mal irgendwie immer dazu bewegen, endlich mal Dokumentation zu schreiben. Zum Beispiel, dass ihr das als festen Bestandteil der Definition of Done macht. oder hey lasst uns doch mal bitte aktiv die zeit nehmen für programming wo ich aber ein riesen fan von bin sind sind gilden oder interne konferenzen und das ist jetzt nicht das gleiche aber wir fangen einfach mal mit gilden an eine gilde ist eine gruppe von leuten die, das gleiche Ziel, das gleiche Problem oder das gleiche Interesse an einem Thema haben und dann zusammenkommen. Das kommt, dieses Konzept kommt aus einem Buch, nennt sich Community of Practice, verlinken wir auch einmal in den Shownotes.

Wolfi Gassler (00:29:40 - 00:29:49)

Moment, das hat nicht Spotify erfunden. Nein. Das hat nicht Spotify erfunden und ihr habt immer die ganze Zeit geglaubt, Gilden hat Spotify erfunden.

Andy Grunwald (00:29:49 - 00:29:53)

Nein, Gilden kommt aus einem Buch namens Community of Practice.

Wolfi Gassler (00:29:53 - 00:30:04)

Meine Welt bricht zusammen. Zuerst habe ich schon erfahren müssen, dass eigentlich dieses ganze Konzept, was Spotify da groß verkündet hat, gar nicht bei Spotify zur Anwendung kommt. Und jetzt erzählst du mir noch, Gilden wurden nicht von denen erfunden.

Andy Grunwald (00:30:04 - 00:30:54)

Auf jeden Fall. Wie kann sowas aussehen? Zum Beispiel bei Trivago hatten wir mehrere Gilden. Wir hatten eine Python-Gilde, die hat sich primär dann zum Beispiel um die Programmiersprache Python gedreht. Wir hatten eine Gilde zum Bereich Machine Learning oder auch Kafka, weil Kafka ist ja jetzt nicht unkomplex das System. Wie benutzt man das richtig? Welche Features kommen da und so weiter? Wir hatten aber auch eine Gilde, die ich eine ganze Zeit lang mit ein paar Kollegen geleitet habe, das waren die Cloud-Infrastructure-Gilde und da ging es natürlich, Achtung, wer hätte es gedacht, um Cloud-Infrastruktur, wie z.B. wie funktioniert Load-Balancing in der Cloud, wie kann man z.B. mit Terraform irgendwas steuern, weil nicht jeder ist damit familiär, aber da wurden sowas halt z.B. auch immer besprochen oder wie viel Wie sieht unsere Kostenstruktur in der Cloud aus? Wie messen wir Kosten? Wie könnt ihr zum Beispiel analysieren, wie viel dein Projekt in der Cloud kostet und so weiter und so fort?

Wolfi Gassler (00:30:54 - 00:31:07)

Wie war der Ablauf in diesen Gilden? Du sagst jetzt, wurden da Präsentationen gemacht? Für wen waren die? Waren die für Externe? Haben die Gilden sich an Teams gerichtet oder wie ist das rein technisch abgelaufen?

Andy Grunwald (00:31:08 - 00:31:15)

Also rein technisch war das erstmal nur ein Kalenderinvite und dieser Kalenderinvite war glaube ich alle zwei Wochen oder alle drei Wochen irgendwie sowas.

Wolfi Gassler (00:31:15 - 00:31:18)

Ich glaube, es hat die Guild da selber entscheiden können.

Andy Grunwald (00:31:18 - 00:31:45)

Ja, ja, genau. Also ich rede jetzt nur von der Cloud Infrastructure Guild. Du hast einen regulären Kalenderinvite und was wir zu Bürozeiten gemacht haben, wir haben uns dann in einem Meetingraum getroffen und da gab es in der Regel ein oder zwei Vorträge zu spezifischen Themen. Das bedeutet, wir mussten natürlich als Organisatoren dann vorher einmal durch die Firma rennen und Leute finden, die entweder ein interessantes Projekt gerade gemacht haben oder die gerade ein interessantes Projekt abgeschlossen haben und darüber erzählen wollen oder irgendwie ein neues Feature entwickelt haben.

Wolfi Gassler (00:31:46 - 00:31:48)

Und wer war Mitglied von diesem Guilden?

Andy Grunwald (00:31:48 - 00:32:20)

Der Kalender-Invite war offen für jeden. Wir haben immer ein paar Tage vorher im Slack hatten wir so einen Tag-Channel und in dem Tag-Channel waren alle Techies drin und wer dann sich als Techie bezeichnet, konnte einfach in diesen Slack-Channel. Und über Zeit waren da 60, 70, 80 Leute in diesem Invite und die konnten sich dann immer dazuschalten, in ein Meeting rumsetzen oder ähnliches. Wir haben es auch gestreamt. Und dann gab es alle zwei bis drei wochen ein zwei vorträge mit fragen antwort teilweise eine diskussion und so eine art man kann sich das vorstellen.

Wolfi Gassler (00:32:20 - 00:32:23)

Eigentlich wie ein meetup oder ein internes meetup fast.

Andy Grunwald (00:32:23 - 00:32:56)

Ja, eigentlich schon. Auch themengebunden. Aber eine Gilde kann auch anderes sein. Wir haben die Gilde jetzt primär mit Vorträgen durchgezogen. Ich kenne zum Beispiel auch andere Gilden, das sind eigentlich nur Interest Groups, die kümmern sich zum Beispiel um API-Design. Und dann auf Code-Ebene zum Beispiel. Die entwickeln dann den API-Standard für die Firma. Also eine Gilde muss nicht im Vortragsstil sein, Einfach nur eine Gruppe von Leuten aus verschiedenen Teams, wild gemixt, die sich um ein Thema kümmern und das dann in der Firma weitertreiben.

Wolfi Gassler (00:32:56 - 00:33:27)

Ihr habt das auch zum Beispiel in der PHP-Guild damals erlebt, die haben den Coding Style Guide gemeinsam entwickelt. Das war ein harter Kampf über Wochen hinweg, aber er ist gestanden. Irgendwann sind die Fetzen geflogen, aber am Ende hat man wenigstens einen firmenweiten Coding Style Guide gehabt. Das heißt, Guilds können natürlich auch Entscheidungen treffen, wenn das von den Mitgliedern so gewünscht ist. auch vom Management so natürlich unterstützt wird, klarerweise. Aber ganz oft haben die auch wirkliche Entscheidungsgewalt über den jeweiligen Spezialbereich.

Andy Grunwald (00:33:27 - 00:34:15)

Das ist aber ein wichtiger Punkt. Da, sofern eine Gilde Entscheidungsgewalt hat, beziehungsweise die Möglichkeit hat, neue Firmenstandards festzulegen, da muss natürlich Management-Backing dabei sein. Das bedeutet, holt euch einen Sponsor, am besten irgendeinen technischen Management-Leader, der CTO oder ähnliches, der die ganze Sache natürlich auch unterstützt. Weil sonst habt ihr die Experten, die in der Gilde drin sitzen, die kommen mit einem Proposal daraus und dann irgendjemand von hinten links sagt, hey, ich find Whitespace ist aber doof, ich hätt gern Tabs. Und dann geht die ganze Diskussion wieder von vorne los. Deswegen ist es sehr wichtig, dass die Gilde eigentlich offen für jeden ist. Und es ist, führt euch das immer wieder vor Augen, es ist eine Gruppe von Leuten mit demselben Problem, mit demselben Interest, die zusammenkommen, um ein Thema zu lösen, zu besprechen, zu teilen und so weiter.

Wolfi Gassler (00:34:15 - 00:34:37)

Jetzt hast du schon erwähnt, man sollte C-Level-Support haben oder Backing. Hast du mal erlebt, dass irgendwie sich Leute beschwert haben, dass das nur Zeitverschwendung ist, dass da dann plötzlich unter Umständen 50 Developer gemeinsam in einem Raum sitzen und da irgendeinen Vortrag hören oder über irgendwelche Coding-Style-Guides streiten? Und vor allem, was würdest du denn den Leuten sagen?

Andy Grunwald (00:34:38 - 00:36:01)

Wenn man sowas hört, dass das ein Problem ganz tief in der Kultur ist, aber habe ich sowas schon mal gehört? Ja, natürlich. Zum Beispiel im klassischen Agenturumfeld ist sowas, da wo wirklich ganz klassische Zeit gegen Geld gemacht wird, wo Leute natürlich auch ihre Arbeitszeit auf Projekte buchen müssen und Co. Da kommt man natürlich relativ schnell in Bredouille, weil dort das generelle Mindset herrscht. Wir haben hier einen Entwickler und ein Entwickler muss mindestens so und so viele Stunden auf Projekte buchen, damit die ganze Sache hier rentabel ist. Ich hörte auch schon hier und da, dass es diverse Agenturen gibt, die das deutlich relaxter sehen, die natürlich dann ein anderes Angebotsmodell haben oder ähnliches. Aber ich würd mich mal aus dem Fenster lehnen und sagen, okay, in vielen Bereichen, wo ganz klares Time-Tracking stattfindet und wo gewisse Schwellenwerte mit deiner Produktivität erreicht werden müssen, da kommt man relativ schnell an solche Aussagen. Ich glaub, ich kenn noch früher, Der Kunde zahlt nicht für Unit-Tests. Geht so ungefähr in dieselbe Richtung, meines Erachtens nach. Meines Erachtens nach ist das aber auch alles ein bisschen zu kurz gedacht. Weil das eigentlich eine Learning Opportunity für jeden Entwickler ist und man möchte ja, dass seine Entwicklerinnen und Entwickler und die Tech-Leute sich kontinuierlich weiterentwickeln, damit die auch zu besseren Lösungen beitragen, damit der Tech-Stack aktueller bleibt, damit man nicht diese technischen Schulden hat und irgendwann alle sagen, hey, pass mal auf, wir können hier kein Feature mehr entwickeln, wir müssen jetzt erst mal alles refactoren.

Wolfi Gassler (00:36:01 - 00:37:08)

Vor allem muss man natürlich auch immer sehen, wenn dann die Management-Ebene auch bei dem Kunden gegenüber sagt, wir haben die besten Developer, wir haben super weitergebildete Developer. Und auch den Mitarbeitern und Mitarbeiterinnen gegenüber sagt, wir haben das super Umfeld, wo ihr euch weiterentwickeln könnt. und wo ihr lernen könnt. Das liest man ja heutzutage fast überall. Und am Ende wird dann nicht erlaubt, dass man irgendwelche Guilds macht oder dass irgendwelche Zeiten freigeschaufelt werden für die Mitarbeiterinnen, damit sich die weiterbilden können und Knowledge Sharing betreiben können. Ganz abgesehen davon, dass es auch einen finanziellen Vorteil hat, weil wenn die einfach schneller sind in Zukunft beim Programmieren, wenn ich weniger Sachen doppelt mache, wenn ich Wenn ich vielleicht besser zusammenarbeiten kann, dann hat das ja auch wirklich einen monetären Vorteil am Ende. Also wenn ich das sogar mal ausblende, dann muss ich aber trotzdem noch sagen, wenn ich ein interessanter Arbeitgeber sein will, dann muss ich halt auch dementsprechend diese Möglichkeiten schaffen und nicht nur ins Job-Ad reinschreiben, sondern dann auch wirklich leben. Und das ist, glaube ich, das größte Problem, wenn es nicht gelebt wird vom Management, scheitert es halt auch in allen ebenen darunter da gibt es einen schönen.

Andy Grunwald (00:37:08 - 00:37:42)

Spruch und zwar geht ein teamleiter zum ceo und sagt der wolfgang der möchte jetzt auf die konferenz kostet 2000 euro man sagt der ceo ja was ist was passiert denn wenn ich das zahle und er geht sagt der teamleiter ja was passiert denn wenn er nicht geht und bleibt Und das ist es eigentlich. Was passiert eigentlich mit den Leuten, wenn die nicht lernen? Und deswegen sage ich, die ganze Sache ist halt zu kurz gedacht. Kurzfristig mag das sein, dass ein solches Guild-Meeting, wo 30 Leute da sind, sehr teuer ist. Gar keine Frage. Mittel- bis langfristig, sofern die ganze Sache richtig aufgebaut ist, hat die ganze Firma was davon, meines Erachtens nach.

Wolfi Gassler (00:37:43 - 00:38:05)

Was glaubst du, was das Prozent-Duell ist bei einer Person? Was würdest du da einplanen für Lernen, Weiterbilden, Knowledge-Sharing? Also jetzt kein Peer-Programming natürlich und keine Dokumentation, weil das ist, glaube ich, Teil von der eigentlichen Arbeit, aber alles, was darüber hinausgeht, gilt, interne Konferenzen, externe Konferenzen vielleicht auch. Wie viel Prozent würdest du schätzen?

Andy Grunwald (00:38:05 - 00:38:06)

Sollte jemand dafür investieren, meinst du?

Wolfi Gassler (00:38:07 - 00:38:13)

Ja, also im C-Level. Was würdest du veranschlagen jetzt von der Arbeitszeit? Wie viel Prozent?

Andy Grunwald (00:38:13 - 00:38:22)

Wir reden nur über explizites Lernen. Explizites Lernen meine ich, ich setze mich jetzt hin, blocke die Zeit dafür und nicht implizites Lernen, das, was ich auf Stack Overflow lese und so weiter, richtig?

Wolfi Gassler (00:38:22 - 00:38:27)

Ja, natürlich. Also alles, was abseits des Entwicklens zum Beispiel passiert.

Andy Grunwald (00:38:27 - 00:38:29)

Ich würde mal sagen, alles so zwischen 10 und 20 Prozent.

Wolfi Gassler (00:38:29 - 00:38:34)

Ja das wäre jetzt auch meine Schätzung gewesen also eine Stunde am Tag würde ich mal sagen.

Andy Grunwald (00:38:34 - 00:38:39)

Wir brechen das auf eine Woche runter dann wäre es halt irgendwas so zwischen vier Stunden und einem Arbeitstag.

Wolfi Gassler (00:38:39 - 00:38:41)

Ja würde ich auch so kalkulieren.

Andy Grunwald (00:38:41 - 00:40:51)

Und das muss gar nicht explizit immer so sein, ich nehme mir jetzt jeden Freitag vor, eine neue Datenbank auszuprobieren. Das kann ja auch in irgendeiner Art und Weise schleichend sein, wie zum Beispiel diese Guild-Meetings, diese Pair-Mob-Programming oder, oder, oder. Von daher, meines Erachtens nach ist auf jeden Fall ein großes Zeitinvestment, ist auch ein großes Geldinvestment. Aber sofern man als Firma da ein bisschen Guidance drauflegt und vielleicht auch ein bisschen die Richtung bestimmt oder Grenzen setzt, dann ist das alles super. Zum Beispiel so diese klassischen Konferenzbudgets, die Firmen haben, ist ja auch so eine Art Lernen. Obwohl Lernen natürlich nicht gleich Knowledge Sharing ist, aber zum Beispiel gibt es ja auch beim Konferenzbudget oft Grenzen. Auf der einen Seite, du hast jetzt irgendwie 2.000 Euro Konferenzbudget. Die werden aber jetzt zum Beispiel nicht für die Black Hat Conference, das ist eine Sicherheitskonferenz in Las Vegas für ... meist so für White Hat Hacker und so was, wenn du jetzt JavaScript programmierst. Weiß ich jetzt nicht, ob das so wirklich passt. Ja? Das sollte schon natürlich Job- oder rollengebunden sein. Aber kommen wir doch mal, wo wir grad über Konferenzen sprechen, wieder zu internen Formen, wie man knowledge sharing macht. Und natürlich gibt es das auch den Bereich Konferenz natürlich auch im internen Forum. Das muss nicht immer eine mehrtägige Konferenz sein, die die Firma organisiert, sondern das können auch ähnliche Meetings wie ein Guild-Meeting sein. Zum Beispiel Trivago war da eine ganze Zeit lang ganz vorne dabei und zwar haben die einmal pro Jahr ein sogenanntes Tech-Get-Together gemacht. das waren zwei tage wo wir in einer externen location waren und dann die so richtig mit call for papers und team building activities und allem drum und dran haben wir wirklich eine interne konferenz gemacht man muss natürlich auch sagen man braucht eine gewisse größe von der firma also so 100 150 200 tech leute sollte man schon sein damit diese konferenz auch wirklich breit gefächert ist weil so hatten wir dann wirklich themen über User Experience, User Design, bis über irgendwelche inner Details der JVM oder wie fängt man am besten mit Home Automation an. Also ihr seht auch schon, dass da nicht immer knallhart um Projekte innerhalb der Firma gehen muss, sondern vielleicht auch mal ein bisschen Zeit trackt, einfach mal um neue Inspirationen zu kriegen.

Wolfi Gassler (00:40:52 - 00:40:59)

Wir hatten auch einen Talk über Brotbacken zum Beispiel. Über die algorithmische Herangehensweise beim Brotbacken.

Andy Grunwald (00:40:59 - 00:41:35)

Dieser Talk war unglaublich schön. Schöne Grüße an Hendrik, was er gemacht hat. Hendrik ist ein faszinierter Softwareentwickler und er mag auch AB-Testing. Und er hat über Monate hinweg Brot gebacken mit verschiedenen Mehlsorten und hat alles ein- und ausgetauscht und dann natürlich alles dokumentiert. Und das hat er mal auf GitHub gepackt und guess what? Die ganze Sache ist auf Hacker News auf die Frontpage gekommen. Also ich habe noch nie jemanden gesehen, der ein GitHub-Repo zum Thema Brotbacken auf die Frontpage von HackerNews gekommen ist. Der hat es irgendwie geschafft. Verlinken wir euch natürlich auch in den Shownotes. Schaut mal rein. Anscheinend gibt es in der Entwickler-Community sehr viel Interesse ans Brotbacken.

Wolfi Gassler (00:41:35 - 00:42:01)

Da ist natürlich mittlerweile ein YouTube-Star, muss man auch dazu sagen. Hat einen YouTube-Channel. Verlinken wir natürlich auch gerne mit ziemlich vielen Followern. Aber man muss gar nicht so jemand sein, der vielleicht einen eigenen YouTube-Channel betreibt, sondern es kann wirklich jeder so einen Vortrag machen. Und das kann man gar nicht oft genug erwähnen, dass es in jedem Eck in der Firma interessante Themen gibt. Und auch Juniors, auch Studenten können Vorträge machen.

Andy Grunwald (00:42:01 - 00:44:06)

Ja, das große Problem ist, weil jeder kann Vorträge machen, ist, es gibt gar kein Problem. Die Herausforderung, die mir immer gegenübergestellt wird, wenn ich mit Leuten spreche und sie versuche zu motivieren, ob sie nicht mal einen Vortrag machen möchten, ist, ich weiß doch gar nichts. Alles das, was ich weiß, wissen die anderen doch schon. Und was ich dann sehr, sehr oft mache, ich frage die Leute oft, hey, woran arbeitest du denn? Ja, ich mache gerade ein WordPress-Plugin. Ja cool, erzähl mir doch mal was. Und auf einmal fangen die an, zu erzählen, und du siehst das Feuer in deren Augen, wie die dafür brennen, ein WordPress-Plugin zu installieren und zu schreiben. Und dann meine ich so, ja, aber Moment mal, wie bindest du das denn jetzt an die Content-Management-Funktionalitäten von WordPress an? Oder wie machst du denn damit jetzt Cross-Publishing, dass ich zum Beispiel den Content, den du in WordPress verlegst, zum Beispiel auch auf ein Mobile-Phone pushen kann, und so weiter und so fort. Und da kommen dann immer Antworten. und am ende und während des gesprächs schreibe ich dann oft mal ein bisschen mit und am ende habe ich dann so ein paar fragen und so ein paar antworten und geschichte hey pass mal auf hier ist was von der outline von deinem talk, werde ich immer mit großen augen angeguckt und wie jetzt ja all das was du mir gerade erzählt hast wusste ich gar nicht ja wie jetzt und dann erkläre ich halt immer, Nicht jeder weiß alles. Was die Leute doch immer denken, dass die Leute, zu denen man selbst aufschaut, alles wissen, was man selbst weiß. Das ist aber falsch. Jeder hat ein gewisses Wissen in einem Bereich. Und nicht jeder kann sich in jedem Bereich umschauen. Und wenn man sich das vor Augen führt, merkt man, dass dieser Satz, ich weiß doch gar nix, ich glaub, der richtige Begriff ist Poster-Syndrom oder so. Da komme ich dann mit meinem Bachelor-Studium um die Ecke, das weiß ich nämlich nicht. Meines Erachtens ist das totaler Blödsinn. Meines Erachtens nach kann jeder was erzählen. Und besonders, angenommen man hat da jetzt eine Gruppe von Senior-Engineers und Staff-Engineers und man kommt als Junior-Engineer da auf die Bühne und spricht einfach mal darüber über seine Erfahrungen, über sein Onboarding in der Codebase. Für mich als Senior oder Staff Engineer wäre das ein super interessantes Thema, weil das zeigt mir erstmal, wie einfach oder halt auch schwer unsere Source Code zu verstehen ist.

Wolfi Gassler (00:44:06 - 00:47:03)

Dieses Imposter-Syndrom, wie du richtig sagst, ist halt gerade in der IT-Welt überall, weil du kommst in irgendein Team, da sind alle Seniors drinnen, die kennen sich alle super aus, die erzählen dir jeden Tag, was du besser machen sollst. Dann gehst du auf irgendwelche Konferenzen, da hast du wieder super internationale Leute von den großen Firmen, Netflix, GitHub, die dir irgendwie in Vorträge zeigen, wie toll sie sind und dann kommst du da als kleiner Junior und sollst jetzt deinen Seniors im Team erklären was gut ist und da sagen natürlich alle ihr habt doch keine Ahnung. Und ich glaube man muss damit umgehen lernen man weiß nicht alles das ist ja auch gut so haben wir ja auch schon besprochen. Du kannst mir keinen Senior zeigen, der alles weiß. Das gibt's einfach nicht. Und wie du schon richtig sagst, das Onboarding-Beispiel ist super. Das kann ein Senior nicht wissen. Ein Senior kann nicht wissen, wie es ist, durch einen Onboarding-Prozess zu gehen, weil höchstwahrscheinlich das schon einige Jahre zurück ist. Und es gibt immer irgendwo interessante Dinge. Und wenn man da einfach mal klein anfängt, man akzeptiert, okay, ich weiß nicht überall Bescheid und es gibt andere, die wissen besser Bescheid in manchen Bereichen, Aber es gibt auch ganz viele Leute, die wissen weniger, auch in der Firma, in anderen Teams oder der Senior eben, der nicht weiß, wie es ist, durch einen Onboarding-Prozess zu gehen. Und wenn man diese Themen findet, wo andere Leute weniger wissen, es gibt sicher auch ein paar Leute im Publikum, die wissen mehr oder wissen genauso viel. Aber ist ja kein Problem, wenn im Publikum 50% Leute sitzen, die das nicht wissen, für die ist das super interessant und auf die muss man sich konzentrieren. Also da würde ich einfach vorschlagen, möglichst klein starten, vielleicht mal einfach ausprobieren, wer wenig Erfahrung hat im Präsentieren, in irgendeiner Gilde oder so, nicht gleich zur externen Riesenkonferenz gehen, sondern da einfach mal langsam starten, dann bekommt man auch das Feedback, was gut ist, was vielleicht optimierungsbedürftig ist und dann kann man dementsprechend weiter wachsen in seinen Präsentationsskills und findet auch mal raus, was interessant ist und was nicht. Da sind natürlich solche Leute wie der Andi, der dann einem sagt, okay, das ist super interessant, extrem wichtig und hoffentlich machen das halt auch die Manager und andere Seniors, dass die einfach die Juniors oder Students oder was auch immer im Team einfach ein bisschen pushen und denen auch zeigen, dass man über solche Dinge sprechen kann und die positiv bestärken, damit die Leute nach außen gehen und auch am Ende dem Senior was beibringen können. Mein Lieblingsbeispiel ist da auch immer mit den Studenten, ich habe denen das immer gesagt, die eine Position angefangen haben, dass sie die sind, die den Blick von außen haben, diesen uneingeschränkten Blick, die nicht im Tunnel drin sind von der Firma und die erstmal sagen können, hey, das ist komisch, das ist schwierig, das war beim Onboarding extrem eigenartig oder warum habt ihr das so und so gemacht? Also du hast diesen Blick nur einmal, wenn du als Junior oder Student reinkommst und diese Chance musst du nutzen. Dieses Learning, was du dort machst, kannst du natürlich auch genauso in einem Vortrag verpacken. Super Idee.

Andy Grunwald (00:47:03 - 00:49:18)

Intern gibt es etliche Möglichkeiten, diese Vorträge zu üben. Wichtig ist jedoch, dass jemand dich bestärkt oder ihr jemanden bestärkt, dass das Wissen, was kommuniziert werden kann, auch wirklich Wissen ist und dass die Person dann auch ein bisschen Selbstvertrauen kriegt. Zum Beispiel, Eine tolle Sache, die wir bei Trivago sehr oft genutzt haben, sind sogenannte Postmortem-Konferenzen. Und zwar kommt es wieder so einer Art aus dem Infrastrukturbereich. Systeme fallen aus, wir haben ein Inzident. Nach einem Inzident schreiben wir ein Postmortem-Dokument. Was lief gut, was lief schlecht, was müssen wir verbessern und so weiter und so fort. Was wir dann einmal hatten, einmal im Quartal hatten wir eine Konferenz, wo wir drei Ausfälle aus dem vorherigen Quartal präsentiert haben. Aber nicht so, hey, das ist passiert, die Kubernetes-Klasse ist hops gegangen und dann gab es einen Regional Outage bei Amazon und so, sondern, Das wurde alles in so einer kleinen Comedy-Show mal so ein bisschen verpackt. Und wir haben uns da mal ein bisschen selbst auf Korn genommen und haben uns über uns selbst gelacht. Weil im Endeffekt waren die meisten Ausfälle von uns selbst verursacht auf Basis von irgendwelchen Fehlern, Bugs oder einfach nur fehlerhaftem ... Oder man hat ein Enter von einem falschen Befehl auf dem Dev anstatt auf dem Podsystem ausgeführt, et cetera, et cetera. Passiert den Besten. Einfach den Leuten Mut machen. um sich einfach mal zu trauen, auf die Bühne zu gehen und was zu erzählen. Apropos erzählen. Das ist nämlich genau ein Klassiker bei den Herausforderungen von solchen internen Konferenzen, intern gilt's. Ihr benötigt einen Driver, einen Organisator, jemanden, der dieses Format kontinuierlich nach vorne treibt. Und kontinuierlich nach vorne treiben heißt jetzt nicht, nur den Kalendertermin einzustellen, Sondern man muss eigentlich konstant auf der Hut sein und neue Speaker finden, immer nur für Content sorgen, mal eine Diskussion anstacheln und so weiter und so fort. Denn ohne jemanden, der das aktiv treibt, wird es über kurz oder lang sterben. Am Anfang sind dann noch alle Leute motiviert, man kriegt vielleicht zwei, drei, vier, vielleicht acht Talks zusammen. Aber was passiert beim fünften Meeting oder beim sechsten? Irgendwann denkt man, wir haben doch schon darüber geredet. Da muss jemand Kreatives an den Platz, der Leute ermutigt, über diese Themen zu sprechen.

Wolfi Gassler (00:49:18 - 00:49:45)

Wer übrigens mehr über dieses Thema wissen will, Episode 29, da haben wir darüber gesprochen, wie man Meetups organisiert und wie viel Zeit das ist. Und nachdem das eigentlich nur ein internes Meetup ist, ist das eigentlich sowas Ähnliches. Also das braucht Zeit, das braucht einen Driver und es entsteht auch nicht von selber. Aber ich glaube, es kann jeder in der Firma anstoßen und hoffentlich wird das positiv aufgenommen und auch dementsprechend unterstützt. Andi, was haltest du eigentlich von Lunch Talks?

Andy Grunwald (00:49:45 - 00:49:47)

Ich habe gehört, dass Leute sowas machen. Habe ich noch nie gemacht.

Wolfi Gassler (00:49:48 - 00:50:03)

Also die Grundidee, ihr habt es auch selber oft miterlebt, ist, dass man einen Vortrag mit dem Essen verbindet. Man bekommt irgendwo Essen üblicherweise, irgendein kleines Buffet. Wir hatten das sogar an der Uni schon und Free Food an der Uni, da ziehst du alle an.

Andy Grunwald (00:50:03 - 00:50:14)

Kann man nicht einfach Pizza bestellen? Buffet also sorry natürlich beim buffet bin ich immer dabei aber ich habe jetzt eigentlich gedacht wir bestellen jetzt eine runde pizza und setzen uns vor irgendein screener schauen wir uns einen talk auf youtube an.

Wolfi Gassler (00:50:14 - 00:51:46)

Ja ich glaube pizza wäre schon zu viel gewesen für das budget damals an der uni das war leider sehr sehr beschränkt wie gesagt unibudget sind leider nicht so umfangreich wie in der industrie da muss man mit kleineren sachen da war da war man teilweise sogar froh wenn da irgendwie zwei drei brötchen oder so gestanden sind die irgendwie vom vortag von irgendwo aufgetrieben worden sind. Aber egal, es geht darum, dass man sich beim Essen vielleicht trifft und dann eben gemeinsam ein Talk anschaut. Jemand gibt ein Talk, man spricht über irgendetwas und verbindet es mit dem Essen. Sehr beliebt bei den Managern natürlich, weil es meistens in der Mittagspause passiert und dann verlierst du keine Zeit, weil die Leute ja in ihrer Mittagspause noch freiwillig dort irgendwo hingehen. Und da sehe ich auch ein bisschen den Knackpunkt von diesen Lunch Talks. Die funktionieren ganz gut in einer Firma, meiner Meinung nach. Ist natürlich sowieso immer freiwillig, aber da kann man dann hingehen, bekommt vielleicht ein gratis Essen. Das ist auch etwas lockerer üblicherweise. Aber was ich jetzt öfters gesehen habe, ist, dass diese Lunch Talks eins zu eins übernommen worden sind in das Home Office, Remote Work. Und da ist es für mich dann schon die Frage, wenn du viele Meetings hast und dann ist deine Mittagspause auch noch mit einem Meeting geblockt, wo du dann vor dem Computer sitzt, dich nicht bewegst und einfach dein Essen nebenbei noch reinschaufelst, dann finde ich das jetzt weniger gut. Also die Lunchtags waren früher eine gute Erfindung im Office. Für Homeoffice und Remote Work, meiner Meinung nach, sind die ein bisschen kritischer zu sehen und ich bin nicht mehr so ein großer Fan davon, wie ich früher eigentlich war.

Andy Grunwald (00:51:46 - 00:52:03)

Ich war dann noch nie so ein richtiger Fan von, aber ich bin auch nicht der Mensch, der sich auf YouTube irgendwelche Talks reinzieht, weiß ich nicht. Ich bin da eher so der Freund von, dass man dann zu einer richtigen Konferenz geht, sich aktiv Zeit nimmt, sich in den Raum setzt und dann dem Speaker lauscht. Ich weiß nicht, ich war noch nie der YouTube Talk-Freund.

Wolfi Gassler (00:52:04 - 00:52:19)

Da waren aber auch echte Talks dabei, also es muss nicht immer ein YouTube Talk sein, überhaupt nicht. Bei Trivago war das oft ein YouTube Talk, aber das hat auch ein ganz normaler Talk eine Präsentation sein können, wo es halt auch was zum Essen gibt oder einfach dass es in der Lunchtime stattfindet.

Andy Grunwald (00:52:19 - 00:52:50)

Aber wir reden jetzt hier gerade sehr viel über Talks und Vorträge und Dokumentationen und so, das bringt mich mal auf eine Frage. Was für ein Lerntyp bist du eigentlich? Bist du eher so der Mensch, der sehr viel liest oder der Mensch, der eigentlich so Videotutorials macht, so Udemy-Kram oder so? Oder bist du eher so der Frontalmensch, dass du dann da vorne irgendwie, so wie in der Schulklasse, dass dann Lehrer sein muss und du machst das dann nach, oder bist du eher so der Typ, der sagt, ne, ich muss mein reales Problem lösen und dann, ich bin der Hands-On-Typ, der Proof-of-Concept-Typ.

Wolfi Gassler (00:52:50 - 00:53:51)

Also ich bin definitiv kein Lesetyp. Ich bevorzuge auf jeden Fall visuellen Input und da vor allem von einer realen Person als Präsentation oder vielleicht im Team. Da kann ich sicher am besten lernen. Aber wenn ich jetzt nur lange Texte lesen muss oder Tutorials oder auch sogar Video-Tutorials, die gehen zwar ein bisschen besser, aber sind auch nicht meine präferierte Art. dann tue ich mir da eigentlich eher hart und im Team hands-on, vielleicht mit Präsentation, möglichst interaktiv. Das ist eigentlich die Form, die ich persönlich bevorzuge. Aber es gibt natürlich auch Leute, die lesen sich am liebsten irgendeine gute Dokumentation durch von A bis Z. habe ich noch nie verstanden, aber ich kenne natürlich auch viele solche Leute und dementsprechend ist es auch halt wichtig, dass man verschiedene unterschiedliche Formate anbietet in der Firma, dass es eben schriftliche Dokumentation gibt, dass es vielleicht Videotutorials gibt, dass viele Sachen aufgezeichnet werden, Talks, dass man die nachschauen kann als Video oder dass man eben auch im Team in irgendeiner Form sich hands-on weiterbildet.

Andy Grunwald (00:53:52 - 00:54:02)

Aber sagst du jetzt gerade dass man ein thema in allen versionen zur verfügung stellen muss einmal das video einmal als geschriebene form einmal als hands on proof of concept und so weiter.

Wolfi Gassler (00:54:02 - 00:55:36)

Das wäre natürlich die die ideale welt aber in der realität schaut es natürlich anders aus wobei ich finde schon, Geschriebene Dokumentation ist einfach langlebig. Die muss fast sein. Und wenn es dann vielleicht einmal bei irgendeiner internen Konferenz oder einem internen Meetup, einem Lunch Talk eine Präsentation gibt, wäre es halt auch cool, die aufzuzeichnen. Dann hat man auch ein Video zu diesem Thema. Videos veralten normal schneller, kann man nicht updaten. Aber dann hat man zumindest zu einem Themenkomplex mehrere Formen schon, indem man eine gute schriftliche Dokumentation hat, man hat ein Video und wenn man dann die Person fragt oder vielleicht auch teilnimmt an so einer Präsentation, hat man eben den menschlichen Kontakt auch noch. Also es ist schon möglich, sowas zu machen, aber es ist natürlich auch wesentlich mehr Aufwand. Aber heutzutage mit dem ganzen Remote-Setup ist es natürlich auch einfacher, Videos aufzunehmen. Das wird normal supported. Wenn man da eine gute Plattform hat innerhalb der Firma, da gibt es mittlerweile auch viele Lösungen, dass man so eine interne YouTube-Plattform in der Art hat, wo alle Videos sind, wo man auch gut drin suchen kann. Also damit man auch wieder so einen zentralen Punkt hat, wo man alle Informationen findet, nicht nur als Text, aber eben auch als Video. Und so kann man eben auch gewisse Dinge dann nachschauen. Vorspulen hat natürlich auch die Vorzüge. Man kann es schneller ablaufen lassen. Also ich schaue meine Videos üblicherweise auch so Vorträge auf 1,5 oder 1,75 Speed. Und wenn es was Tieferes geht, kann ich wieder runterschalten, langsamer. Es hat alles Vor- und Nachteile, darum ist es natürlich auch gut, wenn man da unterschiedliche Leute hat, die in unterschiedlichen Formaten die ganze Sache an die anderen Leute in der Firma weitergeben.

Andy Grunwald (00:55:36 - 00:56:16)

Den selben Content in unterschiedlichen Formaten finde ich ein bisschen overkill, muss ich zugeben. Ich denke, es ist einfach nur wichtig, dass man sich selbst mal damit auseinandersetzt, was für ein Lerntyp man eigentlich ist und was man eigentlich braucht. oder wo man am besten wirklich lernen kann. Ich habe zum Beispiel mal Video Tutorials of Udemy ausprobiert und ich habe mich mal wirklich durchgezogen. Ich habe mal 40 Stunden Videos geguckt über ein paar Wochen. Ich glaube, wie ich eine Flutter App programmiere. Hat auch super Spaß gemacht, aber irgendwann hast du halt das Konzept raus und dann habe ich das Gefühl gehabt, ich habe mich schneller als der Trainer bewegt. Und da habe ich gemerkt, ist ein interessantes Format, ist aber nicht für mich. Ich bin eher so der Hands-on-Proof-of-Concept-Typ, der sich ein Problem schnappt und dann schaut, wie man das löst.

Wolfi Gassler (00:56:16 - 00:57:13)

Aber ich glaube, du brauchst immer geschriebene Dokumentation dazu. Also das ist eigentlich, du kannst ja nicht irgendwas ausprobieren, ohne irgendwo den Input zu bekommen. Also du brauchst eine Abi-Dokumentation, du brauchst eine gute schriftliche Dokumentation. Ich glaube, das ist die Grundlage und alles, was darüber kommt, ist gut. Es muss ja auch nicht dasselbe Content sein. Du hast eine starke schriftliche Dokumentation und dann gibt es halt zu einem Aspekt oder ein Einführungsvideo zu diesem Themenbereich, zu dieser API, zu diesem Produkt, was das Team anbietet zum Beispiel. Also sowas ist ja immer möglich. Du musst ja nicht wirklich jeden Content-Teil auch wirklich in allen Formaten anbieten. Ich glaube, in einer großen Firma, in einer diversen Firma ist schon gut, wenn du das in möglichst vielen Formaten auch anbietest. Podcast wird sich zum Beispiel auch super anbieten. Interne Firmen, interne Podcasts sind ja mittlerweile auch sehr weit verbreitet und größere Firmen machen das eigentlich auch zur Information und hat, glaube ich, so die alte Mitarbeiterzeitung, die es dazu gegeben hat, früher oder den Newsletter schon langsam abgelöst.

Andy Grunwald (00:57:14 - 00:57:25)

Jetzt reden wir hier über Knowledge Sharing, Lernen. Denkst du, man kann zu viel lernen? Denkst du, man kann überlernen, also im beruflichen Kontext jetzt? Denkst du, irgendwann ist mal genug?

Wolfi Gassler (00:57:26 - 00:58:54)

Ich glaube, man kann nie zu viel lernen, aber man kann natürlich zu viel Zeit investieren und das wird halt dann auch irgendwann der Arbeitgeber vielleicht bekritteln. Also man muss sich halt einfach überlegen, wie du auch schon erwähnt hast, was lernt man, zu welcher Konferenz geht man, dass das halt möglichst nahe an dem ist, was man dann auch irgendwie nutzen kann. Natürlich sind es vielleicht auch Perks, dass dich Leute irgendwo hinschicken und wenn es heutzutage Massagen oder so gibt in Firmen. Dann zählt es ja auch als Arbeitszeit und hat jetzt wenig mit deiner Arbeit zu tun, aber wenn es dir halt im Gesamten besser geht, dann hilft es der Firma auch und wenn für dich ein wichtiges Thema ist, was vielleicht auch in der Zukunft einmal wichtig werden könnte für die Firma, obwohl du jetzt vielleicht nicht konkret an diesem Bereich arbeitest, kann es ja auch ein gutes Investment sein für die Firma. Also man muss sich überlegen, wie viel Zeit investiert man und vielleicht muss man da auch mittlerweile dann priorisieren, was ist wichtiger. was will man wirklich lernen und wo hat man mehr davon am Ende, wenn man das lernt. Wobei ich ganz allgemein kein großer Fan bin von dieser Strukturierung. Ich finde es auch schade, dass jetzt bei den Universitäten immer mehr auf diesen Lehrplan gegangen wird. Auf den normalen Universitäten hattest du ja viele Freifächer und konntest da auch aus ganz anderen Bereichen Sachen lernen. Das wird immer weniger, das wird immer weiter runtergekürzt, diese Dinge. Ich finde es schade, weil auch ein breites Wissen kann sehr gut in Firmen helfen, auch wenn es gar nichts direkt damit zu tun hat, mit dem eigentlichen Arbeiten.

Andy Grunwald (00:58:54 - 00:59:43)

Denkst du es ist schwieriger geworden mit dem Wechsel der Arbeitsumgebung, wie es vor Corona war, sehr office getrieben und jetzt während Corona, beziehungsweise sind wir schon nach Corona, weiß ich jetzt auch nicht, aber sehr remote getrieben. Denkst du, die ganzen Themen hier, die wir heute angesprochen haben, wie man Knowledge Shared, Gilden, Lunch Talks, interne Konferenzen, Pair-Mob-Programming, geschriebene Dokumentation und auch die Herausforderungen, die wir angesprochen haben, den mythos was jeder im team alles wissen muss und übernehmen kann imposter syndrome das ist immer schwierig es leute zu finden die vorträge halten oder auch herauszufinden wie viel man lernen sollte oder darf beziehungsweise was für ein lerntyp man ist denkst du dass die arbeitsumgebung von zu hause oder im büro das jetzt schwieriger oder einfacher macht, Ich.

Wolfi Gassler (00:59:43 - 01:00:59)

Glaube, im Allgemeinen ist es einfacher geworden, weil durch das Remote-Arbeiten die Dokumentation viel besser werden muss. Weil wenn ich im Office gemeinsam arbeite, kann ich halt schnell einfach jemanden mal fragen. Das ist Remote wesentlich schwieriger und ich glaube, die meisten Firmen haben schon mal erkannt, dass die Dokumentation wichtiger wird, dass auch Dinge zum Beispiel mehr aufgenommen werden. Früher war das einfach viel schwieriger. Man hat ein komplettes Video-Setup benötigt, um in irgendeinem Raum irgendwas aufzunehmen. Heutzutage, wenn alles remote passiert, drückst du einfach auf den Knopf, kannst es aufnehmen. Es kann ein Teammitglied, was zum Beispiel krank war, schnell nachschauen. Alle solche Dinge vereinfachen eigentlich das Knowledge Sharing. Nichtsdestotrotz brauchst du trotzdem den Treiber hinter dieser ganzen Sache. Du brauchst eine gute Plattform. Du brauchst eine gute Suche. Du musst die Daten irgendwo an den Mann und die Frau bringen überhaupt. Also das bleibt alles gleich. Vielleicht sogar noch schwieriger, weil du jetzt viel mehr Material hast als früher. Aber du hast natürlich auch mehr Chancen. Also ich würde sagen, im Allgemeinen wird es leichter, weil du einfach mehr Material hast, aber die ganzen Challenges bleiben eigentlich gleich, um das wirklich weiter zu verteilen, um die Zeit zu blocken, um die Zeit zu investieren, das Problem mit dem C-Level und so weiter. Also die ganzen Dinge bleiben eigentlich bestehen, meiner Meinung nach zumindest. Wie siehst du das Ganze? Einfacher oder schwieriger?

Andy Grunwald (01:01:00 - 01:01:28)

Ich bin mir gar nicht sicher, ob man das so kategorisieren kann. Ich glaube, das eine ist in dem aktuellen Setup einfacher. Ich glaube, manche Themen sind schwieriger. Das, was mich so ein bisschen stört im Remote Setup, ist eigentlich, dass man den Szenenwechsel für den Kopf halt nicht mehr so hat, dass man immer alles nur von dem Screen macht. Ohne Screen geht es halt nicht. Und im Büro hat man halt mal ein reales whiteboard mal was haptisches da das strengt nicht die augen an entlastet vielleicht auch ein bisschen den kopf weil der kopf dann halt ja eine andere umgebung hat ich glaube das ist so.

Wolfi Gassler (01:01:28 - 01:02:29)

Die reale herausforderung, Das könnte zur neuen Volkskrankheit werden, da hast du vollkommen recht, weil du stehst meistens nicht mal mehr auf und dann hast du noch das Essen während dem Lunch Talk, was du in dich reinschaufelst, sitzt wieder am Bildschirm. Also das kann durchaus ein Problem sein, definitiv. Also ich glaube auch, dass dieses Hybrid-Setup vielleicht die bevorzugte Variante ist, zumindest für mich wäre es die und dass da schon viele Firmen auch möglichst viele Nicht-Display-Events, wenn man es mal so nennen will, machen müssen oder werden in Zukunft, um das einfach zu verbessern, diese ganze Situation. Aber lasst uns mal wissen, was ihr so macht, welche Formen ihr habt, ob wir irgendwas vergessen haben an Sharing-Formen. Vor allem lasst uns wissen, was bei euch vielleicht ganz gut funktioniert oder was auch sehr schlecht funktioniert hat. Würde uns natürlich freuen, wie immer da mehr Input zu bekommen. Was in anderen Firmen so gemacht wird und am besten auf Twitter, Engineering Kiosk oder auch bei E-Mail direkt an uns unter stetisch.engineeringkiosk.de Das war es von uns.

Andy Grunwald (01:02:29 - 01:02:45)

Zum Thema Knowledge Sharing. Und was wir natürlich jetzt von euch erwarten ist eigentlich, dass ihr zu eurem Team geht und eine Sache der hier vorgestellten Methoden einfach mal nehmt und einfach mal durchzieht und einfach schaut darauf mal, was da rumkommt, ob das positiv angenommen wird.

Wolfi Gassler (01:02:45 - 01:02:47)

Und lasst uns dann wissen, wie es funktioniert hat.

Andy Grunwald (01:02:47 - 01:02:49)

Ansonsten würden wir sagen, Bis bald. Ciao.