#190 Mehr Meetings, mehr Macht? Der Weg zur Tech-Führungskraft

Wie kommt man eigentlich zu einer Führungsposition? Wie werde ich Engineering Manager?

Diese Frage hat uns aus unserer Community erreicht. Ein Grund genug, sich diesem Thema in einer Episode zu widmen. Diesmal aber in einer leicht anderen Form. Die Frage stammt von Jan, einem Full-Stack Software-Engineer, der in Zukunft ins Engineering Management wechseln möchte. Mit ihm haben wir ein Vor-Interview geführt und ihn mit Fragen gelöchert.

Wir gehen darauf ein, was wir eigentlich unter einer Führungskraft verstehen, welche Motivationen existieren um ins Engineering Management wechseln zu wollen, ob es dabei automatisch immer mehr Geld gibt, welche Herausforderungen beim Wechsel vom Engineer ins Management entstehen, wo der wechsel leichter ist, im eigenen Unternehmen oder durch einen Firmenwechsel, wie man sich einen klassischen Arbeitsalltag als Manager vorstellt und was man bereits heute tun kann, um für eine solche Position infrage zu kommen.

Bonus: Ein Podcast wird zum Radio.

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

Das schnelle Feedback zur Episode:

👍 (top) 👎 (geht so)

Anregungen, Gedanken, Themen und Wünsche

Dein Feedback zählt! Erreiche uns über einen der folgenden Kanäle …

EngKiosk Community: https://engineeringkiosk.dev/join-discord
LinkedIn: https://www.linkedin.com/company/engineering-kiosk/
Email: stehtisch@engineeringkiosk.dev
Mastodon: https://podcasts.social/@engkiosk
Bluesky: https://bsky.app/profile/engineeringkiosk.bsky.social
Instagram: https://www.instagram.com/engineeringkiosk/

Unterstütze den Engineering Kiosk

Wenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer

Buy us a coffee: https://engineeringkiosk.dev/kaffee

Sprungmarken

(00:00:00) Intro

(00:01:08) Wie werde ich Engineering Manager*in?

(00:03:33) Kontext, Erfahrung und Umgebung von Jan Semrau

(00:07:06) Info/Werbung

(00:08:06) Kontext, Erfahrung und Umgebung von Jan Semrau

(00:19:21) Welches Level einer Führungskraft darf es denn sein?

(00:26:48) Was ist deine Motivation? Warum möchtest du Führungskraft werden?

(00:40:21) Ist es ein klassischer Karriereschritt, in eine Führungsrolle zu wechseln?

(00:50:45) Was wurde bereits getan, um die Position eines Engineering Managers zu bekommen?

(00:53:26) Ist es leichter, eine solche Stelle im eigenen Unternehmen oder bei einem Arbeitgeberwechsel zu bekommen?

(01:04:35) Die Vorstellung eines klassischen Arbeitsalltags als Führungskraft

(01:11:48) Was sind deine größten Herausforderungen beim Wechsel in eine Führungsrolle?

Hosts

