#124 Technische Glaubwürdigkeit bewahren: Müssen Leads den Code kennen?

Hands-On als Engineering Manager: Yay or Nei?

Leute, die einmal das Handwerk des Software-Engineerings professionell ausgeübt haben und dann ins Management wechseln, haben oft den Drang, ihr Hardskills nicht zu verlieren. Doch durch den neuen Job sind die Prioritäten nun andere: People Leadership, das Team effizient halten, Strategie und Roadmaps entwickeln. Wo bleibt denn da noch die Zeit am Code mitzuarbeiten?

Wir stellen uns die Frage: Warum ist das so? Muss das sein, dass Manager weiterhin technisch sind? Und wenn ja, welche Gefahren birgt das? Aber auch: Wie können wir es möglich machen, obwohl unser Kalender sagt, dass die Woche mit Meetings bereits belegt ist?

Darum geht es in dieser Episode. Viel Spaß!

Bonus: Auch Manager laufen auf Kaffee.

Das schnelle Feedback zur Episode:

👍 (top) 👎 (geht so)

Sprungmarken

(00:00:00) Die Anforderung, dass Engineering Manager Hands On sind

(00:06:54) Muss ein Engineering Manager technisch sein?

(00:10:09) Verschiedene Firmen definieren die Rolle einer Managerin unterschiedlich

(00:12:48) Risiken, wenn die Engineering Manager zu technisch sind

(00:14:08) Möglichkeit technisch zu bleiben: Pair-Programming und Code Reviews

(00:18:25) Möglichkeit technisch zu bleiben: Dokumentation schreiben und Architektur Entscheidungen

(00:22:38) Möglichkeit technisch zu bleiben: Rubber Duck Development, On-Call und Coden

(00:32:01) Lernen außerhalb der Arbeitsumgebung: Hackernews, Konferenzen, Meetups und Code Katas

(00:43:48) Engineering Management ist ein anderer Job als Software Entwicklung

Hosts

