Wie entwickle ich meine Teammitglieder eigentlich weiter?
“Wer nicht mit der Zeit geht, geht mit der Zeit”. Ob dieses Zitat nun von Schiller oder Stromberg kommt, spielt eigentlich keine Rolle. Einen Funken Wahrheit hat es trotzdem. Denn speziell in der sich schnell entwickelnden IT- und Software-Welt ist das Thema Leveling Up / Lifting Up / Skilling Up oder die ganz klassische Weiterbildung unabdingbar. Und dabei geht es nicht nur um das besser werden im eigentlichen Handwerk, wie der Softwareentwicklung, Data Science oder ähnlichem, sondern auch um die Persönlichkeit und Soft-Skills wie z.B. Kommunikation - Obwohl die Softskills heutzutage auch irgendwie die wahren Hardskills sind. Egal.
Nun aber die große Frage: Wie hebe ich denn mein Team auf das nächste Level? Wie kann ich meine Mitarbeiter unterstützen, sich aktiv weiterzuentwickeln? Was kann ich als direkter Kollege tun? Denn dieses Thema betrifft nicht nur Leads, sondern auch dich als Individual Contributor ohne Personalverantwortung. Denn spätestens, wenn sich deine Managerin (noch) nicht um deine Weiterentwicklung kümmert, geben wir dir in dieser Episode ein paar Tipps, wie du auch deine Managerin in die richtige Richtung bewegen kannst. Denkt immer dran: “Wer nicht mit der Zeit geht, geht mit der Zeit”.
Bonus: Etwas Streit ist gesund.
Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Das schnelle Feedback zur Episode:
Feedback
- EngKiosk Community: https://engineeringkiosk.dev/join-discord
- Buy us a coffee: https://engineeringkiosk.dev/kaffee
- Email: stehtisch@engineeringkiosk.dev
- LinkedIn: https://www.linkedin.com/company/engineering-kiosk/
- Mastodon: https://podcasts.social/@engkiosk
- Bluesky: https://bsky.app/profile/engineeringkiosk.bsky.social
- Twitter: https://twitter.com/EngKiosk
Links
- Engineering Kiosk Leadership Episoden: https://engineeringkiosk.dev/tag/leadership/
- Engineering Kiosk #95 Effiziente Knowledge Sharing Formate: Wissen teilen und begeistern: https://engineeringkiosk.dev/podcast/episode/95-effiziente-knowledge-sharing-formate-wissen-teilen-und-begeistern/
- Engineering Kiosk Episode #10 Das Karriere Booster Meeting 1:1s: https://engineeringkiosk.dev/podcast/episode/10-das-karriere-booster-meeting-11s/
Sprungmarken
Hosts
- Wolfgang Gassler (https://mastodon.social/@woolf)
- Andy Grunwald (https://andygrunwald.com/)
Feedback
- EngKiosk Community: https://engineeringkiosk.dev/join-discord
- Buy us a coffee: https://engineeringkiosk.dev/kaffee
- Email: stehtisch@engineeringkiosk.dev
- LinkedIn: https://www.linkedin.com/company/engineering-kiosk/
- Mastodon: https://podcasts.social/@engkiosk
- Bluesky: https://bsky.app/profile/engineeringkiosk.bsky.social
- Twitter: https://twitter.com/EngKiosk
Transkript
Andy Grunwald (00:00:00 - 00:00:20) 
Episode 168. Herzlich willkommen. Dieses Mal geht es um dich, um das Thema Leveling up, Lifting up, Skilling up. Und dieses Thema hat der Wolfgang mir mitgebracht bzw. Gepitcht. Und jetzt Wolfgang, möchte ich von dir wissen, warum hast du dieses Thema mitgebracht? Warum sprechen wir genau darüber heute?
Wolfi Gassler (00:00:20 - 00:01:18)
Danke für diesen Start, da kann ich die Übersteuerung gleich in meinem Editing Programm mitdenken und die ganze Lautstärke Anpassung Ÿousand. Danke mal dafür, Andi. Aber um mal positiv zu bleiben, warum dieses Thema eigentlich so relevant ist, ist mir eigentlich gerade kürzlich wieder gekommen, weil ich mit einem alten Freund zusammen gesessen bin, den ich schon lange nicht mehr gesehen habe. Und er hat gemeint, er hatte jetzt unseren Podcast angefangen zu hören und gerade die Management Episoden gefallen ihm so gut, weil er hat gerade ein Team übernommen, ein kleines Team und hat one hundred eins eingeführt und er hört jetzt diese ganzen Management Episoden und fragt sich eigentlich, ob man da nicht noch mehr machen kann oder was da wichtig ist. Und ich glaube einen Punkt, der für die ganzen Seniors Tech Leads und Engineering Manager extrem wichtig ist und den wir noch nie so im Detail behandelt haben, ist eigentlich leveling Up und Lifting up, weil es einfach zum Job dazugehört, wenn man Senioriker wird und bisschen weiter von der Technik abdriftet, eben in Richtung Leadership.
Andy Grunwald (00:01:18 - 00:01:24)
Hol mich mal ab, was heißt leveling up, was heißt lifting ab? Ich bezweifle, dass wir über das Aufzugfahren sprechen.
Wolfi Gassler (00:01:24 - 00:02:42)
Ich habe in der Vorbereitung lange gesucht, ob es einen Unterschied zwischen den zwei Begriffen gibt, leveling up und lifting up, weil man liest die oft und gefühlt hätte gesagt, es gibt einen Unterschied, aber ich habe dann lange gesucht und habe eigentlich keinen Unterschied gefunden, weil diverse Quellen eigentlich, wenn man zu dem Begriff liest, immer dasselbe erwähnen. Also das kontinuierliches Lernen, wie man Leute weiterentwickelt, wie man ihnen hilft weiterzuentwickeln, was für Tools da gibt, z.b. delegieren eben oder die ganze Knowledge Sharing Geschichte. Da haben wir schon eine eigene Episode dazu gemacht. Also wie schafft man es, den Leuten eine Umgebung zu geben, wo sie sich selber gut weiterentwickeln können, so wie sie das gerne hätten und eben nicht die Firma verlassen, weil das ist ja auch so ein großes Problem, gerade jetzt in der Weihnachtszeit. Alle fangen so an zu überlegen, wie geht es mir in der Firma? Kann ich mich dort weiterentwickeln? Und ganz oft ist es ja einer der Hauptpunkte. Mein Manager steht mir im Weg, mein Manager hilft mir nicht weiter, mein Manager ermöglicht mir nicht, dieses Umfeld zu haben, dass ich mich weiterentwickeln kann. Zweitausendein und dann verlassen Leute ganz gerne die Firma, weil es heißt immer so schö man verlasst nicht die Firma, sondern den Manager. Und das trifft leider ganz oft zu. Und diese Episode soll eigentlich dagegen wirken, dass Leute eben dieses Umfeld vorfinden und einen Spaß haben und sich weiterentwickeln können.
Andy Grunwald (00:02:42 - 00:02:56)
Es geht also in dieser Episode darum, was ein Senior, ein Tech Lead und ein Engineering Manager und oder tun kann, um seine bzw. Ihre Leute weiterzuentwickeln, zu fördern und Co. Ist das korrekt?
Wolfi Gassler (00:02:56 - 00:03:24)
Bzw. Alle anderen Personen, die in dem Team dafür verantwortlich sind oder da mitwirken können. Also es muss gar nicht der Tech Lead sein oder eine Engineering Managerin. Es können natürlich einfach auch Leute sein, die bisschen mehr Erfahrung haben, schon länger in der Firma sind und im Team einfach diese Atmosphäre schaffen und dieses Setting schaffen und sich gegenseitig dabei unterstützen, weiterzukommen, zu wachsen, wenn man den englischen Term mit reinbringen will. Aber sich weiterentwickeln, ja, was heißt denn weiterentwickeln?
Andy Grunwald (00:03:24 - 00:03:38)
Heißt das jetzt, ich werde eine bessere Programmiererin? Heißt das jetzt, ich geht es auf die Persönlichkeitsentwicklung? Heißt das, ich muss in Zukunft mehr Arbeit machen? Also von welcher Entwicklung reden wir hier? Hard skills, soft skills, hard soft skills?
Wolfi Gassler (00:03:38 - 00:04:19)
Im Prinzip geht es um diese ganzen Dinge. Also alle, die du jetzt erwähnt hast, sei es Soft skills, sei es Hard Skills. Das heißt, dass man in dem Level steigt, wenn man eine Karriereleiter, eine ganz klassische, hat und zum Staff level engineer will. Also egal, auf was für einer Ebene sich das abspielt, es geht genau um diese Dinge, die du jetzt erwähnt hast. Und das ist eigentlich die große Aufgabe, wo die Seniors und Engineering Managerinnen sich Gedanken machen müssen, was ist die aktuelle Situation? Was finde ich vor in meinem Team und wohin soll es überhaupt gehen? Ist es eben wichtig, Hard Skills zu verbessern? Ist es wichtig, Soft skills zu verbessern? In welche Richtung muss ich gehen? Was brauche ich? Was braucht die Firma? Was brauchen die Leute? Und wie kann ich dann sicherstellen, dass das stattfindet?
Andy Grunwald (00:04:19 - 00:04:36)
Aber ist da nicht die Personalabteilung für zuständig? Ich meine, soviel ich weiß, in ziemlich vielen Firmen setzt die Personalabteilung ein learning Budget fest, womit Leute sich dann frei bedienen können. 1000 €2000 im Jahr, davon können die sich ein Buch bestellen, einen Udemy Kurs kaufen oder halt oder irgendeine Schulung buchen oder eine Konferenz. Reicht das nicht?
Wolfi Gassler (00:04:36 - 00:05:35)
Jetzt bin ich mal ketzerisch, auch gegenüber allen unseren Werbekunden, weil das ist ja so klassisch, was wir auch bewerben, wenn es um Werbekunden geht. Die haben ein Learning Budget, die entwickeln sich weiter und man hat da irgendwo eine Checkliste, Learning Budget, Check, that's it. Aber wenn man in die Tiefe reingeht, in einen ganz speziellen Fall und jemand präsentiert was in einem kleinen Meeting, dann ist da keine HR Abteilung, die dieser Person sagt, hey, diese Präsentation war cool, hey, du hast da irgendwie ein Problem, du stammelst bei dem Punkt immer rum oder du hast irgendein Problem mit deinen oder du stockst oder es war einfach alles perfekt. Also da ist keine HR Abteilung drin in diesem Meeting. Das können nur die Kollegen und Kolleginnen machen oder die Team Managerinnen. Und genau darum geht es. Diese kleinen Hilfestellungen, Feedback, diese ganzen Dinge, die eigentlich Leute wirklich weiterentwickeln und nicht dieses ganz klassische, ich würde es fast unter diesen term Obst setzen. Ich habe auch ein Learning Budget, Obst, Cop und Learning Budget und damit ist alles gut und meine Leute können sich weiterentwickeln.
Andy Grunwald (00:06:35 - 00:07:19)
Ich finde das wundervoll, dass du gesagt hast, ich antworte mal mit einer ketzerischen Antwort. Und meine Frage war natürlich super ernst gemeint. Grandios, grandios. Aber wo ich jetzt wirklich mal eine ernst gemeinte Frage habe, zählt das nicht alles irgendwie ins Performance Management rein? Also ich meine, ich bin angestellt, ich bekomme Gehalt jeden Monat und das bekomme ich im Austausch von Zeit und Outcome. Zeit und Skills gebe ich zur Verfügung und bekomme dafür Geld. Natürlich werde ich auch anhand meiner Performance gemessen. So was tue ich denn? Wie halte ich mich? Wie ist mein Behavior? Wie ist mein Verhalten anderen gegenüber? Und wenn ich jetzt mal einen bekannten deutschen Dichter zitiere, nämlich Friedrich Schiller, das.
Wolfi Gassler (00:07:19 - 00:07:23)
Ist schön, wenn du anfängst, Dichter zu zitieren. Jetzt bin ich gespannt.
Andy Grunwald (00:07:23 - 00:07:46)
Wenn ich mit der Zeit geht, geht mit der Zeit, dann stelle ich mir halt da schon die Frage, dass wenn ich einfach stehen bleibe, dann gehe ich ja automatisch mit der Zeit. Also gehen, verlassen, weggehen, weil die IT entwickelt sich ja schneller denn je. Und deswegen meine Frage, warum muss man sich wirklich aktiv darum kümmern, wenn es doch ein Teil von Performance Management und Co. Ist?
Wolfi Gassler (00:07:46 - 00:08:41)
Die Frage ist, ob es ein Teil überhaupt ist. Und ich glaube, bei ganz vielen Firmen ist es kein ausgewiesener Teil. Natürlich gibt es Firmen, die haben das in den Values drin, dass man sich weiterentwickelt, dass man lernt, lebenslanges Lernen und so weiter. Aber ich glaube, es gibt auch ganz klassische Firmen, da gibt es keine Definitionen. Und bei manchen ist es drin und bei manchen nicht. Und ich glaube, du kannst, und das ist ein Riesenproblem, du kannst viele Jahrzehnte, würde ich fast sagen, ohne eine Weiterentwicklung gut durchkommen. Und es kann sein, dass es dich dann irgendwann frisst nach dreiig Jahren, weil du kommst vielleicht 20, dreiig Jahre gut durch, machst immer dasselbe. Aber ich vermute, dass es irgendwann, also du bist dann schon immer im Rentenalter, dann hattest du Glück, aber sonst frisst dich irgendwann. Aber ich glaube, du kannst ganz lange durchtauchen in vielen Unternehmen, weil eben niemand darauf schaut und niemand dir sagt, dass das wichtig ist und vielleicht es nicht im standardisierten Performance Management oder Review drin ist.
Andy Grunwald (00:08:41 - 00:08:49)
Würde ich nicht so generell mitgehen. Ich denke, das kommt ganz stark auf die Firma an. Bei einem Großkonzern, nehmen wir mal die deutsche Bahn, ich glaube, da hast du.
Wolfi Gassler (00:08:49 - 00:09:59)
Recht, denn ich würde nicht einmal Großkonzerne sagen, ich kenne ja auch viele Unternehmen und das passiert auch gerade in kleinen, weil das ist ja auch so, dass du sehr wertvolle Arbeit leisten kannst, ohne dich weiter zu entwickeln. Weil es gibt halt Bereiche, die ändern sich nicht so schnell und da ist dein Wissen sehr hilfreich und bewegt auch sehr viel. Also das ist ja der Klassiker, wenn man so sagt bei Startups, auch die Leute, die am Anfang das Startup aufgebaut haben, mit ihrem schnellen Reagieren, schnell was hacken, schnell was rausbringen, das ist super für die startup Phase. Aber 10 Jahre später, wenn du dann eine große Firma hast, die sich etabliert hat und du dich eben nicht weiterentwickelt hast in diese Richtung, dass du auch in der großen Codebase, wo 200 Leute gemeinsam an dem Code arbeiten, dass du da dann ganz andere Dinge an den Tag legen musst, ganz anders reagieren musst, ganz anders zusammenarbeiten musst und nicht mehr schnell hacken kannst, dann hast du wahrscheinlich ein Problem. Aber du hast wahrscheinlich dann 1015 Jahre, du hast ja auch eine Reputation aufgebaut, in einem Startup kannst du gut überleben. Also das muss kein großer Konzern sein, meiner Meinung nach. Es ist immer die Frage, wie du richtig sagst, wie die Firma aufgestellt ist und wie die das in ihrer Struktur und in den Performance Management Zielen eigentlich drin hat.
Andy Grunwald (00:09:59 - 00:10:43)
Okay, vielleicht ist es nicht die Größe der Firma, sondern das Umfeld. Denn umso stabiler die Firma, desto weniger muss man sich glaube ich an neue Gegebenheiten, vielleicht die auch von außerhalb kommen, anpassen. Denn wenn du jetzt ein kleines Startup hast, was jetzt gerade irgendwie neuen Markt durchbrechen möchte, da geht es halt wirklich darum, schnell dynamisch zu sein, auf neue Aktionen, Events, die von außen kommen, zu reagieren. Und da muss man ja, ich sag mal, ja, vielleicht hat er wirklich schiller recht, wenn ich mit der Zeit geht, geht mit der Zeit und das gilt dann für die ganze Firma. Aber da muss man sich ja unglaublich schnell anpassen und da muss man sich ja unglaublich schnell auf neue Situationen einrichten und da wächst man ja dann automatisch, weil man ja konstant irgendwie über den Tellerrand geschubst wird. Ich glaube, da ist das so ein bisschen ein bisschen gegeben, oder?
Wolfi Gassler (00:10:44 - 00:11:39)
Genau. Und darum auch wieder zurückzukommen, was ihr am Anfang gesagt habt, du musst mal den Status quo erheben in deiner Firma. Was zweitausendein hast du da eigentlich für eine Firma? Was ist überhaupt gefordert? Was ist gefragt? Ist Weiterentwicklung überhaupt so ein Thema? Wohin können sich denn die Mitarbeiterinnen überhaupt weiterentwickeln? Gibt es da ein learning Budget? Gibt es kein learning Budget? Wo muss ich ansetzen? Wie kann ich die Firma weiterbringen? Bei uns in der IT ist wahrscheinlich, wie du richtig sagst, weil sie sehr schnelllebig ist, schon wichtig, dass man sich weiterentwickelt und neue Sachen lernt. Ich vermute, am Fließband muss man vielleicht weniger neue Dinge lernen, beziehungsweise heißt es halt noch ganz anders geregelt, aber in der klassischen IT, wo jeden Tag irgendwie ein neues KI Modell um die Ecke kommt und irgendwelche neuen Tools und Programmiersprachen und jetzt muss man Rust lernen oder F Sharp, dann muss man wahrscheinlich einfach akzeptieren, dass man in der IT und in der Softwareentwicklung mehr Zeit reservieren muss für diese Weiterentwicklung als in anderen Branchen.
Andy Grunwald (00:11:39 - 00:13:09)
Würde ich dir zustimmen. Gibt aber auch verschiedene Level. Z.B. habe ich mal in einer Firma gearbeitet, da hatte jeder Mitarbeiter ein sogenanntes learning budget, sagen wir einfach mal 1000 oder 2000 Ÿousand Euro. Und immer wenn man eine Idee hatte, konnte man seine Vorgesetzte sein Vorgesetzten fragen, kann ich das dafür nutzen? Und da wurde ja oder nein gemacht. Daumen hoch oder Daumen runter. Ich habe aber auch schon mal in der Firma gearbeitet, da ging es darum, dass jeder Mitarbeiter am Anfang des Jahres oder des finanziellen Jahres, ja, Kalenderjahr oder finanzielles Jahr ist ja oft nicht das gleiche, dass jeder Mitarbeiter und jede Mitarbeiterin einen sogenannten PDP hat, ein Personal Development Plan. So, den setzt man am Anfang fest. Und wenn du etwas vom Learning Budget haben wolltest, was es da auch gab, auch wieder 1000 oder €2000, dann musste das mit einem Ziel aus deinem PDP, aus seinem Personal Development Plan übereinstimmen, weil sonst sagt die Firma Okay, wir nehmen Wachstum ernst und das muss ja auch alles strukturiert sein. Und dieser PDP war natürlich dann auch an den Organisationszielen irgendwie ausgerichtet. Also Wachstum Growing ist also Teil des Performance Managements. Und warum sage ich diese zwei unterschiedlichen Firmen bzw. Warum beschreibe ich diese zwei Szenarien? Weil das recht gut verdeutlicht, wie ernst oder ich sag mal loose auf Englisch, also lose salopp, man die ganze Thematik auch nehmen kann. So nach dem Motto. Du hast gerade gesagt, Learning Budget ist eine Checkbox, würde ich bei Firma eins so sagen, man kann das machen und bei dem anderen ich will nicht sagen, man wird gezwungen, aber man wird so ein bisschen aus der Komfortzone getrieben und sagen okay, wir nehmen das Thema denn jetzt mal wirklich ein bisschen ernst.
Wolfi Gassler (00:13:09 - 00:13:27)
Ÿousand ja, vor allem ist ja auch die Frage und das kennst du ja wahrscheinlich nur zu gut, wenn du ein learning Budget hast, wie viele Leute in deinen Teams haben dieses Learning Budget immer aufgebraucht? Und wie viele Leute sind zu dir gekommen und haben gesagt, mein Learning Budget ist aus, kann ich bitte noch zu der anderen Konferenz gehen? Also wie viele Leute waren das von 10 Leuten bei dir?
Andy Grunwald (00:13:28 - 00:14:12)
Ja, sehr gute Frage. Die Antwort ist relativ simpel. Wenn ich als Teamleiter oder als Engineering Manager in meiner Rolle nicht aktiv vorgeschlagen habe, so langsam mal nach Quartal eins, nach Quartal zwei, hey, möchtest du da nicht ich mal gucken, was hältst du davon oder davon, wenn ich da oft nicht aktive Vorschläge gemacht habe, dann ist das meist verfallen oder wird das einfach gar nicht genutzt. Seltenst kam jemand zu mir ich habe nur noch €500 von meinem Learning Budget über, aber das, was ich noch investieren möchte, kostet 600. Können wir mal in der Regel kein Problem. Aber das ist halt nie, ich glaube einmal passiert in meinen letzten 12 Jahren. Aber das bringt mich zu der nächsten Frage. Wer ist denn dafür zuständig? Du selbst, der, der wachsen möchte? Zweitausendein oder deine Reporting Line oder die Reporting Line von der Reporting Line.
Wolfi Gassler (00:14:12 - 00:15:10)
Also ich glaube, grundsätzlich sind alle dafür verantwortlich und es müssen auch alle irgendwie gewillt sein mitzuwirken. Also sei es jetzt die oberste Ebene, die das Learning Budget freigibt, die Management Ebene, die das in irgendeiner Form kommuniziert und die Leute pusht und natürlich die Leute selber, die das auch annehmen oder vielleicht im besten Fall von sich aus einfach vorschlagen würde gern dorthin, würde gerne ein Buch kaufen, zu einer Konferenz gehen, einen Onlinekurs machen, einen internen Hackathon organisieren, was es dann auch immer ist. Also ich glaube, es sind alle eingebunden, aber wir haben uns ja im Vorfeld schon geeinigt, wir werden in diesem Podcast uns eher damit beschäftigen, wie man möglichst andere Leute in irgendeiner Form unterstützen kann bei ihrer Weiterentwicklung. Also ganz klassisch die Engineering Manager natürlich, aber auch ganzen Staff Engineers oder auch einfach seniorigere Mitarbeiterinnen oder im Team Leute, die das gerne machen, die einfach schon weiter sind als andere. Okay, weil sonst bekommen wir das vermutlich nicht in einer Episode unter.
Andy Grunwald (00:15:10 - 00:16:08)
Das würde ich nicht so nennen, denn der andere Punkt ist relativ einfach zusammengefasst. Du möchtest wachsen, du möchtest dich weiterbilden, du möchtest dich weiterentwickeln und der einzige Mensch, der dafür die Verantwortung tragen kann, bist du selbst. Du bist dir gegenüber Rechenschaft schuldig, ob du dich weiterentwickelst oder nicht. Und du hast dein Leben selbst in die Hand. Und das ist das Too long didn't read für die andere Seite, von der du sagst, wir kriegen das nicht mehr im Podcast unter. So haben wir jetzt den Podcast untergebracht und jetzt kommen wir wieder auf die andere Seite, dass der Engineering Manager oder Direct Report oder Tech Lead oder Senior für das Environment verantwortlich ist. Und deswegen kommen wir zur ersten Frage, denn bevor man irgendwelche Maßnahmen vorschlägt, macht man auch im Projektmanagement eine sogenannte Requirements Analyse. Man schaut sich erstmal an, was habe ich denn da? Wie viel Legacy liegt denn zu meinen Füßen? Wie gehe ich denn da vor, wenn ich meine Status quo Erhebung mache? Ich habe jetzt fünf Direct Reports und ich weiß nicht, wo ich anfangen soll. Was mache ich?
Wolfi Gassler (00:16:08 - 00:18:03)
Die Antwort auf fast alles, wenn es ums Engineering Management geht, sind eigentlich one on ones, würde ich fast sagen. Die Frage ist dann natürlich, was macht man in den one on ones? Aber grundsätzlich bei einer Bedarfsanalyse oder Status quo Erhebung geht es natürlich immer darum Ÿousand, was habe ich aktuell in meinem Team zur Verfügung? Das heißt, was für Skills habe ich zur Verfügung? Welche Leute habe ich zur Verfügung? Welche Projekte muss ich erledigen? Welche Technologien? Also wo stehe ich im Prinzip aktuell in meinem Team? Und das kann man sehr gut über One on ones natürlich abbilden, dass man einfach mal die Leute fragt, eine Eigeneinschätzung einholt. Es kann eine ganz simple Matrix sein, wo ich irgendwelche Technologien aufzähle, plus meine Soft skills, die mir wichtig sind, Kommunikationsskills z.B. oder im Idealfall, wenn ich eine offizielle Karriereleiter habe, kann ich da vielleicht sogar Punkte mit rausnehmen, um eben auf nächste Levels zu kommen. Also was ist bei mir in der Firma wichtig oder values? Und kann dann einfach die Leute fragen okay, trag mal ein in so einer Matrix, wo steht ihr bei Kommunikation? Wo steht ihr bei der Technologie Java? Wo steht ihr bei Technologie Rust und so weiter. Und das gleiche kann ich dann natürlich auf meiner Ebene machen. Das heißt, ich kann eine Selbsteinschätzung machen auf meiner Seite als als Lead. Wo stehen denn meine Leute? Und die kann unter Umständen auch noch die Peers von den Leuten fragen, also eine Fremdeinschätzung einholen von anderen Leuten. Was denkt ihr, wie sind wir aufgestellt im Team? Was fehlt uns? Was brauchen wir noch? Also ich glaube, das ist ganz wichtig, dass man immer alle drei Seiten abdeckt, weil du hast vielleicht den großen Kontext als Lead, was noch gebraucht wird, welche Projekte in Zukunft anstehen, was noch kommt. Aber im Alltag kennen sich die Leute natürlich wesentlich besser aus und wissen, wo der Schuh drückt. Und wenn die sagen hey, wir haben da dieses neue Framework und von unseren fünf Leuten vier haben keine Ahnung von diesem Framework und haben immer noch Probleme, dann kannst du natürlich reagieren und vielleicht in irgendeiner Form was organisieren, dass genau das Framework geschult wird, verbessert wird das Wissen und man dann im Team dementsprechend weiterkommt.
Andy Grunwald (00:18:03 - 00:18:14)
Okay, ich glaube, einer der größten Herausforderungen bei so einer Skill Matrix ist auf der einen Seite okay, was braucht das Team? Das Vielleicht kriegt man die Punkte aus der Job Ad raus, die man letztens noch gemacht hat, weil da steht ja drin, die Qualifikation, die du mitbringen solltest, zweitausendein.
Wolfi Gassler (00:18:14 - 00:18:23)
Aber im Idealfall, dann hast du das eh schon mal gemacht. Wenn du das Job so ideal aufgebaut hast, dann hast du dir schon mal überlegt, was du eigentlich brauchst. Dann hast du wahrscheinlich schon eine Matrix.
Andy Grunwald (00:18:23 - 00:19:15)
Im Vorhinein gebaut, was natürlich schon ein bisschen schwieriger ist. Wo hört man auf? Ja, weil sonst hat man nämlich auf der y Achse, also vertikal die ganzen Teammitglieder und horizontal, also auf der x Achse hat man dann sehr wahrscheinlich irgendwie mal Matrix bis Az, wenn du dir jetzt mal so Excel vorstellst. Da muss man natürlich eingrenzen, denn die Übung soll jetzt natürlich nicht drei Tage dauern zum ausfüllen, sondern und sie wird natürlich nie vollständig sein. Also ich bin mir nicht sicher, ob Public speaking oder Gruppenteam Meetings halten ein Skill ist, der in der Matrix sein sollte. Für Produktmanager ist dieser doch schon mehr relevant als für jeden Softwareentwickler und Softwareentwicklerin. Obwohl das natürlich dann auch eine Art Skill sein kann, die man entwickeln kann, wenn die Person natürlich irgendwie mal deinen Job möchte oder auch mal lieb werden möchte. Aber irgendwo muss man halt, ich sag mal, einen Cut machen, weil sonst hat man halt eine riesen Matrix.
Wolfi Gassler (00:19:15 - 00:21:06)
Es soll natürlich nicht ausarten, das ist klar. Vor allem wenn wenn du da eine Matrix hinlegst, die 50 mal 50 Felder hat, dann wird keiner mehr einen Spaß haben, diese auszufüllen. Also das sollte schon irgendwo in der Größenordnung, wo die mal sagen, von sinnvollerweise sechs, sieben Feldern bzw. Dimensionen sein. Das sollte schon das Maximum eigentlich sein. Und es geht ja auch darum, eigentlich wieder bei so einer Matrix, dass du dir einfach Gedanken drüber machst, also sei es jetzt als Manager in oder als als Teammitglied auch, dass du einfach darüber nachdenkst und dich irgendwo einsortierst, weil das ist ja ganz klassisch wie in One on ones mit mit solchen Fragen, um einfach mal eine Einschätzung zu bekommen, wo man dann in die Tiefe gehen kann. Wenn jetzt jemand eine Selbsteinschätzung gibt, Kommunikation ganz schlecht, dann kann die tiefer gehen. Okay, warum denkst du denn, deine Kommunikation ist so schlecht? Wo siehst du die Möglichkeiten, dich zu verbessern in der Kommunikation? Und das kann dann public speaking sein, das kann Kommunikation im Team sein, das kann sein, dass man sich nicht traut, in irgendeinem Meeting zu sprechen, nach außen zu gehen. Also es können ja da ganz viele Dinge sein, die in Kommunikation reinfallen. Und da kannst du dann in die Tiefe gehen in einem Einzelgespräch. Aber im Großen und Ganzen hilft es dir einfach mal so grob dein Team zu kategorisieren und einfach Gedanken zu machen und die aufzuschreiben. Zweitausendein, dass du da Zahlen vor dir hast. Es gibt auch Leute, die schaffen das ganz ohne eine Matrix und die haben das einfach im Kopf. Und üblicherweise, wenn du one on ones machst, kommen ja diese Problemfelder auch mit der Zeit. Wenn du mit Leuten sprichst, die sagen ja, okay, da sind wir schwach, bei dem Framework sind wir schwach, wir sind schwach bei der Architektur, wir haben da immer Probleme, wir müssen ganz viel refactoren im Nachhinein. Also wenn da konkretere Dinge aufpoppen, dann kannst du die ja mit reinnehmen und vielleicht dann auch Unterkategorien für dich ausdenken. Aber das ist dann die Aufgabe von der Managerin, einfach aus diesen Zahlen, aus diesen Grundinformationen mehr rauszuholen.
Andy Grunwald (00:21:06 - 00:21:42)
Ich glaube, das ist ganz wichtig, dass man sich von den reinen Zahlen nicht blenden lässt, denn eine Schulnote sagt nicht das Warum aus. Und vielleicht kann man natürlich auch, ich sag mal, ein zweistufiges Kategoriesystem nutzen. Das bedeutet, man hat Kategorie eins, Kommunikation und Kategorie zwei. Und die zweite Kategorie sind die Kategorien, die du eigentlich bewertest. Weiß ich nicht, Ÿousand, public speaking, written Communication und so weiter. Das ist, wenn man so Riesenthemen halt ein bisschen mehr aufsplittet. Denn es ist ich hatte Teammitglieder, die waren eins plus mit Sternchen und Sticker in dem Notenheft in geschriebener Kommunikation. Wenn es aber darum ging, sich mal vor eine Gruppe Menschen zu stellen, dann war es eher das Gegenteil.
Wolfi Gassler (00:21:43 - 00:23:18)
Es kommt ja auch darauf an, was du eben als Team brauchst. Weil wenn Written Communication ganz wichtig für dich ist, weil du remote unterwegs bist, dann hat es natürlich einen anderen Stellenwert, als wenn du fünf Tage im Office zusammenarbeitest. Dann ist es vielleicht weniger wichtig. Oder in einem kleinen Startup ist es vielleicht auch am Anfang weniger wichtig. Also da gibt es natürlich auch Prioritäten, die du festlegen musst und die hast auch du in deiner seniorigeren Stelle meistens zur Verfügung, weil du eben diesen Kontext auch hast. Wo will sich die Firma weiterentwickeln? Wo will sich die Firma hin entwickeln? Wo soll sich das Team hin entwickeln? Was für Projekte kommen in Zukunft? Wird das Team wachsen? Wird es gleich bleiben? Und solche Dinge kannst du dann natürlich in deine Planung mit reinnehmen und die sind auch ganz wichtig. Was ich jetzt natürlich auch noch nicht erwähnt habe, ist ein ganz anderer wichtiger Punkt. Du musst natürlich auch wissen, nicht nur wohin entwickelt sich deine Firma und dein Team und die Projekte, sondern wohin wollen sich die Leute entwickeln? Weil es gibt ja auch Personen, die ein ganz klares Ziel haben. Manche haben auch kein Ziel, kann auch vorkommen, ist meiner Meinung nach auch komplett in Ordnung. Aber es gibt natürlich Leute, die sagen, ich will eigentlich raus aus meiner Q Rolle und ich will Entwicklerin werden. Gibt es ja auch. Oder ich will noch tiefer in irgendeine Technologie gehen. Es gibt andere Leute, die sehen mehr Möglichkeiten auf der Leadership Seite oder auf der Product Seite. Also du musst schon wissen, wo wollen die Leute hin? Wollen sie Karriere machen? Ist es ihnen komplett egal? Wollen sie einfach nur einen gemütlichen Job haben? Alle diese Dinge musst du natürlich auch dementsprechend in One on ones ermitteln. Und das fließt dann natürlich auch wieder in die Matrix mit rein bzw. In deine Überlegungen.
Andy Grunwald (00:23:18 - 00:23:28)
Und das bringt mich zu einem wichtigen Punkt. Erstellt man die Matrix auf dem aktuellen Status quo oder erstellt man die Matrix, das, was das Team in Zukunft braucht?
Wolfi Gassler (00:23:28 - 00:23:32)
Beides. Am besten du startest mal mit dem Status quo und dann, ich meinte von.
Andy Grunwald (00:23:32 - 00:23:43)
Den Skills, die bewertet werden. Beispiel wir nutzen jetzt PHP und wollen alles nach Rust migrieren. Schreibe ich PHP noch als Skill drauf oder schreibe ich nur noch Rust drauf? Ÿousand, forward looking oder present?
Wolfi Gassler (00:23:43 - 00:24:38)
Beides. Ich würde beides machen. Also ich würde wirklich den Status quo mal erheben und dann überlegen, wo wollen wir hin? Das machst du ja mit Personen auch. Du setzt dich hier hin und sagst, wo wirst du in fünf Jahren sein? Wobei diese Frage eigentlich ziemlich dumm finde mittlerweile. Und ich gehe eigentlich eher weg von diesem klassischen fünf Jahre Schema, aber einfach, um mal zu triggern, wo willst du hin? Ja, weil diese fünf Jahre, die zweitausendein meisten Leute da eigentlich ein Problem haben mit fünf Jahren. Klar, es gibt einige Leute, die das klar formulieren können und das Ziel sehen, aber eigentlich den Großteil, den ich erlebt habe in meinen Teams, war eher, dass sie nicht so klare Vorstellungen gehabt haben und mehr so eher so Richtungen und vielleicht zu kurzfristigere Ziele, dass das wesentlich einfacher gegangen ist, als diese klassische fünf Jahres Frage, wo man sich irgendwas aus den Fingern saugt und dann zweitausendein ehrlich gesagt kein großer Mehrwert für mich da rausgekommen ist.
Andy Grunwald (00:24:38 - 00:25:24)
Das Ziel, was in fünf Jahren erreicht werden soll, muss ja auch noch nicht super kristallklar sein. Das kann ja auch nur eine Richtung sein. Das reicht ja schon, denn in fünf Jahren fließt noch so viel Wasser den Rhein runter, dass sich hier sowieso ganz viele Gegebenheiten ändern. Deswegen, ich finde die Frage gar nicht so doof und ich finde es nicht schlimm, wenn man keine Antwort hat, aber ich finde es schön, wenn man eine hat, denn dann hat man ja wenigstens was, wo man mal eine Richtung hat. Weil wenn man gar nichts hat, finde ich, dann wird es schon schwieriger, weil da gehst du nämlich in so eine Discovery Phase. Ja, möchtest du denn mal Personen, möchtest du denn mal Leute leiten? Möchtest du denn mal der sein, den man hier als Projektarchitekt reinholt? Oder also wie stellst du dir das denn vor, wohin wir in eine Richtung gehen? Ja, ich schaue mal so ein bisschen, ich gehe mal ein bisschen links und dann gehe ich mal wieder ein bisschen rechts. Also da wird es schon relativ schwer.
Wolfi Gassler (00:25:24 - 00:25:59)
Ja, finde ich aber kein Problem. Ich weiß, du bist, du bist jemand, der sehr strukturiert ist und sehr auf Ziele geht. Ich bin das Gegenteil. Und ich habe auch sehr viele Leute erlebt, die kein klares Ziel gehabt haben, aber einfach super Mitarbeiterinnen gewesen sind und die sich auch super weiterentwickelt haben und wo man kurzfristig auch eine Art Ziele machen hat können, aber die auch ein Problem mit dem Wort Ziele an sich schon gehabt haben. Also ich glaube, es gibt eine ganz breite Bandbreite von Leuten, wie sie mit der Zukunft von Zielen umgehen. Und es gibt auch Leute, die einfach sagen, ich möchte gemütlich meine Projekte machen und ich möchte da Gas geben und that's it. Und ich finde das auch komplett fair.
Andy Grunwald (00:26:00 - 00:26:12)
Das ist ja auch okay. Aber du hast jetzt gerade den Bias zu der unstrukturierten Seite beschrieben und gesagt hast, ich gehe einfach weg von der fünfjahres Thematik, denn jetzt gerade lässt du die strukturierten Leute in deinem Ansatz nämlich eigentlich aus, muss man zugeben.
Wolfi Gassler (00:26:12 - 00:26:24)
Na, das heißt ja nicht, dass man nicht über Ziele spricht, aber diese klassische Frage ist mir persönlich einfach nicht mehr sehr sympathisch. Wo siehst du dich in fünf Jahren? Die finde ich einfach bullshit, diese Frage. Die stelle ich nicht mehr so.
Andy Grunwald (00:26:24 - 00:26:37)
Ja, was ich sagen möchte, dass du deinen persönlichen Bias jetzt aber zur Entwicklung von den Leuten, ich sag mal, vorschreibst, nur weil du die persönlich für dich nicht gut findest, heißt das nicht, dass das nicht der Kicker für deine Leute sein kann.
Wolfi Gassler (00:26:37 - 00:26:41)
Und deswegen kann sein, ja, 13. Trotzdem verwende ich diese Frage nicht.
Andy Grunwald (00:26:41 - 00:26:57)
Genau. Und das theoretisch würde ich sagen, könntest du theoretisch der falsche Lied für ein paar diverse Leute sein, weil du denkst, dein geschlossenes System ist gegebenenfalls das richtige oder mein offeneres System ist zweitausendein das beste für alle. So liest sich das jetzt gerade. Wenn ich dich mal challengen darf.
Wolfi Gassler (00:26:57 - 00:27:13)
Du hast mich falsch verstanden. Ich stelle diese Frage nicht. Wo siehst du dich in fünf Jahren? Das heißt nicht, dass man über Ziele nicht diskutieren kann und die, die fragt und über die Zukunft redet und Ziele festlegt. Ich persönlich finde diese Frage wo siehst du dich in fünf Jahren einfach Bullshit heutzutage.
Andy Grunwald (00:27:13 - 00:27:20)
Ja gut, aber wo ist der Unterschied ist, was sind deine Ziele? Und wo sehe ich zu den fünf Jahren, wenn jemand strukturiertes und Ziele hattest? Jetzt kommt das schlecht heraus.
Wolfi Gassler (00:27:20 - 00:27:24)
Es kommt vielleicht das gleiche raus, aber es ist eine andere Kommunikationsart.
Andy Grunwald (00:27:24 - 00:27:46)
Weiß ich jetzt nicht. Für mich ist das die gleiche Frage umformuliert, außer dass man die Zahl selbst weglässt. Also wo sieht man sich in der Zukunft? Ist dieselbe Frage mit hast du Ziele? Also ist nicht dieselbe Frage. Also weil die Antwort ist keine Ahnung, in der Zukunft sehe ich mich mit einem Hund am rheinspazieren. Dann kann man sagen okay, sein Ziel ist, einen Hund zu haben.
Wolfi Gassler (00:27:46 - 00:27:59)
Wir werden da nicht auf einen grünen Zweig kommen. Es gibt unterschiedliche Herangehensweise. Ich habe auch sehr viele Leute kennengelernt, die ganz unterschiedlich reagieren auf Ziele und auf das Wort Ziele. Und ich bin da einfach auch flexibler geworden, wenn es darum geht, Ziele zu definieren.
Andy Grunwald (00:27:59 - 00:28:15)
Ja, okay. Wie unterstützt du denn deine Team Member, wenn du, wenn du sagst, okay, man hat jetzt keine Ziele oder die reagieren allergisch auf das Wort Ziele. So, was ist denn dein Vorgehen, wie du diese Leute dann jetzt unterstützt in einem Ÿousand Weiterentwicklungsplan?
Wolfi Gassler (00:28:15 - 00:30:42)
Also probiere deine Frage bisschen anders zu beantworten. Und zwar fange ich jetzt bei denen an, die eine Struktur wollen, weil das ist sehr einfach. Die Leute, die sehr strukturiert vorgehen, die wollen einen Development Plan meistens haben. Das heißt, sie wollen da ihre Ziele reinschreiben. In einem Jahr habe ich diese neue Technologie gelernt, habe einen Kurs gemacht für Kafka und habe auf einer Konferenz irgendeinen Talk gehalten und habe intern noch einen Junior weiterentwickelt mit Mentorship. Also das ist relativ einfach. Jetzt die andere Seite, wenn Leute nicht so klare Vorstellungen haben, gibt es meistens trotzdem, ich nenne es jetzt Ziele, obwohl man in dem Fall dann oft nicht von Ziele spricht. Aber die haben Probleme und die wollen die Probleme lösen und dann kann man mit denen auch vereinbaren, in welche Richtung man geht, kann ein paar Notizen schreiben. Das ist dann einfach kein so ein sehr strukturierter Development Plan, ÿousand, wie es manche wollen, wo dann genau irgendwelche Deadlines oben stehen, die nächsten Schritte und so weiter. Also so ein umfassender Plan, den würde ich dann einfach nicht machen. Aber grundsätzlich einen Plan zu haben, was man in der Zukunft so macht, in welche Richtung man sich bewegt, der ist, glaube ich, sehr wichtig. Und das können im Prinzip auch irgendwelche One One Notes sein, wo man reinschreibt, diese Stichwörter, willst du das mal probieren? Okay, wenn du auf einer Konferenz sprechen willst, dann könntest du mal bei einem Meetup sprechen, probier das mal aus. Next step, kümmere dich mal drum, ob es irgendwo ein nettes Meetup gibt oder so. Also dass man so schrittweise geht und nicht den Wasserfallplan für das ganze Jahr macht. Und da gibt es durchaus Unterschiede in der Persönlichkeit, wie Leute eben an die Dinge dran gehen. Und da habe ich zumindest immer probiert, flexibel zu sein und mit dem Flow, wenn man so will, mit den Leuten mitzugehen, wie man die eben am besten unterstützen kann. Und bei den einen ist es ein super strukturierter Plan und bei den anderen ist es eher ein bisschen loser und vielleicht eher so eine iterative Vorgehensweise, agile Vorgehensweise könnte man es fast nennen. Auf jeden Fall, auch wenn man diese agile oder lockere Vorgehensweise wählt, muss man, glaube ich, auf der eigenen Seite schon eine gewisse Struktur haben und sich überlegen, was für ein Potenzial steckt in den Leuten, was kann man machen und wo kann man denen helfen, zweitausendein sich weiterzuentwickeln. Und ich glaube, da gibt es schon so ein paar Hauptkategorien, an die man sich entlanghandeln kann, um Leute zu unterstützen, die so klassisch in einem Engineering Managerleben ganz oft auftreten oder auch bei Tech Leads in einem Team.
Andy Grunwald (00:30:42 - 00:30:43)
Und was sind diese Kategorien?
Wolfi Gassler (00:30:43 - 00:30:59)
Also die erste Kategorie, ich habe es ja mal so genannt, ist Motivation und Anerkennung. Also wie schaffe ich es im Team Motivation zu erreichen, dass die Leute eben Spaß haben, Motivation haben, zweitausendein sich weiterzuentwickeln, aber auch an der Arbeit einfach Spaß haben und motiviert sind.
Andy Grunwald (00:30:59 - 00:31:13)
Ist das wirklich, was du beeinflussen kannst? Denn ich denke, wenn es der Firma gerade nicht so gut geht, vielleicht wurden gerade Layoffs durchgeführt, ein paar deiner alten Kollegen wurden entlassen, da ist die Gefühlslage schon sehr weit unten aktuell.
Wolfi Gassler (00:31:14 - 00:31:17)
Umso wichtiger ist es, würde ich sagen, dass du das machst und dich darum.
Andy Grunwald (00:31:17 - 00:31:21)
Kümmerst, dich weiterzuentwickeln, damit du nicht auch abgesägt wirst. Oder weswegen ist das dann umso wichtiger?
Wolfi Gassler (00:31:22 - 00:32:22)
Ÿousand ja, also die Motivation ist schon eine allgemeine Motivation, weil wenn du keine allgemeine Motivation hast beim Arbeiten, dann wirst du dich auch nicht weiterentwickeln. Weil wenn dein normaler Arbeitsplatz schon die reinste Katastrophe ist und überall nur negative Stimmung und links in der Ecke sitzt jemand, der schon wieder weint, weil den Job verdient hat und rechts ist irgendein Product Owner, der einen cholerischen Anfall hat. Klar, das ist kein Umfeld, wo man gerne sich weiterentwickelt. Also ich glaube, das ist eine Grundsatzproblematik, wenn du sowas hast, aber dagegen kannst du arbeiten. Also ich glaube, das ist durchaus möglich, weil das wirst du im Alltag ganz oft vorfinden. Du wirst eine schlechte Stimmung haben in deinem Team und die Leute werden dir auch immer erklären, was alles schlecht läuft. Gerade in One on ones ist das ein Klassiker. Im Team läuft alles schlecht, unser Produkt hat extrem viele Probleme, irgendwelche Stakeholder nerven uns die ganze Zeit mit irgendwelchen Bug Reports, der Product Owner ist extrem pushy. Also solche Dinge wirst du haben. Die Leute kommen ja oft zu dir, weil sie diese ganzen Probleme haben.
Andy Grunwald (00:32:23 - 00:33:49)
Ich frage das jetzt so ketzerisch, aber warum ich das so frage, ist, weil das recht brutal gesagt die Realität ist und besonders in letzter Zeit. Es werden negative Meldungen kommen, die auch das Team empfängt, die auch auf die Stimmung vom Team drücken. Und jetzt ist es ganz, ganz wichtig, dass du als Teamleiterin, als Teamleiter dich davon nicht einfangen lässt. Denn was ich sehr oft auch gesehen habe, dass Engineering Manager ebenfalls dann in eine negative Stimmung verfallen und diese Stimmung dann auch ans Team weitertragen. Das Schlimmste, was man machen kann, ist zu sagen, ja, ich finde das auch scheiße, aber ich muss das jetzt so kommunizieren. Das ist der Todesstoß für die Stimmung des Teams, auch wenn du es wirklich nicht toll findest. Du musst ja jetzt auch nicht hey, ich hatte heute Geburtstag, hier ist mein Kuchen und die Welt ist wieder alles toll. So muss es vielleicht auch nicht rüberbringen, aber es macht einen realen Unterschied, wie du dich selbst als Teamleiter, als Senior, als Deaf, als mehr oder weniger Vorbildfunktion im Team verhältst und wie du dann auch mit diesen Nachrichten umgehst und ganz, ganz wichtig, wie du diese Nachrichten denn kommunizierst. Denn im Endeffekt, jede negative Nachricht, jede negative Stimmung schlägt auf die Performance des Teams und deine Aufgabe, deine Verantwortlichkeit der Zweitausendein als Teamleiter ist die Performance des Teams, ist die Delivery. Und wenn du dazu beiträgst, dass die Stimmung immer weiter in den Keller geht, dann würde ich sagen, schadest du dir eigentlich selbst.
Wolfi Gassler (00:33:49 - 00:35:11)
Und darum haben wir die Kategorie auch Motivation und Anerkennung genannt, weil ich glaube, das ist genau die Möglichkeit, die man hat, dagegen zu wirken. Einfach Anerkennung zeigen. Das heißt, man fokussiert sich auf die positiven Dinge, die passieren im Team. Man schafft ja irgendwelche Dinge, man delivert irgendwelche Dinge. Es gibt Leute, die man vielleicht loben kann, weil sie irgendeine coole Präsentation gemacht haben, weil sie sich um einen Junior gekümmert haben, weil sie gerade das Onboarding übernommen haben im Team. Ist ja egal. Also du findest ja sicher Sachen, die gut laufen oder die funktioniert haben. Und auf Diese Dinge solltest du dich einfach dann fokussieren und die auch kommunizieren. Das heißt, in einem gemeinsamen Slack, Teams, was auch immer, dementsprechend publishen, den Leuten vielleicht mal auch offiziell bei irgendeiner Veranstaltung, bei einem kleinen Team Meeting und sei es nur Stand up, einfach danke sagen, Leute loben, auch direktes vielleicht Feedback geben, wenn was gut geklappt hat, weil nicht jeder mag das Public Feedback, muss man auch dazu sagen, habe ich auch gelernt. Das ist leider, oder nicht leider, aber dass es da Leute gibt, die ein Problem damit haben. Also muss man vorsichtig sein unter Umständen, aber üblicherweise positives Feedback wird gerne angenommen und darauf muss man sich fokussieren. Und dann hat man schon mal eine gute Basis geschaffen im Team, weil man weiß, wo wo wollen sich die Leute weiterentwickeln, wo will man selber das Team weiterentwickeln? Und man hat dann hoffentlich eine positive Stimmung.
Andy Grunwald (00:35:11 - 00:36:12)
Der Wolfgang sagt das jetzt so salopp innerhalb der letzten 2 Minuten, doch ich möchte zwei Sachen sagen. Erstens, sich selbst nicht in dieses negative Loch fallen zu lassen, ist unglaublich harte Arbeit. Und wenn du dann auch mal ein bisschen Luft auslassen möchtest, dann geh zu deiner Vorgesetzten oder zu deinen Peers. Zweitausendeinundzwanzig, denn die haben alle dasselbe Problem, ist die erste Baustelle. Die zweite Baustelle. Persönliches Feedback sofort nach einem Meeting z.B. zu geben oder meine Weekly oder bi Weekly Summary über die Wins von dem Team irgendwie zu formulieren, ist ebenfalls sehr harte Arbeit. Das bedeutet nämlich konstante Beobachtung von jedem Teammitglied, wie die sich verhalten und so weiter. Und das ist nicht mal eben auch, ich lehne mich jetzt zurück und andere Leute machen das Meeting. Nee, das ist wirklich harte Beobachtung. Niederschreiben, danach überlegen, wie kommuniziert man das und so weiter und so fort. Das ist, das klingt beobachten klingt einfach, aber nee, wirklich was impactvolles zu sagen und was wirklich Detailreiches, das ist wirklich harte Arbeit.
Wolfi Gassler (00:36:12 - 00:36:41)
Und genau darum sprechen wir ja jetzt schon zu lange eigentlich über die Basis, die überhaupt da sein muss, damit die eine Weiterentwicklung ermöglicht. Also erst jetzt kann man wirklich in die ersten Schritte gehen, wie entwickle ich mich dann oder das Team weiter? Also diese Basis muss gegeben sein. Ich muss wissen, wohin wollen die Leute, wohin will ich mit dem Team, wohin will die Firma? Und ist diese positive Stimmung im Team da, die Motivation, sich weiterzuentwickeln? Und erst dann kann man sich wirklich weiterentwickeln.
Andy Grunwald (00:36:41 - 00:37:48)
Ein Element, was ich im Personen oder Team weiterentwickeln oft nutze, und das hört sich jetzt total dreckig an, ist ping Pong spielen. Und mit ping Pong spielen meine ich jetzt nicht mit dem klassischen Tischtennisschläger an der Tischtennisplatte beim hippen Startup, sondern es ist halt oft der Fall, dass zweitausendein Teammitglieder zu mir ankommen und sagen, wir haben dieses Problem und das müssen wir jetzt, das ist jetzt ganz wichtig, da müssen wir uns jetzt drum kümmern. Und viele neue Manager sagen jo, danke, wusste ich nicht, nehme ich auf meine Zettel, ich kümmere mich drum. Der kluge Manager sagt, der nimmt den Tischtennisschläger und ping pongt das Problem zurück. Denn mit klassischen Mentoring bzw. Coaching Fragen warum ist das denn ein Problem? Was hast du denn schon versucht, um es zu lösen? Und so weiter. Man stellt sich also selbst die Frage, hä, ist das wirklich ein Problem, was ich als Manager lösen muss? Oder Ÿousand, ist das nicht eine Möglichkeit, die Mitarbeiterin einen Tick eigenständiger zu machen, einen Tick besser in der Firma zu vernetzen, damit sie weiß, wen sie beim nächsten Mal zu diesem Problem ansprechen soll und ihr zu helfen bzw. Sie oder ihn an die Hand zu nehmen, dass er oder sie das Problem selbst löst.
Wolfi Gassler (00:37:48 - 00:38:23)
Das, was da Andi jetzt so schön unter ping Pong gesetzt hat, nennt man ja auch ganz gern delegieren, in dem Fall zurückdelegieren. Eigentlich zweitausendein, die Mitarbeiterin delegiert das Problem eigentlich zu dir und man delegiert es dann wieder zurück. Und der große Vorteil ist natürlich da, dass man dann auch die Autonomie fördert von dieser Person, weil die kann sich dann wirklich selber auch um ein Problem kümmern und da Verantwortung übernehmen. Aber meine Frage wäre jetzt auch an dich, Andy, woher weiß ich als Lied, ist es ein Problem für mich oder ist es so ein Ping Pong Problem, was sie gemütlich zurückspielen kann?
Andy Grunwald (00:38:23 - 00:40:08)
Brutal gesagt, wenn ich Frage, was hast du denn schon versucht, um das Problem zu lösen? Und da kommt einfach nichts. Ich bin gerade erst auf das Problem gestoßen, dann weiß ich jetzt schon mal, okay, das ist wahrscheinlich ein Problem, was ich ping Pong zurückspielen kann. Es sei denn, ich als Manager habe mehr Kontext, denn wir als Führungsposition haben in der Regel mehr Kontext. Und mehr Kontext in diesem Sinne meine ich, es gibt Teamstreitigkeiten, da ist die Richtung der Strategie der Firma noch nicht klar, da ist vielleicht Firmenpolitik involviert, man überlegt vielleicht das ganze Produkt sogar abzuschaffen oder oder oder. Also wirklich Informationen, die die Mitarbeiterin und die der Mitarbeiter noch gar nicht haben kann. Wenn das der Fall ist, wenn da, ich sag mal, gerade so ein bisschen Feuer im Busch ist, dann könnte man auch sagen, okay, man spielt das Problem nicht ping Pong zurück, sondern handhabt es selbst oder stellt es zurück. Oder das ist mein, mein Verhalten oft, ich versuche Transparenz zu geben, sag, hey, vielen Dank für das Problem, pass auf, im Hintergrund ist das Thema gerade so ein bisschen heiß diskutiert, ich kann keine Details nennen, aber da geht was vor sich. Wenn ich ein bisschen mehr Details nennen kann, halte ich dich auf dem Laufenden. Das wird deswegen, das ist der Grund, weswegen wir das Thema erstmal zurückstellen würden. Normalerweise würde ich das jetzt Ping Pong zurückspielen und würde dich fragen, wie du das Problem lösen würdest und dir dann helfen, mit dir das Problem zu lösen. Aber aus diesem Kontext, weil da gerade so ein bisschen viel Diskussion im Management ist, stellen wir es mal zurück. Also diese Transparenz, dieses warum ist ganz wichtig, weil auch mit diesem Warum einen soliden Grund zu geben, hilft deinen Mitarbeitern und deinen Teammitgliedern zu verstehen, warum du so agierst. Und zweitens, es erhöht natürlich die Transparenz und somit auch das Vertrauen, weil die Teammitglieder wissen ganz genau, der bullshittet nicht rum, der enthält mir keine Geheimnisse vor, sondern der kümmert sich darum. Und das ist so meine Erfahrung.
Wolfi Gassler (00:40:08 - 00:41:14)
Was ich mir auch immer überlege, ist eigentlich eine der Grundregeln vom sinnvollen Delegieren oder von guten Delegieren ist, kann die Person das auch wirklich stemmen und selbst machen? Weil wenn jetzt irgendwer daherkommt und sagt, okay, wir müssen jetzt umsteigen auf einen besseren Entwicklungsflow und wir steigen jetzt auf Git um von SVN oder sonst was und das ist eine Firma mit 500 Leuten oder 600 Entwicklerinnen und du sagst, ja, ja, geh mal und löst es und stell die Firma auf Git um, das wird halt nicht funktionieren. Also die Person wird gegen die Wand rennen, enttäuscht sein und zurückkommen. Oder im schlimmsten Fall, wenn es irgendwie ein großes Projekt ist, wo man viel Verantwortung übernehmen muss, dass das Ganze in einem Burnout endet oder zumindest in einem Desaster. Also da muss man wirklich aufpassen, ist die Person in dieser Rolle, mit dem Einfluss, den die Person hat, ist es möglich, dieses Projekt durchzuführen? Also das ist, glaube ich, ganz wichtig und das muss man ganz allgemein, wenn man delegiert, Aufgaben delegiert, immer mitdenken. Zweitausendein ist die Person dazu fähig, hat sie die Kenntnisse, das Wissen, das Netzwerk, den Impact in der Firma, damit man die Person, und so hart klingt, aber es ist so nicht verbrennt.
Andy Grunwald (00:41:14 - 00:42:17)
Es gibt aber auch Projekte, die sind gerade so, wie sagt man so schön, on the edge, ein Projekt, was eigentlich schon zu groß ist, aber trotzdem machbar. Und genau diese Projekte nutze ich oft, um die Leute wirklich weiterzuentwickeln. Ich ping ponge das Problem zurück, ich weiß aber auch, das Projekt ist eigentlich zu groß. Und dann nehme ich die Person wirklich aktiv an die Hand für die nächsten paar Wochen und Monate. Und das aktiv an die Hand nehmen bedeutet auch fast täglicher Austausch von Slack Nachrichten oder ähnliches über dieses Problem. Aktive Guidance geben, wie man vielleicht kommuniziert. Am Anfang ein bisschen mehr, nach zwei, drei Wochen schleicht sich das so ein bisschen aus, dann vielleicht alle zwei, drei Tage und so weiter. Aber das sind gerade diese on the Edge Projekte, die vielleicht ein Tick zu groß sind, aber deswegen auch nicht langweilig. Da bin ich dann involviert. Aber ich bin so weit im Hintergrund involviert, dass die ganzen Credits zur Mitarbeiterin, zum Mitarbeiter gehen. Das klingt jetzt aus meiner Sicht so leicht, für die Mitarbeiterin ist das aber sehr wahrscheinlich und sehr oft unglaublich stressig, weil das ist so ein bisschen so die Extrameile gehen.
Wolfi Gassler (00:42:17 - 00:44:17)
Ich glaube, das ist auch auf der Management Seite ganz schwierig, dass man sich überlegt, okay, wie weit ist man involviert? Weil meiner Meinung nach, ÿousand, wenn man irgendwas delegiert, sollte man ja den Kontext ganz klar definieren. Also wohin will ich eigentlich gehen mit dem Projekt? Was will ich erreichen? Und nicht das wie, nicht, dass man eine Anleitung gibt, du musst diese genau fünf Steps durchführen, damit du zu dem Ziel kommst, sondern man gibt das Ziel vor, wir wollen jetzt den Entwicklungsprozess umstellen in eine gewisse Richtung. Wir wollen erreichen, dass die Leute schneller sind oder schneller Feedback bekommen bei ihrem Entwicklungszyklus. Ÿousand and that's it. Und wie man dann dorthin kommt, mit welchen Leuten man spricht, was man bewegt und so weiter, das ist dann eigentlich die Aufgabe von der Person, die das Projekt delegiert bekommen hat. Also das ist, glaube ich, ganz wichtig, den richtigen Kontext festzulegen. Und dann ist eben die Frage, wie weit ist man eingebunden? Wie du richtig gesagt hast, Andy, muss man vielleicht mehr sein, je nach Projektgröße. Aber man muss halt aufpassen, nicht ins Micromanagement zu verfallen. Oder was ich auch super gern bei Firmen sehe, ist so ein Riesenproblem meiner Meinung nach, dass alle auf CC sind. Irgendwie man sagt, okay, es sollen andere machen, aber man ist dann CC, bekommt die gesamte Kommunikation mit, muss alles mitlesen oder liest es dann auch nicht mit und die andere Person glaubt, man hat aber mitgelesen. Also das ist schon ein extremes Problem. Man muss, glaube ich, auch die Kommunikation klar definieren, dass man sagt, okay, mach du, aber halte mich in the loop und zwar nicht mit CC Messages, sondern gib mir ein Reporting, gib mir ein Update jede Woche in unserem one hundred one, gib mir ein Update, dass man da klar definiert, was Kommunikation bedeutet und wann vor allem die Kommunikation stattfindet oder das Reporting, damit es nicht überhand nimmt. Und wenn ich alle CC e Mails immer wieder mitlesen muss, habe ich eigentlich auch gar nichts gewonnen an dem Delegieren, meistens zumindest. Also da muss man, glaube ich, wirklich den Sweet Spot finden, je nach Person und Projektgröße, wie weit ist man involviert und vor allem, wie ist man involviert? Und im Idealfall definiert man das gemeinsam zum Start des Projektes, wie man die Kommunikation macht oder das Reporting.
Andy Grunwald (00:44:17 - 00:45:00)
Ich glaube, das, was der Wolfgang gerade gesagt hat, es hilft einfach zu sagen, man delegiert das Problem nicht, weil was man unter delegieren versteht, ich gebe es ab und habe damit nichts mehr zu tun. Was aber schon der Fall sein muss, ist die Person accountable halten, also verantwortlich halten und sagen, hey, das ist dein Baby und ich frage die ganze Zeit nach, weil im Endeffekt sind wir da beide, haben wir beide da ein bisschen was im Boot. Von daher ist delegieren vielleicht das falsche Wort, accountable halten und konstant wirklich nachfragen, hey, wie ist denn der Stand? Und das ist kein Micromanagement, das zeigt einfach nur, du hast was auf dem Zettel und du solltest eigentlich für jeden deiner Mitarbeiter mindestens zwei bis drei dieser Themen immer auf dem Zettel haben, wo du die Leute wirklich accountable hältst.
Wolfi Gassler (00:45:00 - 00:45:29)
Okay. Delegieren ist ja eine klassische Methode, wie man Leute weiterentwickelt und wie die wachsen können. Jetzt erreicht man ja irgendwie dann auch einen Punkt, wo man eigentlich gerne hätte, dass die Leute selbstständig agieren und sich weiterentwickeln und vielleicht sogar mit neuen Ideen um die Ecke kommen. Also so dieses berühmte, die Innovation, die Lieblingsfrage so in Interviews für Engineering Manager, wie fördern sie denn die Innovation in ihrem Team? Also das Next Level sozusagen von der Weiterentwicklung.
Andy Grunwald (00:45:30 - 00:45:41)
Also du meinst jetzt, wir sind halt wirklich jetzt beim Leveling ab. Genau, wir haben jetzt alle Probleme gelöst und alle ping Pong zurückgespielt und jetzt können wir uns mit dem Spaß mal ein bisschen Zeit verbringen.
Wolfi Gassler (00:45:41 - 00:45:49)
Genau. Also wie würdest du die Frage beantworten, wie fördern sie die Innovation in ihrem Team, Herr Grunwald? Und komme jetzt nicht mit dem Hackathon.
Andy Grunwald (00:45:49 - 00:46:17)
Um die Ecke, wir kopieren Big tech, wir kopieren Google 20. %. Nein, also die Beantwortung der Frage ist unglaublich schwierig, weil ich glaube, dann hätte ich den Kontext vom vorherigen Interview gebraucht, um da wirklich zweitausendein effektiv antworten zu können. Die Frage ist aber eigentlich ist dasselbe, wenn eine Mitarbeiterin, ein Mitarbeiter mit einer Idee zu mir kommt und sagt hey, wir haben ja diesen Monolithen. Ich schlage vor, wir dritteln den Monolith in drei Services und dies und das und das sind die Gründe.
Wolfi Gassler (00:46:17 - 00:46:20)
Was ist deine Frage? Ob das schon Innovation ist oder nein?
Andy Grunwald (00:46:21 - 00:47:32)
Ja, es ist Innovation in dem Sinne, weil es kommt jemand mit einer wirklichen Idee, die Vorteile hat in der Zukunft, weil man merkt, die Applikation wächst. Wenn drei Teams an Monolithen arbeiten, wird es schwierig. Deswegen schlägt diese Person aktiv vor, Dieses Problem haben wir jetzt noch nicht. Diese Person schlägt aktiv vor, den Monolithen zu dritteln, damit jedes Team unabhängig arbeiten kann. Und jetzt ist die nächste Frage Moment, das haben wir doch gerade gemacht. Ping pong ich das zurück und sage ja, dann kümmere dich darum, dass es passiert. Und da sage ich nein, es ist nicht dasselbe, denn jetzt ist deine Arbeit als Manager, als Senior wirklich gefragt, denn hier geht es darum, um eine teils strategische Antwort und du musst ja Zeit rausschneiden. Du musst eigentlich eine Produktinnovation, wenn du so möchtest, zwar eine interne Plattform Produktinnovation und vielleicht keine, die den Kunden jetzt alleine betrifft, aber du musst ja Zeit vom normalen Feature Development rausschneiden. Du musst ja eine eine eine Änderung an der Arbeitsstruktur halt auch vorantreiben. Vielleicht brauchst du Approval von deinem Chef, von deinem Chefchef und so weiter. Und da brauchst du natürlich dann schon mehr, ich sag mal hands on als Manager.
Wolfi Gassler (00:47:32 - 00:47:38)
Jetzt hast du dich schön rumgedrückt um die Antwort auf meine Interviewfrage, wie kann ich Innovation fördern?
Andy Grunwald (00:47:38 - 00:48:09)
Ja, weil da gibt es nur falsche Antworten auf diese Frage. Wenn du das Standardrepertoire haben möchtest, ja, okay, man kann ja vielleicht irgendwie sagen, keine Ahnung, 10 % time Budgets, ja, jeden Freitag von 12 bis 16 Uhr macht man das, Belohnungssysteme, Hackathons, blablabla, man schickt die Leute auf Konferenzen, damit die neue Ideen bekommen, eine offene Kultur, Team zusammen, dann kommen die Ideen von ganz alleine. Aber sowas willst du ja nicht hören.
Wolfi Gassler (00:48:09 - 00:48:32)
Naja, ich würde schon sagen, dass das auch alles richtig ist. Also es ist ja nicht so, dass das Zweitausendein nicht so wäre, das wenn man auf eine Konferenz geht, dass man da externe Inspiration vielleicht mitnehmen kann und dass der Hackathon vielleicht auch ganz gut funktioniert oder ein internes Belohnungssystem. Wobei das klingt schon immer so konzernartig alles, wenn man da irgendwie dann so eine Ideen Schmiede, so eine Plattform hat. Online oder so, je nachdem wie man das Ganze umsetzt.
Andy Grunwald (00:48:32 - 00:49:22)
Genau, genau. Und da kommt es halt jetzt gerade, Beispiel, du gehst auf eine Konferenz, jemand hat neue Ideen mitgebracht und wenn du diese Ideen nicht volley nimmst und wirklich mal versuchst einzubetten, dann war das eine schöne Zeit für die Mitarbeiterinnen und Mitarbeiter, alles gut, aber die Firma hat im Endeffekt nichts davon. Ich sage nicht, dass man jede Idee von einer Konferenz irgendwie in der Praxis umsetzen soll, das sage ich jetzt nicht. Aber wenn du da ein bisschen mehr Struktur hintersetzt und versuchst die Mitarbeiterin mit dem neu gewissen, mit dem neu gewonnenen Ideen auch zu enablen, diese Innovation im Unternehmen durchzubringen, da steckt ja so viel Arbeit hinter für dich als Manager. Und das ist die Innovation. Die Innovation ist nicht, die Mitarbeiter zur Konferenz zu schicken, sondern wie du das in der Kultur im Unternehmen verwandelst. Und genau darauf habe ich gerade geantwortet und das ist meine Antwort, wie ich Innovation fördere, Herr Dr. Gassler.
Wolfi Gassler (00:49:22 - 00:50:02)
Also ich glaube auch, dass die Rahmenbedingungen wieder mal stimmen müssen, das sagt sich auch so leicht, aber ich glaube, das ist eigentlich das Schwierige. Und mir hat gerade kürzlich mal ein Kollege erzählt von einer Situation in einer sehr ansehnlichen Firma, die gerade sehr viel im Gespräch ist in Deutschland und eigentlich auch als moderne Firma gilt. Und er hat was vorgeschlagen, dass man in der Datenbank sich vielleicht mal etwas anschauen könnte. Und die Antwort, was er bekommen hat, war, deine Aufgabe ist nicht die Datenbank zu verbessern, du bist Entwickler. Und das ist, glaube ich, genau diese Kultur, die man nicht haben will, weil genau da killst du einfach alles, was es an Innovation gibt, eigentlich in deiner Verwaltung.
Andy Grunwald (00:50:02 - 00:50:10)
Memo an den Audio Engineer, können wir hier irgendwie so ein He man so Pau irgendwie da reinmachen, das wäre kein Universal.
Wolfi Gassler (00:50:10 - 00:51:05)
Also was ich damit nur zeigen will, ist, dass diese Fehlerkultur, die immer alle belächeln, dass das halt schon ein Problem ist, was es in der Realität gibt. Also das ist nicht so, dass eh jeder diese tolle Fehlerkultur lebt. Ich weiß, es ist schon ziemlich abgedroschen, aber ich glaube, das ist immer noch ein wichtiger Punkt und den muss man halt einfach sicherstellen, dass die Leute sich trauen, etwas vorzuschlagen, sich trauen zu dir zu gehen, dass du offen bist, eben wie du auch schon davor richtig erwähnt hast, wenn du den Kontext gibst, warum das aktuell nicht möglich ist, dass man da auch richtig reagiert. Und das ist, glaube ich, extrem wichtig. Ohne dieser Kultur und den Rahmenbedingungen gibt es eigentlich keine Innovation, meiner Meinung nach. Also auch wenn du die ganzen Konferenzen und so weiter und alles andere machst, aber es braucht halt trotzdem diese, diese, wenn ihr das in ein Bild fassen darf, die nährstoffreiche Erde die Grundlage ist, damit mal über etwas wächst.
Andy Grunwald (00:51:05 - 00:52:19)
Nährstoffreiche Erde Philosophie im Engineering Kiosk. Aber ja, das Wichtige ist wirklich, diese neuen Learnings strategisch in der Firma unterzubringen. Denn ihr müsst euch immer im Hinterkopf behalten, wenn man sich Zeit rausnimmt, etwas neu Gelerntes aus einer Konferenz irgendwie ins Produkt zu überführen. Im Endeffekt ist das ein finanzielles Investment der Firma. Es wird Arbeitszeit von euch weggenommen, ins Produkt gesteckt. Du hast nämlich immer Opportunitätskosten. Es hätte nämlich auch ein neues Feature sein können. Das klingt brutal und das klingt trocken, aber das ist das Involvement bzw. Die Arbeit, die ein Engineering Manager hintendran tut und vielleicht auch verhandelt mit dem Produktmanagement und so weiter und so fort, weil es verschieben sich möglicherweise dadurch Roadmaps und vielleicht sogar zugesagte Features für Kunden, keine Ahnung, je nach Kontext, wo dran ihr arbeitet. Aber das ist halt das Wahre, die die wahre Arbeit dann später, um wirklich Innovation zu fördern. Und nur weil das Timing jetzt gerade nicht passt, seid nicht beleidigt, euer Direct Report wird in der Lage sein, sich das auf den Zettel zu schreiben und als Wiedervorlage für in drei Monaten wieder rauszuholen. Und vielleicht kann man es dann machen. Wie sagt man so schön? Aufgehoben ist nicht aufgeschoben. Nee, aufgeschoben ist nicht aufgehoben. Zweitausendein. Naja, ihr wisst, was ich meine.
Wolfi Gassler (00:52:19 - 00:53:31)
Ein anderer heißer Tipp von mir, den ich immer ganz gerne gibt, auch bei Innovation, ist Networking, weil meiner Meinung nach entsteht Innovation oder Ideen entstehen vor allem dann, wenn man in irgendeiner Form externe Inspiration bekommt. Und wir haben ja schon Konferenzen genannt, aber ich glaube, was viele vergessen ist, dass man ja auch in dem Unternehmen, in der Firma oder auch außerhalb mit Meetups, was es auch immer ist, Inspiration bekommen kann. Also wenn man mit anderen Leuten spricht und wenn man das Network hat, dann entstehen Ideen. Weil auch wenn ich eine schnelle Idee habe und vielleicht mal dann meine Kollegin ansprechen kann, hey, du arbeitest doch in einem anderen Bereich, du arbeitest im Datenbankbereich, was denkst du denn über Idee XY, dass wir da einen neuen Index einführen oder eine neue Technologie? Und so kann man Ideen meistens auch viel schneller treiben und dann entsteht ein Ping Pong und man diskutiert und hat eine gute Idee am Ende. Und Networking wird ganz oft unterschätzt, also dieses Ganze, was man sonst auch gerne unter Knowledge Sharing versteht, aber wirklich gezielt networken, dass Leute in der Firma kommunizieren und dass es auch erlaubt wird, weil auch da gibt es wieder Firmen, die erlauben keine Kommunikation zwischen unterschiedlichen Teams und die haben da eine harte Struktur und meiner Meinung nach ist das ein Killer von Innovation.
Andy Grunwald (00:53:31 - 00:55:14)
Ein positives Beispiel hier kann man mal die Firma Cloudflare nennen. Da weiß ich z.B. dass jeder zweitausendein Mitarbeiter mindestens einmal im Interview mit einem c Level gesprochen hat, also mit der Geschäftsführung. Und der Grund ist dafür, dass das c Level damit signalisieren möchte, dass man jeden Mitarbeiter innerhalb der ganzen Firma ansprechen kann, zu egal welchem Thema. Also und das würde ich sagen, ist ein wahres Commitment, denn Cloudflare hat 3000, 3000, 504000 Mitarbeiter. Und dass sich zweitausendein ein Geschäftsführer oder eine Geschäftsführerin Zeit nimmt mit jedem Interviewkandidaten, natürlich zu einem späteren Prozess, wenn das Angebot, der wahrscheinlich schon angenommen wurde, 20 dreiig Minuten hinsetzt und spricht. Das ist ein Kultur und aber man muss das gar nicht so hochtrabend machen. Es gibt auch z.B. relativ einfache Mittel, wenn ihr z.B. slack oder Teams habt, da gibt es eine Software, die nennt sich Donut, die kann man installieren und dann ist das ein Bot in einem Channel und dieser Bot allokiert wöchentliche Meetings mit zwei random Personen aus dem Channel. Und dann hat man einfach jede Woche oder alle zwei Wochen so ein Coffee Chat mit irgendeiner random Person und ein Bot hat die Person ausgewählt und ein Bot hat einfach ein Meeting reingesetzt. Ist auch eine nette Idee, einfach mal mit jemandem aus Finance oder ähnlichem zu sprechen. Und da kommen auch ganz viele andere Ideen und da kommen oft an solche Thematiken, ja wir haben diesen manuellen Prozess und dann muss ich dann immer Jira Tickets anlegen und du als Software Engineer denkst dir, das mache ich dir doch in 5 Minuten mit einem Python Skript. Schon hat man jemandem geholfen, schon ist das Innovation. Und wer weiß, vielleicht entsteht da ein halbes Jahr später einfach nur ein firmeninternes productivity Team und du bist ganz vorne dabei. Wer weiß das schon.
Wolfi Gassler (00:55:14 - 00:56:10)
Und wenn wir gerade bei externer Inspiration sind, was ich auch super interessant finde, ist, dass ganz viele Firmen side Projects erlauben. Und noch besser, es gibt auch Firmen, die side Projects unterstützen. Also ihr habt schon Firmen erlebt, wo teilweise die interne Legal Abteilung den Leuten geholfen hat bei externen side Projects, die sie privat machen, einfach um zu zeigen, dass sie das unterstützen, dass sie auch was anderes lernen können. Vielleicht entwickelt sich sogar eine Firma daraus, ist ja okay. Also die waren so offen, dass sie das wirklich aktiv unterstützt haben. Und ich glaube, das bringt dann auch wieder eine gute Stimmung, eine motivierte Stimmung ins Team, wenn solche Sachen erlaubt sind und man hat noch externe Inspiration. Und genau das fördert meiner Meinung nach genauso wieder Innovation. Also finde ich extrem cool, wenn Firmen so was machen, auch wenn das natürlich schon viel verlangt ist, wenn man sogar dann interne Ressourcen unter Umständen quasi für private Zwecke entfremdet.
Andy Grunwald (00:56:10 - 00:56:22)
Und wenn du jetzt noch den Firmennamen nimmst, dann kann sich die Firma vor Bewerbung nicht mehr retten. Denn ich glaube, Legal Advice für dein Zeitprojekt, ich glaube, da lächelt jeder zweitausendein. Also mach mal eine Kooperation klar und dann können wir den Namen droppen hier.
Wolfi Gassler (00:56:23 - 00:56:37)
Ja, ich bin mir auch gar nicht sicher, wie offiziell das natürlich gelaufen ist, ist nochmal eine andere Frage, aber es war von C Level zumindest approved, also das war kein Problem. Es ist der Vorteil, wenn man eine private Firma ist, da kann man sich sowas erlauben. Und ich finde es im Allgemeinen eigentlich ganz gut.
Andy Grunwald (00:56:37 - 00:56:43)
Wie kann es nicht offizieller sein, wenn der C Level das approved? Also wer, also offizieller geht ja gar nicht mehr.
Wolfi Gassler (00:56:43 - 00:57:10)
Ja, aber ob die Firma damit Werbung nach. Ob sie sich so darstellen will und Werbung damit nach außen macht, zweitausendein, das ist dann noch mal eine andere Sache. Aber grundsätzlich finde ich das eigentlich eine gute Sache, weil man da einfach sieht, dass die Firma mit den Mitarbeiterinnen gut umgeht und die einfach fördern will in der Weiterentwicklung. Und sogar wenn es extern ist und die Gefahr besteht, dass die sich dann selbstständig machen mit dem side Project, kann ja passieren, aber sogar das ist eigentlich gewünscht, weil es eben um die Weiterentwicklung der Personen geht.
Andy Grunwald (00:57:10 - 00:58:34)
Und wir sprechen jetzt die ganze Zeit immer nur der Lead, der Direct Report ist dafür zuständig, so weiter. Nee, das ist eine ganze, ganze Team Thematik. Denn wenn man von dem klassischen Knowledge Sharing spricht, Pair Programming, Learning Sessions, Lunchtalks, Demo Days, Micro Learnings, Watch Parties, was es da nicht noch alles gibt, da ist wirklich jeder gefragt. Und da heißt es nicht nur immer, ich möchte lernen, also immer nur fordern, sondern auch geben. Auch wenn du Midlevel Engineer bist, Junior Engineer, dann ist es unglaublich wertvoll für alle und auch für Senior und Staff, einfach nur nach deinem Onboarding zu sagen, was du gut fandest, was du nicht so gut fandest und was du für den nächsten Junior Engineer, der ongeboardet wird, verbessern würdest, wenn du das einfach mal ganz doof, ganz klassisch in einer PowerPoint Präsentation zusammenfasst, alle Leute mal in den Meetingraum holst und einfach mal 20 Minuten durchgehst. Solche Informationen sind auch sehr, sehr, sehr gute Learnings für Staff Engineers und Senior Engineers. Also was ich damit sagen möchte, diese klassischen Knowledge Sharing, Angebote, über die wir eigentlich fast noch gar nicht hier in dieser Episode gesprochen haben. Das haben wir alles in Episode 95 getan. Für Details mal hören. Das ist eine Teamgeschichte, das bedeutet, ihr seid da auch gefragt. Und natürlich, wenn man von einer Gruppe von Menschen spricht, dann ist das auch in irgendeiner Art und Weise leveling up, lifting up, zumindest im Bereich Soft skills und Kommunikation.
Wolfi Gassler (00:58:34 - 00:59:46)
Was da natürlich wichtig zu erwähnen ist, zweitausendein und das haben wir, glaube ich, in der Episode 95 auch erwähnt, wo es dann wirklich um die ganzen Formate an sich auch geht. Aber genau da spielt natürlich die Engineering Managerin oder Staff Level auf jeden Fall eine große Rolle, weil die müssen das erlauben und vorantreiben und vielleicht die Formate einführen oder ermöglichen oder dies erlauben, dass die Zeit investiert wird. Also es kann nicht nur von von unten kommen, sozusagen aus dem Team heraus, sondern es muss auch wieder das Setting, dieses Setup gegeben sein, dass das überhaupt möglich ist. Und da ist es dann wichtig, dass die Engineering Manager einfach dementsprechend das supporten und vielleicht, ich glaube, das ist ganz wichtig, auch in gewisser Weise pushen. Weil, seien wir uns ehrlich, jeder nimmt sich irgendwie vor, sich weiterzubilden, irgendwo hinzugehen zu einem Talk, aber am Ende passiert es dann doch seltener als man denkt. Und da kann die Engineering Managerin einfach mehr Druck drauflegen und eben in einem One on One vielleicht auch, nennen wir es nicht Ziel, aber vielleicht einfach einen Next Step vereinbaren. Du haltest einen Talk oder du gehst zu dorthin oder solche Dinge dann wirklich konkret in den One on ones vereinbaren. Und so kann man ein bisschen Druck aufbauen.
Andy Grunwald (00:59:46 - 00:59:50)
Also was heißt das jetzt? Tipp Nr. Eins Vorbild sein oder wie kann man das zusammenfassen?
Wolfi Gassler (00:59:51 - 01:00:32)
Ja, weiß nicht, ob Druck ausüben ein Vorbild ist unbedingt, aber das ist ja ein positiver kleiner Druck, Ÿousand. Aber du hast vollkommen recht. Ich glaube, Vorbild zu sein und vielleicht auch mal selber einen Talk zu halten, das ist ja auch so ein großer Fehler, was viele dann machen. Ich bin jetzt irgendwie Manager, ich halte keine Talks mehr oder so. Das müssen die anderen machen. Einfach da vielleicht mal einen Talk halten, zu den Events hingehen, wirklich Leute mitschleppen. Ich kann mich erinnern, Andi, wo wir uns, da haben wir uns noch nicht lange gekannt und das erste, was du gesagt hast, hey, heute Abend diesen Meetup Wolfige mit und hast mir einfach da mitgeschleppt. Also einfach ein Vorbild sein und dementsprechend die Leute mitnehmen, sie enablen, pushen, wie man das auch immer nennen will und das möglichst authentisch auch selber leben.
Andy Grunwald (01:00:33 - 01:00:39)
Möchtest du damit sagen, ich war damals ein Vorbild oder möchtest du mir damals sagen, ich habe mich der Entführung schuldig gemacht?
Wolfi Gassler (01:00:39 - 01:01:01)
Ja, das ist nicht so klar trennbar, würde ich sagen. Das fällt dann in eine Kategorie, das ist so schwammig dann. Ich sage ja, pushen oder enablen, wie du das auch immer nennst. Du sollst nett sein zu den Leuten, aber sie doch irgendwie vielleicht auch nur an die Hand nehmen und ja, zum Meetup mitnehmen z.B. gar nicht pushen, mitnehmen.
Andy Grunwald (01:01:01 - 01:02:19)
In dieser Episode haben wir jetzt natürlich ziemlich viel darüber gesprochen, was deine Managerin oder Manager tun sollte und wie du dich dann vielleicht auch ein bisschen verhalten sollst. Oder wenn du Senior bist oder Staff Engineer oder Manager, was du tun sollst. Aber ab und zu ist es halt auch so, dass dein Lead, dein Manager in dem Bereich wenig bis gar nicht macht und sich nicht um dein Leveling abkümmert bzw. Bisher nicht gekümmert hat. Und das ist schade, ganz klar. Aber hey, so ist die reale Welt. Oft fällt es auch hinten runter, weil der Alltag so stressig ist. Deswegen hier mal einen kleinen Push an alle, die in dieser Situation sind. Ab und zu braucht deine Reporting Line zweitausendein auch mal einen Tritt in den allerwertesten. Challenge bitte deine Reporting Line und fordere es ein. Denn im Endeffekt macht es dich zu einer besseren Mitarbeiterin, zu einer performanteren Mitarbeiterin. Und wenn dies gegeben ist, ist deine Reporting Line erfolgreicher. Denn People Management und Project Delivery ist mit sehr hoher Wahrscheinlichkeit eine Verantwortlichkeit deiner Reporting Line und somit ist das ein Win Win. Also sind auch nur Menschen, die haben auch ab und zu mal einen Hänger. Vielleicht geht in deren privaten Leben gerade was ab, weiß ich nicht. Ein bisschen, ja, ich würde schon sagen, Empathie zeigen bzw. Verständnis. Also fordert es ein, setzt es auf die One on One Agenda im neuen.
Wolfi Gassler (01:02:19 - 01:02:50)
Jahr, wenn es zumindest ein one on one gibt. Also treten allerwertesten bitte nicht zu wörtlich nehmen wieder, wie der Andi das meint, aber pushen wieder. Und wir haben da auch eine nette Geschichte, hat uns kürzlich jemand erzählt aus unserer Community, dass ein Mitglied aus seinem Team ihm die Episode, was war es, glaube ich, neun oder so, zu One on ones gesendet hat und der Lied hat dann die 101 eingeführt. Also ihr könnt es gleich mit dieser Episode machen, Leveling Up Episode, einfach an euren Lead oder an die Lead schicken und dann ist das quasi der Tritt in den allerwertesten.
Andy Grunwald (01:02:50 - 01:03:09)
Und noch final, bevor wir uns hier mit dem Mikrofon verabschieden, noch eine Beobachtung. Wir reden oft über Engineering Manager und individuell Contributor um diese Beziehung. Meine Frage ist, wer kümmert sich denn um das Lifting up leveling up? Der Engineering Manager selbst.
Wolfi Gassler (01:03:09 - 01:03:11)
Die Directors natürlich.
Andy Grunwald (01:03:11 - 01:03:50)
Genau. Jetzt würde man sagen die Directors, aber was in vielen Firmen gelebt wird, da hört es dann auf. Ja, also eine eine essentielle Aufgabe von Engineering Managern ist es, die individuelle Computer Computer, die individual contributor abzuliften. Und der Direktor kümmert sich oft nicht um seine Direct Reports, was dann Engineering Manager sind, denn es wird ja gesagt, das sind ja Manager, die müssen ihre Karriere selbst in die Hand nehmen. Also das kann es ja auch nicht sein. Deswegen, falls ihr irgendwie höher in der management Hierarchie seid, wie sieht das denn mit dem Leveling up Lifting up von euren Leuten aus, die auch Teammitglieder. Denkt mal drüber nach. Das war mein Wort zum Dienstag.
Wolfi Gassler (01:03:50 - 01:03:59)
So viele Dritte in den allerwertesten heute zweitausendein, die du austeilst in alle Richtungen und empfiehlst. Sehr gut gemacht, bekommst du den Pokal. Der dritte heute.
Andy Grunwald (01:03:59 - 01:04:23)
Na, ich arbeite ja auch primär remote, deswegen dritte sind dann nur verbal, aber nun gut. Aber fordert es ein. Es ist mehr oder weniger euer Recht. Und wenn ich jetzt sage euer Recht, dieses Recht ist eine Win win win Situation für die Firma, für euren Direct Report, aber auch für euch. Von daher, ich verstehe nicht, wer da verlieren kann. Und das war es mit unserer Episode 168. Vielen dank Wolfgang. Wir hören uns bei der nächsten Episode.
Wolfi Gassler (01:04:23 - 01:04:24)
Danke auch, ciao.