Wolfgang Gassler (https://gassler.dev)
Andy Grunwald (https://andygrunwald.com/)

Community

Diskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord

Transkript

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

Andy Grunwald (00:00:03 - 00:02:34)

Herzlich willkommen zu einer weiteren Episode vom Engineering Kiosk Podcast. Wie kommt man eigentlich zu einer Führungsposition? Also so klingt das zumindest im guten deutschen stabilen Mittelstand. Im Startup wird das heiß. Wie werde ich Engineering Manager? Diese Frage kam aus unserer Community. Ein Grund genug, sich diesem Thema mit einer Episode zu widmen. Diesmal aber in einer leicht anderen Form. Die Frage stammt von Jan, einem Fullstack Software Engineer, der in Zukunft ins Engineering Management wechseln möchte. Mit ihm haben wir ein Vorinterview geführt und ihn mit Fragen gelöchert. Wir gehen darauf ein, was wir eigentlich unter einer Führungskraft verstehen. Welche Motivationen existieren, um ins Engineering Management wechseln zu wollen. Ob es dabei automatisch immer mehr Geld gibt, welche Herausforderungen beim Wechsel vom Engineer ins Management entstehen, wo der Wechsel leichter ist im eigenen Unternehmen oder durch einen Firmenwechsel. Wie man sich einen klassischen Arbeitsalltag als Manager vorstellt und was man bereits heute tun kann, um für eine solche Position in Frage zu kommen. Lass uns am besten direkt loslegen. Viel Spaß mit dieser Episode. Der Wolfgang und ich machen diesen Podcast jetzt ein bisschen länger als drei Jahre und wir freuen uns eigentlich immer über Feedback. Konstruktives Feedback, positives Feedback. Und manchmal bekommen wir das auch. Ich meine, wir rufen ja schon noch des Öfteren dafür auf. Und immer wenn wir Feedback bekommen, fragen wir natürlich auch mal eine Follow up Frage. Und dann fragen wir nach Themenwünschen. Da kommen ab und zu mal Themenwünschen. Wir haben eine super lange Liste von diversen Themenwünschen. Da kommt ab und zu was Software Engineering related, ab und zu etwas von Themen, wo ich noch nie was gehört habe und ab und zu aber auch was über Leadership Themen. Und diese behandeln wir auch im Podcast, zwar aus mehreren Bereichen. Einmal mit Personalverantwortung, einmal ohne. Und ein Themenwunsch, der hat uns erreicht, und zwar vom Jan. Der Jan hat sich gewünscht, einfach mal die Frage zu beantworten wie wird man eigentlich Führungskraft? Wie kommt man in eine Führungsposition? Wie wird man eigentlich Engineering Manager oder Engineering Managerin? Und da habe ich mir gedacht, das ist doch mal prinzipiell eine ganz coole Frage, über die wir sprechen konnten. Aber wir drehen die ganze Sache mal mit einem kleinen Twist. Und zwar wie? Wir haben mit Jan ein kleines Vorab Interview geführt, die wir stellen ein paar Fragen zusammen, die alles auf diese Ursprungsfrage, auf diese Ausgangssituation wie werde ich eigentlich Führungskraft? Wie werde ich eigentlich Engineering Managerin? Abzielen und fragen ihn mal ein bisschen nach dem Kontext und was er denn unter dieser Rolle versteht und an all sowas.

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

Also im Prinzip, was man sonst in einem mono One stellen würde oder wenn jemand zu dir kommt, Mitarbeiterin aus dem Team, wie werde ich Engineering Managerin? Was würdest du dann sagen und für Fragen stellen?

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

Ich weiß nicht, ob ich alle Fragen in One on one stellen würde, aber vielleicht in so einer Mentorship Rolle oder ähnlicher Coaching Rolle vielleicht eher. Man ist ja dann schon in eher so eine Art Beziehung Vorgesetzter, Mitarbeiterin und Coach ist ja dann vielleicht schon ein bisschen distanzierter oder Mentor oder ähnliches. Deswegen spielen wir das Ganze heute mal durch. Und jetzt noch zur Transparenz. Der Jan hat die Fragen vorher zugesendet bekommen. Das bedeutet, er konnte sich da ein bisschen vorbereiten, denn man muss jetzt nicht glauben, dass von einem abverlangt wird, dass man spontan alle Fragen beantworten kann, die dazu führen, dass man Engineering Manager wird.

Wolfi Gassler (00:03:21 - 00:03:34)

Vor allem in dieser Tiefe, wie sie der Jan beantwortet hat. Also da sind schon viele Sachen drin, aber wenn man z.B. zu einem Interview gehen würde, dann sollte man sich wahrscheinlich genau so vorbereiten, damit man eben diese Fragen auch dementsprechend beantworten kann.

Andy Grunwald (00:03:34 - 00:04:07)

Man könnte fast sagen, diese Episode ist eine Art Premiere, denn wir machen jetzt eigentlich wir beantworten mal eine Hörerfrage und dann in so einer Art Radio Feature und holen die Leute mit in den Podcast, damit das nicht immer so eine langweilige Show zwischen Wolfgang und mir wird und damit wir nicht in unserer eigenen Suppe schwingen. Deswegen würde ich sagen, Jan, im Vorhinein vielen lieben Dank, dass du deine Zeit und deine Stimme geopfert hast und natürlich aber auch deinen Kontext. Und wir haben gedacht, wir fangen mit einer ganz einfachen Frage wer ist eigentlich Jan? Und deswegen hören wir da jetzt einmal rein.

Jan Semrau (00:04:08 - 00:05:50)

Vielen Dank, dass ich hier sein darf. Ich bin Jan, noch junge, 24 Jahre und wohne in der Nähe von Hannover. In meiner Freizeit bin ich als Kirchenmusiker noch unterwegs und in der Regel jedes Wochenende auf der Orgelbank. Habe auch noch Projekte, die ich zweimal im Jahr mache, bin sonst beim DRK in der Bereitschaft in Peine tätig und auch Mitglied in der freiwilligen Feuerwehr hier im Ort. Zu meinem aktuellen ich bin Fullstack Software Engineer bei TUI, habe dual dort auch Wirtschaftsinformatik studiert, habe jetzt noch meinen Master berufsbegleitend hinten dran gehangen und bin seit etwa drei Jahren jetzt in der Abteilung, wo ich als Fullstack Entwickler tätig bin, in der Webentwicklung. Wir machen mit HTML, CSS, JavaScript quasi klassisch das Frontend und mit Node JS dann eben so ein bisschen Backend, Backend Services. Wir kümmern uns jetzt in meinem Team in erster Linie um Landingpages und auch die help. Wir haben mehrere statische Seitengeneratoren, die wir maintainen und bauen auch eigene MFEs, die wir auf diesen Generatoren dann einsetzen. Zur ich arbeite bei TUI. Der TUI Konzern besteht aus ungefähr oder hat ungefähr Mitarbeiter. Die TUI Infotech hat ungefähr 800 Mitarbeiter, ist quasi die IT Tochter. Es gibt aber auch noch ITler, die z.B. bei TUI Deutschland angestellt sind, wir bei TUI Com. Also ich bin zwar bei der Infotech angestellt, arbeite quasi aber für die TUI Com. Die kümmern sich halt eben um den Internetauftritt der TUI. Und da sind wir aktuell sieben Pods, also quasi kleine Teams mit unterschiedlichen Verantwortlichkeiten. Und ich bin eben Teil eines dieses, einer dieser Pods.

Andy Grunwald (00:05:50 - 00:05:54)

Du hast gesagt, du hast Master gemacht. Wie viel Jahre auf Berufserfahrung, Years of Experience hast du dann?

Jan Semrau (00:05:55 - 00:06:07)

Also das ist jetzt die Frage, wie man das sieht. Also ich habe dual ja Wirtschaftsinformatik studiert, drei Jahre und den Master habe ich berufsbegleitend gemacht. Also sind das jetzt zwei Jahre, zweieinhalb Jahre volle Berufserfahrung.

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

Also kann man sagen, den Bachelor hast du dann Vollzeit im Studium gemacht?

Jan Semrau (00:06:11 - 00:06:18)

Dual. Also ich war immer drei Monate in der Uni, drei Monate im Unternehmen und drei Jahre.

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

Okay, also vier, viereinhalb Jahre eigentlich Berufserfahrung, wenn man so möchte.

Jan Semrau (00:06:22 - 00:06:36)

Wenn man das so sieht. Ich kenne Recruiter, die sehen das nicht so. Die sagen, ich habe zwei Jahre Berufserfahrung. Wenn man jetzt das duale Studium mit der Zeit, die man im Unternehmen verbracht hat, als Berufserfahrung zählt, dann sind es jetzt viereinhalb, fünf Jahre.

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

Hallo Jan, nett dich kennenzulernen. Eine wichtige Information, die ich zumindest aus dieser Vorstellung nehme, ist, wir reden über ein Firmenumfeld in einem Konzern. Wir reden jetzt hier aus dieser Situation nicht um eine 20 Mann Webagentur oder fünf Personen Game Schmiede, sondern schon um einen Konzern mit circa Mitarbeitern. IT Abteilung hat circa 800 Mitarbeiter. Schon. Ich würde mal auf gut Deutsch sagen, das ist kein kleiner Laden.

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

So, endlich einmal ohne dem Andi. Das heißt für mich endlich kein Hochdeutschzwang. Und damit willkommen im sogenannten Werbeblog. Aber keine Sorge, es wird kein Promo Monolog, ganz im Gegenteil. Ich wollte einfach mal Danke sagen. Danke, dass du zuhörst, lachst, mitdenkst und vielleicht auch noch was dabei lernst. Weil genau das treibt uns eigentlich an. Wir machen das, weil uns das Ganze spaß macht und weil wir selber jedes Mal was mitnehmen für uns. Wenn du also die Mischung aus Schmäh, manchmal Tiefgang und vor allem Neugier gefällt, dann tu uns doch einen kleinen Gefallen. Schnapp dir jetzt mal deine Messenger deiner Wahl und schick einer Freundin oder Kollegin den Link zu deiner Lieblingsepisode, weil so wächst die Community und mehr Leute haben Spaß am Ende. Und ü dieser Slot, da kann auch deine Bühne sein. Die richtige bezahlte Werbung, die liest dann natürlich der andi auf mehr oder weniger hochdeutsch oder was mit dem Roboter immer so redet. Also Werbung für dein Produkt, eine Firma oder sonst was cooles. Und falls du ein gemeinnütziges oder open source Projekt hast, dann noch besser, schick uns einfach eine Mail. Wenn es zu uns passt, nehmen wir das gern kostenlos mit auf. Und jetzt zurück zum Podcast. Natürlich wieder mitten Andi. Aber Andi, du hast dich wieder nicht auf das Wichtige fokussiert. Das Wichtigste in seiner Vorstellung ist natürlich, dass er bei der freiwilligen Feuerwehr ist. Für mich als Feuerwehrler ist das natürlich das Wichtigste in dieser Vorstellung. Danke dafür, Jan schon mal.

Andy Grunwald (00:08:22 - 00:08:41)

Und du wirst lachen, als ich das gehört habe, muss ich genau daran denken, dass es dich stolz macht. Aber hey, finde ich super. Danke für deinen freiwilligen Einsatz. Deswegen steigen wir mal ins Thema. Die erste Frage, die wir Jan gestellt haben, war, ich sag mal Basiswissen. Was ist dein Verständnis einer Führungskraft? Was verstehst du darunter?

Jan Semrau (00:08:42 - 00:09:52)

Mein Verständnis einer Führungskraft ist, dass die Person die menschliche Verantwortung trägt für das Team. Wir haben bei uns auch den sogenannten Technology Team Lead, also der die menschliche Verantwortung für das Team trägt und den PO, der dann wiederum das aus der fachlichen Sicht betrachtet. Und ich habe das Gefühl oder mein Verständnis ist die Führungskraft eben das Team im Blick. Also wie läuft es im Team? Was haben die Teammitglieder für Sorgen? Engste Nöte, räumen Probleme aus dem Weg, ist aber auch verantwortlich für strategische Entscheidungen innerhalb des Teams. Es kommt auch, finde ich, wieder auf die Ebene an, was für eine Führungskraft man ist. Ob man jetzt operativ nah dran ist, wie jetzt z.B. bei mir im Team als Technology Team Lead oder ob man eine höhere Führungskraft ist und über quasi noch weitere Führungskräfte besteht, wie das eben mit der strategischen Entscheidung, Kommunikation der Vision und Strategie ist. Für mich auch wichtig. Also wofür machen wir eigentlich das, was wir jeden Tag tun? Wir sind 8 Stunden hier am Computer und arbeiten und wofür machen wir das? Die Führungskraft ist eben nah dran bei uns jetzt auf Sicht des technology Team Leads und nimmt am Daily teil, gibt regelmäßig One Once, versucht Dinge zu klären, fragt, ob es Probleme gibt, holt sich auch immer wieder Feedback ein und gibt aber auch dem Mitarbeiter wieder Feedback, wo er sich weiterentwickelt.

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

Du hattest gerade ganz kurz der Po ist fachlich verantwortlich. Da gibt es natürlich in der Führungspositionssprache die zwei Begriffe fachlich und disziplinarisch verantwortlich. Fachlich bedeutet also das, was dein Team tut. Disziplinarisch bedeutet, du stellst jemanden ein, Gehaltserhöhung, feuerst jemanden und so weiter. Was ist dein Verständnis der Führungskraft in Bezug auf fachlich und oder disziplinarisch? Sollte eine Führungskraft beides haben oder soll sie nur disziplinarisch sein? Wenn ich das gerade rausgehört habe, dass der Po fachlich verantwortlich ist.

Jan Semrau (00:10:24 - 00:10:37)

Also aus meinem Verständnis her ist die Führungskraft disziplinarisch verantwortlich und der Po ist fachlich verantwortlich. Der Po was ist zu tun in nächster Zeit? Und die Führungskraft kümmert sich um die Mitarbeiter und ist disziplinarisch verantwortlich.

Andy Grunwald (00:10:37 - 00:10:44)

Und wer kriegt auf die Mütze, wenn das Projekt nicht in time geliefert wird? Die Führungskraft, wenn doch der Po fachlich verantwortlich ist.

Jan Semrau (00:10:44 - 00:10:46)

Das ist dann die Frage, wie man das sieht.

Andy Grunwald (00:10:46 - 00:10:56)

Okay, okay, gut, lassen wir stehen. Aber okay, du siehst, da könnt ihr drüber diskutieren. Das ist spannend, ne? Machen wir, machen wir. Also siehst du disziplinarisch als Führungskraft?

Wolfi Gassler (00:10:58 - 00:11:41)

Also bei dieser Antwort hatte er fast das Gefühl, Jan ist auf unsere Leadership Tag Seite gegangen von unserem Podcast und hat sich unsere Episoden angeschaut, weil gerade Vision und Strategie z.b. das ist ja so ein Klassiker, haben wir eigene Episode darüber gemacht. Insofern, ich find mal, der Anfang ist eigentlich ganz gut. Also so die high level Themen, Strategie, Entscheidungen, viel Kommunikation, Team im Blick halten für eine gute Basis an dich und vor allem die richtige Richtung. Also weniger das entscheiden, was und wie wir das genau machen. Meine Erfahrung ist, dass Leute ganz oft eher in diese Entscheidungsrichtung gehen und ich möchte entscheiden, was gemacht wird und darum will ich in die Führungsposition. Also das finde ich eigentlich eine gute.

Andy Grunwald (00:11:41 - 00:13:13)

Antwort, da würde ich mitgehen. Was ich auch ganz interessant bei der Antwort fand, ist, dass unterschiedliche Wording wie Teamleiter oder Engineering Manager bezeichnet werden. Hier heißt es Technology Team Lead und Jedes Mal, wenn ich über eine neue Firma etwas lerne, dann bekomme ich auch irgendwie einen neuen Begriff, wie Teamleiter oder Teamleitung oder Engineering Management genannt wird. Das ist immer ganz interessant. Wo ich nicht wirklich mitgehe, ist diese Trennung zwischen fachlich und disziplinarisch. Denn Jan hat ja beschrieben, dass sein Verständnis ist, dass die Führungskraft disziplinarisch verantwortlich ist und der PO, was ich jetzt mal mit Product Owner übersetzen würde, fachlich verantwortlich ist. Und da gehe ich nicht so ganz mit, denn meine Follow up Frage wäre eigentlich was heißt denn hier fachlich? Heißt jetzt hier fachlich, ich muss alles über die Einlösung von Coupons und Help pages und Co. Und Landingpages wissen. Da wo Jan drin arbeitet, in dem Sektor oder heißt ich weiß, wie ich das technisch hier umsetze, weil das sind ja zwei fachliche Domänen, die nicht unbedingt eine Überschneidung haben müssten. Und wenn man jetzt sagt, der Engineering Manager oder die Engineering Managerin oder Jan ist nur disziplinarisch verantwortlich, dann ist die ist der Tech Background benötigt? Denn prinzipiell würde das bedeuten, er ist reiner People Manager und dann kann man da jemanden auch von der Personalabteilung hinsetzen oder irgendwen, denn da geht es ja dann wirklich nur um People Skills und nicht um technische Skills.

Wolfi Gassler (00:13:14 - 00:13:28)

Wie würdest du denn deine Frage beantworten? Wer bekommt was auf die Mütze, wenn das Projekt nicht läuft? Mathe schon gehört? Du warst nicht so zufrieden mit der Antwort und hast gekämpft, nicht zu antworten. Also frage ich dich jetzt, wie antwortest du?

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

Also ich finde, man kann nicht sagen, dass die Führungskraft einen auf die Mütze bekommt bekommt, wenn die Führungskraft nicht fachlich verantwortlich ist.

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

OK, was siehst du dann als fachlich an?

Andy Grunwald (00:13:37 - 00:14:32)

Ich sehe die Trennung zwischen Product Owner hat Domänenwissen und ein Engineering Team hat die fachliche Kompetenz, wie das umgesetzt wird. Weil es ist das Engineering Team, es ist das Programmierer Team. Weil wenn der PO sagen würde, wie es umgesetzt wird, engineering technisch, dann hast du keine Software Engine, hast du da Code Monkeys, die kriegen dann Anweisungen, schreib diese Klasse, schreib diese Architektur, mach dieses Design Pattern und bla und wir reden ja über Software Engineering und die Leute brauchen ja auch eine Motivation, die brauchen ja auch Freiheit, wie sie die Fachdomäne, in diesem Fall jetzt Landingpages und Co. Umsetzen. Und deswegen ist der Product Owner von der Fachdomänen Seite die Person, die das sagen hat, aber von der Fach Engineering Domäne ist das das Engineering Team. Und da kommt dann natürlich auch dann der Engineering Manager, in diesem Fall Jan, zu Rate, der dann auch auf die Mütze bekommt, falls das Thema nicht in Zeit geliefert wird.

Wolfi Gassler (00:14:32 - 00:15:52)

Also meine Meinung ist ja, wenn etwas nicht in Zeit geliefert wird, dann ist der PO verantwortlich, weil Zeiten kommunizierter PO, also ein Engineering Manager kommuniziert keine Zeiten, wenn es einen PO gibt. Das heißt Deadlines und Zeiten kommuniziert immer der PO und der muss sich darum dann im Hintergrund kümmern, dass es passiert. Das heißt, dann den Engineering Manager verantwortlich zu machen, ist meiner Meinung nach nicht möglich, wenn es darum geht. Wenn es natürlich jetzt darum geht, das Team funktioniert nicht, es gibt irgendwelche technischen Probleme, dann ist in irgendeiner Form natürlich der Engineering Manager wieder auch mit dabei und an Bord. Aber das ist ja auch in der Realität hoffentlich so, dass sich das Team schon als Team sieht und es geht weniger darum, wer bekommt eine auf die Mütze, sondern wo liegen die Probleme, wen muss man mit einbeziehen, um diese Probleme dann am Ende zu lösen? Und da ist der Engineering Manager, glaube ich, grundsätzlich immer dabei, egal um was es geht. Aber für die ganz klassische Deadline, wann ist etwas fertig, ist meiner Meinung nach der PO verantwortlich. Außer du hast ein Setup ohne PO, was es ja auch ganz oft gibt, dass der Manager das gesamte Team eigentlich verantwortet. Also auf der Product Seite, auf der fachlichen Seite, auf der disziplinarischen Seite meistens dann auch. Dann ist er natürlich die Rolle, die alles übernimmt. Und dann ist natürlich diese Person auch verantwortlich.

Andy Grunwald (00:15:52 - 00:16:19)

Wie Kannst du jemanden für etwas verantwortlich halten, der in diesem Kontext keine Kontrolle über das Team hat? Denn der Po ist nicht disziplinarisch verantwortlich. Der Po sagt, was das Ziel ist, was wir umsetzen wollen. Wie kannst du diese Person verantwortlich machen, ob das Projekt in Zeit, in Budget, in Quality geschippt wird? Denn das ist eigentlich nur dann, dass der Po betteln muss beim Engineering Manager, nicht nur technische Schulden wegzuräumen.

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

Ja, üblicherweise macht der Po ja den Plan mit dem Team. Also das Planning ist ja der Po.

Andy Grunwald (00:16:25 - 00:16:53)

Mit dem Team, aber er hat keine Durchsetzungskraft in keinster Weise. Wie kannst du solche Leute dann verantwortlich halten? Also wie kannst du zumindest für die Deadline fürs Schippen? Für mich gehört Das engineering Team ist in der Verantwortung, eine Lösung zu finden, die wir in der Zeit schippen können. Und dazu zählen dann auch Trade offs wie ich hack mir jetzt einfach mal hier die Klasse jetzt rein und pack mal ein bisschen Gaffa Tape drauf. Wenn man zuvor ziemlich viel an Architekturdiskussionen.

Wolfi Gassler (00:16:53 - 00:18:06)

Verbracht hat z.B. ja, da kommt es meiner Meinung nach auch darauf an, wie weit eine Engineering Managerin einfach in dem Team auch mitwirkt. Wenn diese Person nicht im Tagesgeschäft mit dabei ist und im Planning und so weiter, dann kann sie auch weniger helfen diesbezüglich. Wenn die natürlich 100 % im Planning mit dabei ist und vielleicht mitprogrammiert, dann ist es natürlich was anderes. Aber sonst ist natürlich das Team zusammen mit dem PO verantwortlich. Und der Po hat ja mit seinen Sprints oder was es für Methodologien auch immer gibt, ja auch Einblick, wie schnell etwas voranschreitet. Und der muss ja auch dann die Planung zusammen mit dem Team machen. Wie viel technische Schuld machen wir? Was machen wir auf der Product Seite? Das ist ja üblicherweise zumindest so, dass der PO ja auch mit dem Team zusammenarbeitet und es kein ich werfe über die Mauer hinüber zum Entwicklerteam irgendwelche Tickets und meine Produkte und dann entscheidet der Engineering Manager zusammen mit dem Team, was gemacht wird. So läuft es ja nicht ab. Insofern glaube ich, ist die Verantwortung schon auch auf der Poseite. Aber das Gegenstück natürlich zum PO ist der Engineering Manager. Wenn es Probleme gibt, wenn es Deadline Schwierigkeiten gibt, dann müssen die natürlich gemeinsam auch mit dem Team dann eine Lösung finden.

Andy Grunwald (00:18:06 - 00:18:20)

Ich denke, dass der Engineering Manager gar nicht hands on dabei sein muss, um dafür verantwortlich zu sein. Ich denke, dass es einfach zwei Arten von fachlicher Kompetenz sind. Und weil sonst, es gibt ja auch diesen Bullshit Filter, von dem ich immer spreche.

Wolfi Gassler (00:18:21 - 00:18:48)

Aber wenn du ja sagst, Engineering Manager ist trotzdem verantwortlich, obwohl er nicht hands on ist, dann müsste der Engineering Manager ja alle Deadlines und alles im Auge haben, was wo delivered wird und den gesamten Überblick über alle Details haben. Das kann er ja meiner Meinung nach gar nicht. Außer er ist wie gesagt, so tief drinnen im Team, dass er wirklich auch tagtäglich mitarbeitet. Es kommt darauf an, wie viel Verantwortung du einfach hast oder ob du mehr Teams hast oder nur ein Team und wie weit du drinsteckst.

Andy Grunwald (00:18:48 - 00:18:58)

Natürlich geht es von einem Team aus und ich gehe davon aus, dass diese Person weiß, was das Team macht, wie die Plan, wie der Planungsstand ist und allem drum und dran.

Wolfi Gassler (00:18:58 - 00:19:05)

Aber auch, weil also auch bei jedem Planning dabei ist, bei jedem Stand up und so weiter. Also wirklich nur für dieses Team verantwortlich und dann auch ein Team wahrnehmen kann.

Andy Grunwald (00:19:05 - 00:19:17)

Es ist kein Senior Engineering Manager, da kommen wir gleich noch mal zu, was das heißt. Es ist ein Teamlead, kümmert sich um ein Team, vier bis acht Leute oder dass es auch 10 sein im Extremfall oder 11 oder ähnliches. Aber okay.

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

Aber dann wird da der Engineering Manager in dem Sinne auch garantiert hands on sein, weil wenn du nur fünf Leute hast und ein Po, dann bist du auch hands on.

Andy Grunwald (00:19:26 - 00:20:03)

Würde ich so nicht mitgehen. Es kommt auf das Firmenkonstrukt an und was man noch so alles zu tun hat und in welcher Phase man ist und Co. Deswegen würde ich erst mal so nicht unterschreiben. Aber dazu haben wir auch mal eine eigene Episode gemacht, ob ein Engineering Manager hands on sein sollte oder nicht. Verlinken wir natürlich auch in den Shownotes. Lass uns mal weitergehen, denn die reden wir von einem Team, reden wir von mehreren Teams oder von welchem Level einer Führungskraft sprechen wir denn hier? Haben wir auch Jan gestellt. Und zwar haben wir die Frage gestellt, welches Level einer Führungskraft hast du denn im Sinn? Welches möchtest du denn, ich nenne es mal beackern? Hören wir mal rein.

Jan Semrau (00:20:04 - 00:20:51)

Initial habe ich im Sinn die Führungskraft der untersten Ebene, also wirklich das Team Leads, der seine Mitarbeiter unter sich hat, als nah am operativen Geschehen dran ist. Also wirklich eben die die Entwickler in dem Fall unter sich hat. Auch mit dem Hintergrund, dass ich mit meiner Expertise als Fullstack Entwickler auch eben meine Gedanken, meine Erfahrungen mit einfließen lassen kann in Prozessgestaltung z.b. und perspektivisch kann ich mir schon vorstellen, auch dann eine Ebene höher zu gehen, ins C level oder weit nach oben wiederum kann ich mir nicht vorstellen, weil mir die Menschen persönlich wichtig sind und ich auch den Erfolg des Teams ein Stück weit mitgestalten möchte. Und das kann ich meiner Meinung nach am besten, wenn ich nah an den Mitarbeitern dran bin, die am Ende das auch umsetzen.

Andy Grunwald (00:20:52 - 00:21:37)

Das ist ja genau der Punkt, wo wir gerade drüber gesprochen haben, wie viele Leute hast du, wie bist du involviert? Und Jan sagt ja auch, er möchte mit seiner Expertise als Fullstack Entwickler auch einen gewissen Wert schaffen. Denn das, was du da gerade beschrieben hast, das verstehe ich unter Senior Engineering Manager oder Director. Also wenn man sich die Leiter mal anschaut, dann ist eine klassische Engineering Managerin ein klassischer Team Lead Leiter von Individual Contributor. Darüber, je nach Organisation kann man sagen, wenn du mehrere Teams leitest, das bedeutet, wenn du selbst der Manager von Teamleitern bist, dann wird das oft Senior Engineering Manager oder Director genannt, darüber Vice president, darüber Senior Vice president und so weiter. Und umso mehr Teams hast du dann unter dir und umso mehr Hierarchien hast du unter dir.

Wolfi Gassler (00:21:38 - 00:22:58)

Das stimmt natürlich grundsätzlich, diese Theorie gibt es, aber in der Praxis ist es ja auch ganz oft anders. Also ich habe es natürlich selber erlebt, wesentlich mehr Leute auch zu haben, aber auch wenn du jetzt in irgendeinem Chapter arbeitest, ein Spotify Model hast oder ich kenne es auch in Startups, da gibt es einen Lead, der dann für zwei Teams verantwortlich ist meistens. Also wenn es ein kleines Startup ist, irgendwie 10 Leute, kommen mal die ersten zwei Teams, gibt einen Engineering Manager für die zwei Teams. Also in der Realität trifft man das schon auch oft an, dass der Engineering Manager nicht wirklich nur einem Team zugeordnet ist, sondern in irgendeiner Form das vielleicht flexibel läuft. Cross Functional kann ja alles sein. Also da gibt es schon andere Modelle auch. Und da ist halt die Frage, wie weit man dann einfach im Prozess involviert ist. Und je nachdem, wie tief man drin ist, wird man natürlich nur dann gerufen, wenn auf der jeweiligen Ebene auch was passiert und man weiterhelfen kann. Also wenn dann in irgendeinem Ticket irgendein Problem ist und du bist für vier Teams verantwortlich, dann wird man dich nicht holen, außer es ist wirklich ein ganz hartes Problem und du kennst dich zufällig da Dr. Aus. Aber wenn es natürlich auf irgendeiner Prozessebene ein Problem gibt oder das Team hat überhaupt ein Problem, zwei Leute, drei Leute streiten sich, der Po kommt dann zu dir und hey, wir können die Deadline nicht halten, wir haben da ein Problem im Team. Dann bist du gefragt als Engineering Manager. Ganz klar.

Andy Grunwald (00:22:58 - 00:23:29)

Ich hoffe, das war ein Versprecher, was du gerade gemacht hast, denn ich denke nicht, dass eine Person verantwortlich sein sollte für vier Teams und diese mit den individual Contributor als Direct Lead leiten sollte, denn das ist nicht nachhaltig. Denn da sollte man mindestens doch mal vielleicht eine Zwischenebene einziehen und sich die Teamleiter selbst holen. Bzw. Solltest du dann pro Team Leute haben, die sehr, sehr stark als technical lead agieren oder ähnliches.

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

Dem würde ich grundsätzlich zustimmen. Ich selber habe es ja leider genau so erlebt und war teilweise bis zu 28 Leute ICs verantwortlich.

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

Ja und schau, was aus dir geworden ist. Jetzt bist du Podcast. Eben.

Wolfi Gassler (00:23:41 - 00:24:22)

Das ist, dass es nicht gut funktioniert ist. Ich würde gar nicht sagen, dass es gar nicht funktioniert. Es ist schwierig. Und wie du richtig sagst, du brauchst dann ganz starke Leute in den Teams und du hast dann quasi solche, ich würde es nicht Team Leads nennen, aber zumindest irgendwelche Senior Senior plus Leute im Team, die genau diese fachliche Leadership Rolle dann übernehmen können. Und in ganz vielen Firmen gibt es da halt keine explizite Rolle, sondern sind alle nur Team Members und dann gibt es halt einfach die Senior Leute, die das übernehmen. Aber die disziplinarische Verantwortung, die offizielle ist dann irgendwo weiter draußen. Und in cross functional Teams kann dir das durchaus passieren. Sogar wenn du nur für fünf Leute verantwortlich bist, sitzen deine fünf Leute in fünf verschiedenen Teams.

Andy Grunwald (00:24:22 - 00:24:44)

Das stimmt. Das bringt leader technisch ganz andere Herausforderungen mit. Da stimme ich dir zu. Dennoch allein die One on one bei 20 Direct Reports, ein Tag hat eine Woche, hat fünf Arbeitstage. Sagen wir mal, ein One ist im Durchschnitt dreiig bis 45 Minuten lang. Wir haben 40 Arbeitsstunden. Wöchentliche One on ones machst du da nicht mehr.

Wolfi Gassler (00:24:44 - 00:24:49)

Es geht schon, aber es geht dann viel Zeit flöten. Du machst halt zwei Tage One on.

Andy Grunwald (00:24:49 - 00:25:52)

Ones, mehr sogar, würde ich fast sagen, weil du musst auch eine Pipi Pause dazwischen machen und Kaffee holen und allem drum und dran. Das bedeutet, du hast mindestens zweieinhalb Tage, vielleicht sogar drei, weil die anderen haben noch Konflikte und so weiter. Also nachhaltig ist das nicht. Dann die andere Thematik ist natürlich auch was beackern. Deine Teams sind deine Teams, Research Teams. Das ist ein ganz anderer Fokus, als wenn sie jetzt bei Paypal für die Fraud Detection dabei verantwortlich sind. Denn, also was ich damit sagen möchte, an welchem Produktteil arbeitet dein Team und wie stark steht dieses Produktteam im Fokus des Hauptproduktes? Denn umso wichtiger dein Team für das Produkt wirklich ist, desto mehr Anforderungen hast du, desto mehr musst du viel tiefer involviert sein und viel krassere Planungszyklen haben und Co. Denn wenn das Research Team ist, klar, da fährt man Experimente und Co. Aber deswegen, ich glaube, es kommt ganz stark auf den Kontext drauf an. Aber wieder so eine scheiß Antwort mit it depends, also irgendwie, irgendwie dieses Informatik Kram. Ich würde mal eine Regel einführen. Wir dürfen nicht mehr it depends sagen.

Wolfi Gassler (00:25:52 - 00:26:06)

Das Problem ist schon, dass natürlich das wirklich auf Setup drauf ankommt. In jeder Firma hast du unterschiedliche Strukturen und Setups und darum ist es natürlich auch schwierig, da irgendwie eine spezielle Antwort zu geben, die immer gültig ist. Also das ist fast ein Ding der Unmöglichkeit.

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

Ich glaube, worauf wir uns einigen können, wenn man neu in dieser Position ist, ist man gut damit bedient, ein Team von fünf Leuten zu haben und das ist direkt zu leiten, oder? Denn da kommen so viele neue Aufgaben auf einen zu und um alles weitere muss man sich, glaube ich, erst mal keine Gedanken machen, weil über das, was wir hier reden, zwei Teams, drei Teams mit 15 Leuten und Co. Als Frischling nenne ich es mal in dem Job, würde ich dediziert als Selbstmord bezeichnen.

Wolfi Gassler (00:26:29 - 00:26:53)

Es macht sicher nicht einfacher, ganz klar. Und vor allem hast du einen Vorteil, dass du einfach, wenn du in einem Team bist, dass du nur ein Thema grundsätzlich mal hast und da vielleicht auch noch wirklich hands on oder zumindestens in tiefer drinnen auch in der Architektur und so noch mitwirken kannst. Und das macht es einem ja dann auch einfacher, als wenn man eine hundertprozentige People die Stelle dann plötzlich annimmt, was es ja durchaus auch gibt.

Andy Grunwald (00:26:53 - 00:27:14)

Jetzt arbeitet Jan als Fullstack Entwickler und möchte Engineering Manager werden. Ich habe schon Leute getroffen, die wollten diese Position haben, weil sie mehr entscheiden wollen, weil sie mit manchen Entscheidungen ihrer bisherigen Vorgesetzten nicht einverstanden waren. Da haben die ich mache alles besser. Deswegen haben wir Jan mal gefragt, was denn eigentlich die Motivation ist, warum er Führungskraft werden möchte.

Jan Semrau (00:27:15 - 00:29:33)

Ich arbeite nun seit etwa drei Jahren als Softwareentwickler oder als Fullstack Entwickler bei TUI und jetzt steht tatsächlich in nächster Zeit ein Teamwechsel an in ein Backend Team, da ich mich in dem Bereich noch weiterentwickeln möchte, um selbst dann auch wirklich ein gutes Verständnis von Front und backend zu haben. Also da besteht gar nicht der Wunsch, jetzt unmittelbar morgen Führungskraft zu werden, aber schon Potenzial oder potenziell in ein bis zwei Jahren. Und ich möchte aktiv beeinflussen, wie sich das Team entwickelt und zusammenarbeitet und auch das Potenzial der Mitarbeiter versuchen zu entfalten, durch was genau das jetzt passiert, durch Workshops, regelmäßige Retros, die man macht und organisiert, zusammen Prozesse zu erarbeiten, z.B. wie kann man das Code Review verbessern, wie kann man neue Mitarbeiter besser onboarden, Dokumentation besser gestalten? Wie kann man auch z.B. technische Schuld oder auch etwas, was man früher vielleicht nicht so gut umgesetzt hat, identifizieren und auch verbessern und dort die Arbeit damit zu erleichtern. Ich habe auch Freude am Mentoring und Coaching. Ich helfe öfter Kollegen, mache mit denen auch regelmäßig Pair Programming. Wenn mal der Po nicht da ist, moderiere ich auch gerne das Daily. Das fühlt sich immer ganz gut an, auf dieser menschlichen Ebene mit den anderen Entwicklerinnen zusammenzuarbeiten und auch ins Gespräch zu kommen, wie man helfen kann, wie man unterstützen kann und auch perspektivisch als Führungskraft, wie man quasi Potenzial in Entwicklern, Kollegen sehen kann und die dann auch zu fördern. Und das natürlich auch als weitere Herausforderung, also was anderes zu machen, als jeden Tag zu coden. Ich mache Coding gerne, ich programmiere gerne, das macht alles spaß. Aber auch mehr auf dieser zwischenmenschlichen Ebene zu arbeiten, mehr sich zu connecten, etwas im Team zu probieren. Wir haben z.B. jetzt ein Devsing vor einigen Monaten eingerichtet, wo wir einfach als Team zusammen zusammenkommen und dann mal gucken, was hat den der eine oder der andere in letzter Zeit gemacht, was er gerne sharen möchte, was den anderen auch helfen kann und was kann verbessert werden. Und ich möchte eben selbst dazu beitragen und gestalten. Und aus Sicht eines Techies, also der ursprünglich mal eben softwareentwickler war, der hat halt eben auch diese technischen Zusammenhänge, sowohl im Frontend als auch dann im Backend und kann das wiederum im Team analysieren und dann mit dem Team zusammen gucken, okay, was können wir denn machen, wie können wir technische Schuld abbauen, wie kann dafür Raum gegeben werden? Und natürlich auch die Entwicklung jedes einzelnen Mitarbeiters zu fördern und auch mit anderen Teams zusammenzuarbeiten.

Wolfi Gassler (00:29:34 - 00:30:31)

Also was ich super schön gefunden habe, ist, dass er das Team beeinflussen will und Prozesse beeinflussen will, weil was man sonst immer hört auf diese Antwort oder ganz oft hört leider, ich will das Produkt beeinflussen, ich will entscheiden, was gemacht wird, ich will entscheiden, welche Technologie eingesetzt wird. Und bei ihm steht zumindest der Antwort nach das Team im Vordergrund, die menschlichen Aspekte, die Prozesse, die Zusammenarbeit. Und auch da wieder, das ist glaube ich, ein guter Anfang, auch wenn es vielleicht fast nach einer Bilderbuchantwort klingt, aber nachdem ich auch viele andere Antworten gehört habe, finde ich die trotzdem sehr gut als Basis, wenn man in diese Rolle wechseln will. Meine Frage wäre sofort gewesen, wenn du das eh schon alles machst teilweise und da auch versuchst, Sachen zu verbessern, warum willst du überhaupt die neue Rolle? Was kannst du jetzt nicht in deiner aktuellen Rolle machen von den ganzen Auflistungen, was du dann aber in der Engineering Manager Rolle schon machen könntest?

Andy Grunwald (00:30:31 - 00:31:00)

Das ist eine gute Frage zur Transparenz. Ich habe die Fragen gestellt, ich habe das vor Interview geführt und ich musste mir immer auf die Zunge beißen oder auf die Lippen beißen, nicht direkt zu antworten und so weiter. Und deswegen habe ich solche challenger Fragen nicht im Nachhinein gestellt. Man sehe mir nach. Vielleicht, wenn Jan diese Episode mal hört, kann er natürlich uns gerne schreiben und das Feedback leiten wir dann an die Community auch weiter. Als ich gerade noch mal den Einspieler gehört habe, dachte ich mir, hatte der Jan da irgendwie so ein Leadership Buch daneben liegen?

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

Hat er abgelesen, habe da unsere Podcasts, unsere Episoden gehört.

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

Ganz klar, ich kann bezeugen im Vorinterview, da war kein Buch involviert, aber ja, natürlich. Also ich meine, mit Menschen arbeiten, Menschen weiterentwickeln, hat er gesagt, finde ich schön. Was ich auch ganz schön fand, ist, er hat jetzt drei Jahre als Fullstack Softwareentwickler gearbeitet. Er möchte aber auch mal ein bisschen was anderes machen. Das fand ich auch ganz schön, weil zeigt natürlich auch eine Art von Weiterentwicklung. Bei dieser Frage stellt sich natürlich auch die was sind eigentlich die falschen Motivationsgründe? Was sind die top drei falschen Motivationsgründe, die dir, Wolfgang, schon präsentiert wurden? Auf die warum möchtest du eigentlich Führungskraft werden? Ich möchte das Produkt beeinflussen. Ist das Nr. Eins oder ist das Nr. Drei?

Wolfi Gassler (00:31:40 - 00:32:17)

Es spielt so ein bisschen mit, das Produkt beeinflussen. Aber was man ganz oft hört, ich möchte nicht mehr so lang diskutieren, möchte nicht mehr mit den anderen streiten, was wir jetzt einsetzen. Die anderen haben immer die und die und die Meinung, die machen das Falsche. Ich will entscheiden, was gemacht wird, welche Architektur, welche Technologie, ohne ständig mit den anderen diskutieren zu müssen oder dass dann falsche Entscheidungen getroffen werden. Und darum will ich in die Position. Das ist eigentlich die klassische Antwort, die man oft hört. Teilweise offensichtlicher, teilweise so zwischen den Zeilen, je nachdem, wie smart Leute sind. Und das ist für mich so ein Knock out Kriterium eigentlich in Interviews, wenn man das raushört.

Andy Grunwald (00:32:17 - 00:33:38)

Wenn ich das generalisiert zusammenfassen würde, geht das auch in meine Nr. Eins rein. Ich habe nämlich auch schon gehört, Leute wollen Führungskraft werden, um einfach mehr Macht zu haben. Und die Entscheidungsfindung oder die Entscheidungsforcierung nenne ich es eher, spielt dann natürlich eine ganz große Rolle. Also jetzt noch mal ganz explizit, das ist der falsche Motiv. Wenn man jetzt nicht mit Menschen arbeiten möchte, wenn man nicht mit den Menschen weiterentwickeln möchte, dann hat man einen schweren Stand. Denn ihr müsst immer wissen, wenn ihr Führungskraft seid, eine Führungskraft selbst, ein Engineering Manager, ein technology Team Lead, ein Bereichsleiter oder ähnliches, das ist eine Overhead Position, die wird in einem perfekten Setup nicht benötigt. Wenn alles rund läuft, kann man euch wegrationalisieren und euer oberstes Ziel ist eigentlich, das Team so performant zu machen, ohne dass ihr involviert seid. Das ist die Thematik dahinter. Das bedeutet auch, ihr seid nur erfolgreich und mit erfolgreich meine ich tolles Ansehen, Lob, Gehaltserhöhung und was alles noch dazugehört, wie ihr Erfolg definiert, wenn das Team erfolgreich ist. Somit ist eure oberste Priorität, ihr sorgt dafür, dass das Team erfolgreich ist, dass das Team performt und wenn das gegeben ist, dann seid ihr erfolgreich. Und deswegen, wenn man nicht sehr daran interessiert ist, Menschen weiterzuentwickeln, hat man einen sehr schweren Stand.

Wolfi Gassler (00:33:39 - 00:34:16)

Es macht dann eh die AI in Zukunft, oder? Kann man ja eigentlich alles dann von ChatGPT machen lassen, mehr oder weniger. Also ich glaube, dass das wirklich reale Sache ist, also dass es in Zukunft vielleicht auch weniger Engineering Manager brauchen wird. Wenn du dir überlegst, wie oft man sich eigentlich wiederholt als Engineering Manager in one on one und wie viele Sachen, banale Sachen man beantwortet, was vielleicht mit mit einem Rack genauso möglich ist. Wie findet man in der Firma irgendein Prozess? Was soll man machen, wenn man XY braucht oder wenn man irgendein Event starten will? Was muss ich tun in der Firma? Mit wem muss ich sprechen? Könnte natürlich schon großteils übernommen werden und dann kannst du auch die 20 Leute betreuen als Engineering Manager in Zukunft.

Andy Grunwald (00:34:16 - 00:34:46)

Du hast einen Punkt, ich stimme dir aber nicht zu, weil wenn dein Punkt, wenn du mit deinem Punkt recht hättest, wäre das jetzt schon der Fall. Weil das, was du eigentlich sagst, lies die Dokumentation und in jeder Firma gibt es eine Dokumentation oder in vielen Firmen gibt es eine Dokumentation, wie man was und so weiter macht, ein Standard Operational procedure oder ähnliches. Besonders in Konzernen, wie wir hier gerade besprechen, wie bei TUI. Leute werden trotzdem gefragt. Und warum? Weil Fragen einfacher ist als suchen und tun.

Wolfi Gassler (00:34:46 - 00:35:26)

Ja, aber du kannst ja dann den Chatbot fragen. Also es war ja der Tom Bartel, den wir auch mal in einer Episode hatten, der hatte das ja so gemacht damals, dass er sich für Fragen, die er oft erhalten hatte, hat er sich einfach die Zeit genommen, einen Blogpost zu schreiben. Und dann hat er am Ende nur mit die Blogposts an die Leute geschrieben. Wenn er jedes Mal eine Frage bekommen hat, die er schon beantwortet hat, hat er gesagt, lies dir mal den Blogpost zuerst durch. Da stehen schon die relevantesten Dinge drinnen. Und wenn du das noch automatisieren könntest in irgendeiner Form, kann ich mir schon vorstellen, dass es zumindest weniger Leute vielleicht braucht oder gewisse Fragen gar nicht mehr zu dir kommen als Engineering Managerin, sondern die im Vorfeld einfach schon über irgendeinen Chatbot oder so erledigt werden.

Andy Grunwald (00:35:26 - 00:35:30)

Kann man so machen. Dann leidet halt die Empathie und das Zwischenmenschliche.

Wolfi Gassler (00:35:30 - 00:35:52)

Aber ja, also ich meine, das ist ein allgemeines Problem. Also ich sage ja nicht, dass es die Stelle nicht mehr geben wird, aber ich könnte mir schon vorstellen, dass sich die Stelle auch ändert, inwieweit man wie weiterhilft den Leuten und wie der Fokus dann schlussendlich ist. Aber dass es die Stelle grundsätzlich braucht, davon bin ich schon mal vorläufig noch überzeugt, würde ich mal sagen.

Andy Grunwald (00:35:52 - 00:35:56)

Ich hoffe, dass die Stelle sich ändert, denn wie Stromberg schon sagte, wenn ich mit der Zeit geht, geht mit der.

Wolfi Gassler (00:35:56 - 00:37:12)

Zeit aber auch die Motivation, die Prozesse zu verändern, was Jan gesagt hat, ist glaube ich auch ganz wichtig, weil genau darum geht es, dass du auch deinen Impact ja änderst eigentlich oder wie du den Impact schaffst und dass du mehr auf eine Prozessebene gehst und auf eine höhere Ebene gehst, wo du dann mit deinem Impact noch mehr bewegen kannst, weil du eben den Prozess optimiert hast. Aber auch da ist die kann es in Zukunft nicht vielleicht ein Tool auch besser? Machst die Analysen, wie dein Prozess abläuft und dann bekommst du irgendwelche Recommendations von irgendwelchen Tools, wie du den Prozess verbessern kannst. Also auch da könnte das Ganze natürlich schon Process Mining und so weiter weiterhelfen. Aber grundsätzlich, dass man sich wegbewegt von dem klassischen Hands on Programmieren in die Prozessoptimierung, das ist sicher ein ganz wichtiger Punkt beim Engineering Manager und Managerin. Und umso weiter man nach oben geht, umso höher ist die Ebene, die Prozessebene, auf der man dann agiert. Und wenn man halt auf CTO Ebene ist, dann bestimmt man den globalen Prozess auf der gesamten Firmenebene, wie Teams zusammenarbeiten, wie Abteilungen zusammenarbeiten. Also es geht dann immer eigentlich um die Prozesse. Man muss sich dann vom Coding mehr verabschieden und muss Prozesse lieben lernen. Also das ist, glaube ich, schon eine wichtige Motivation, die man mitbringen muss und die einem auch bewusst sein muss, wenn man in diese Richtung sich bewegt.

Andy Grunwald (00:37:12 - 00:37:54)

Nebenbei habe ich dein LinkedIn Profil auf mit deiner Berufserfahrung. Und da du jetzt gerade darüber gesprochen hast, was CTOs tun, kann ich nur mutmaßen, dass du das aus Hörensagen widerspiegelst. Denn laut deinem CV warst du noch nie CTO, aber du bist direkt von der Universität in eine Engineering Manager Rolle gewechselt. Und deswegen interessiert mich, wie bist du eigentlich in die Rolle gekommen? Was war eigentlich deine Motivation, Engineering Manager zu werden? Und die Frage stelle ich jetzt nicht, weil ich ganz stark interessiert bin an deinem Leben. Doch, bin ich natürlich auch, sonst würde ich hier dieses Projekt nicht mehr als drei Jahre mit dir machen. Aber diese Frage kommt unter anderem auch von Jan. Jan wollte mal wissen, was unsere Motivationsgründe waren bzw. Wie wir in die Rolle gekommen sind.

Wolfi Gassler (00:37:54 - 00:38:20)

Also grundsätzlich nochmal auf deine Anmerkung zum CTO zurückzukommen. Gerade du müsstest ja wissen, dass man eigentlich nicht sich irgendwo gut auskennen muss, damit man irgendwie gescheit daherreden kann, wie man bei uns sagt. Also es ist ja auch so, dass die sehr guten Fußballtrainer nicht unbedingt die guten Fußballer waren. Also man muss nicht unbedingt CTO gewesen sein. Außerdem ist man ja gleich mal CTO. Also meine eigene Firma, da bin ich dann eigentlich schon CTO in dem Sinn.

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

Wie viele Prozesse setzt du den für dich auf?

Wolfi Gassler (00:38:22 - 00:39:53)

Ja, ich habe schon zur Selbstoptimierung ein paar Prozesse aufgesetzt. Doch, doch, es gibt schon ein paar Checklisten und Tools, die ich verwende. Also von dem her gilt es sogar. Aber zurückzukommen zu deiner Frage. Ich war ja früher auch selbstständig. Also ich habe nicht nur diese Rolle an der Uni gehabt, sondern war auch selbstständig und habe dort eigentlich schon Teams auch angeleitet in der selbstständigen Funktion, Freelancer Teams und so weiter. Also ich war damit schon vertraut. Ich glaube nämlich auch, dass es sonst schwierig ist, wirklich in Leadership Rollen reinzukommen von außen in eine Firma, wenn man noch nie davor in irgendeiner Form mit Leadership zu tun gehabt hat. Also das ist, glaube ich, schon schwierig. Meine persönliche Motivation war eigentlich, dass ich einfach mal was Größeres kennenlernen wollte, also eine größere Firma. Da war die Position gar nicht so wichtig. Aber ich habe mir natürlich schon eher so in den Senior Leadership Rollen herumgetrieben, würde ich mal sagen, in den Job Ads. Aber es war nicht ein Must. Und dankenswerterweise, die Leute, die mich interviewt haben damals, haben das Vorwissen aus meiner Selbstständigkeit, aber auch an der Uni mit Projektmanagement und mit Studis als sinnvoll bewertet, dass sie mir das zugetraut haben, was ich übrigens sehr cool finde, weil es eben nicht unbedingt der Standard ist. Also dass man eine Erfahrung schätzt, die nicht genau dieselbe Erfahrung ist, die man eigentlich sucht. Also dass man sagt, okay, du musst schon einmal in einer großen Firma einfach ein Team geleitet haben, genau so und so groß, damit du jetzt bei uns ein Team leiten kannst, was ja ganz oft eigentlich die Voraussetzung ist.

Andy Grunwald (00:39:53 - 00:40:04)

Das klingt auch nach einer Art Diversifikation. Da ist das englische Wort einfacher. Diversity. Willst du da mitgehen? Weil Diversity ist ja nicht nur Geschlecht, Religion, Herkunft.

Wolfi Gassler (00:40:04 - 00:40:25)

Also ich persönlich bin ja ein großer Fan davon. Ich sage nur, dass es oft eben nicht so gehandhabt wird. Damals war es vielleicht auch einfach so, dass es schwer war, Leute zu finden, die so Leadership Rollen übernehmen hätten können. Also was ich so gehört habe. Und wir haben ja auch danach, nachdem ich bei Trivago angefangen habe, ja, verzweifelt würde ich fast sagen, Leadership Leute gesucht.

Andy Grunwald (00:40:25 - 00:41:50)

Bei mir war es alles ein bisschen anders. Ich hatte gar keine richtige Motivation, bei mir war es eher ein Unfall. Kurz zusammengefasst war die Story eigentlich so im Engineering Team kamen dann die Ops Leute an und hey Jungs, wir haben ein bisschen Probleme mit der Datenbank. Ich starte die ganze Zeit neu, aber irgendwie gehen die Probleme nicht weg. Kann sich das wer ansehen? Habe ich meine Hand gehoben, habe mir das angesehen, habe das erste Problem behoben. Danach habe ich meinem Chef hör mal du, wir haben ein paar mehr Probleme auf dieser Ecke mit den ganzen Datenbanken und so. Dann hat er mir einen anderen Mitarbeiter an die Seite gestellt. Dann haben wir da zusammen dran gearbeitet. Dann habe ich gesagt, wir haben doch noch ein paar mehr Probleme. Und irgendwann war dann die okay, ja, dann fang an, ein Team aufzubauen. Ich hatte von Tuten und Blasen keine Ahnung, bin deswegen so ein bisschen via Unfall da reingerutscht. Und dann hatte ich zum Glück ein paar sehr, sehr fähige Leute an meiner Seite, die mir vielleicht auch den Einstieg auch sehr einfach gemacht haben, gebe ich zu. Aber so bin ich dann da in die ganze Thematik reingerutscht, habe es lieben gelernt. Und deswegen kann ich gar nicht sagen, ob ich eine wirkliche Motivation hatte, oder seitdem habe ich vielleicht die Motivation geboren, ich möchte einfach nur coolen Scheiß mit coolen Leuten machen und habe dann Freude entwickelt, wenn die auch wirklich Bock an der Arbeit haben, wenn die den Bug fixen und dann gefühlt nackig durch die Wohnung rennen. Wenn wir aber schon über die Motivation sprechen und über Teamleitung und Co. Dann war meine nächste Frage an Jan, ob er es als einen klassischen Karriereschritt ansieht, in eine Führungsrolle zu wechseln?

Jan Semrau (00:41:50 - 00:42:14)

Auf der klassischen Ebene auf jeden Fall. Also wenn man jetzt anfängt als Junior Entwickler und dann als Mitdev und dann irgendwann mal Senior wird und dann ist so von meinem Verständnis her die klassische Karriereleiter, dann ins Management zu gehen auf unterster Ebene. Wie es dann weitergeht über die Jahre, ist wieder eine andere Sache. Aber für die klassische Hierarchie Karriereleiter sehe ich das schon als Karriereschritt.

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

Wie sieht es mit der monetären Vergütung aus? Gibt es aus deiner Sicht automatisch mehr Geld als Führungskraft im Vergleich zu sehr erfahrenen, hochspezialisierten Senior entwicklern?

Jan Semrau (00:42:25 - 00:42:42)

Das würde ich aus meiner Einschätzung her nicht direkt unterschreiben, aber aus meiner Einschätzung her kann es sein, dass der Weg zu mehr Gehalt durch eine Führungskraft oder durch eine Position einer Führungskraft schneller erreicht werden kann als ein hochspezialisierter Mitarbeiter.

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

Ist mehr Geld auch eine Motivation für dich?

Jan Semrau (00:42:44 - 00:42:54)

Ja, es ist eine Motivation, klar. Mehr Geld bedeutet häufig auch eben mehr Wohlstand. Das ist auch ein Ziel, klar. Ja, mehr gibt es dazu nicht zu sagen.

Andy Grunwald (00:42:54 - 00:43:01)

Ne, alles gut. Ich meine, Miete muss gezahlt werden. Du, also wir arbeiten nicht für Luft.

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

Und Liebe, aber Andi, willst du mir jetzt sagen, dass du als normaler Entwickler dir keine Wohnung leisten könntest oder die Miete bezahlen könntest als normal unter Anführungszeichen sterblicher Entwickler?

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

Kann ich mir als normaler Entwickler eine dreiig Quadratmeter Wohnung im duisburger Norden leisten? 100. %. Kann ich mir als normaler Entwickler eine Penthouse Wohnung in den kölner Kranenhäuser leisten? Wahrscheinlich nicht. Deswegen würde ich auch wieder sagen, kannst.

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

Du dir das als Engineering Manager leisten?

Andy Grunwald (00:43:30 - 00:43:34)

Ich glaube auch nicht, aber das war nicht die Frage. Aber natürlich kann man.

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

Aber dich motiviert Geld auch, so wie das mitbekommen habe, oder?

Andy Grunwald (00:43:38 - 00:44:10)

Ich sag nur ganz Miete muss gezahlt werden, gute Arbeit soll belohnt werden. Punkt. Ich sage nicht, dass ein Engineering Manager automatisch mehr Geld verdient, das habe ich nicht gesagt. Aber man muss auch mal auf dem Teppich bleiben, denn auch als Software Engineer arbeiten wir in einer sehr, sehr privilegierten Branche. Und wenn ich mir zumindest die Statistiken in Deutschland ansehe, was die Durchschnittsgehälter angeht, ab wann man als reich gilt und Co. Da würde ich schon fast sagen, dass sehr, sehr, sehr viele Entwickler in diesen Bereichen mitspielen.

Wolfi Gassler (00:44:10 - 00:44:34)

Da kann wieder meinen tollen Link von diesem kölner Institut gerne verlinke ich in den Shownotes, wo man sich vergleichen kann mit der restlichen Gesellschaft in Deutschland, weil ich glaube auch, dass Entwickler innen eher so in den Top 10 % wahrscheinlich liegen in Deutschland. Aber die eigentliche Frage war ja, was Jan beantwortet hat, ob das für ihn ein Karriereschritt ist und ob man damit schneller auch ein höheres Gehalt bekommt und.

Andy Grunwald (00:44:34 - 00:45:04)

Den wichtigen Zusatz, den Jan gesagt in der klassischen Karriereleiter. Denn in der ganz klassischen Karriereleiter in einem Traditionskonzern in Deutschland würde ich fast ja, es ist ein Karriereschritt. In der modernen Karriereleiter bin ich da überhaupt nicht mit d'accord, denn ich denke, es ist kein Karriereschritt. Ich denke, es ist 100 prozentiger Berufswechsel. Man arbeitet zwar in demselben Segment und man macht einfach einen anderen Job. Punkt, aus, Ende.

Wolfi Gassler (00:45:05 - 00:45:52)

Wobei, ich sage das ja auch immer gern, es ist kein Karriereschritt, sondern ein neuer Job, den man beginnt, weil man neue Fähigkeiten braucht. Ganz andere Tätigkeiten sind, haben wir schon gesprochen, mehr Prozess, weniger Coding oder weniger Architektur. Aber man muss schon auch sagen, üblicherweise verdienen Engineering Manager mehr. Man muss davor üblicherweise auch Entwickler in gewesen sein, damit man in diese Position überhaupt kommt. Also man hat schon was davor. Insofern ist es natürlich schon in gewisser Weise ein Karriereschritt, würde ich mal sagen. Auch wenn es natürlich so ist, dass es nicht klassisch ein Job ist, wo man dann das, was man bisher gelernt hat, noch intensivieren kann und dadurch dann noch mehr Gehalt bekommt, sondern es ist halt schon eine andere Art. Aber man braucht durchaus das Vorwissen aus der Zeit, wo man Entwickler, Entwicklerin war.

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

Ja, da widersprichst du dir ja gerade so ein bisschen. Wenn du sagst, okay, der Engineering Manager hat nur disziplinarische Führung und nicht fachliche Führung, dann sage ich dir jetzt schon mal, okay, dann kannst du da auch jemanden hinsetzen mit einem MBA.

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

Kannst du, auch wenn er gar keine fachliche hat. Aber ich habe nie behauptet, dass er keine fachliche hat. Also wenn du reine People Manager hast, dann ist ja okay, wenn du jemanden aus HR mit einem MBA, was es auch immer ist, hinsetzt, ist ja auch legitim. Und das gibt es ja auch, aber ist auch schon eher die Seltenheit, weil du ja schon deine technische Expertise mit einbringst, üblicherweise in diese Rolle.

Andy Grunwald (00:46:24 - 00:48:29)

Und wenn wir von Karriereschritt reden, dann denke ich mir immer, okay, ein Schreiner, der in seiner Schreinerkarriere weitermacht, der wird sich besser mit Holz auskennen, der wird mit mehr Holzarten gearbeitet haben, der wird mehr Projekte gemacht haben und deswegen kennt er mehr Kniffe und Co. Und ist erfahrener in seiner Thematik. Und wenn wir das jetzt auf Software entwickeln übersetzen, dann ist der Karriereschritt für mich eigentlich, okay, du bist Seniorentwickler, dann bist du vielleicht Staff oder Architekt oder Senior Staff oder principal. Das bedeutet, das, was du gerade sagtest, man vertieft seine Kenntnisse, man macht vielleicht größere Projekte mit größerem Uservolumen, mit komplizierteren Aufgaben und Co. Und deswegen, von meinem Verständnis von Karriere, ist es die Vertiefung einer Thematik. Und wenn man ins Management geht, dann ist es eher ein Seitwärtsschritt. Und ein Seitwärtsschritt kann natürlich immer noch im Engineering Bereich sein. IT ist ja nicht gleich IT. Und deswegen sage ich, es ist kein Karriereschritt auf der klassischen Leiter, was das Gehalt angeht. Ich hatte Leute schon bei mir im Team, die mehr als ich verdient haben und das ist okay, hatte ich auch. Denn wenn du das so siehst, dass es kein Karriereschritt auf der Leiter ist, dann sind die ja nicht unter dir, sondern sie machen nur einen anderen Job und du bist dafür verantwortlich. Das heißt nicht, dass sie weniger Verantwortung tragen, das heißt nur eine andere Verantwortung. Nehmen wir mal zum du bist verantwortlich für das Team, du hast Personalverantwortung. Sie können aber verantwortlich sein für die technische Reliability von Google Mail z.B. und dann ist die muss ein Engineering Manager immer mehr verdienen? Auch gerechtfertigt? Nein, dann ist sie nicht gerechtfertigt. Entschuldigung, dann ist die Frage nicht gerechtfertigt. Denn wenn jemand die technische Verantwortung für Google Mail hat oder für dein Flagship Produkt, was ihr in der Firma habt, dann steckt da auch ein Riesenvolumen hinter. Und all Die ganzen Thematiken wie Cost of living und so weiter, lassen wir jetzt mal außen vor. Also wenn jetzt jemand in San Francisco arbeitet, dann hat er auf dem Paycheck natürlich mehr Geld stehen als ich hier in Deutschland. Aber die Cost of living sieht auch ganz anders aus, es sei denn, ich wohne in den kölner Kranhäusern.

Wolfi Gassler (00:48:29 - 00:49:26)

Ich persönlich bin sowieso der Meinung, dass diese Aussage, ich habe mehr Verantwortung jetzt in einem Job und diese Verantwortung muss mir abgegolten werden und ich muss mehr verdienen, weil ich die Verantwortung habe, damit kann ich sowieso eigentlich nie so viel anfangen, weil es ist ja trotzdem nur ein Job. Also diese Verantwortung, das ist nichts, was irgendwie mir Nachteile gibt, dass sie das irgendwie ausgeglichen haben will mit Geld. Natürlich vielleicht weiter oben, dass ich leichter den Job verliere, wenn ich verantwortlich bin, okay, das kann schon sein, aber sonst kann ich mit dem eigentlich relativ wenig anfangen, weil ich arbeite trotzdem nur meine 40 Stunden und die Verantwortung an sich ist ja nichts, was ich bekomme, nur weil ich jetzt, keine Ahnung, fünf Jahre studiert habe, mehr als andere oder sowas z.B. also das ist ja schon klar, wie vielleicht einen anderen Wert für die Firma, aber dass Verantwortung automatisch bedeutet, ich muss viel, viel mehr Geld bekommen, damit kann ich eigentlich wenig anfangen, aber es ist mehr eine persönliche Meinung von.

Andy Grunwald (00:49:26 - 00:49:58)

Aber auch in eher traditionelleren Unternehmen gibt es natürlich Gehaltsbänder und die werden dann in der Regel an sogenannte Level geknüpft. Und in der Regel ist ein Engineering Manager im Management Track aufgehangen, und oft werden Manager Tracks auf traditionellen Firmen ein bisschen besser gezahlt. Das ist zumindest das, was ich so gesehen habe. Was aber auch bei Firmen der Fall ist, die auch die klassische Fachkarriereleiter haben, das bedeutet Senior Staff und so weiter, ist dann, dass das Staff Level auf demselben Level ist wie ein Engineering Manager und somit im selben Gehaltswand.

Wolfi Gassler (00:49:58 - 00:50:49)

Und das leuchtet mir viel mehr ein, weil da geht es eigentlich darum, wenn ich 1 Stunde investiere, kann ich dann mehr Impact haben? Und wenn ich natürlich 1 Stunde investiere, um irgendeinen Prozess zu verbessern, dass dann jede Person in meinem Team 5 % besser arbeiten kann, egal ob als Staff oder als Engineering Manager. Aber in so einer Rolle, dann bin ich natürlich für die Firma an sich mehr wert und vielleicht brauche ich da auch mehr Erfahrung dazu, wie Projekte ablaufen, wie ein Projekt sauberer abläuft, wie gut der Tech Leadership aussieht und solche Dinge. Dann macht es für mich Sinn, okay, dann bin ich mehr wert, bekomme vielleicht auch mehr Gehalt, egal ob als Staff oder als Engineering Manager. Aber nur, dass ich die Verantwortung habe und vielleicht jetzt one mache, heißt es ja noch lange nicht, dass ich der Firma mehr bringe. Also da sehe ich nicht automatisch den Zusammenhang zumindest. Also ich muss schon auch beweisen, dass ich am Ende mehr Impact haben kann.

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

Jetzt ist die große Coaching, Mentoring, will Jan den Job wirklich? Und wenn man sich die Frage stellt, dann fragt man was hat er denn bereits probiert bzw. Getan, um diese Position zu bekommen?

Jan Semrau (00:51:03 - 00:51:39)

Ich habe das aktuell ja nicht vor in nächster Zeit und von daher habe ich jetzt auch aktiv nichts dafür unternommen, aber ich möchte es in Zukunft werden. Und die Bereitschaft grundsätzlich ist da, auch selbst zu handeln, Probleme zu erkennen, Dinge zu moderieren, zu gucken, was kann optimiert werden? Ergibt dieser Prozess Sinn? Und einfach schon ein Stück weit in die Richtung zu kommen, wie eine Führungskraft zu denken, auch wenn das noch nicht aktuell der Fall ist und auch nicht der Fall werden soll. Aber schon Erfahrungen zu sammeln in so kleinen Dingen wie Moderation, selbstständiges Arbeiten, Probleme zu erkennen und Prozesse zu optimieren, finde.

Wolfi Gassler (00:51:39 - 00:51:49)

Ich persönlich eine sehr sympathische Antwort, weil man auch nicht sofort mit der. Wie ist der Spruch? Tür durch die, durch die. Andi, wie heißt das Ding?

Andy Grunwald (00:51:49 - 00:51:50)

Mit der Tür ins Haus fällt.

Wolfi Gassler (00:51:50 - 00:51:55)

Danke, danke. Mit dem Kopf durch die Wand. Wild. Das wollte ich eigentlich sagen.

Andy Grunwald (00:51:55 - 00:51:57)

Da kommt aber keine Tür vor.

Wolfi Gassler (00:51:59 - 00:53:33)

Also dass man das grundsätzlich mal gemütlich angeht, ist glaube ich, eine sehr gute Idee, weil dann kann man vielleicht warten, ob sich irgendwo eine Chance ergibt, die man dann einfach ergreifen kann. Und die Herangehensweise, dass man jetzt schon probiert, möglichst diese Dinge auch zu stärken. Das ist, finde ich, auch eine super Herangehensweise, weil das beantwortet vielleicht meine eigene Frage, die ich ganz am Anfang mal gestellt was kannst du nicht tun in der aktuellen Situation, was du tun könntest in der Engineering Manager Rolle? Und ich glaube eben, dass es relativ wenig ist, außer dass es dann vielleicht mehr Gewicht findet und du auch mehr eigentlich dafür gezahlt wirst, als wenn du das als individual contributor schon machst. Aber es gibt, glaube ich, ganz viele Dinge, die man da machen kann, einfach indem man als mit Leading bei example gut vorangeht im Team, dass man einfach den anderen weiterhilft, dass man die Kommunikation verbessert im Team, das ist auch kein Problem, dass man andere Teammitglieder vielleicht hochleben lässt, wenn sie mal was Gutes machen. Also diese ganzen Dinge, die man so auch in einer Leadership Position machen muss, die kann man ja auch als individual Contributor machen. Gutes Code Review, irgendwie Mentorship machen, andere irgendwo unterstützen in dem Projekt oder wenn sie neu beim Onboarding sind. Also diese Dinge kann man alle machen und da kann man auch definitiv Experience aufbauen. Und wenn man sich das dann noch in Bread Document schreibt, dann kann man später mal, wenn es wirklich darum geht, in so eine Stelle zu gehen, kann man auch sagen, ich war zwar offiziell noch nie in so einer Stelle, habe aber da schon auf jeden Fall einen Junior gemintert oder drei Juniors gemintert und habe die und die Tätigkeiten gemacht, so und so viele Code Reviews, habe weitergeholfen etc. Ich stimme dir zu.

Andy Grunwald (00:53:33 - 00:54:26)

Sehr sympathisch. Besonders die Aussage, wie eine Führerkraft zu denken. Und das hat mich an eine Situation erinnert. Ich habe mir die Frage jetzt wird eine Teamleiterstelle frei. Wie sorgt man dafür, dass Jans Name auf die Liste von möglichen Kandidaten kommt? Wie mache ich mich ready, dass ich auf diese Liste komme? Und da fiel mir mache den Job bereits, ohne die Rolle zu haben. Denn wenn du diesen bereits agierst, wenn du schon so agierst, dann kommst du automatisch auf diese Liste, automatisch in dieses Sichtbarkeitsfeld von den Leuten, die das entscheiden. Und das fand ich recht schön. Richtiges Mindset meines Erachtens. Jan, mach weiter so. Jetzt agiert man aber schon in dieser Rolle. Und jetzt ist die nächste Wie kommt man denn an diese Position? Und ich habe Jan die Frage gestellt, was er denkt, was leichter ist. Ist es leichter, an diese Position zu kommen im eigenen Unternehmen oder bei einem Arbeitgeberwechsel? Hören wir mal rein, was er zu sagen hat.

Jan Semrau (00:54:27 - 00:55:18)

Ich weiß es natürlich nicht, aber ich kann es mir vorstellen, dass es leichter ist, von außen herein sich neu zu bewerben und dann in eine andere Firma zu kommen und dort gleich als Engineering Manager, Technology Team Lead zu starten. Ich weiß aus Erfahrung von anderen Kräften, dass der Weg relativ lang sein kann in Führungspositionen und es muss ja auch überhaupt erstmal eine Stelle da sein. Also es ist ja auch nicht so, dass wenn ich sage, okay, ich möchte Führungskraft werden und mein Chef würde auch ja, sehe ich, dass ich das dann auch in den nächsten Monaten werden kann, weil überhaupt eine Stelle dafür da ist. Es ist eben manchmal auch nötig, das Unternehmen zu wechseln, weil überhaupt die Position bei uns gar nicht, gar nicht da ist. Aber auch von dem, was ich bisher so gehört habe, wenn man jetzt Karrieresprünge machen möchte, dass man die in der Regel nicht innerhalb eines Unternehmens macht, sondern durch Arbeitgeberwechsel. Und ich glaube, dass das auch mit der Führungskraft einfacher ist, statt innerhalb des Unternehmens sich woanders zu bewerben und dann in eine andere Rolle zu kommen.

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

Wenn ich mich recht erinnere, Wolfgang, hast du auf diese Frage schon partiell geantwortet. Du hast bei einer anderen Frage gesagt, dass du denkst, dass es leichter ist, an eine solche Stelle zu kommen, wenn man das Unternehmen wechselt. Ist das korrekt?

Wolfi Gassler (00:55:32 - 00:56:36)

Eher umgekehrt. Also ich gehe gar nicht mit dem Jan. Es ist zwar vielleicht leichter überhaupt eine offene Position zu finden, klar, weil in der eigenen Firma gibt es meistens nicht so viele Leadership Positionen. Glaube aber, dass es wesentlich einfacher ist, innerhalb von der Firma zu wechseln in eine Engineering Manager Rolle, weil wie das eben schon erwähnt habe, wenn du dich irgendwo bewirbst, die suchen Leute mit Erfahrung. Also die wollen meistens schon sehen, dass du in dieser Rolle gewesen bist, gerade wenn es um Leadership Themen geht. Also es gibt glaube ich wenig Firmen, aber sind wirklich verzweifelt, weil sie Hypergrowth haben und so viele Leute brauchen und am Markt gibt es keine Leute, dass sie sich auch einlassen auf irgendwas, wo man sieht, es sind Leute, die motiviert sind, die den richtigen Mindset haben und dann in so eine Rolle einsteigen. Aber innerhalb von dem Team, innerhalb von der Firma kennen dich die Leute ja schon, die wissen, wie du tickst, dein Lead kennt dich vielleicht. Und wenn dann sich irgendwo etwas auftut, eine Chance sich ergibt, glaube ich, dass es innerhalb von der Firma wesentlich leichter ist, weil das Vertrauen einfach schon da ist.

Andy Grunwald (00:56:36 - 00:58:49)

Das was Wolfgang sagt, das was Wolfgang man höre diesem Mann zu, ich stimme zu. Also es ist bei einem Wechsel in eine andere Firma ist es unglaublich schwierig, da ein Engineering Manager eine Multiplikatorrolle ist und die seltensten Firmen einen Junior EM oder einen Junior Tech Lead suchen. Denn die Frage ist, welche Qualifikation hat man, um Leute zu leiten? Und du bewirbst dich bei einem neuen Unternehmen, die kennen dich noch nicht, die wissen nicht, ob du die Rolle bereits ausgefüllt hast oder nicht. Und damit du die Chance kriegst, diesen Leuten das zu beweisen, musst du erstmal ins Interview eingeladen werden. Das bedeutet, die erste Hürde, die du überspringen musst, ist die Lebenslaufhürde. Und wenn da nicht drinsteht Leadership Erfahrung, dann ist es oft so, du kommst nicht ins Interview. Und das wird in Zukunft nicht leichter mit diesen ganzen AI Aussortierungs algorithmen und Recruiter, die hart sind und so weiter. Die kennen dich alle nicht und die sehen nur deine Präsentation in deinem Lebenslauf. Und deswegen ist das relativ schwierig. Was einfacher ist, und das war auch bei mir der Fall, in stark wachsenden Unternehmen, da muss der Need schnell gelöst werden. Das, was Wolfgang auch gerade gesagt hat, was natürlich ein externer Faktor ist, den du nicht beeinflussen kannst, ist die ökonomische und die wirtschaftliche Lage. Wie geht's der Reiseindustrie, wenn wir jetzt von Trivago sprechen oder von Booking oder von Airbnb? Wie geht es der Cloud Industrie, wenn wir jetzt von Amazon, Microsoft, Hetzner und OVH sprechen und Co. Ich merke gerade, Reiseindustrie ist natürlich auch TUI. Wie geht es? Also TUI in unserem Beispiel jetzt hier, deswegen stark wachsende Unternehmen, Quote und Quote. Start ups ist da schon eine leichte Thematik, weil da werden neue Teams am laufenden Band gegründet, aber auch geschlossen. Das ist das Risiko und vielleicht auch, das muss der Wolfgang jetzt bestätigen oder nicht, aber das ist mein Gedankengang, weil auf den Wolfgang trifft das zu, wenn man einen hohen Bildungsgrad hat, einen hohen akademischen Bildungsgrad. Denn als Wolfgang bei Trivago reingekommen ist, hatte er noch keinen Doktortitel, war aber kurz davor, plus minus drei Jahre oder zwei Jahre. Aber wenn man Doktortitel hat oder bzw. Kurz davor, dann kann ich mir auch schon vorstellen, dass man auf jeden Fall die Fähigkeiten abgesprochen kriegt, dass man ein Team leiten kann. Ist das richtig, Wolfgang?

Wolfi Gassler (00:58:49 - 00:58:52)

Abgesprochen Meinst du, dass man es nicht hat?

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

Nee, nee. Wie heißt das denn? Dass jemand sagt, der muss einen Dr. Haben oder der hat jetzt bald einen Dr. Und deswegen kann er das. Also man traut dem das zu.

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

Ja, keine Ahnung, ob jetzt ein Dr. Irgendwie Leadership beeinflusst. Also würde jetzt mal nicht sagen. Es kann natürlich sein, dass du schon viele Projekte innerhalb deiner Dr. Zeit gemacht hast und vielleicht viele Studis betreut hast, dann ist es was anderes. Da hat man ja auch in gewisser Weise Leadership Erfahrung, ein bisschen zumindest in gewissen Bereichen. Auch wenn das natürlich andere Leadership Erfahrungen sind und jetzt kein klassisches Team natürlich.

Andy Grunwald (00:59:26 - 00:59:32)

Obwohl man schon sagen muss, dass viele Leute mit Doktortiteln auch in C Level gehoben werden.

Wolfi Gassler (00:59:32 - 00:59:50)

Es hilft dir dann wahrscheinlich ab einem gewissen Grad wieder, wo irgendwie verlangt wird, dass du eigentlich so ein Doktortitel womöglich hast. Also da kannst du dann wieder helfen, umso höher du in der Leiter bist, weil es einfach irgendwie Eindruck macht. Obwohl wie gesagt, keine viele Leute, die einen Dr. Haben. Ja, ich will gerne nicht ins Detail.

Andy Grunwald (00:59:50 - 00:59:57)

Gehen, das bringt mich zu einer anderen Frage. Lohnt sich erst ein Dr. Zu machen, um dann eine Engineering Manager Stelle zu bekommen?

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

Auf keinen Fall, würde ich mal sagen. Also macht absolut keinen Sinn. Aber ich glaube, was du gesagt hast, auch, dass der Markt schwieriger wird. Es ist sicher der Fall, gerade aktuell, weil die Firmen sich halt eher verschlanken und kleiner werden und darum gibt es noch viel weniger Leadership rollen. Und auch mit anderen Leuten gesprochen und habe das jetzt öfters bestätigt gehört, dass sich oft Leute bewerben, die überqualifiziert sind, die eigentlich Direktor waren und vielleicht noch höher und die jetzt sich auf Teamlead bewerben, weil einfach der Markt aktuell keine Stellen mehr hat in dem Bereich. Also das ist schon ein großer Punkt. Das ist aktuell sicher schwieriger. Und wenn man dann gar keine Erfahrung hat, ich glaube, dann ist es, dann ist man chancenlos. Also üblicherweise ist es dann eher so, man ist bei einem kleinen Startup, übernimmt ein Team und geht dann vielleicht einen Schritt größer in eine größere Firma oder in, keine Ahnung, Mittelstand und geht dann in irgendwie eine größere Firma oder in eine coole Tech Firma, also von derselben Rolle im Prinzip, aber die Firma wird dann größer oder der Anspruch wird dann höher. Diese Möglichkeit besteht dann eher.

Andy Grunwald (01:01:01 - 01:01:52)

Lasst euch von der wirtschaftlichen Lage gerade nicht demotivieren, denn vor drei Jahren sah die ganze Sache anders aus. Da hat man eine Zeile Code schreiben können und hat teilweise ein sechsstelliges Gehalt angeboten bekommen. Also das kann sich auch wieder ändern. Die eine Baustelle, die zweite Baustelle. Wir reden hier in Jans Situation über einen Konzern mit Mitarbeitern, wo die IT Abteilung oder IT Firma circa 800 Mitarbeiter hat, 800 Mitarbeit. Das sind ein paar Teams und auch da gehen Leute in Rente, auch da wechseln Leute die Firma, auch da werden Positionen frei. Es kann natürlich sein, dass in einem anderen Team dann irgendwann eine Teamleiterin, eine Teamleiterstelle frei wird und man sich dann intern weiter bewerben kann. Denn je größer die Firma, umso mehr Chancen kommen dann natürlich auch auf, unter der Voraussetzung, dass es keine Layoffs gibt. Also dann sieht die ganze Thematik natürlich wieder ein bisschen weiter.

Wolfi Gassler (01:01:52 - 01:02:31)

Es ist glaube ich sogar so, dass man das eigentlich ganz allgemein sagen kann, in der Firma kann man nach oben wachsen und in anderen Firmen geht man teilweise sogar nach unten. Es gibt ja da diesen bekannten Artikel, Andy, du kannst wahrscheinlich den Link auswendig. Wir werden auf jeden Fall in den Shownotes auch verlinken, dass wenn man Firma wechselt, dass man jetzt von einem Startup zu einer größeren Firma wechselt und im Startup war man Senior, dann steigt man wieder vielleicht als normale Entwickler in in der größeren Firma ein. Oder wenn man von Staff Level in der kleinen Firma ist und dann einen Schritt höher geht, dass man wieder in der neuen Firma dann in einem niedrigeren Level anfängt. Also es ist vielleicht sogar genau das Gegenteil, wenn man sich nach außen bewirbt.

Andy Grunwald (01:02:31 - 01:03:59)

Ja und nein. Also ich meine, ich glaube hier beim Engineering Management ist das eine spezielle Position beziehungsweise eine spezielle Situation. Denn wenn ich von einer Softwareentwicklerstelle in eine Management stelle wechseln möchte, dann würde ich sagen, innerhalb der Firma, wenn man jetzt von man hat bereits eine Teamleiterstelle und möchte vielleicht auf eine Director Stelle, dann ist das wieder sehr gut möglich bei einem externen Firmenwechsel. Denn wenn man einmal in dem Track drin ist, in dem Management Track, dann macht man größere Karrieresprünge beim Wechsel. Natürlich gibt es auch Beförderung und alles gut. Es gibt immer wieder Leute, die haben auch als Engineer bei Google angefangen und sind jetzt Google Fellow. Das ist das höchste der Gefühle bei Google und waren da auch VP und Senior VP und so weiter. Gibt es alles. Urs Hölzle ist z.B. so einer, aber der ist schon 22 Jahre da. Verlinken wir auch in den Shownotes, wer diesen Lebenslauf mal sehen möchte. Auch sehr impressive. Aber wenn man einmal in dem Track drin ist, dann kann man, glaube ich, über Firmenwechsel mehr springen. Wenn man jetzt aber, wie der Wolfgang schon sagte, von einem kleinen Startup nach Big tech wechselt, dann ist der Scale größer. Dann kann das sein, ob man Down Leveling hat vom Senior zum Mid level engineering. Wenn man jetzt aber dann von einer Big tech Firma wie Microsoft zu einem Startup wechselt und man war Senior Engineer bei Google, kann das auch sein, dass du sofort Architekt bei dem Startup wirst. Also das kommt dann immer ganz auf die, ich nenne es mal Problemstellung, die man bei dem Arbeitgeber dann hat. Darauf kommt es dann.

Wolfi Gassler (01:03:59 - 01:04:39)

Ich habe den Artikel mittlerweile gefunden, the Seniority Rollercoaster and Downleveling Intake. Das ist so der Klassiker. Ich würde dem aber auch sogar ein bisschen widersprechen, was du gesagt hast, weil ich glaube auch, dass es so ist, wenn du auf einer Director Ebene bist und dann in einem sehr großen, coolen Unternehmen anfängst, Google oder so, dann bist du meistens kein Director, sondern steigst du wieder eine Kategorie drunter ein. Also je nachdem, ob die Firma dann wirklich wichtiger und größer ist, steigt man meistens dann tiefer ein. Aber wenn du natürlich von oben kommst, von der großen Firma, keine CTO, dann wirst du auf dem CTO Level bleiben oder am Director level bleiben, wenn du schon in so einer Kapazunda Firma sozusagen drin bist.

Andy Grunwald (01:04:39 - 01:04:58)

Und wer jetzt immer noch dran ist, hat verstanden, dass wir denken, es ist ein anderer Job bzw. Ist nicht der gleiche Job, wie eine Softwareentwicklerin ausübt. Und das hat natürlich auch einen Effekt auf den Arbeitsalltag. Ich habe Jan gefragt, was seine Vorstellung eines klassischen Arbeitsalltags als Führungskraft ist.

Jan Semrau (01:04:59 - 01:05:57)

Wenn man sich das so klischeehaft vorstellt, sind es erstmal Meetings, Meetings, Meetings und keine Zeit, irgendwas dazwischen zu schaffen. Also ein voller Kalender von morgens bis abends. Wenn ich mir das jetzt aussuchen könnte oder vorstellen würde, dann würde ich grundsätzlich morgens erstmal ankommen, Mails checken, was am Nachmittag passiert, Nachrichten in Teams, Slack, was auch immer man hat, wer hat sich vielleicht abgemeldet aus dem Team, gucken, wer ist da, wie sieht das Board aus, was hat sich da so verändert? Und morgens dann die Zeit zu nutzen, Aufgaben noch nachzuarbeiten, was liegen geblieben ist oder eben für den Tag vorzubereiten. Der Tag startet dann meiner Meinung nach so richtig mit dem Daily, wenn alle zusammenkommen und gucken, was ist gestern passiert, was passiert heute? Und dann kann ich mir vorstellen, dass eben viele Meetings, Abstimmungen mit anderen Führungskräften, anderen Pods anstehen, one on ones mit den einzelnen Mitarbeitern. Und zwischendurch, wenn da mal Luft ist, werden dann eben diese Aufgaben aus den Meetings heraus abgearbeitet, vorbereitet, nachverarbeitet und dann hoffe ich, nach der normalen Zeit von 8 Stunden am Feierabend machen zu können.

Wolfi Gassler (01:05:58 - 01:05:59)

Jo, stimmt.

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

Also war dein Arbeitsalltag Meetings, Meetings, Meetings.

Wolfi Gassler (01:06:02 - 01:06:16)

Mein Arbeitsalltag war wirklich Meetings, Meetings, Meetings. Aber ich habe auch keine Dailies oder so vorbereiten müssen. Also es waren wirklich nur klassische Meetings. Aber wie gesagt, waren auch sehr viele ICs und ich hatte gute POs und Scrum Master, die das auch mit übernommen haben.

Andy Grunwald (01:06:16 - 01:06:27)

Kennst du noch dieses Shit Sandwich, wo man erst mit etwas Positivem beginnt, dann mit etwas Negativem und dann endet man wieder mit einem Positiven, damit das Feedback gut rübergebracht wurde.

Wolfi Gassler (01:06:27 - 01:06:29)

Ja, der Shit sandwich ist Shit.

Andy Grunwald (01:06:29 - 01:06:36)

Jans Vorstellung hat stark angefangen und stark nachgelassen. Nein, du meinst mit dem pünktlich nach.

Wolfi Gassler (01:06:36 - 01:06:39)

8 Stunden Feierabend machen. Das war das Problem, oder?

Andy Grunwald (01:06:40 - 01:07:53)

Könnte man sagen, gut, das hatte ich jetzt nicht so gemeint. Also ich denke, gibt es Tage, wo man wirklich echt viel in Meetings hängt? Ja, gibt es. Ist das auch verständlich? Ja, denn ich habe einen Lieblingsartikel von Paul Graham, der heißt Maker's Schedule Managers Schedule. Maker in diesem Kontext sind Softwareentwickler und Softwareentwicklerinnen. Sie brauchen eine lange Phase an Konzentration, mehrere Stunden, um etwas zu erzeugen, etwas zu machen, etwas zu maken. Und Manager schedule oft viele kleine Meetings, Kontextsprünge und so weiter. Also Jan hat nicht unrecht. Meine erste Frage ist als Gegenargument, wo bleibt denn da die Zeit zur Arbeit? Denn hoffentlich bereitet man Meetings vor, sie sind sinnstiftend und man hat Action Points danach, weil man etwas entscheiden muss, denn alles andere hätte eine e Mail sein können. Dann die zweite wenn man die ganze Zeit im Meeting steckt, wann denkt man denn nach und wann arbeitet man denn strategisch? Was meine ich jetzt damit? Es ist, ich glaube, als Neuling in dem Beruf sehr einfach, sich durch Meetings und externe Anfragen treiben zu lassen. Und es ist sehr schwierig, seine eigene Strategie zu verfolgen und seine eigenen Ziele zu verfolgen und explizit zu nein, ich nehme an diesem Meeting jetzt nicht teil, weil ich denke nicht, dass das sinnstiftend für mich ist.

Wolfi Gassler (01:07:53 - 01:09:04)

Das hat Jan übrigens auch noch uns als Frage gestellt. Also er hat gemeint, ich kenne viele Führungskräfte, die viele Überstunden machen. Wie kann man im Rahmen seiner Arbeitszeit bleiben und wie sind eure Erfahrungen diesbezüglich? Also das ist wirklich eine Herausforderung in dieser Rolle. Wie du richtig sagst, man bekommt extrem viele Einladungen, man kann bei extrem vielen Meetings mitmachen und da muss man dann wirklich selektiv das Ganze auswählen und sehr stark auswählen. Oder man investiert die vielen Überstunden. Aber es ist natürlich schon so, dass man sehr viel kommunizieren muss. Und Kommunikation ist meiner Meinung nach der Hauptteil dieses Jobs, in welcher Form auch immer. Meeting ist ja nur eine Form des Jobs, aber du brauchst natürlich auch irgendwelche Zeiten, wo du nachdenkst, wo du Strategieplanungen machst, wo du dir überlegst, was du in Meetings machst, wenn es jetzt nicht nur Meetings sind, die von außen reinkommen, wo du jetzt vielleicht nur unter anführungszeichen Teilnehmer bist. Also da gibt es schon Zeiten, die du einplanen musst. Und wenn man da das nicht in 8 Stunden unterbekommt, dann wird schon schwierig. Also es war schon für mich auch immer schwierig, muss ich sagen, in der Normalzeit zu arbeiten und man muss da schon wirklich einen Fokus drauflegen, dass man das in den Griff bekommt.

Andy Grunwald (01:09:04 - 01:09:57)

Als du gerade gesagt hast, man bekommt schon sehr viele Einladungen fiel mir ein Spruch ein, den ich sehr früh in meiner Karriere gelernt habe, von meinem damaligen wenn ich nicht mehr weiter weiß, bilde ich einen Arbeitskreis. Das ist so ungefähr. Besonders in größeren Firmen ist es gang und gäbe, dass da sechs bis 10 Leute im Meeting rumhängen. Und da fragt man sich ganz können die überhaupt alles irgendwie da was beitragen? Kann man nach 8 Stunden nach Hause gehen? Ja, kann man hundertprozentig. Ist das super schwierig? Ja, kann man. Ist das super schwierig? Ja, auf jeden Fall. Denn das ist genau der Punkt, den ich gesagt habe. Wenn man sich konstant treiben lässt, man nimmt jede Meeting Einladung ein, kümmert sich um jeden Kram, der auf deinen Tisch geworfen wird. Dann sage ich nein, du gehst nicht nach 8 Stunden nach Hause. Es ist immer die was tut man nicht? Was lässt man hinten rüber fallen? Denn ich würde mal fast sagen dreiig. 40 % der Sachen, die du auf deinen Tisch bekommst, sind nicht wichtig. Die kannst du einfach weglassen.

Wolfi Gassler (01:09:57 - 01:09:59)

Da schreit erledigen sich von selbst.

Andy Grunwald (01:09:59 - 01:11:52)

Ja, lass die einfach liegen. Und wenn von 20 Sachen, die du liegen lässt, zwei eskalieren und dein Vorgesetzter fragt noch mal nach, ganz im Ernst, dann ist das eine sehr gute Quote. Das ist okay. Dafür hat er bei den anderen 60 %, um die du dich gekümmert hast, gar nicht erst nachgefragt. Du hast die Probleme einfach nur gelöst. Von daher, Zeitmanagement ist sowieso super hart. Ich verfolge da Getting things Done, haben wir auch mal eine Episode zu gemacht. Und es ist sehr, sehr einfach, sich in diese Überstunden fallen zu lassen und sich treiben zu lassen. Und ich kenne auch Leute, die haben das ein Jahr gemacht, die haben das anderthalb Jahre gemacht und nach zwei Jahren waren sie dann länger krankgeschrieben wegen Burnout, weil sie neu in dieser Rolle waren, weil sie performen wollten und sie haben nicht auf ihren Körper gehört. Geht auch sehr einfach. Und es ist wie immer, nur weil jemand laut schreit, heißt das nicht, dass das wichtigste Thema ist. Stellt euch immer die Woran arbeitet ihr gerade? Was für einen Impact hat das und wie wichtig ist das? Und für wen ist das? Und für wen ist das meine ich auch. Wenn dein Chef oder Chef Chef oder Chef Chef Chef danach fragt, dann mag das toll sein und du möchtest dieser Person zuarbeiten. Doch wenn du valide Gründe hast, warum du das nicht tun solltest oder wenn du valide Gründe hast, an etwas anderem zu arbeiten, was wichtiger ist, dann würde ich dich bitten, das auch zu sagen. Denn die Personen über dir, die haben viel mehr Erfahrung als du und die wertschätzen das auch. Du gibst ja keine Gegenwehr. Du gibst ja nur einen besseren Grund und die können dann deinen Kurs korrigieren. Die sagen nein, meine Aufgabe ist gerade wichtig, lass das, was du gerade arbeitest, bitte liegen. Doch dafür müssen die Leute den Kontext haben, woran du gerade arbeitest. Somit schiebst du eigentlich die Entscheidung auch ein bisschen nach oben. Aber ja, es ist sehr einfach, sich in 10 12 Stunden Tage zu verlieren. Es ist sehr einfach, seine Strategie nicht zu verfolgen. Das heißt nicht, dass man alle ignorieren sollte. Bitte nicht. Doch ihr kriegt da, glaube ich, relativ schnell ein Gefühl für, welche Elemente eurer Arbeit und welche Personen wichtig sind.

Wolfi Gassler (01:11:52 - 01:12:07)

Und nachdem dieses Zeitmanagement ja nur eines der vielen Probleme ist, die man so miterlebt als Engineering Manager, hat der Andi natürlich auch die Frage gestellt, was ganz allgemein die größten Herausforderungen sind, was sich Jahn in dieser Rolle als Führungskraft vorstellt.

Jan Semrau (01:12:07 - 01:13:17)

Ich glaube erstmal diesen Schritt in die Führungskraftrolle zu wechseln, ist in dem Sinne nicht ganz einfach, wenn man gecodet hat, nicht selbst Hand anlegen zu wollen, also technisch drin zu bleiben, aber nicht aktiv mit zu coden. Ich kenne das noch aus einem Bereich, wo ich im Rahmen des Studiums war, da hat einer zwischenzeitlich die Rolle des Engineering Managers oder des Team Leads übernommen, hat trotzdem immer wieder noch mitgecodet und ist nicht so richtig beiden Rollen gerecht werden können, dadurch, dass er beides gemacht hat. Ich glaube auch mit negativen Entscheidungen umzugehen, z.B. wenn Teaminteressen und Unternehmensinteressen nicht ganz im Einklang stehen, wie man da die Balance findet und den richtigen Weg, könnte auch eine Herausforderung sein. Genauso habe ich ja bisher auch keine Erfahrung, wie man schwierige Themen in Bezug auf eine Person anspricht. Zum klassisch, wenn Stellenabbau, Kündigungen im Raum stehen oder Beschwerden kommen, wie man mit solchen Situationen umgeht. Und auch eine Herausforderung für mich wäre, wie ich mich als Führungskraft weiterentwickle, gerade wenn ich nicht die klassische Karriereleiter im Sinne von vom Team Lead zum darüber gehenden Lead gehen möchte, wie ich mich da weiterentwickle.

Andy Grunwald (01:13:17 - 01:13:57)

Ein schöner Aspekt ist die Selbstreflexion, dass er jetzt schon sagt, dass die Herausforderung ist, nicht direkt wieder in den Code zu springen und mitzumachen. Das ist so, ich glaube, der Number One Fehler, den ziemlich viele Personen in dieser Rolle machen. Und besonders auch, wenn die Person schon zwei, drei Monate in einem Job ist, denn sie haben relativ schnell das Gefühl, ich mache ja gar nichts, ich arbeite ja gar nicht richtig, weil man hat ja nicht so ein Output, man hat ja nicht so ein Feedback wie beim Coden. Beim Coden fixe ich einen Bug, schließe das Jira Ticket und Deployment, da habe ich ja wirklich was geschaffen. Und im Management, da haben Leute, die frisch in die Rolle wechseln, oft das Gefühl am ich schaffe ja gar nichts, ich mache ja gar nichts, da kommt ja nichts bei rum.

Wolfi Gassler (01:13:57 - 01:14:00)

Und was wären deine Tipps, wie kann man damit umgehen?

Andy Grunwald (01:14:00 - 01:15:01)

Ich wiederhole mich, weil ich habe das schon mal öfters in diesem Podcast gesagt. Man muss einfach nur verstehen, der Feedback Cycle ist anders. Als Engineering Manager ist man Multiplikator und alles das, was man tut, hat einen Effekt auf Menschen. Und bis Menschen sich ändern, das dauert. Ich sag immer, dass der Feedback Cycle beim Coden eine halbe h bis einen Tag bis zum Deployment. Ich hoffe, ihr deployed mindestens einmal pro Tag. Wenn nicht, arbeitet mal daran. Sollte möglich sein. Und beim Engineering Management ist das Feedback Cycle eher so drei Monate. Das, was du heute machst, wird einen Effekt in drei Monaten haben. Sei es Quartalsplanung, sei es ein Mindset Change bei jemandem anders, sei es eine Rolle zu wechseln und da rein zu wachsen oder, oder oder. Einfach Bewusstsein, denke ich. Das wäre so mein Tipp. Aber ich glaube, das ist eine richtig harte Nr. Und das war es für mich am Anfang auch, weil man denkt, warum dauert es denn so lange? Man verliert ja den Blick für die Details. Man geht ja eine sogenannte Flughöhe, ein sogenanntes Flight Level höher. Man hängt jetzt nicht mehr mit den Augen im Code, sondern auf der Projektplanung.

Wolfi Gassler (01:15:01 - 01:15:46)

Z.B. ja sonst was auch beim individual Contributor eine gute Sache ist. Brag Document haben wir ja eine eigene Episode auch dazu gemacht. Das kann man natürlich auch auf dem Leadership Level genauso machen, weil man vergisst natürlich auch ganz schnell, was man denn eigentlich so geschafft hat an dem Tag, weil man ja denkt eigentlich, man ist nur in Meetings. Aber wenn man mal zusammenfasst, was wurde eigentlich alles entschieden, was für Kommunikation wurde betrieben, welche Informationen habe ich weitergeleitet an welche Personen? Dann merkt man erst, dass man da eigentlich schon eine Leistung vollzogen hat und Impact hat. Und das natürlich dann dementsprechend auch wichtig, dass man sich das selbst vorliest sozusagen oder zeigt, was man denn alles geschafft hat. Und es ist natürlich auch praktisch, wenn man das weiterleiten will, dann nochmal als ein Report oder sowas ähnliches.

Andy Grunwald (01:15:46 - 01:16:07)

Dann, was auch ein Dauerbrenner ist, sind die Kommunikation von schwierigen Themen, Stellenabbau oder Beschwerden oder ähnliches. Wenn man sowas noch nie kommuniziert hat, ist das glaube ich echt eine Hausnummer. Und das war bei mir auch der Fall. Mein Vorgesetzter hat mir damals sehr, sehr viel Support gegeben, wie ich negative Nachrichten auf überbringe. Da bin ich sehr dankbar für. Also da holt euch am besten Hilfe.

Wolfi Gassler (01:16:07 - 01:17:19)

Also ich glaube ganz allgemein diese Dinge, auch wie bildet man sich weiter in dieser Position, also die Weiterentwicklung an sich, allgemein schwierige Themen, man ist in der Position nicht alleine, man ist vielleicht bisschen mehr alleine als in einer individual contributor Rolle, in der Praxis zumindestens. In der Theorie sollte es ja eigentlich eh nicht so sein, weil du jemand über dir hast, der dir dann weiterhilft, dich coacht, also ein Direktor z.B. aber in der Praxis funktioniert das natürlich ein bisschen weniger. Also da auch wieder Support suchen, sei es vom Director, von jemandem über einem, also Vorgesetzte oder auch auf Peer Ebene. Andi und ich, daraus ist der Podcast eigentlich entstanden, wir haben einfach auf der Peer Ebene viel miteinander zu tun gehabt und gesprochen über Probleme und so kann man sich da wirklich Hilfe von außen suchen, weil es ist einfach schwieriger. Man ist eher alleine, man hat nicht ein Team um einen herum, mit dem man auch sprechen kann über solche Dinge. Also da muss man einfach von außen sich Hilfe reinholen und Support holen. Und man kann natürlich auch viel lesen. Klar kann man sich natürlich auch weiterbilden, aber es ist schon besser mit Personen zu sprechen, die da tiefer reingehen können in das Thema mit einem und helfen können. Coaching, ganz klassisch.

Andy Grunwald (01:17:19 - 01:17:58)

Die Kommunikation von schwierigen Themen wird nicht einfacher, man wird routinierter, würde ich sagen. Man weiß, wie man sie kommuniziert, man macht sich aber trotzdem seine Gedanken und das macht niemandem Spaß. Also Leute kündigen oder echt schlechte Nachrichten zu überbringen oder, oder, oder, das macht niemandem Spaß. Die Leute werden nur routinierter, abgeklärter und wissen vielleicht, worauf sie sich wirklich beziehen sollten und dass sie bei der Sache bleiben und nicht ins Persönliche überrutschen, obwohl es natürlich schon was Persönliches ist. Und auch jemand, der das schon öfters gemacht hat auf Director oder VP Ebene oder C Level, glaub mir bitte, die machen das auch alles nicht gerne.

Wolfi Gassler (01:17:58 - 01:18:35)

Es ist so ähnlich, wie wenn man irgendeinen Ausfall hat, wenn man auf der technischen Ebene bleibt, also irgendwie die Plattform fällt aus oder die Software ist einfach down oder was man auch immer macht. Das erste Mal ist sicher am schwierigsten, wenn man sich daran gewöhnt, an so Ausfälle, wie man reagiert. Es ist immer noch kein schönes Erlebnis, würde ich mal sagen, aber man wird routiniert und da geht es noch dazu um Menschen, das heißt, es ist noch mal schwieriger klarerweise, aber mit der Zeit gewöhnt man sich auch an diese Dinge und kann mit denen einfach besser umgehen. Aber leicht ist es auf keinen Fall. Aber einen Ausfall von einer Plattform hat man auch immer ein Stresslevel, wenn jetzt plötzlich Millionen von User das Service nicht mehr nutzen können.

Andy Grunwald (01:18:35 - 01:19:38)

Aber ich möchte mal ein großes Lob an Jan aussprechen. Er sieht jetzt schon als Herausforderung, sich als Führungskraft weiterzuentwickeln. Und was soll ich sagen, er hat recht. Denn es ist sehr einfach, sich in die Arbeit zu stürzen, alle weiterzuentwickeln, aber sich selbst zu vergessen. Natürlich die Firma, wenn man eine gute Firma hat, pusht die Personalabteilung ein, vielleicht mal zu Management Trainings und Co. Aber das nur die halbe Miete, denn auch sich technisch weiterzuentwickeln gehört dazu. Nicht nur Kommunikationsworkshop und Leadership Workshops, sondern vielleicht auch mal was anderes zu sehen, auf Konferenzen zu gehen, ein paar Bücher zu lesen oder, oder, oder. Also ich meine, da gibt es so viel Entwicklungsmöglichkeiten. Und sich selbst nicht zu vergessen ist ganz wichtig. Ich habe z.B. von meinem Mentor dir selbst muss es gut gehen und du musst ausgeglichen sein und co. Damit du anderen Leuten helfen kannst, damit du andere Leute die Probleme auf dich nehmen kannst und weiterentwickeln kannst. Denn wenn du dich selbst vergisst, dann kannst du auch nicht als Multiplikator agieren.

Wolfi Gassler (01:19:38 - 01:20:00)

Es ist so schön, dass wir jetzt auch wieder die Feuerwehr drin haben. Das ist eine Grundregel bei der Feuerwehr, das Selbstspiel. Weil wenn du selbst nicht geschützt bist, kannst du noch keine anderen Menschen retten. Das heißt, du musst selber mal keine Atemschutzflasche haben, damit du Luft atmen kannst, bevor du in ein Feuer rein rennst. Und so ähnlich ist es da halt eigentlich auch. Der Selbstschutz geht immer voran und ist eigentlich das wichtigste an erster Position.

Andy Grunwald (01:20:00 - 01:20:16)

In dem Kontext der Herausforderung hat Jan uns aber auch eine Frage gestellt, denn er wollte von uns wissen, ob wir schon mal schwierige Situation hatten, in denen wir uns dachten, fuck, warum bin ich eigentlich Führungskraft jetzt gerade? Wolfgang, welche Situation kommt dir da in den Sinn?

Wolfi Gassler (01:20:16 - 01:21:13)

Es ist eigentlich so ein Grundsatzproblem, was Jan jetzt auch gerade angesprochen hat, dass man so zwischen dem Team und zwischen der Firmenmeinung so drinsteht und irgendwie so zwischen zwei Stühlen sitzt. Und in dieser Rolle, wenn man da nicht so transparent sein kann oder eine gewisse Meinung vertreten muss, sei es bei Layoffs, sei es bei großen Reo, wenn man da dann so mit 10 Personen geredet hat und die alle dann Probleme damit haben und man da immer noch die Meinung vertreten muss, bis zum gewissen Grad natürlich und nur irgendwie mit schlechten Emotionen die ganze Zeit zu tun hat, dann kommt man da schon an einen Punkt, wo man dann öfter überlegt, muss das unbedingt sein in dieser Rolle? Und da ist es dann auch wichtig, dass man vielleicht extern Leute hat, mit denen man sprechen kann, also im privaten Umfeld, wo es auch immer ist, ist, dass man da eben nicht zu sehr reinschlittert, weil das kann dann schon intensiv sein und sich so über zwei, drei Wochen ziehen. Und das ist dann schon eine extrem intensive Zeit und das ist dann einfach sehr knackig.

Andy Grunwald (01:21:13 - 01:22:37)

Du sprichst einen guten Punkt an, denn als Führungskraft hat man in der Regel mehr Informationen als das Team und man kommuniziert nicht alles, um vielleicht Unsicherheit nicht zu verbreiten. Das ist richtig. Das ist, glaube ich, ein Punkt. Ein anderer Punkt ist, wo ich es mir manchmal denke und besonders in der Anfangszeit, weil ich noch nicht wusste, wie ich damit umzugehen habe, ist, wenn ich Entscheidungen von den Ebenen über mir kommunizieren muss, obwohl ich nicht d'accord mit diesen Entscheidungen bin oder vielleicht nicht das ganze warum dahinter habe, weil das ist so eine Art Selbstmordkommando. Ich muss eine Nachricht überbringen, ich vertrete diese Nachricht nicht und ich verstehe den Grund nicht. Und eigentlich müsste ich bei jeder Gegenfrage des Teams und Shouldersruck machen, weil ich kann ja nicht sagen, die über mir haben entschieden. Das ist das Schlimmste, was du machen kannst. Du musst die Meinung des Unternehmens vertreten, weil du bist der, kann man sagen, abgesandte Abgeordnete, wenn man so möchte, in der Hinsicht. Und wenn dir von oben drüber keine richtigen Gründe genannt werden oder auch nicht auf Gegenfragen reagiert wird, auf Basis von fehlenden Kommunikationsmitteln oder Kommunikationsfähigkeiten vielleicht auch, dann ist das einfach nur eine echt undankbare Situation, weil das Ergebnis ist eigentlich, du kannst nur verlieren. In solchen Situationen denke ich mir, muss das jetzt wirklich sein? Kann man sich nicht noch einen Tag mehr Zeit nehmen, um ein bisschen mehr Informationen zu transferieren?

Wolfi Gassler (01:22:37 - 01:23:16)

Aber nun gut, bei diesem Thema haben wir leicht unterschiedliche Meinungen, zumindest wenn es um Transparenz geht und wie weit man mit der Firma mitgehen muss. Wir hatten es auch mal diskutiert in Episode 83 zur Fehlerkultur und Leadership ganz allgemein. Da sind wir ein bisschen in die Tiefe gegangen und haben das auch ein bisschen ausdiskutiert, wenn es interessiert. Aber dass es schwierig ist, da stimme dir auf jeden Fall zu. Das ist wirklich eine Gratwanderung, die man da immer macht bezüglich Transparenz und Meinung der Firma und Unterstützung und wie man das Ganze dann dementsprechend auch framed und wie weit man sich auf die eine oder andere Seite schlagen lässt. Das ist schon ein schwieriges Thema an.

Andy Grunwald (01:23:16 - 01:23:34)

Sich, aber da soll jeder seinen eigenen Weg finden, denke ich. Denn wenn alle gleich wären, hätte man nur eine Art von Manager und das ist es ja auch nicht. Jetzt würde mich natürlich mal interessieren, wenn Leute diese Episode gehört haben, ob die wirklich noch Manager und Teamleiter werden wollen, oder ich weiß nicht, ob wir die ganze Sache positiv rübergebracht haben. Ich hoffe, natürlich schon.

Wolfi Gassler (01:23:34 - 01:23:54)

Naja, uns macht es auf jeden Fall beiden Spaß, in dieser Welt tätig zu sein. Also ich glaube, ich persönlich kann es nur empfehlen, wenn man damit umgehen kann, dass man eben auf einer ganz anderen Ebene arbeitet und eher im Prozessdenken, Kommunikation, menschlichen Umfeld eigentlich arbeitet und weniger auf der Coding Seite.

Andy Grunwald (01:23:54 - 01:24:59)

Ich habe Spaß in der Rolle und ich denke auch mit ein paar Jahren Berufserfahrung in dieser Rolle. Man lernt unglaublich viel dazu, besonders wenn man die Firmen wechselt. Nicht jede Firma operiert auf dem Engineering Manager und Teamleiter level gleich. Manche Firmen erwarten mehr von einem, was natürlich auch deine Lernkurve wieder nach oben schraubt. Manche Firmen sagen, vier Leute sollten maximal in einem Team sein. Manche Leute akzeptieren 15 Leute in einem Team. Welches Produkt du in deinem Team behandelt, spielt auch eine Rolle, zumindest für deinen Impact, für deinen Multiplikator. Deswegen immer wieder spannend und ja, mit größeren Herausforderungen wächst man auch sehr stark, besonders in der Kommunikation. Lieber Jan, ich hoffe, wir konnten deine Fragen ein bisschen beantworten bzw. Hoffen wir, dass du ein paar neue Einblicke erhaschen konntest. Wir haben dir auf jeden Fall zu danken für dein Pre Interview und deinen Audio Content. Du warst sozusagen mitbeteiligt an einer Premiere, an einer Premiere, an einer, wie soll man sagen, Hörerfrage, wo der Hörer aktiv involviert war.

Wolfi Gassler (01:24:59 - 01:25:42)

Und ich muss schon auch mal ein Lob aussprechen, weil der Jan hat sich wirklich gut geschlagen in den Antworten, würde ich sagen. Also das ist schon wirklich ein super Mindset, was er da an den Tag gelegt hat. Es kann sich jeder mal die Episode drei und dreiig anhören. Das ist Andi im Team Lead Bewerbungsgespräch, wie sich der Andy damals in dem Bewerbungsgespräch zu einem Teamlead geschlagen, das ich fiktiv mit ihm geführt habe. Also ich glaube, Jan, du bist schon definitiv auf dem richtigen Weg und wir wünschen dir auf jeden Fall viel Glück auf deinem Weg. Wenn wir irgendwas für dich machen können, melde dich bei uns und wir hoffen natürlich, dass wir vielleicht dann bald irgendwann eine Episode machen können, wenn du in der Engineering Manager Rolle bist und wie dann deine Erfahrung war in diesem Bereich.

Andy Grunwald (01:25:42 - 01:26:02)

Auch spannend wäre natürlich, wenn wir jetzt den Jan mal einladen würden und das Bewerbungsgespräch aus Episode drei und dreiig mit ihm machen würden. Denn Disclaimer, ich sag auch mal, das war im August 22, wir nehmen jetzt gerade im April 25 auf. Ich bin mal gespannt, wie ich jetzt innerhalb der letzten drei Jahre unterschiedlich antworten würde. Aber es wäre natürlich auch spannend.

Wolfi Gassler (01:26:02 - 01:26:06)

Du meinst, wir sollten das wiederholen mit dir einfach mal so Standard Interview jetzt rausbringen?

Andy Grunwald (01:26:07 - 01:26:59)

Ja, so ein Referenzinterview und dann einfach mal wie in so einem Survey, wie in so einer Umfrage, dann einfach mal die Ergebnisse vergleichen. Aber ich fände es natürlich auch toll, wenn wir jetzt die Episode hier rausbringen und dann den Jan einladen und dann live mit ihm mal ein solches Bewerbungsgespräch machen. Es wäre natürlich dann unglaublich hart mit zwei Interviewern, aber ich weiß nicht, wir lassen uns mal in den Kopf gehen und wenn wir guten Tag haben, sind wir mal eine Anfrage raus. Schauen wir mal, was wird. Jan natürlich auch viel Erfolg von meiner Seite. Es würde uns natürlich sehr freuen, wenn du auch etwas Feedback für diese Episode da lässt. Auch gerne öffentlich irgendwo auf LinkedIn, in der Discord Community, auf Twitter, X Blue Sky, Mastodon oder auf Spotify oder Apple durch irgendeine Bewertung. Also wir wollen natürlich wissen, hat dir das hier was gebracht oder ist das hier irgendwie alter Kram von gestern?

Wolfi Gassler (01:26:59 - 01:27:04)

Haben wir immer noch diesen x Link, den müssen wir endlich mal rauskicken. Aber der Andi ist noch nicht so überzeugt.

Andy Grunwald (01:27:04 - 01:27:06)

Ne, ich glaube den X Link haben wir jetzt rausgekickt.

Wolfi Gassler (01:27:06 - 01:27:10)

OK, noch besser. Also nicht mehr auf x antworten, bitte.

Andy Grunwald (01:27:10 - 01:27:39)

Das war's von uns, eine etwas längere Folge. Wir hoffen trotzdem, dass ihr bis hierhin durchgehalten habt. Und falls ihr mit dem Thema weiter diskutieren wollt, unten in den Shownotes findet ihr einen Link zu unserer Discord Community. Da sind wir fast 400 Leute und auch diverse Engineering Manager, Director. Wir haben auch C Level da drin teilweise, also Leute mit richtig Management Erfahrung. Kommt einfach mal rein, eure Frage stellen oder challenge mich auch gerne oder den Wolfgang auf einer unserer Antworten oder vielleicht auch den Jan, was ihr dazu denkt.

Wolfi Gassler (01:27:39 - 01:27:45)

Und lasst uns mal wissen, was ihr zu diesem Format sagt und ob es noch andere Themen gibt, die ihr gerne in so einem Format hören würdet.

Andy Grunwald (01:27:45 - 01:27:48)

Das war's von uns. Wir wünschen einen schönen Tag. Bis später und tschüss.

Wolfi Gassler (01:27:49 - 01:27:51)

Ciao. Und in Jans Namen natürlich auch noch ciao.