Wolfgang Gassler (https://mastodon.social/@woolf)
Andy Grunwald (https://twitter.com/andygrunwald)

Feedback

EngKiosk Community: https://engineeringkiosk.dev/joindiscord
Buy us a coffee: https://www.buymeacoffee.com/engineeringkiosk
Email: stehtisch@engineeringkiosk.dev
LinkedIn: https://www.linkedin.com/company/engineeringkiosk/
Mastodon: https://podcasts.social/@engkiosk
Twitter: https://twitter.com/EngKiosk

Transkript

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

Andy Grunwald (00:00:04 - 00:02:05)

Willkommen zu einer neuen Episode des Engineering Kiosk Podcasts. Heute tauchen wir tief in das Thema Engineering Management ein und beantworten die Frage, die viele von euch bewegt. Wie bleibt man als Engineering Manager nah am Code? Wir diskutieren, warum so viele Entwickler den Wunsch haben, auch in Management Positionen weiter zu coden und welche Herausforderungen und Lösungen es dabei gibt. Bleib dran, wenn du wissen möchtest, wie du als Manager weiterhin deine technische Leidenschaft ausleben kannst. Viel Spaß! gar nicht so lange her, da gab es zumindest im deutschen oder europäischen Raum sogar das Dilemma des Karrierepfades für Softwareentwicklerinnen und Softwareentwickler. Was meine ich damit? Du hast angefangen zu programmieren, Junior, warst ein paar Jahre im Job, wurdest gegebenenfalls befördert zum Mid-Level oder vielleicht gab es auch keine Beförderung und du hast dich einfach so genannt und irgendwann hast du dir gedacht, weißt du was, wenn ich drei Jahre Mid-Level war, dann kann ich auch auf LinkedIn schreiben, dass ich Senior Engineer bin. So, und dann hat sich oft die Frage gestellt, wie geht's denn weiter? Und die meisten haben dann gesagt, okay, der nächste Karriereschritt, ich muss ins Management. Das hat sich seit ein paar Jahren gedreht, denn aus der amerikanischen Techkultur kam dann ein zweiter Karrierepfad, und zwar der technische Karrierepfad. Und da haben wir auch schon öfters drüber gesprochen. Du gehst vom Senior, gehst du nicht ins Engineering Management, sondern Richtung Staff Level, Senior Staff, von mir aus auch Principal und so weiter und so fort. Dennoch, obwohl wir jetzt zwei Karrierepfade haben, einmal einen technischen und einmal nach dem Senior gehst du dann ins Management, ins People Management, ins Team Leadership Management, stellt sich immer wieder die Frage des klassischen Dilemmas. Leute, die zum Engineering Management wechseln, wollen die Aufgabe des Programmierens im Job nicht abgeben. Und somit haben wir, Wolfgang und ich, schon des Öfteren die Frage bekommen, wie kann ich denn in meinem Engineering Management Job weiter coden? Wie kann ich denn nah am Code bleiben? Wie kann ich denn technisch bleiben? Wolfgang, wie oft hast du diese Frage schon gehört?

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

Ich glaube, man müsste die Frage anders stellen, wie oft habe ich die Frage nicht gehört, wenn sich jemand irgendwie für die Management-Position interessiert hat. Also kann ich da irgendwie hands-on bleiben? Kann ich da noch weiterhin coden? Das sind so die größten Fragen, weil ich will ja nicht weg von der Technik eigentlich. Diese Fragen hat man ständig und immer und irgendwie habe ich die von jedermann und jeder Frau eigentlich bisher gehört.

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

Und ich frage mich immer, warum kommt diese Frage überhaupt auf? Denn jeder sagt ja ... Also, hallo.

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

Du bist der Erste, der den ganzen Tag irgendwie coden will und dann irgendwas rumschrauben will und eigentlich nur an dem Interesse hat. Also, du hast mir gerade vor der Episode erklärt, dass du auch noch irgendwie da deinen Home Assistant auf die Reihe bringen willst, irgendwie neue Proxmox installieren willst, da deinen NUC oder wie er auch immer heißt, Over-Engineering. Also, da warst du mir jetzt nicht zu erklären.

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

Das ist privat, Freizeit. Ich fahre auch ziemlich viel Fahrrad in der Freizeit, werde trotzdem nicht die Tour de France mitfahren. Also von daher, im Job ist es natürlich was anderes. Im Job installiere ich jetzt kein Proxmox und maintaine kein Home Assistant. Wäre aber auch mal eine coole Geschichte für einen Job eigentlich. Naja, aber ich stell mir halt immer die Frage, warum möchte denn immer jemand Hands-on bleiben? Denn es gibt ja auch diesen tollen Spruch, der Wechsel ins Engineering Management ist keine Beförderung, sondern es ist ein Jobwechsel. Denn Programmieren ist halt nicht mehr deine Priorität. Deine neue Priorität ist, du sollst Teams enablen und empoweren und denen eine Richtung zeigen und so weiter. Deswegen, warum stellt sich die Frage, weiter Hands-on zu bleiben? Was denkst du? Was wären zumindest die Gründe, die du bisher in deiner Karriere gehört hast?

Wolfi Gassler (00:03:40 - 00:04:51)

Naja, ist eigentlich relativ einfach zu beantworten und du hast es ja auch schon angeschnitten, dass wenn du jetzt auf Senior Level bist und da deine ganze Karriere eigentlich gecodet hast oder technisch warst und hast nochmal, keine Ahnung, fünf Jahre oder länger dich damit beschäftigt hast und jetzt sollst du das plötzlich alles unter Anfangszeichen wegwerfen oder zurücklassen, und einen kompletten neuen Job machen, wie du richtig sagst. Das ist ein Wechsel und keine Promotion. Und davor haben normalerweise extrem viele Leute Angst und berechtigterweise, weil es ist einfach zeitlich schwierig, da wirklich noch Hands-on zu bleiben. Also je nach Position natürlich. Wir hatten ja auch in Episode 85 die Isabelle Glasmacher zu Gast und die hat uns ja erklärt, sie macht sehr stark noch Hands-on und managt sogar noch ziemlich viele Leute. Also es geht natürlich schon, aber je nach Position ist es schon schwieriger und man lässt dann das natürlich in irgendeiner Form zurück, verliert womöglich den Anknüpfungspunkt zur Technik und viele Leute fragen sich dann glaube ich auch, kann ich überhaupt ein technisches Team, ein Team von EntwicklerInnen überhaupt in irgendeiner Form führen, leaden, wenn ich selber so weit weg bin von der ganzen Technik.

Andy Grunwald (00:04:52 - 00:05:00)

Aber wovor haben die Leute Angst? Also ist das wirklich der FOMO, seine wertvollen Skills, die man etliche Jahre zuvor aufgebaut hat, zu verlieren?

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

Ja, es ist das, was man halt gerne macht. Und das ist ja auch das größte Problem, was ich zumindest immer von den Leuten gehört habe. Jetzt, wenn ich weg bin von der Technik, die Technik ist das, was ich wirklich gut kann. Ich kann gut coden, ich kann Architektur bauen, ich kann was auf die Straße bringen. Und jetzt in meinem neuen Job soll ich irgendwie Leute führen. Das ist einfach was Neues. Und kann ich dann überhaupt die alten Dinge noch gebrauchen? kann ich dann nur mehr Sachen machen, die ich gar nicht mehr machen will, die, die ich fünf Jahre lang so geliebt habe, unter Anführungszeichen. Und daher kommt, glaube ich, die Angst, also einerseits einen neuen Job zu haben, neue Skills aufbauen zu müssen, die halt nicht technisch sind, und auf der anderen Seite eben diesen Kontakt zu verlieren zu dem, was man jahrelang gerne gemacht hat. Weil es ist ja selten der Fall, dass jetzt irgendwer extrem technisch gut ist und so gut Leadership Skills aufgebaut hat, dass er dann super gerne wechselt ins Management. Das ist ja eher seltener und meistens ist es ja schon so, dass die Leute sehen, okay, ich habe Möglichkeiten in Richtung Leadership, ich habe da Ich will es gar nicht Talent nennen, weil man kann das eigentlich alles lernen. Aber ich möchte in die Richtung gehen, weil ich da auch Möglichkeiten sehe für mich, mich weiterzuentwickeln. Aber trotzdem hat man halt davor 80 Prozent gecodet, würde ich mal sagen.

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

Und warum kennt dann jeder diesen Spruch? Es ist keine Beförderung, sondern ein Jobwechsel. Aber warum nimmt ihn niemand ernst?

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

Ich glaube, das ist auch nur auf deiner grünen Wiese, dass jeder diesen Spruch kennt. Und auch weil du gesagt hast, das ist ein altes Problem in Deutschland oder so. Also ich glaube, das ist gar kein altes Problem. Und auch im englischsprachigen Raum hat es sicher noch nicht so eine Durchdringung, dass das in allen Firmen irgendwie angekommen ist, dass es da die Leadership-Richtung geht und die technische Richtung gibt und die ganze Karrierepfade. Also so weit sind wir garantiert noch nicht und nur weil man Spruch kennt, heißt es noch lange nicht, dass man in die Tat umsetzen kann.

Andy Grunwald (00:06:54 - 00:07:15)

Das bringt mich aber zu einer nächsten Frage. Muss ein Manager, auch ein Engineering Manager, eigentlich technisch sein? Denn ich habe von meinem letzten Vorgesetzten einen guten Spruch gehört. Ein guter Manager kann auch eine domänenfremde Abteilung oder ein domänenfremdes Team leiten. Also ein Team, das etwas beackert, wo der Manager nicht viel Fachwissen hat. Würdest du dem zustimmen?

Wolfi Gassler (00:07:16 - 00:07:25)

Ich glaube, er kann das oder sie kann das grundsätzlich, aber ich bin mir nicht sicher, ob es die perfekte Konstellation ist und ob es nicht besser geht.

Andy Grunwald (00:07:25 - 00:07:26)

Das musst du mir erläutern.

Wolfi Gassler (00:07:26 - 00:09:14)

Weil es ist natürlich möglich, jetzt auch ohne technischen Background irgendwie ein technisches Team, glaube ich, zu führen, aber du hast natürlich schon den Teil, der da fehlt, diesen technischen Teil, das Verständnis unter Umständen, die Möglichkeit, mit dem Team in einer technischen Sprache zu sprechen, alle diese Dinge fehlen dir. Das heißt, auf der einen Seite, du kannst es kompensieren, indem du vielleicht andere Personen auch aufbaust zu einem gewissen Tech-Lead oder dir an die Seite nimmst, die Person, die dir hilft, um diese technische Lücke zu füllen. Oder dein Team ist natürlich so groß, dass du gar nicht so viel Kontakt hast. Das ist natürlich eine andere Sache. Aber ich glaube, du brauchst eine gewisse technische Komponente. Die kann für dich sein als Person, aber die kann auch einfach durch eine andere Person kompensiert werden. Aber ich glaube grundsätzlich, dass es besser ist, wenn der oder die Manager die technische Komponente mit sich trägt und dadurch einfach einen direkten Kontakt zum Team hat. Weil was ich schon gemerkt habe in M101 zum Beispiel oder wenn du auch neu in ein Team reinkommst, Du wirst einfach schneller akzeptiert, wenn du diese technische Sprache sprichst. Und wenn du einfach verstehen kannst, wenn jemand zu dir kommt, wenn eine Entwicklerin zu dir kommt und sagt, ich habe dieses Problem auf der technischen Seite mit den anderen Leuten, mit der Deployment Pipeline oder Also eher auf der organisatorischen Seite, wenn du sofort sagst, okay, verstehe, das sind die Probleme, kenne ich, technische Lösung XY, oder wenn du einfach in der Sprache sprechen kannst, du kennst, was ein Speicherproblem ist, du kennst das Problem, wenn jemand anderer in den Pull-Requests picky ist, in den Kommentaren, alle diese Dinge, wenn du die selber kennst und verstehst, dann glaube ich, dass du einen besseren Kontakt mit dem Team aufbauen kannst und besseres Leadership am Ende machen kannst.

Andy Grunwald (00:09:14 - 00:09:35)

Wenn ich dir zuhöre, habe ich das Gefühl, du vermischst so ein bisschen Management und Leadership. Ist das für dich das Gleiche? Ich sage nicht, dass ein Teamleiter oder eine Teamleiterin nicht beide Komponenten des Management und Leadership haben sollte, doch wenn ich dir zuhöre auf die Frage, kann eine gute Managerin auch ein domänenfremdes Team leiten, dann ich stimme dir zu, aber es ist halt ein Mix.

Wolfi Gassler (00:09:36 - 00:10:09)

Ja, es ist natürlich ein gewisser Mix und das habe ich auch gemeint. Wenn du die Leadership-Komponente rausziehst, die technische Leadership-Komponente, dann ist es natürlich möglich. Dann ist es eine andere Person und dann trennst du vielleicht das klassische Management, Projektmanagement. Wenn wir es einmal aufs Projektmanagement reduzieren und dann hast du auf der anderen Seite technisches Leadership, was dann wirklich auch um die Technik geht. Also das kannst du sehr wohl trennen. Meiner Meinung nach in einem kleinen Team, also ich spreche jetzt nicht von einer ganzen Abteilung, sondern wenn du jetzt, keine Ahnung, fünf Leute hast, glaube ich, dass es besser ist, wenn du das in einer Person vereint hast.

Andy Grunwald (00:10:09 - 00:11:24)

Man muss ja auch sagen, wenn wir mal auf diesen Satz weitergehen, dass in verschiedenen Firmen die Rolle des Teamleiters oder Teamleiterinnen, Engineeringmanagerinnen, Abteilungsleiterin etc. anders ausgelebt wird. In manchen Firmen ist das ein People Lead Only. In manchen Firmen sind Projektmanagement-Tätigkeiten im Engineering-Management vorhanden. In manchen Teams hast du einen Tech-Lead dabei, also eine technische Person, die auch sehr gut in der Kommunikation ist, aber dann keine People-Leadership. In manchen Teams hast du das nicht. manchmal hat die abteilungsleiterin oder die teamleiterin die technische verantwortlichkeit und die finale entscheidung also die die rolle wird ganz komisch definiert in ganz verschiedenen firmen deswegen ist es natürlich auch sehr sehr schwierig zu sagen okay inwieweit muss denn jemand technisch bleiben aber, Jetzt haben wir schon gesagt, okay, das wäre eine tolle Geschichte, wenn jemand technisch bleibt, also im Management ist und technisch bleibt. Doch jetzt spiele ich mal den Devils Advocate. Wenn ich technisch bin und ich leite ein Team, setze ich mich da nicht der Gefahr aus, dass ich ratzfatz zum Micromanager werde? Weil ich bin ja dein Vorgesetzter, Wolfgang. Und du nutzt jetzt Design Pattern X, aber ich mag Design Pattern Y mehr. Und Design Pattern Y ist viel besser und ich bin ja dein Vorgesetzter. Kannst du es bitte ändern? Oder ich mag deinen Variablenamen nicht.

Wolfi Gassler (00:11:24 - 00:12:48)

Da kommt es darauf an, wie weit du natürlich in dem Team drin bist und die Sachen kontrollierst. Also Micro-Management gibt es auf jeder Ebene und da brauchst du nicht mal technisch sein, um Micro zu managen. Also das ist jetzt, glaube ich, nicht wichtig, ob du technisch bist oder nicht. Das ist mehr dein Verhalten. Aber du hast natürlich vollkommen recht. Es ist, glaube ich, viel, viel schwieriger, wenn du aus der technischen Seite kommst, davor Senior warst, vielleicht im selben Team und plötzlich dann auf die Management-Ebene kommst und dann das irgendwie ablegen musst, dass du ständig in den Code reinschaust. sofern du jetzt nicht mehr so involviert bist. Also dieses heraustreten, dieses sich zurückhalten, das ist natürlich extrem schwierig. Aber das kann natürlich auch ein großer Vorteil sein. Du verstehst den Code, du kannst dich einbringen, wenn jetzt dein Team auf dich zukommt und Fragen hat, einen schwierigen Bug hat, dann kannst du vielleicht helfen. Du verstehst die Codebase, du kennst die Historie, du kennst allgemeine Architektur und kannst dort helfen, wenn du gefragt wirst. Also da hilft dir dann schon, wenn du technisch bist, bei Diskussionen, wenn es um die Architektur geht, wenn es um Produktplanung geht, in irgendwelchen Meetings, wo man priorisiert. Da hilft dir natürlich alles, wenn du verstehst, wie funktioniert die Codebase, wie ist die aufgebaut, Was gibt's dort? Das hilft dir natürlich mit den Einschätzungen extrem. Trotzdem kann es natürlich nicht die Voraussetzung sein, dass man immer aus dem Team kommt. Weil es kann immer sein, dass man von außen kommt und da muss es auch funktionieren.

Andy Grunwald (00:12:48 - 00:14:08)

Neben der Gefahr, ich sag mal, ins Micromanagement abzurutschen, hab ich aber auch schon andere Risiken in der Praxis gesehen. Und zwar hab ich beobachtet, wie Leute vom Senior Engineer ins Engineering Management gewechselt sind. Und diese Personen sind dann hands-on geblieben. Sie haben immer die spannendste Arbeit für sich beansprucht. hatten dann aber gar nicht mehr die fokuszeit diese arbeit umzusetzen und das ist natürlich dann natürlich auch eine recht schwierige situation denn da wurde dann oft ich sag mal die projekt wichtige arbeit zurückgehalten beziehungsweise wurde nicht richtig fertig oder wurde durch überstunden kompensiert was natürlich auch nicht die die lösung sein kann also man hat dann irgendwie durch seine hands-on fähigkeiten war man so eine kleine gatekeeper rolle Und damit schneidet man sich ja eigentlich doppelt irgendwie ins eigene Fleisch. Denn auf der einen Seite bist du jetzt verantwortlich, dass das Team das Projekt in Time, in Budget, in Quality, wie sagt man so schön, abliefert. Aber du hordest halt die wichtigste Arbeit, dass das überhaupt irgendwie machbar gemacht wird. Und das find ich dann halt auch immer sehr, sehr schade. Dieses, seine Legos abzugeben, sagt man ja immer, ne? Sein Lieblingsspielzeug abzugeben. Das natürlich fällt ziemlich vielen Leuten sehr schwer. Also das ist natürlich auch ein Risiko, umso mehr technisch man ist beziehungsweise bleibt, wo man ganz stark aufpassen muss.

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

Die Frage ist ja, die ich mir dann aber immer stelle, jetzt soll man technisch bleiben, um den Kontakt aufrechtzuerhalten, um in irgendeiner Form bei Diskussionen weiterhin beteiligt zu sein, die Credibility aufrechtzuerhalten mit dem Team, dass man gefragt wird. Das heißt, man soll technisch bleiben, aber jetzt sagst du, man soll möglichst weg vom Code und da eben keine Gatekeeperrolle sein und möglichst wenig involviert sein. Und da stellt sich natürlich für mich die Frage, wie kannst du trotzdem technisch bleiben in deiner Rolle, um die Credibility aufrechtzuerhalten, aber eben kein Gatekeeper zu sein?

Andy Grunwald (00:14:41 - 00:16:25)

Supergute Frage. Und ich denke, da gibt's etliche mögliche Lösungen, die sich auch sehr, sehr gut im, ich sag mal, Leben einer Managementperson irgendwie vereinbaren lassen. Auf der einen Seite fällt mir da halt ein, okay, mach einfach mal ein bisschen Pair-Programming mit. Also, setz dich am besten so dazu, dass vielleicht ein Pair-Programming zum Mob-Programming wird. Zwei Leute programmieren etwas. Der eine ist der Driver, der andere ist der Pilot und der Navigator beziehungsweise der Observer. Und du setzt dich einfach daneben und schaust den einfach vielleicht mal über die Schulter. Das Problem ist, kann natürlich auch ein bisschen schräg rüberkommen. Mein Chef oder meine Chefin kontrolliert, was wir hier machen. Aber wenn man das ganz einfach explizit sagt, hey, ich will einfach nur mal ein bisschen gucken, wie ihr so arbeitet, um ein besseres Verständnis dafür zu kriegen, ist das kein Problem. Eine andere Geschichte ist natürlich auch, schau dir einfach mal Code Reviews an. Und hier ist ganz, ganz wichtig, mach keine normalen Code Reviews. Also ich bin ein Fan von sogenannten Meta-Code-Reviews. Was sind Meta-Code-Reviews? Meta-Code-Reviews mach ich, wenn der Pull-Request oder Merge-Request einfach schon gemerged wurde. Weil dann ist nämlich dieses ganze Ping-Pong nämlich vorbei. Also ich mach keine Code-Reviews, ich spring da nicht rein und sag, hey, mach das mal, mach das mal, mach das anders, weil das führt immer während eines Pull-Requests immer zu so einem Ping-Pong und reißt mich aus dem Fokus raus. Aber Meta-Code-Reviews, Da kann ich Konflikte zwischen Kollegen frühzeitig aufdecken und die signalisieren mir auch so ein bisschen die Dynamik innerhalb des Teams. Auf der einen Seite zum Guten, auf der anderen Seite zum Schlechten. Weil wenn du immer mal wieder Metacode-Reviews machst und schaust, okay, wer gerät da eigentlich wirklich aneinander, diese Informationen kannst du natürlich dann später auch irgendwie in One-on-Ones nutzen oder in den Team-Meetings oder Ähnliches. Aber du liest auch ein bisschen den Quellcode, skimmst den so ein bisschen drüber, aber lässt die technische Verantwortlichkeit eigentlich deinem Team.

Wolfi Gassler (00:16:26 - 00:17:38)

Ich glaube, das ist ein sehr wichtiger Punkt, wenn es ganz allgemein um Leadership und Management geht, dass du auch vieles im Hintergrund machst. Normal, wir haben das ja auch schon oft besprochen, sollst du zeigen, was du alles Cooles gemacht hast. Und diese Aktionen, so wie deine Meta-Reviews, oder ich mache das auch oft gern, wenn ich zum Beispiel Leuten irgendeine Empfehlung gebe oder eine Aufgabenstellung gebe, dass sie doch in Richtung XY wandern sollen oder diese Person fragen sollen, dann kenne ich oft die Antwort schon oder hab die im Hintergrund vielleicht schon abgeklärt für mich und hab das aber trotzdem nicht gezeigt, damit die Person das vielleicht lernen kann und ich bosaun das nicht groß heraus, ich hab da jetzt irgendwelchen Code reviewed, ich hab da jetzt im Hintergrund irgendwas gecheckt. Also es gibt gewisse Dinge, die muss man meiner Meinung nach zurückhalten und die machen dann aber die Qualität aus und im richtigen Moment kann man dann die Information nutzen, in einer Diskussion zum Beispiel, dass man eben den Code gelesen hat Aber man muss da aufpassen, dass man eben nicht alles ins Brack-Document schreibt, was man nicht alles Tolles gemacht hat im Hintergrund. Ich glaube, da muss man auch lernen, dass man Zeit investiert, obwohl man das in der Öffentlichkeit im Brack-Document vielleicht nicht groß announced.

Andy Grunwald (00:17:38 - 00:18:01)

Wichtiger Punkt, was du da ansprichst, und da möchte ich mal ganz kurz klassifizieren in das, was man macht, ich bin busy, versus das, was dein Outcome ist. Nämlich, du hast mit einer Person zusammengearbeitet, die dann weiterhin befördert wurde. Das, die Beförderung, dass du mit dieser Person zusammengearbeitet hast, kannst du in ein Brack-Document schreiben. Jede einzelne Schritte, die dazu geführt haben, ja, weiß ich jetzt nicht, ob ich die jetzt da reinschreiben würde.

Wolfi Gassler (00:18:01 - 00:18:20)

Aber ich würde es jetzt auch nicht zum Beispiel dann gegenüber den Personen, die den PR gemacht haben, da jetzt groß erwähnen, ich habe jetzt deinen PR da angeschaut und da gesehen, du hast XY nicht gemacht. Vielleicht kann man es lobend erwähnen, wenn es irgendwie ein cooler PR war, aber sonst würde ich mich da zurückhalten, mit alles in irgendeiner Form erwähnen, auch den Personen gegenüber.

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

Das kommt halt sehr schnell rüber, als würdest du alles kontrollieren.

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

Und dann wieder micromanagen.

Andy Grunwald (00:18:25 - 00:19:42)

Genau. Eine andere Thematik, die man auch machen kann, und jetzt ist das eine sehr unpopuläre Meinung, du kannst Dokumentation schreiben. Denn das ist irgendwie oft eine vernachlässigte Aktivität. Jeder sagt, müssten wir mal machen. Ja, oder vielleicht haben wir einen Projektdruck mit der Deadline. Und deswegen, nimm dir doch einfach mal irgendwie ein Design-Dokument von einem System, was gebaut wurde, und dokumentier das doch einfach mal. Oder aktualisier einfach technische Dokumentation. Somit bleibst du auf der einen Seite technisch, weil du die Architektur verstehst, auf der anderen Seite kontributierst du aber auch zu deinem Team und zu der Firma, indem du mit Dokumentation andere Leute enablest. Da ist jetzt natürlich der Knackpunkt, bin ich als Manager denn jetzt der neue Techniker-Writer? Und... Das kann natürlich ganz schnell dahingehend ausarten, dass du jetzt einfach immer dokumentierst und das ganze Team sich auf dich verlässt. Da muss man natürlich ganz klar ein bisschen drauf aufpassen mit dem Knackpunkt, okay, ich gehe zwar mit einem Beispiel voran, aber dass diese neue Praxis dann auch im Team etabliert wird und dass du dann einfach mal über die nächsten paar Teammeetings fragst, hey, liest dir die Dokumentation oder vielleicht baust du irgendwie so eine Art Google Analytics in, Deine Dokumentation ein, einfach um zu gucken, okay, wird die überhaupt aufgerufen und Co., damit du das einfach mal als Standard-Practice irgendwie ins Team etablierst und du nicht der neue Bottleneck zur Dokumentation bist.

Wolfi Gassler (00:19:43 - 00:21:54)

Man kann da ja auch einen Vorteil ausspielen, dass man ja üblicherweise eher in Architektur- und Designentscheidungen und Diskussionen eingebunden war und dementsprechend halt auch einen guten Überblick hat, vielleicht sogar aus dem Team heraus. Also es kommt dann natürlich darauf an, ob du jetzt einen Tech-Lead im Team hast, der das vielleicht machen sollte und eigentlich ist es dem seine Aufgabe. Also oder ein Technical Writer oder Writerin. Das ist natürlich schwierig dann, wenn man denen die Aufgaben wegnimmt. Aber ich gehe mal davon aus, dass nicht jedes Team das hat. Und dann ist das natürlich schon eine gute Möglichkeit. Oder man arbeitet mit dem Tech Lead dann zusammen und macht Reviews auf den Architektur- und Designdokumenten. Also solche Möglichkeiten gibt es schon. Und das ist, glaube ich, ganz allgemein einer der wichtigsten Punkte, in diesen Diskussionen und Designentscheidungen einfach involviert zu bleiben. Natürlich, wenn man jetzt Abteilungsleiter ist, ist das schwieriger, ist man auf einem anderen Level. Aber grundsätzlich, wenn du ein Lead bist, dann solltest du in diesen Entscheidungen zumindest anwesend sein. Wenn du gute Tech-Leads hast, können die das ja unter sich ausmachen, aber du solltest im Meeting dann wenigstens anwesend sein, um gewisse Sichten von außen mit reinzubringen in die Diskussion oder einfach nur zuzuhören und um zu verstehen, wie das mit der Technik ist, weil du bist dann in anderen Meetings wieder verantwortlich und musst es verstehen, wenn es darum geht, schnelle Entscheidungen zu machen. Wie wird mit anderen Teams zusammengearbeitet? Welche APIs braucht man oder solche Dinge? Dazu brauchst du das Wissen einfach. Und dann kannst du eben technisch bleiben, weil man muss nicht jede Zeile selber geschrieben haben, um technisch zu bleiben. Und das habe ich eigentlich in meiner Karriere ganz viel erlebt, dass man in Diskussionen und Gesprächen mit anderen Leuten Technologie super verstehen kann, ohne dass man sie selber verwendet hat. Natürlich ist es besser, wenn man sie selber verwendet, Aber ganz viele Dinge laufen auf einem High-Level ab und wenn man da die richtigen Fragen stellt und einen gewissen Background hat, dann brauche ich nicht selber in Kafka implementiert haben, wie da Messages gehandhabt werden, sondern da kann ich bei High-Level Fragen stellen und verstehe dann, ob das irgendeine, keine Ahnung, als Beispiel Delivery-Once-Garantie hat. Da muss ich das nicht selber einmal ausprobiert haben, sondern da reicht mir die Information, um das sofort einordnen zu können.

Andy Grunwald (00:21:54 - 00:22:01)

Und in der Regel ist dieses High-Level-Wissen auch ausreichend. Also da stimme ich dem Wolfgang leider mal zu in der Richtung.

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

Ich meine, es ist schon praktisch, wenn man das selber auch mal angewandt hat, da lernt man schon mehr. Also ich kann mich damals erinnern, wie Docker so aufgekommen ist. Das hat mir natürlich schon was gebracht, das selber auch mal auszuprobieren, als das nur auf High-Level zu verstehen. Also es gibt natürlich schon Unterschiede, aber ich glaube, für die meisten Diskussionen und Entscheidungen, wenn du ein gewisses technisches Wissen schon hast, sind ja die High-Level-Informationen durchaus ausreichend, um Entscheidungen zu treffen. Und das ist ja eigentlich das Wichtigste, was man machen muss. Oder böse Gegenfragen stellen. Dumme Fragen stellen. Und das kann man eigentlich auch ohne Wissen.

Andy Grunwald (00:22:38 - 00:23:51)

Und bei dummen Fragen stellen fällt mir noch eine Praxis ein, die du auch als Managerin oftmal machen kannst. Und zwar ist es dieses Rubber Duck Development. Du spielst einfach die Gummiente mit einem Teammitglied zu dir. Und zwar bist du die Gummiente. Du hörst einfach zu, stellst einfach Fragen, versuchst ein Verständnis aufzubauen. Das spielt ja nämlich sehr, sehr gut als Managerin in die Karten. Denn Engineering Manager haben beziehungsweise bauen Erfahrung über Zeit auf im Bereich von Coaching. Du musst ja deine Mitarbeiter weiterentwickeln. Und wenn du jetzt die Gummiente mit einem technischen Mitglied deines Teams bist, dann hilfst du eigentlich durch kontinuierliches Fragestellen diesem Teammitglied die Kommunikation zu verbessern. Weil gute Kommunikation ist unter anderem komplexe Dinge einfach beschreibbar. Und somit kannst du als Managerin natürlich auch dein Detailwissen irgendwie ein bisschen stärken. Und es ist mehr oder weniger so eine Coaching-Session. Aber was mir in der Praxis schon ganz oft passiert ist, wenn ich mich irgendwo im Büro, ja, remote sieht das vielleicht ein bisschen anders aus, im Büro zu jemandem gesetzt habe, hab einfach mal versucht, ein paar Details zu verstehen. Keine 15 Minuten später saßen da vier Leute drumherum und haben einfach zugehört, also aus dem eigenen Team, weil die diese Details auch verstehen wollten. Fand ich eine ganz interessante Team-Dynamik auf jeden Fall.

Wolfi Gassler (00:23:51 - 00:24:36)

Du kannst die Rubberduck-Ente, aber die gelbe Ente auch umdrehen. Und das, was du jetzt beschrieben hast, ist, du bist die Rubberduck, die immer dumme Fragen stellt. Aber du kannst es ja auch ins Mentoring umdrehen. Wenn du jetzt zum Beispiel jemanden neuen bekommst beim Onboarding, dann ist diese Person die Rubberduck. Und die neue Person stellt die dummen Fragen. Und du musst dann erklären. Du musst die komplexen Dinge erklären. Und die neue Person kann die dummen Fragen stellen. und ist die Rubber Duck. Also es geht in beide Richtungen, aber im Endeffekt, was du auch richtig gesagt hast, Andi, ist, dass die Kommunikation verbessert wird, egal in welche Richtung und ob du jetzt ganz Junior-Leute hast oder auf höherer Ebene, auf irgendeinem technischen Diskussionsentscheidungslevel bist und mit irgendeinem Tech Lead diskutierst.

Andy Grunwald (00:24:36 - 00:26:27)

Das tolle ist, wenn du das erklärst, dann hast du auch wirklich so einen Gegentest, ob du es wirklich verstanden hast, weil du kannst es ja nur lehren, wenn du es wirklich verstanden hast, da zwingst du dich halt selbst auch ein bisschen wieder tiefer einzusteigen. Apropos tiefer einsteigen. Bei meinem letzten Job zum Beispiel bin ich direkt als Engineering Manager eingestiegen. Das bedeutet, ich war an dieser Codebase nie hands-on. Was ich damals gemacht habe, ist, ich habe halt nicht nur das Manager-Onboarding mitgemacht, aber zeitgleich auch das Software-Engineering-Onboarding. Und das hat mir einen ziemlich guten Überblick über die Architektur gegeben, welche Probleme man hat und so weiter und wie komplex es eigentlich ist, ein lokales Dev-Environment aufzusitzen. Und ich habe mal sogar gelesen, dass es bei großen Firmen wie Facebook und Google halt eigentlich sogar Pflicht ist, dass Engineering Manager die ersten sechs Monate als Individual Contributor, als Software Engineer arbeiten, denn die sagen, dass ein Blast Radius eines schlechten Engineering Managers höher ist als der Blast Radius eines schlechten Individual Contributors. Ob das jetzt wirklich so wahr ist, dass die Leute dann für die Probezeit den Manager als Individual Contributor arbeiten lassen und dann sagen, ah, das funktioniert so nicht und den dann feuern, sei dahingestellt. Ich finde es aber auf jeden Fall einen interessanten Ansatz. Zumindest ist das Software Engineering Onboarding mitzumachen und dann ebenfalls ein oder zwei Monate als Individual Contributor zu arbeiten, damit man halt wirklich mal versteht, wie die Person arbeitet, die man da managt. Und wenn du natürlich an dieser Codebase, an der du jetzt nicht mehr arbeiten solltest, mal gearbeitet hast, dann kannst du natürlich auch hier und da mal On-Call gehen. Ich kenne einige Manager, die ab und zu mal eine ganze On-Call-Shift machen. Ist eine sehr unpopuläre Meinung, stimme ich zu. Verbessert aber 100% das Verständnis für den On-Call und Operational Workload für dein Team. Und ich sage dir, gegebenenfalls wirst du nach einer schlechten On-Call-Shift einige Sachen im Team ändern.

Wolfi Gassler (00:26:27 - 00:26:40)

So, das war jetzt ein schöner persönlicher Angriff, weil ich kann mich erinnern, damals wie ich zu Trivago gekommen bin, habe ich keine Zeile Code natürlich jemals implementiert dort. Heißt das, ich war ein schlechter Manager, Andi, willst du das jetzt sagen?

Andy Grunwald (00:26:40 - 00:26:50)

Ich hatte das Glück, ich habe noch nie zu dir reported, deswegen kann ich da nichts drüber sagen, tut mir leid. Ich sage nicht, dass ich empfehle, dass jeder On-Call geht. Ich sage nur, es ist eine mögliche Art, technisch zu bleiben.

Wolfi Gassler (00:26:50 - 00:27:16)

Also ich muss dazu sagen, es hat dann ja immer Tech-Leads gegeben in meinen Teams, die das übernommen haben und die mir vielleicht so ein bisschen auf der Seite was abgenommen haben. Trotzdem, in den Diskussionen lernt man natürlich extrem viel und ich glaube, dass mir da eigentlich zumindestens gefühlt, Ich hatte natürlich keine andere Welt, wo ich das testen hätte können, aber mir hat eigentlich der Einblick in den Code in dem Sinne nicht gefehlt.

Andy Grunwald (00:27:16 - 00:30:09)

Ich möchte nicht widersprechen mit dem, was du gesagt hast, denn du hast nicht Unrecht. Es ist jedoch ein ganz anderer Motivator für dich als Teamleiter, Sachen zu ändern, wenn du den Schmerz selbst gefühlt hast. Wenn du selbst, nehmen wir mal das On-Call-Beispiel, in der Nacht dreimal rausgeklingelt wurdest, glaub mal, auf einmal, ist die Reliability von deinem System doch top-prio. Und auf einmal gehst du in Konflikt mit dem Produktmanager aus dem anderen Team, warum das Feature jetzt nicht rechtzeitig fertig wird, weil du musst die mentale Gesundheit deines Teams erst mal stärken oder zurückholen, damit die nicht jede Nacht rausgeklingelt werden. Deswegen, wenn du hörst, dass einer deiner Teammitglieder dreimal die Nacht rausgeklingelt wurde, du nimmst das an, du versuchst der Person noch was Gutes zu tun, bleib einfach den Vormittag zu Hause, schlaf aus und so weiter. Es ist aber nicht das gleiche, wenn du den Schmerz wirklich gefühlt hast. Und ich denke, das bringt dann eine andere Motivation an den Tisch. Also, siehst du dich jetzt als schlechter Manager? Side-Note, in meinem aktuellen Job bin ich auch nicht on-call, nur für als Incident-Manager. Also, ich behebe selbst keine Production-Bugs. Okay, aber wenn du jetzt diesen Podcast hörst und denkst, ja, das sind ja alles immer schöne, nette Sachen, aber ich krieg's einfach nicht unter, dann hier noch mal zwei kleine Tipps, die man auf jeden Fall machen kann. Und zwar nennen wir das, bleib mal in der Nähe da, wo die Arbeit stattfindet. Und zwar sieh einfach mal zu, dass du hier ein lokales Development-Setup aufgesetzt hast. Dass du wenigstens die Logs und die Monitoring-Dashboards ansehen kannst. Vielleicht habt ihr irgendwie ein Kundensystem, wo Kunden Support-Tickets erstellen. Oder fang einfach an, ganz kleine Sachen zu automatisieren. Ich habe in meinem aktuellen Job eine Sache automatisiert, und zwar nutzen wir Ops-Genie für Rufbereitschaft und andere Art von Rotationen, die gemacht werden müssen, wie zum Beispiel Incident Commander und so weiter. Und manchmal haben Leute Urlaub, das bedeutet, ich hab ein kleines Skript geschrieben, was eigentlich mit unserem HR-System connectet, mit Ops-Genie connectet, und dann einfach matcht, okay, wer hat denn wann Urlaub, und wer ist denn wann, ich sag mal, in einer Rotation drin, und diese Person wird dann frühzeitig via Slack gepinkt, Und gesagt, hey, du hast an diesem Tag Urlaub, aber an diesem Tag bist du in dieser Rufbereitschaftsrotation als aktiv gemeldet. Schau doch mal, dass du da vielleicht irgendwie einen Ersatz findest. Das sind so ganz kleine Geschichten, die du auf jeden Fall machen kannst. Oder, weil du hast ja jetzt ein Dev-Setup, Organisiere doch einfach mal einen kleinen Hackathon oder eine sogenannte Fix-It-Week oder eine Woche, wo ihr Technical Debt irgendwie aufräumt und macht doch da einfach mal mit. Bevorzugt natürlich mit Low-Priority-Tasks, aber in dieser Woche wird dann gegebenenfalls nicht viel Manager- und Leadership-Aufgaben von dir erwartet, sondern du setzt dich einfach mit deinem Team dahin und hackst mal eine Runde. Und hol dir dann mal schön kritisches Feedback auf die Pull-Requests von deinen Teammitgliedern, denn ich glaube, die werden dann auch mal Spaß haben, dich im PR auseinanderzunehmen.

Wolfi Gassler (00:30:09 - 00:31:04)

Wichtig ist dabei einfach, was du gesagt hast, Low-Priority-Tasks. Also kein Gatekeeper, kein Blocker werden. Das ist meiner Meinung nach das Wichtigste und man nimmt dann irgendeinen Task und liefert da nie ein Ergebnis ab. Das ist das Schlimmste, was man eigentlich machen kann. Dann kann man es gleich lassen. Also darum am besten immer eher mit den Leuten zusammenzuarbeiten und unterstützend in irgendeiner Form sein oder eben mit einem Hackathon, der zeitlich abgeschlossen ist. Aber ich habe das schon öfters erlebt, wenn dann Tasks irgendwo hängen, Und da muss man dann vielleicht auch als Manager einschreiten, wenn da irgendwo Tasks hängen bei irgendeinem Lead oder bei einem Tech-Lead und der zeitlich einfach nicht mehr dazukommt, dann muss man das einfach verschieben und dann muss das klar sein, dass das andere Leute machen, weil sonst blockiert man da wirklich ganze Releases, ganze Features und es geht im Endeffekt nichts weiter, weil du als Manager oder ein Tech-Lead oder wer auch immer dann auf dem Task oben sitzt.

Andy Grunwald (00:31:04 - 00:31:21)

Jetzt kann es natürlich auch so sein, dass deine Firma oder dein Unternehmen nicht das Setup bietet, wo du dir ein bisschen Zeit rausnehmen kannst. Wenn das so ist, bitte kämpfe für deine eigene Zeit, dass du wenigstens ein paar Stunden pro Woche Zeit für dich hast zum Lernen, denn davon hat die Firma natürlich auch was.

Wolfi Gassler (00:31:21 - 00:32:00)

Wobei das ja jetzt alles, was wir jetzt erwähnt haben, natürlich auch lernen ist, weil in der Diskussion und im Codeschreiben und was es auch immer ist, lernt man natürlich auch. Wenn du Designdokumente schreibst, RFCs, da lernt man natürlich. Also das ist alles Lernzeit. Und ich glaube auch, dass man, sobald man in die Managementrichtung kommt, viel, viel mehr Zeit ins Lernen eigentlich investieren muss und wirklich reservieren muss, wie du richtig sagst, Andi. Also man muss sich die Zeit nehmen als IC. Da ist man am Coden, da lernt man sowieso. Das ist irgendwie inhärent da. Das ist viel mehr akzeptiert. Und auf der Managementseite muss man sich die Zeit wirklich nehmen und reservieren und darauf pochen, dass man die auch weiterhin hat.

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

Und jetzt kommt dein Vorgesetzter, Wolfgang, und sagt, weißt du was, dann lern, kannst du in der Freizeit machen. Wie ist dann deine Antwort?

Wolfi Gassler (00:32:08 - 00:33:34)

Naja, ich würde ihm die Kündigung natürlich hinwerfen als erstes Mal, aber trotzdem in meiner Freizeit lernen, weil es stimmt natürlich schon, es ist natürlich Bullshit, wenn man das Lernen auf die Freizeit ausschließlich verschiebt und das von vorgesetzter Seite da mitbekommt, aber der Punkt ist natürlich, komplett richtig. In der Freizeit kann man lernen, wenn man will. Und ich persönlich habe viel gelernt in meiner Freizeit einfach mit Side-Projects. Und ich mache gerne Side-Projects, aber erfahrungsgemäß machen ganz viele Leute Side-Projects und haben Spaß daran. Und das ist natürlich ein super Punkt, eine super Quelle, um zu lernen, neue Technologien auszuprobieren, um das dann wirklich auch in der Arbeitszeit wieder zu verwenden. Ich habe schon erwähnt, damals wie Docker aufgekommen ist, Ich habe extrem viel mit Docker herumgespielt, habe das in meinem Side-Project eingesetzt, wirklich in einem produktiven Side-Project, habe dort lernen können und habe dann in den Diskussionen in der Firma mit Wissen auftreten können. Und ich habe teilweise sogar mit Entwicklern dann irgendwelche Parameter gewusst oder Empfehlungen machen können, hey, probier mal den Parameter aus. Und das ist natürlich super für die Credibility, wenn du als Manager plötzlich da irgendwelche Parameter auf unterster Ebene weißt. Also es ist kein Zwang, dass man das immer wissen muss, aber wenn man in gewissen Bereichen einfach ein Wissen hat und das auch einbringen kann, dann wird das extrem wertgeschätzt und das hilft dir natürlich im Alltag beim Leaden, beim Managen von einem Team.

Andy Grunwald (00:33:34 - 00:34:19)

Wenn ich jetzt dem Wolfgang so zuhöre, hört sich das so an, als müsstest du das machen, weil sonst wirst du nämlich im täglichen Job abgehängt. Aber ich möchte nur mal eine ganz kurze Sache sagen. Wenn du die Zeit hast, in deiner Freizeit zu lernen und auch die intrinsische Motivation und auch noch die Energie, tu das, bitte. Wenn du diesen Podcast hier in deiner Freizeit hörst, ist es ja auch mehr oder weniger eine Art von kontinuierlichem Lernen. Es ist aber auch so, Arbeit ist Arbeit, Freizeit ist Freizeit und meine Lieblingsdefinition von Arbeit ist Austausch, von zeit gegenüber geld und fähigkeiten und du hilfst natürlich jemandem anders seinen traum zu verwirklichen das bedeutet du musst dich jetzt nicht kontinuierlich mit arbeitsthemen in deiner freizeit beschäftigen nur auf der arbeit dann irgendwelche docker parameter mit einem team durchzukauen wie der wolfgang sagt ja also es ist ihr habt.

Wolfi Gassler (00:34:19 - 00:35:36)

Es ja nicht auswendig gelernt muss man dazu sagen es war ja wirklich hatte spaß und habe dadurch dann dieses Detailwissen gehabt. Aber du kannst dir natürlich im Idealfall, wenn du die Zeit investieren willst, mal ein Video anschauen, einen Online-Kurs machen, eben YouTube-Videos anschauen, Podcasts hören, Newsletter lesen. Das machen wir wahrscheinlich eh alle. Und ich persönlich finde es jetzt auch irgendwie ein bisschen spießig, jetzt zu sagen, hey, lieber Arbeitgeber, Ich lese da auch drei Newsletter am Tag und diese 15 Minuten müssen noch Arbeitszeit sein. Wenn man auf so einem Level diskutiert, glaube ich, ist sowieso der falsche Arbeitgeber und vielleicht das Arbeitnehmer. Keine Ahnung, ob man da das beste Verhältnis hat. Arbeitszeit wird ja heutzutage eh nicht mehr so hart getrackt, hoffentlich in der IT-Welt. Dass ich in meiner Arbeitszeit dann noch mal ein paar Stunden für lernen habe, ist, glaube ich, ganz, ganz wichtig. Aber ob ich das jetzt da, diese 15 Minuten noch in der Arbeitszeit drin sind oder nicht, glaube ich, sollte heutzutage hoffentlich bei den meisten Jobs kein Problem mehr sein und einfach in der flexiblen Arbeitszeit in irgendeiner Form erfasst sein. Ob das jetzt am Abend stattfindet oder im Bett oder vorm Schlafen gehen oder Auch einfach mal am Nachmittag, wenn ich keine Lust habe, irgendwas zu programmieren oder zu coden oder zu managen, dass ich dann ein YouTube-Video anschaue, sollte alles drin sein.

Andy Grunwald (00:35:36 - 00:36:16)

Bei sowas ist natürlich schon wichtig, dass ihr wisst, wie ihr am besten lernt. Seid ihr irgendwie Leute, die sehr gerne lesen oder Audio hören oder Videokurse anguckt? Je nachdem, was ihr da habt. Die Firma bietet bestimmt auch noch mal LinkedIn-Learning, Udemy oder Coursera an. Auf YouTube kannst du inzwischen alles lernen. Wir bieten für Tech-Podcasts eine deutsche Tech-Podcast-Liste an, wo, glaube ich, über 80 deutschsprachige Technologie-Podcasts sind. Verlinken wir natürlich auch in den Show Notes. Dann gibt's, wenn du liest, viele Firmen kaufen sich die O'Reilly-Library. Gib dem Pragmatic Engineer Newsletter, Hacker News. Es gibt so viel, was du irgendwie machen kannst, was du, ich sag mal, ja, um deinen Skill-Level ein bisschen hochzuhalten.

Wolfi Gassler (00:36:17 - 00:36:43)

Ich habe mich gerade vor ein paar Tagen bei unserem Meetup in Innsbruck geoutet und gesagt, ich lese keinen Hacker-News regelmäßig. Und die drei Leute, mit denen ich da gerade gesprochen habe, sind fast in Ohnmacht geflogen und haben mich gefragt, woher bekommst du denn sonst deine Informationen? Wie machst du das? Also scheinbar ist Hackernews schon eine wichtige Quelle, ja. Aber ich bin nur hin und wieder auf Hackernews, nie regelmäßig. So wie der Andi, der das Tag und Nacht durchscrollt.

Andy Grunwald (00:36:43 - 00:37:06)

Es hat auch abgenommen, bin ich auch ehrlich, weil manche Dinge kommen auch auf Hackernews wieder. Und Hackernews hat einfach auch so eine hohe Geschwindigkeit, du kannst da gar nicht mithalten, bin ich ehrlich. Dieses FOMO, Fear of Missing Out, ja, das muss man, man muss einfach lernen damit umzugehen. Was ihr natürlich aber auch machen könnt, ist Networking und Community Events oder Engagement, also geht einfach mal auf Tech Meetups, Konferenzen.

Wolfi Gassler (00:37:06 - 00:37:09)

Und lasst euch sagen, dass Hackernials das Wichtigste ist.

Andy Grunwald (00:37:09 - 00:39:43)

Ja gut, da bist du vielleicht von der einen Bubble in die andere Bubble gefallen. Aber sowas gibt es immer. Oft habt ihr auch so ein Learning Budget zu Hause. Zu Hause, in der Firma natürlich, wo ihr dann auf Konferenzen geht. Und wenn die Konferenzen sogar noch was mit Data Streaming zu tun haben, ist das sogar noch hoch industrierelevant. Kann also auch eure Firma nach vorne bringen. Eine Sache, die ich immer ganz interessant finde, ist kleine Coding-Aufgaben. Denn wenn man jetzt sich zu Hause hinsetzt oder man macht sich ein schönes Weinchen auf und denkt, jetzt code ich mal ein bisschen. Dann ist die erste Frage, woran code ich denn? Viele Leute wollen dann irgendwie zu Open Source Contribute und wissen dann aber nicht, wo sie starten und dann ist die Einstiegsbarriere so hoch. Deswegen finde ich immer so Übungen wie Code Cutters oder Lead Code Probleme immer ganz interessant. Das sind so kleine Coding-Übungen, um, ich sag mal, scharf zu bleiben oder um eine neue Sprache zu lernen. Du kriegst halt einfach eine kleine Aufgabe. Und die musst du dann umsetzen. Und eine Thematik ist ein Event, was jeden Dezember stattfindet, nennt sich Advent of Code. Jeden Tag im Dezember gibt es dort ein neues algorithmisches Problem. Und ich sage euch, der erste Dezember ist immer einfach, der zweite geht auch noch, der dritte auch noch. Ja, und dann rattert mein Hirn schon, weil die Dinger werden einfach mit dem Verlauf des Dezembers einfach immer, immer schwieriger. Oder, wenn du aus dem Infrastruktur- und Admin- und Zeit-Reliability-Engineering-Bereich kommst, gibt's was Neues, was bei uns in der Discord-Community genannt wurde. Kannte ich selbst noch nicht, sadservers.com. Supergeile Webseite. Du klickst einfach, gib mir mal das Environment, und dann kriegst du eine kleine Aufgabe, und dann hast du so 10, 20, 30 Minuten Zeit, um den Server zu debuggen. Die erste Aufgabe ist schon eine ganz schöne Geschichte. Du hast irgendwo ein Log-File und irgendein Prozess schreibt kontinuierlich eine Zeile in das Log-File und deine Aufgabe ist es, diesen Prozess zu killen. Das fängt also an, wie findest du denn diesen Prozess, wer auf diese Datei zugreift und so weiter. Super interessant. Also ich hatte sehr viel Spaß. Irgendwie habe ich mich da irgendwie zwei, drei Stunden in diesen Übungen verloren. Auch super interessant, falls du noch nichts mit Infrastruktur zu tun hast, einfach mal ein bisschen Linux zu lernen. Du kannst dann auch immer was fragen. Hey, gib mir mal einen Hint oder so. Also diese Codecutters, kleine isolierte Übungen, einfach nur mal ein bisschen, ja ich sag mal, die Finger warm zu halten oder vielleicht, wenn ihr mal Rust oder Go oder PHP oder JavaScript oder TypeScript oder ähnliches lernen wollt, dann bietet sich sowas natürlich auch an. So, jetzt quatschen wir die ganze Zeit darüber. Ich bin Manager von vier Leuten. Ich habe noch ein bisschen Zeit, mich technisch zu engagieren, vielleicht sogar Hands-on. Aber der Wolfgang hat schon öfter mal in diesem Podcast gesagt, dass er zu Hochzeiten, ich glaube, 15 Leute geleitet hat.

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

25 oder sowas.

Andy Grunwald (00:39:46 - 00:40:00)

Da prallt er sogar. Verstehst du, der Wolfgang war noch wichtiger, als ich gedacht habe. Er hatte nicht 15, sondern 25. Wolfgang, machen wir uns mal nichts vor. Mit 25 Direct Reports, da machst du doch von diesen Sachen, die wir gerade empfohlen haben, gar nichts mehr, oder? Wie?

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

Du genehmigst Urlaub. Das ist noch eine sehr wichtige Tätigkeit. Du sitzt den ganzen Tag da und machst Urlaubsgenehmigungen.

Andy Grunwald (00:40:08 - 00:40:23)

Aber was hast du denn gemacht? Weil, also, wenn du jetzt sagst, okay, du hast jetzt so viele Direct Reports oder so viele strategisch wichtige Projekte, du hast einfach gar keine Zeit dazu, ja, ihr seid so busy, dann ist das ja ungefähr das Gleiche, als wenn ich irgendwie als Softwareengineer eine Seitwärtsbewegung gemacht habe und jetzt zum Beispiel Produktmanager bin.

Wolfi Gassler (00:40:23 - 00:40:30)

Ja, du warst ja auch mal Director. Hast du, wie du auf Director-Ebene warst, noch irgendwie Code geschrubbt oder einen On-Call gemacht?

Andy Grunwald (00:40:31 - 00:41:03)

In der Firma nein, überhaupt nicht. Ich habe dann ein bisschen Codecutters gemacht in meiner Freizeit, aber da ging dann halt die Freizeit bei drauf und das war dann mein persönliches Leben, wo andere Leute, aber ich habe auch keinen Nachwuchs oder ähnliches. Deswegen, ich habe halt in meiner Freizeit, möchte ich nicht sagen Zeit, aber ja, es ist dann schon ein privates Investment, was ich halt verstehe, wenn das nicht jeder machen kann. Aber nee, habe ich dann nicht mehr. Wenn du 40 Leute unter dir hast, mehrere teams beschäftigt du dich nur noch mit strategie und ausrichtung und cooler machst du gar nichts mehr aber deswegen was was hast du denn gemacht um da wenigstens ein bisschen mit deinem technischen verstand scharf zu bleiben.

Wolfi Gassler (00:41:04 - 00:43:48)

Es wird immer immer schwieriger, umso weiter du natürlich in der Karriereleiter, unter Anführungszeichen, nach oben wanderst, eben auf Director-Ebene zum Beispiel. Klar, die private Zeit hast du natürlich noch und wenn du dich für Technik interessierst, wird die meiner Meinung nach noch wichtiger, weil wenn du den ganzen Tag eben nicht technisch unterwegs bist, dann willst du ja vielleicht auch noch irgendwie Technik machen und das verlagert sich dann noch mehr in die Freizeit, leider. Was natürlich schon war, und das war natürlich für mich schon ein Problem, umso mehr Reports ich hatte, umso weniger war ich dann auch in die technischen Diskussionen involviert und bin immer weiter rausgewandert, einfach aus Zeitgründen, weil du kannst nicht mehr in den technischen Diskussionen mit dabei sein und verlierst dann den Anschluss, weil du auch auf der Architekturebene immer weiter nach oben wanderst und dann den Anschluss verlierst. Das ist natürlich ein großes Problem. Was für mich ganz gut war, war eigentlich, die Diskussion in 101s, die ich hatte mit Leuten, wo ich wirklich tief in technische Details eingestiegen bin teilweise, wenn die Probleme hatten, dass wir dann wirklich, wo ich was beitragen konnte, auf einem Meta-Level diskutiert hatten. Und das hat mir dann schon auch viel gebracht, um Einblick zu bekommen und die technische Diskussion weiterhin zu haben. Also weniger in klassischen Architektur-Meetings oder solchen Dingen, wo man natürlich unter Umständen schon auch noch involviert sein kann, aber dann auch wirklich in der One-on-One-Seite, wenn es darum geht, wie kann ich dieser Person weiterhelfen, eben nicht nur in der Kommunikation, in der Weiterentwicklung, aber auch auf technischer Seite. Und da kann man dann schon auch teilweise technisch noch diskutieren und sich ein bisschen up-to-date halten, würde ich mal sagen. Sonst ganz klassisch irgendwelche Meetings oder Entscheidungen auf ganz hoher Ebene, die aber auch noch technisch sind. Also geht ja rauf bis zum CTO. Der CTO wird dann auch in irgendeiner Form noch in technische Entscheidungen involviert sein. Ist natürlich ein paar Ebenen höher. Aber auch da bleibt man natürlich in irgendeiner Form in Architekturmeetings, Firmenweitern vielleicht oder Begleitungen von technischen Projekten auf einer höheren Ebene, dass man da mit den Techleads diskutiert und da in irgendeiner Form auch noch involviert bleibt. Aber ich glaube, es ist schwierig und umso höher man steigt, umso schwieriger ist es. Und irgendwann ist es dann, glaube ich, kaum mehr möglich, in irgendeiner Form auf tiefer Ebene technisch involviert zu bleiben. Und da bleibt dann eigentlich nur mehr die Freizeit oder irgendwelche Hackathons, also irgendwas, was nicht klassisch Arbeit ist, meiner Meinung nach. Mit dem muss man sich einfach abfinden, wenn man nach oben wandert. Und frühestens beim Director-Level fängt es an, dass man wirklich auch da wieder einen Schritt zurück machen muss und damit leben muss, wenn man in die Richtung gehen will, dass man von der Technik einfach weg wandert langsam.

Andy Grunwald (00:43:48 - 00:44:34)

Ist ja nicht nur nach oben, ne? Teilweise auch die Seitwärtsbewegung, falls man irgendwie Projektmanagement, ins Projektmanagement geht oder Produktmanagement oder ähnliches. Aber generell hilft es vielleicht so ein bisschen zu verstehen, aber auch zu akzeptieren, dass man jetzt einen anderen Job hat, dass man nicht mehr alles ins kleinste Detail verstehen muss, dass man auch einfach diesen Luxus nicht mehr hat. Ich meine, niemand erwartet, dass ich Constant Code irgendwie in Produktion schippe. Und es ist halt wirklich gut, sich mal wieder vor Auge zu führen, was meine Verantwortlichkeiten in meinem Job sind. Natürlich möchte ich technisch bleiben, aber ich hab jetzt eine Leadership Rolle, ich muss mein Team effizient kriegen und es so fördern, dass es auch ohne mich gut funktioniert. Von daher, es ist einfach ein anderer Job.

Wolfi Gassler (00:44:34 - 00:45:21)

Und man kann da ja extrem viel damit auch erreichen, muss man ja auch dazu sagen. Also wenn du schaffst, deine Teams zu enablen, dann ist der Output ja viel, viel höher noch. Also du kontribuierst halt einfach von einer anderen Seite mit einem anderen Werkzeugkoffer, wo die Technik halt ein kleiner Teil ist. Du wirst sicher noch technischen Input liefern können, Wissen liefern können, aber es wird halt nur mehr ein kleinerer Teil und umso weiter du oben bist, umso kleiner wird dieser Teil. Aber dafür baust du ganz viele andere Skills auf, die ganz, ganz wichtig für die Teams sind. Und wenn du dort richtig investierst, dann kannst du halt das Ganze verzehnfachen, verzwanzigfachen, je nachdem, wie groß das gesamte Team ist. Und im Endeffekt kontributierst du dann viel, viel mehr zum Gesamten.

Andy Grunwald (00:45:21 - 00:45:26)

Und eine Sache, die ich mir immer so zurechtlege, damit ich mir die ganze Sache schönreden kann.

Wolfi Gassler (00:45:26 - 00:45:30)

Musst du dir schönreden? Du liebst deinen Job, oder?

Andy Grunwald (00:45:30 - 00:46:02)

Ich sehe schon. Ich liebe wirklich meinen Job, aber es ist halt auch so, es ist was anderes, ja. Und zwar ist der Feedback-Cycle ein bisschen anders. Als Software-Ingenieur programmiere ich, committe, deploy und sehe den Effekt in Produktion. Wenn ich in einer Management-Rolle arbeite und dann mit Personen arbeite, bis ich da ein Feedback habe von Aktionen und ein Ergebnis sehe im Mindset-Change oder ähnliches, dann dauert das halt Wochen, teilweise Monate. Ich sage immer so, in der Software-Entwicklung dauert das, wenn alles gut geht, eine halbe Stunde, dann ist die ganze Sache in Produktion. nicht immer eine halbe Stunde, gebe ich auch zu, ab und zu auch ein bisschen länger, aber ihr versteht, was ich meine.

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

Aber man merkt schon, du bist schon auf der Manager-Ebene, das kann ich in einer halben Stunde programmieren. Was ihr da programmiert habt in zwei Wochen, das könnt ihr am Wochenende programmieren.

Andy Grunwald (00:46:10 - 00:47:26)

Nein, nein, nein. Also ab und zu dauert es natürlich auch ein paar Tage, aber bei Menschen oder mit Menschen arbeiten, da sieht man den Effekt natürlich auch ab und zu erst nach drei Monaten. Und da ist der Feedback-Cycle ein anderer, da muss man ein bisschen mit klarkommen. Und deswegen stellt man sich als Manager natürlich auch oft die Frage, okay, was habe ich heute eigentlich gemacht, was habe ich heute einfach nicht gemacht, weil die Aktion, die du vor drei Monaten gemacht hast, haben jetzt einen Effekt. Deswegen werdet euch dessen bewusst akzeptiert ist. Es kann auch einfach sein, dass der Management-Job nicht das Richtige ist oder dass ihr in einem anderen Job mehr Spaß habt. Dann gibt es natürlich noch das Management-Pendulum, wo wir auch mal eine Episode gemacht haben. Und das bedeutet, dass du natürlich von deinem Management-Job auch wieder zurück als Software-Engineer wechseln kannst, ohne dass das irgendwie ein Problem ist, beziehungsweise als Rückschritt angesehen wird. Aber im Endeffekt, die Realität sieht halt ein bisschen anders aus. Manche Firmen sagen als explizite Erwartungshaltung, du als Manager musst hands-on sein. Andere Firmen sagen, uh, nee, dafür haben wir Tech-Leads und so, du machst nur People-Management. Klärt das doch mal mit eurer Vorgesetzten, was eigentlich wirklich erwartet wird. Also manche Firmen haben auch 15 Direct Reports und da wird noch erwartet, dass du ein Tag pro Woche hands-on bist. Frage ich mich ganz ehrlich, klappt das denn wirklich so gut? Ich denke nicht.

Wolfi Gassler (00:47:26 - 00:47:59)

Ich glaube, man kann es auch gar nicht pauschal sagen. Jede Firma tickt anders, jede Person tickt anders, jede Teamstruktur ist anders. Also es kommt wirklich darauf an und man muss, glaube ich, den besten Weg finden. Was meiner Meinung nach wichtig ist, man sollte den Kontakt zur Technik einfach nicht verlieren. Im Idealfall erlaubt es der Arbeitgeber in der Arbeitszeit. Sonst hoffe ich, dass man auch Spaß daran hat, wenn man das in gewissen Side-Projects oder einfach bei einem netten YouTube-Video sich auch aneignen kann und dabei Spaß hat noch nebenbei. Ich glaube, das ist einfach wichtig. weil es im Alltag einfach extrem weiterhilft.

Andy Grunwald (00:47:59 - 00:48:12)

Das war das Wort zum Dienstag oder welchen Tag ihr auch immer diesen Podcast hört vom Wolfgang. Aber das war es von uns in Bezug auf, wie man hands-on bleiben kann bzw. wie man technisch bleiben kann.

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

Und ob man es bleiben muss.

Andy Grunwald (00:48:13 - 00:48:15)

Und ob man es bleiben muss, natürlich auch.

Wolfi Gassler (00:48:15 - 00:48:19)

Zusammengefasst nochmal ja.

Andy Grunwald (00:48:19 - 00:49:11)

Also springt einfach zum Ende. Ja, hier ist das Ergebnis. Too long didn't read. Ja. Aber uns interessiert natürlich auch, wie schafft ihr es? Seid ihr in einer Managementrolle? Wie bleibt ihr technisch? Welche Rituale habt ihr? Kommt doch einfach mal in unsere Discord-Community oder schreibt uns eine E-Mail. Kontaktdaten findet ihr in den Shownotes. Auch würde uns mal interessieren, wie ihr diese Episode gefunden habt. Und zwar gibt's in den Shownotes so einen kleinen Daumen nach oben oder einen kleinen Daumen nach unten. Und falls ihr noch mehr Episoden von uns hören wollt, dann wisst ihr natürlich, jeder Ingenieur oder jeder, der mal ein Ingenieur war, läuft nicht auf Benzin, läuft nicht auf Gas und zwar läuft diese Person auf Kaffee. Deswegen könnt ihr uns auch einen Kaffee ausgeben. In den Shownotes findet ihr bei mir einen Koffeelink. Wir würden uns sehr, sehr freuen, mal ein neues braunes Heißgetränk von euch zu bekommen.

Wolfi Gassler (00:49:11 - 00:49:41)

Und weil du gerade erwähnt hast, wer es noch nicht weiß, wir haben auf der Webseite auch alle Episoden getaggt und haben da zum Beispiel Leadership oder solche Tags jeweils auf den Episoden. Das heißt, wenn ihr neu eingestiegen seid, könnt ihr da über die Tags wirklich ähnliche Episoden auch schnell rausfinden. Und wir probieren die Episoden eigentlich immer so zu designen, dass das Evergreen Episoden sind, die man auch eben ein Jahr, zwei Jahre später hören kann. Also gerne mal auf die Webseite gehen und auch ein bisschen stöbern, ob es da alte, interessante Episoden gibt.

Andy Grunwald (00:49:41 - 00:49:44)

Das war's von uns. Bis später. Bye bye. Ciao.