#112 Das Engineering Manager Pendulum: Zwischen Coding und Leadership mit Tom Bartel

Wenn der Wechsel vom Software Engineer zur Managerin eine Beförderung ist, ist dann der Wechsel vom Manager-Dasein zurück zum Software Engineer eine Degradierung?

Genau mit dieser Frage beschäftigen wir uns in dieser Episode. Umgangssprachlich nennt man den Wechsel hin und her, von Software Engineer zum Management und zurück, das Engineering Manager Pendulum.

Wir haben mit Tom Bartel gesprochen, der diesen Wechsel schon zweimal vollzogen hat. Mit Ihm sprechen wir darüber, wie der Gedanke zum Pendeln entstanden ist, wie sein Umfeld und das eigene Unternehmen darauf reagiert hat, wie schwierig es ist sich an andere Perspektiven und Flughöhen in der täglichen Arbeit anzupassen, wie das Gehirn sich auf die unterschiedlichen Tagesabläufe verändert, und was er Leuten raten würde, die ebenfalls darüber nachdenken, in das Engineering Manager Pendulum einzusteigen.

Bonus: Wie ein neuer Grill eine Verpackungswut auslösen kann.

**** Diese Episode wird gesponsert von Eurowings Digital

Eurowings Digital: Ein internationales Team, Englisch als Firmensprache. Java und AEM im Backend, Vue.js im Frontend und Kotlin sowie Swift für die Mobile Apps. Fürs Data Crunching werden Python, Scala und die Databricks-Plattform verwendet. Alle offenen Job Positionen und Details zu Benefits, wie Standby-Fliegen & Jahresurlaubsflug, findest du unter https://engineeringkiosk.dev/eurowings

****

Das schnelle Feedback zur Episode:

👍 (top) 👎 (geht so)

Sprungmarken

(00:00:00) Intro

(00:04:00) Das moderne Tech-Team bei Eurowings-Digital (Werbung)

(00:05:00) Engineering Management Pendulum und unser Gast Tom Bartel

(00:08:39) Was ist das Engineering Management Pendulum

(00:20:14) Möchtest du wieder Individual Contributor werden?

(00:27:21) Pendulum und die Firmenkultur

(00:31:34) Wie sich nach einem Pendel deine Arbeit verändert

(00:44:28) Leute im Team, die selbst gependelt sind

(00:51:57) Andere Flughöhen vs. Hands-On

(01:12:54) Tips zum pendeln, wenn du drüber nachdenkst

Hosts

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

Feedback (gerne auch als Voice Message)

EngKiosk Community: https://engineeringkiosk.dev/join-discord
Email: stehtisch@engineeringkiosk.dev
Mastodon: https://podcasts.social/@engkiosk
Twitter: https://twitter.com/EngKiosk
WhatsApp +49 15678 136776

Transkript

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

Tom Bartel (00:00:02 - 00:00:58)

Wenn man mal Manager war und so Teamverantwortung hatte und dann wieder IC wird, ... ... man hat immer noch diese Denkweise, dieses Mindset von einem Manager. Man weiß, okay, mein Manager, der ist auch nicht allwissend, weil ich war es als Manager auch nicht. Wenn ein Engineer zum Manager kommt und sagt, ich habe da so und so ein Problem, dann hat der Manager nicht die Antwort parat, weil er meistens auch nicht, er steckt ja nicht so tief drin wie der Engineer in der Regel. Er kann oft nur helfen, dem Engineer die Lösung selber zu finden. Und wenn du das als Engineer weißt, dann sparst du dir manchmal den Schritt, ... zu deinem Manager zu gehen und den um die Lösung anzubetteln quasi, ... ... sondern du weißt, okay, der ist auch nicht schlauer als ich oder allwissend, ... ... dann probiere ich erstmal selber eine Entscheidung zu fällen und eine Lösung zu finden.

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

Wenn der Wechsel vom Software-Engineer zur Managerin eine Beförderung ist, ist dann der Wechsel vom Manager-Dasein zurück zum Hands-on-Software-Engineer eine Dekretierung? Und was ist, wenn man dann später womöglich nochmal wieder Engineering-Manager wird? Was soll dieses Hin und Her? In der Branche hat sich dafür ein Begriff etabliert, das Engineering Manager Pendulum. Aber ist das gesund und das Herumgehobse denn akzeptiert in der Branche? In dieser Episode sprechen wir mit Tom Bartel, der diesen Wechsel schon mehrfach und auf verschiedenen Ebenen durchgeführt hat. Wir sprechen über die initialen Gedanken zum Pendeln und wie diese entstanden sind. wie sein Umfeld und das eigene Unternehmen darauf reagiert haben, wie schwierig es eigentlich ist, andere Perspektiven und Flughöhen in der täglichen Arbeit anzupassen, welche Vorteile die Pendelbewegung haben kann und natürlich, was Tom Leuten raten würde, die ebenfalls darüber nachdenken, herum zu pendeln. Also pendeln wir einfach mal direkt drauf los. Viel Spaß! Ihr habt wieder mal das große Vergnügen, wirklich neben Andi zu sitzen. Also das haben wir, oder haben wir das überhaupt schon mal geschafft?

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

Wir haben schon mal eine Podcast-Ausnahme in persona gemacht. Das ist korrekt, ja. Ganz am Anfang, ich glaube Episode 1 oder 2. Aber ob ich das als erfolgreiche Podcast-Episode bezeichnen würde, weiß ich jetzt gerade auch nicht mehr. Aber zumindest nicht in den letzten anderthalb Jahren.

Wolfi Gassler (00:02:29 - 00:03:46)

Und nachdem wir nebeneinander sitzen, sprechen wir heute mal über ein Thema, was uns beide stark betrifft. Und zwar, wir sind ja beide so eher aus der Engineering-Manager-Ecke. Und wenn man sich das so überlegt, heutzutage, oder vielleicht nicht heutzutage, was man damals so gesagt hat, man wird irgendwie Softwareentwickler, bildet sich dann weiter, irgendwann übernimmt man dann ein Team, das ist der große Schritt, wenn man so ein Team übernimmt, dann befördert wird und wirklich zum Engineering-Manager wird. Und normalerweise geht man dann die Karriere weiter, weiter und weiter, so wie es halt in den 60er Jahren so der Standard war. Und wenn man das aber heute sich anschaut und zum Beispiel auf Andis Karriere schaut, Andi hat sich dann wieder zurückentwickelt. Und ob das wirklich eine Zurückentwicklung ist, werden wir noch klären. Aber wir haben jemanden heute zu Gast, der nämlich noch mehr Wechsel durchgeführt hat, vom Individual Contributor, also vom ganz normalen Entwickler, zum Lead, zurück, dann wieder zum Lead und wieder zurück und jetzt ganz neu sogar auf Director Level, also Lead von Leads. Also den absoluten Spezialisten, würde ich mal sagen, im Herumspringen. Und genau darüber werden wir heute mal sprechen, wie das mit diesem Herumspringen so ist, ob man das darf, ob man das soll und wie viel Sinn das Ganze macht. Willkommen Tom.

Andy Grunwald (00:03:47 - 00:05:27)

Also Wolfgang, so wie du es gerade beschrieben hast, hört sich das an, als würde der Tom Stellen wechseln, wie Unterhosen. Und das macht mir ein bisschen Angst. Ne, aber in der Tat. Wir sprechen heute über das sogenannte Engineering Management Pendulum. Das Engineering Manager Pendel lässt sich vor allem innerhalb von größeren Unternehmen mit moderner Firmenkultur umsetzen. So eine Kultur findest du auch bei unserem Episodensponsor Eurowings Digital. Auch dort hat es bereits Pendelbewegungen von MitarbeiterInnen gegeben. Eine hundertprozentige Tochter von Eurowings, die aber eigenständig und in eigenen Büroräumlichkeiten eine Startup-Atmosphäre lebt. Mit einem internationalen Team bestehend aus über 40 Nationen und Englisch als Firmensprache wird dort unter anderem mit Java im Backend, Vue.js im Frontend und Kotlin sowie Swift für die Mobile-Apps gearbeitet. Fürs Data Crunching werden Python, Scala und die Databricks Plattform verwendet. Im Hybrid Setup oder Fully Remote genießt man trotz Startup Setup auch die vielen Fluggesellschafts-Benefits wie Standby-Fliegen und Jahresurlaubsflug. Das ist mal was anderes als der Standard Obstkorb. Interesse geweckt, um in einem modernen Team abzuheben? Alle Informationen zu den offenen Positionen findest du unter engineeringkeyers.dev slash eurowings oder, wer zu faul zum Tippen ist, natürlich auch in den Shownotes. Bei der Vorbereitung habe ich mich natürlich die Frage gestellt, wer ist eigentlich Tom? Und wenn man die Recherche beginnt, beginnt man heutzutage wo? Viele Leute sehr wahrscheinlich bei JGPT, ich bei Google. Wenn man nämlich den Namen Tom Bartel bei Google eingibt, dann habe ich natürlich mich gefragt, welcher ist denn jetzt der wahre Tom, mit dem ich das Interview führe? Du bist, glaube ich, kein Facharzt für physikalische und rehabilitative Medizin aus Hamburg.

Tom Bartel (00:05:27 - 00:05:28)

Sehr weit, ich weiß nicht.

Andy Grunwald (00:05:28 - 00:05:31)

Du bist auch kein Keramik-Künstler aus Cleveland, Ohio?

Tom Bartel (00:05:31 - 00:05:33)

Sicher nicht.

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

Spielst du denn Fußball bei Posterium United Dortmund in der Kreisliga C Dortmund 6?

Tom Bartel (00:05:38 - 00:05:40)

Nee.

Andy Grunwald (00:05:40 - 00:06:08)

Dann wirst du sehr wahrscheinlich der Mensch sein, der sich selbst als Softwareentwickler, Engineering-Manager, Speaker und Human-Communication-Geek bezeichnet, denn du bloggst regelmäßig über diese Themen wie Software-Management, People-Management und Communication. Und du bist auch sehr in der Lehre zu Hause, nämlich hast du einen Udemy-Kurs zum Thema Dein Einstieg in Node.js professionell und komplett aufgenommen, den du sogar noch, ich glaube, Mitte letzten Jahres aktualisiert hast.

Tom Bartel (00:06:08 - 00:06:12)

Ja, mini bisschen. Ich habe ein paar Kommentare beantwortet.

Andy Grunwald (00:06:13 - 00:06:24)

Aktualisierung ist Aktualisierung. Und du hast im Oktober 2022 einen neuen Grill gekauft und hast dich dann über Twitter bei Burnhard Grill über die Verpackung der Kleinteile beschwert.

Tom Bartel (00:06:24 - 00:06:33)

Und ich würde gerne wissen, wie erfolgreich war deine Beschwerde? Ich habe keine Antwort bekommen, glaube ich. Oder vielleicht habe ich auch nur nicht nachgeguckt.

Wolfi Gassler (00:06:34 - 00:06:36)

Wir sollten das retweeten. Vielleicht haben wir mehr Power.

Tom Bartel (00:06:37 - 00:06:45)

Mit eurer Reichweite, ja, vielleicht wird das was. Es war eine große Verpackungsflut, sagen wir so, und ich fand es ein bisschen übertrieben.

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

Ich hoffe denn, aber deine Essenszubereitung auf diesem Grill ist erfolgreich?

Tom Bartel (00:06:49 - 00:07:01)

Die ist tadellos, ja. Also der Grill ist sehr gut. Aber zum Thema regelmäßig bloggen, es ist weniger regelmäßig geworden. Ich glaube, mein letzter Post liegt auch schon zwei oder drei Jahre zurück.

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

Aber so ähnlich wie unsere Episoden machst du ja so Evergreen-Posts und darum haben wir die auch extrem oft erwähnt. Also ich glaube alle, die uns regelmäßig zuhören, die müssten eigentlich schon mindestens fünfmal mit einem Link konfrontiert worden sein von dir, weil du natürlich auch über deine Reisen gebloggt hast und wir die ja natürlich immer gern referenzieren, weil es einfach super Blogartikel sind, die da Bisschen Insights geben, die man sonst eigentlich ganz selten findet online. Und der Andi hat schon angesprochen, wir sprechen über dieses Pendulum. Ihr habt übrigens nachgeschaut, Andi, weil wir sind ja ein deutscher Podcast. Was das auf Deutsch heißt, das heißt Pendel. Also das Engineering Manager Pendel.

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

Heißt das bei euch auch Pendel?

Wolfi Gassler (00:07:46 - 00:07:50)

In Österreich heißt es auch Pendel, ja. Also so international ist dieses Wort, ja.

Tom Bartel (00:07:50 - 00:07:54)

Muss man ja immer sicher gehen auch. Könnte ja auch anders heißen.

Wolfi Gassler (00:07:54 - 00:08:02)

Der Dom kommt ja übrigens fast aus meiner Heimat. Schwarzwald ist ja quasi fast direkt in Österreich.

Tom Bartel (00:08:02 - 00:08:03)

Das ist ein Katzensprung, ja.

Wolfi Gassler (00:08:04 - 00:08:15)

Genau. Aber bevor wir in dieses Thema einsteigen oder vielleicht zum Einstieg in dieses Thema, Andi, erklär mal du, wie du dieses Pendel verstehst, das Engineering-Kiosk-Pendel und woher dieses eigentlich kommt.

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

Das Engineering-Kiosk-Pendel?

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

Das kenne ich jetzt auch nicht.

Tom Bartel (00:08:20 - 00:08:31)

Das mache ich heute Abend. Ich bin heute Abend von Mönchengladbach nach Duisburg gependelt zum Engineering-Kiosk und danach pendel ich wieder von Duisburg nach Mönchengladbach zurück.

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

Erstmal willkommen in einer der schönsten Städte Duisburgs.

Tom Bartel (00:08:33 - 00:08:34)

Auf jeden Fall.

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

Und wir haben österreichisches Bier, also es kann nichts besser werden.

Tom Bartel (00:08:37 - 00:08:39)

Ja, das ist die perfekte Kombi.

Andy Grunwald (00:08:39 - 00:09:35)

Nein, was ist das Engineering Management Pendulum? Pendel, Entschuldigung, wir sind ein deutschsprachiger Software Engineering Podcast. Was ist das Engineering Manager Pendel? Und zwar ist meine simplifizierte Beschreibung so, dass wenn man Software Engineer ist oder ein sogenannter IC Individual Contributor, das ist für mich die Bezeichnung, jemand der die wahre Arbeit macht, der wirklich Hands-on macht, der den Profit für die Firma wirklich mit der Schaufel aus der Miene rausträgt, Und dann vielleicht in irgendeine Managementrolle wechselt, dass man dort nicht gefangen ist, sondern dass man vielleicht sogar auch wieder, Achtung, zurückpendeln kann zum Individual Contributor. Und dass man sagt, okay, vielleicht war das Management nix für mich, vielleicht möchte ich diese Rolle nicht. Aber vielleicht sagt man auch, hey, nach 25 Jahren im Management möchte ich mal wieder an die Front, dass das nämlich keine Schande ist. Also ein Pendel, dass man hin und her pendeln kann.

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

Über dein erstes Pendel oder deine erste Pendelbewegung haben wir schon mal in irgendeiner Episode gesprochen, die wir gerne dann unten in den Show Notes verlinken, ich habe sie leider vergessen. Aber Tom, wann war denn deine erste Pendelbewegung und warum hast du dich überhaupt entschieden, da wieder in irgendeiner Form aus deiner Engineering-Manager-Rolle zurückzukehren in die normale Welt, unter Anführungszeichen?

Tom Bartel (00:10:00 - 00:11:57)

Ja, also das Engineering Manager bin ich geworden in einer Phase, wo Trivago, wo ich da gearbeitet habe, wo gerade viele Leute eingestellt hat. Ich bin schon direkt mit sieben Direct Reports eingestiegen, also sieben, die mir zugeordnet waren. sieben engineers und das ist dann rasant angewachsen auf 10 auf 12 auf 15 bis auf 20 und kannst dir vorstellen wenn du people management machst für 20 leute da bleibt dann nicht mehr viel von der technik übrig Und ja, da war ich aber halt noch Anfang 30 sowas. Und dann mit Anfang 30 als Softwareentwickler zu sagen, okay, das war's jetzt für mich mit der Technik, das ist irgendwie, ist ein bisschen erschreckend, weil du wirst natürlich schwächer, was die technischen Fähigkeiten betrifft. Du bist nicht mehr, hast keine Zeit, dich bei allem auf dem Laufenden zu halten. Du hast keine Übungen im Programmieren mehr, so wie vorher. ... dann stellt man sich irgendwann die Frage, ... ... okay, wenn ich jetzt mal doch die Firma wechsle, ... ... was ja durchaus vorkommt, ... ... was kann ich dann eigentlich vorweisen ... ... so als Fähigkeiten? Mein Status als Experte ... ... in irgendeiner Technik, ... ... der wird immer schwächer ... ... und das ist dann irgendwann auch kein ... ... Verkaufsargument mehr in einem Vorstellungsgespräch ... ... und wenn ich dann sage, ... ... ja, ich habe aber People Management ... ... für 20 Leute gemacht, ... ... dann beeindruckt das halt einen potenziellen ... zukünftigen Arbeitgeber vielleicht nur bedingt. Und deshalb habe ich schon den Gedanken gehabt, okay, nochmal zurück in eine andere Rolle wäre auf jeden Fall gut. Und da gab es dann halt mal wieder eine Umstrukturierung, wie das immer auch mal wieder vorkommt. Und dann habe ich die Gelegenheit genutzt und bin wieder in eine IC-Rolle zurückgegangen.

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

So wie sich das jetzt bei dir anhört, beschreibst du das an einen Engineering Manager, keine Qualitäten hat, nichts an den Tisch bringt und dass man solche Leute auf keinen Fall einstellen sollte. Ist das so?

Tom Bartel (00:12:09 - 00:13:03)

Nee, das ist auf jeden Fall nicht so. Aber ich glaube, das war bei mir halt ein bisschen extrem mit dem Zuschnitt von der Rolle mit 20 Direct Reports. Also das würde ich auch nicht mehr machen wollen, ganz ehrlich. Und ich würde es auch von keinem anderen verlangen wollen, weil das ist einfach eine recht einseitige Rolle. Du bist dann irgendwann nur noch am Gespräche führen und Konflikte schlichten und zu vermitteln und so. Und die meisten Firmen, wenn die einen Engineering Manager einstellen, dann wollen sie halt beides so ein bisschen. Ja, die wollen People-Skills und die Kommunikations-Skills, Soft-Skills und dergleichen. Aber sie wollen auch technisches Verständnis, technische Fähigkeiten, so dass du halt auch den Leuten, die du managst, dann musst du ja auch Führung geben und du musst dafür sorgen, dass die besser werden und so weiter.

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

Aber du hattest Spaß als Engineering Manager?

Tom Bartel (00:13:07 - 00:13:20)

Ich hatte Spaß und ich habe im Moment auch immer noch Spaß. Nur in dieser speziellen Rolle mit 20 Direct Reports, das ist ein bisschen viel. Das hätte ich nicht noch ewig weitermachen können.

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

Aber du hättest es ja auch reduzieren können. Also wir waren ja mal sogar gemeinsam eigentlich Peers und du hattest 20 Leute und ich hatte 20 Leute, die zusammen in Teams gearbeitet haben. Ich kenne den Schmerz, aber man könnte ja auch sagen, ich reduziere einfach oder baue da neue Strukturen ein oder mache sowas.

Tom Bartel (00:13:38 - 00:14:05)

Wenn dein Chef da mitmacht, dann ja, aber das ist nicht immer der Fall. Also ich habe es später auch noch erlebt, in der gleichen Firma, gleiche Abteilung, da wurde es wieder so gemacht, als dann mit einer Umstrukturierung noch mal ein bisschen andere Strukturen eingebaut worden sind, aber da hatten die Engineering Manager auch wieder zwölf oder fünfzehn oder so Leute unter sich und dann hast du eine ähnliche Situation.

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

Und wie viele Leute haben gesagt, du spinnst doch, da wieder jetzt von deinem guten Engineering-Manager Boston zu gehen?

Tom Bartel (00:14:14 - 00:14:36)

Mir ins Gesicht gesagt hat es keiner. Ich weiß nicht, wie viele es gedacht haben, aber die, ja. Ist dann halt so. Also ich finde, das muss drin sein. Und bei einer Firma wie Trivago war es zum Glück drin. Und das war kein Problem für mich. Und ich glaube, auch für die, mit denen ich dann gearbeitet habe, war es keins.

Andy Grunwald (00:14:37 - 00:15:10)

Du hattest gerade aber gesagt, du hattest so ein bisschen Angst, okay, du verlierst deine technischen Fähigkeiten. Das hat sich so ein bisschen angehört, so auf FOMO, bin ich überhaupt noch hire-bar, kann ich überhaupt noch mitreden. Auf die zweite Nachfrage hattest du dann gesagt, wenn jemand einen Engineering Manager einstellt, dann erwarte man technisches Verständnis. Und dann bist du wieder zurück zur Individual Contributor-Rolle gewechselt. Und jetzt wäre meine Frage, hast du dann gemerkt, wie weit du von der Technik weg bist? Oder hast du dir das alles nur eingebildet und hast gesagt, okay, so viel hat sich unten drunter eigentlich gar nicht geändert und die Skills habe ich eigentlich alle noch?

Tom Bartel (00:15:10 - 00:16:11)

Ja, also ich meine, ein bisschen aufholen musste ich schon. Einfach so Day-to-Day-Routinen, so Alltags... Abläufe, wie genau machen wir das und das im Prozess. Aber klar, es gibt auch Grundlagen, die ändern sich nicht. Was jetzt eine gute Struktur von Code ist oder wie man Funktionalitäten aufteilt in verschiedene Funktionen, das ist immer noch gleich. Und das verlernt man auch nicht, das ist gut. Aber, ja, ich meine, gerade so in dem Bereich, wo ich meistens tätig war, im Web-Bereich, da verändert sich halt schon viel mit Standards, was HTML, CSS, JavaScript betrifft. Und da muss man schon dann mal ein bisschen aufholen zumindest. Und vielleicht hat man es irgendwo schon mal gelesen, aber man hat es noch nicht so ... benutzt selber was schreiben, ... ... ist ja auch nochmal was anderes, ... ... als in einem Blogartikel ... ... darüber zu lesen und ... ... ein bisschen was aufzuholen war das schon.

Andy Grunwald (00:16:11 - 00:16:30)

Der Wolfgang hatte gerade gefragt, ... ... wie andere Leute reagiert haben, ... ... als du für dich entschieden hast, ... ... dass du von einer Managementposition ... ... wieder zurück in eine Softwareentwicklungsposition ... ... gewechselt bist. Meine Frage war eigentlich, ... ... oder wäre eigentlich, ... ... wie hat denn dein Umfeld außerhalb ... ... deiner Arbeit selbst reagiert? Weil du wirst Freunde haben, ... ... die vielleicht in einem Konzern arbeiten, ...

Tom Bartel (00:16:30 - 00:16:47)

Nee, habe ich leider nicht. Beziehungsweise mein Bruder vielleicht. Aber da gab es eigentlich keine so riesen Diskussionen. Ich habe das auch nicht an die große Glocke gehängt. Viele verstehen auch nicht so genau, was ein Informatiker macht und ein Softwareentwickler.

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

Druckerbeheben an Weihnachten?

Tom Bartel (00:16:49 - 00:17:00)

Ja, zum Beispiel. Oder früher war's, ich hab ein Problem mit meinem CD-Brenner, ne? Aber ne, da hab ich keine großartigen Diskussionen geführt.

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

Okay, wenn's nicht dein direktes Umfeld war, dann ist natürlich die nächste Frage, was hat denn die LinkedIn-Bubble gesagt? Weil die feiern ja eigentlich nur, wenn du einen Schritt nach oben gehst, einen weiteren Schritt auf der Leiter.

Tom Bartel (00:17:11 - 00:17:53)

Ja, auch da muss ich dich leider enttäuschen. Ich bin nicht so der LinkedIn-Poster und generell Social Media, das ist mehr so für mich, ich habe da immer einen großen inneren Widerstand und bin da nicht so aktiv. Ich hatte ein paar Gespräche mit Kollegen, die haben mich halt so gefragt, wie und warum. denen habe ich das erklärt, dass ich halt wieder mehr Hands-on mal eine Zeit lang sein will und die haben das halt als Fakt hingenommen und relativ problemlos akzeptiert und da auch nichts anstößiges oder irgendwie das als eine Niederlage gesehen oder so oder als ein Step-Down.

Andy Grunwald (00:17:54 - 00:18:04)

Aber wie war denn dein Mindset von Beginn an? Also ich meine, als ich in die Berufswelt kam, da war das natürlich, oh wow, diese Karriereleiter. Die muss man nach oben und man kann nicht zurück.

Wolfi Gassler (00:18:04 - 00:18:06)

Und jetzt bist du beim Podcast.

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

Und jetzt mache ich einen Podcast mit einem Österreicher. Ich weiß auch nicht, wo ich im Internet falsch abgewogen bin. Aber hat sich dein Mindset, also war dein Mindset von Anfang an so offen oder hast du gesagt, ne Andi, auch ich habe mich entwickelt und musste mich mit dem Gedanken anfreunden und allem drum und dran. Ich meine, irgendwann bist du ja auch mal in die Berufswelt gestartet und ich sage mal, du bist jetzt auch keine 18, sondern vielleicht gerade 22. Das bedeutet, du hast natürlich auch schon ein gewisses Mindset, was von deinen Eltern vorgelebt wurde und allem drum und dran.

Tom Bartel (00:18:35 - 00:19:57)

Ja, ich war nie so der Karriere-Typ. Ich wollte coden. Also ich habe immer schon Software-Entwicklung geliebt. Ich habe es geliebt, Code zu schreiben. Ich habe damals meinen Job gewechselt, weil ich in meinem vorigen Job nicht genug gecodet habe. Das war so IT-Consulting und da haben wir auch Software geschrieben. Aber es war halt nur so ein Bruchteil von meiner Zeit und das war mir zu wenig. Deshalb bin ich zu Trivago gegangen, um da wieder mehr zu coden. Das hat ein paar Monate funktioniert. Aber weil wir da so gewachsen sind, weil irgendwie Strukturen her mussten. Du bist damals auch dann Team Lead geworden, Andi. Und ich eben auch. Oder zuerst so Lead Developer, so eine informelle Funktion und dann Richtiger. ... People Manager, Engineering Manager ... ... mit Personalverantwortung ... ... und ja, ich bin da ... ... ich bin gefragt worden ... ... und ich habe es mir vorstellen können, ... ... ich habe das gemacht ... ... und zu meiner Überraschung ... ... hat es mir auch Spaß gemacht. Also ... ... das weg vom reinen Coden ... ... hin zu ein bisschen ... ... mehr auch Kommunikation, Koordination ... ... für Leute da sein, die ... ... einzuweisen und ein bisschen Führung ... ... zu geben, das ... war, fand ich gut.

Andy Grunwald (00:19:57 - 00:20:05)

Aber als du von der Position wieder runter wolltest, das war deine Entscheidung, da wurdest du jetzt nicht gefragt, wie initial für den Engineering Management Job.

Tom Bartel (00:20:05 - 00:20:14)

Doch, auch, aber ich war auch sehr froh, dass es passiert ist, weil ich weiß nicht, wie lange ich das sonst noch weitergemacht hätte.

Andy Grunwald (00:20:14 - 00:20:30)

Aber Moment mal, wenn jetzt zu mir jemand ankommen würde, ich wäre Engineering Manager und mich fragt jemand, möchtest du wieder als Individual Computer arbeiten? Dann wäre meine erste Gegenfrage, was habe ich falsch gemacht und wieso stimmt meine Performance nicht oder also dann fange ich an, oh was ist denn hier los, sitze ich auf einem Jumpseat?

Tom Bartel (00:20:30 - 00:21:41)

Das war so ein spezielles Thema, also erstens hatten wir eine Umstrukturierung intern und zweitens, ich war im Engineering Recruiting. ... sehr aktiv halt, weil wir damals so sehr gewachsen sind. Ich habe da, ... ... ich weiß nicht, 2016 oder so, oder 2015, ... ... habe ich glaube ich 16, 17 Leute ... ... mit ins Team aufgenommen von außen ... ... und eben auch entsprechend ... ... Dutzende oder über 100 Interviews geführt wahrscheinlich. Und Tech Recruiting war damals ganz heiß. Also das war ein sehr, ... ... ist ja immer noch ein umkämpfter Markt, ... ... aber das war auch ... Das war damals aus firmenstrategischer Sicht ein sehr heißes Thema. Da hat sogar der CEO selber drauf geschaut und der hat mich gefragt, ob ich mir vorstellen könnte, meine Erfahrung im Tech Recruiting in die Personalabteilung einzubringen. Und dann haben wir da zunächst versucht, eine spezielle Stelle für mich zu definieren, wo ich dann mit dem Talent Acquisition Team zusammengearbeitet habe. Das hat nicht so gut funktioniert und deshalb bin ich dann bald weiter in...

Wolfi Gassler (00:21:41 - 00:21:44)

Das heißt aber, da bist du wirklich auch ganz vom Coding weg?

Tom Bartel (00:21:44 - 00:21:46)

Da bin ich zunächst ganz vom Coding weg, ja.

Wolfi Gassler (00:21:46 - 00:21:49)

In eine Product Owner Rolle, wenn ich das richtig empfehle.

Tom Bartel (00:21:49 - 00:22:03)

Das war es dann letzten Endes, genau. Wir haben da so ein paar Eigenentwicklungen fürs Talent Recruiting und speziell auch technisches Recruiting gehabt. Und die Produkte habe ich dann mitverantwortet als Product Owner.

Wolfi Gassler (00:22:04 - 00:22:30)

Das zeigt schon eine gewisse Flexibilität, würde ich mal sagen, oder? Weil man komplett aus dem Coding-Teil aussteigt. Ich meine, wir haben beide viel Recruiting gemacht und man hat da ja auch Spaß dran, aber mit den meisten, mit denen ich gesprochen habe, war das halt so eine nette Nebenbeschäftigung, hin und wieder mal ein Interview zu führen. Aber das jetzt Fulltime zu machen, ist ja doch noch ein ganz anderer Schritt. Hat dir dann am Ende irgendwas geholfen, diese Erfahrung jetzt komplett woanders zu sein?

Tom Bartel (00:22:31 - 00:22:57)

Ja, würde ich schon sagen, weil man hat halt nochmal einen ganz anderen Blick auf Dinge. Also ich war dann als Product Owner mit dem Produkt beschäftigt, habe quasi mit einem Entwicklerteam, ich habe sozusagen die Seiten gewechselt und habe Entwickler mit denen diskutiert, welche Features wir bauen sollen und mit den Designern die Ideation gemacht und so weiter.

Wolfi Gassler (00:22:58 - 00:23:01)

Warst du da irgendwie dann akzeptierter bei den Engineers dadurch?

Tom Bartel (00:23:01 - 00:23:43)

Total, ja, total. Also mit denen hat es von Anfang an gepasst und das war sogar remote. Also das Entwicklerteam saß in Palma, ich saß in Düsseldorf und das hat super geklappt. Ich bin super mit denen ausgekommen, die sind super mit mir ausgekommen. Ich habe nur eins auf die Finger gekriegt, als ich irgendwann mal ein Code-Review gemacht habe und in GitHub irgendwie dann oder in der Code-Verwaltung LooksGoodToMe abgelassen habe. Und dann ist sofort einer von den Engineering-Managern gekommen und hat gesagt, ey, bitte Produktmanager halten sich da zurück. Die nehmen nicht an Code-Reviews teil. Und das musste ich dann auch akzeptieren.

Andy Grunwald (00:23:44 - 00:23:45)

Würdest du das heutzutage so unterschreiben?

Tom Bartel (00:23:45 - 00:23:54)

Ich weiß nicht, also wenn der Produktmanager Ahnung von Code hat, dann würde ich da jetzt keine so strikte Trennlinie ziehen.

Andy Grunwald (00:23:55 - 00:24:03)

Also kannst du dir vorstellen, dass ein Produktmanager den kompletten architekturellen Kontext der Applikation im Kopf hat, um einem Pull-Request zu sagen, looks good to me?

Tom Bartel (00:24:04 - 00:24:23)

In der Regel nicht. Aber ich weiß nicht mehr, was das für ein PR war. Vielleicht war es auch nur etwas Kleines oder so. Man muss auch sagen, klar hat man einen Interessenskonflikt als Produktmanager. Du willst in der Regel als Produktmanager das Zeug schnell raushaben, dass es live geht. Und das kann zu Lasten der Qualität gehen.

Wolfi Gassler (00:24:23 - 00:24:33)

Und von der anderen Seite ein gewisses Konflikt, dass du zu nett zu den Entwicklern bist, weil du sie zu sehr verstehst und zu wenig das Product im Kopf hast?

Tom Bartel (00:24:33 - 00:25:12)

Das ist auch was, was man im Kopf haben muss. Ich denke, ich habe da eine gute Balance gefunden. Also ich habe denen jetzt auch nicht alle Zeit der Welt zugestanden, wenn sie irgendwas komplett neu schreiben wollten oder mal experimentieren mit irgendeiner neuen Bibliothek, nur einfach, weil es interessant klingt oder so. Also ich habe da schon geguckt, dass wir auf der Spur bleiben. Aber ich habe, glaube ich, schon auch gut einschätzen können, Wenn jetzt was wirklich nötig ist und wenn die die Zeit brauchen, um sich einzuarbeiten in irgendwas, dann hat man da vielleicht schon mehr Verständnis, wenn man selber auch einen technischen Hintergrund hat.

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

Also wir haben ja jetzt 2024, das ist ja jetzt schon eine Zeit her, aber ich kann mich erinnern, damals war das eigentlich schon, wie ich gehört habe, du wechselst, war das schon irgendwie was Neues. Also sogar damals in der hippen, coolen, modernen, flexiblen Firma war das schon was Neues. Und du bist ja mittlerweile nicht der Einzige, es gibt ja da zum Beispiel von Mitchell Hashimoto von HashiCorp, dem Gründer. Das war 2021, dass der zurückgetreten ist aus dem C-Level und Individual Contributor ist, der halt geschrieben hat, man soll das tun, was man liebt und nicht was von einem erwartet wird. Aber das war 2021. Und es gibt da den berühmten Artikel eben oder beziehungsweise den Artikel, der meines Wissens zumindestens den Term geprägt hat von diesem Engineering Manager Pendulum oder Pendel von der Charity Mayers, der war 2017 und dein Artikel, war von 2018 in deinem Blog, also es dürfte alles um den Dreh gewesen sein, aber es war schon sehr sehr früh, also es war jetzt definitiv kein Standard-Move, würde ich mal sagen, oder? Oder hast du in deiner Umgebung irgendwie Leute ähnliche Schritte machen gesehen?

Tom Bartel (00:26:24 - 00:27:21)

Nee, ich kann mich auch an den Fall von einem Kollegen erinnern, auch bei Trivago, der wurde 14, 15 oder so, Engineering Manager, und hat nach einem halben Jahr oder so gemerkt, er wollte das nicht mehr weitermachen, sah sich aber, also er hat es für sich nicht als Option gesehen, jetzt in derselben Firma wieder Individual Contributor zu werden. Er hätte das, ich weiß nicht, ob er es als Gesichtsverlust oder sonst was wahrgenommen hätte, oder hätte Angst gehabt, dass die anderen das so sehen. Aber da hat dann wirklich die Firma gewechselt deshalb und ist wieder Entwickler geworden woanders dann. Und das finde ich halt schon schade. Also ich habe da immer Vertrauen gehabt eigentlich, dass das jetzt nicht, dass man da ein Ansehen verliert, wenn man jetzt in eine Einzel-Contributor-Rolle wieder zurück wechselt. Ich habe die Gefahr nie gesehen.

Andy Grunwald (00:27:21 - 00:28:20)

Aber ich glaube das ist auch ganz stark abhängig von der Firmenkultur, also wenn man jetzt mal andere Podcasts hört, zum Beispiel gibt es den Podcast Minimal Empires von Sumit Kumar und er hatte auch mal eine Karriere im Daimler Konzern und er spricht auch immer über die Daimler Karriereleiter. Ich habe noch nie für Daimler gearbeitet, aber es klingt so, als wäre das, was du gerade gesagt hast, den Schritt zurück, in einer solchen Konzernstruktur jetzt nicht wirklich offen, beziehungsweise wo Leute links und rechts sagen, hm, hat der keinen guten Job gemacht. Also und von der traditionellen Bildung, die ich habe, von dem traditionellen deutschen Arbeitsumfeld, Vielleicht auch aus der Duisburger Stahlindustrie und Kohleindustrie, ich weiß es jetzt gerade nicht. Auf jeden Fall ist es da wirklich, ich sag mal, so der Standardprozess, okay, du versuchst die Karriereleiter nach oben zu gehen, bist vielleicht nicht glücklich und dass du dann, ich sag mal, einen Neubeginn in einer anderen Firma startest. Also die Flexibilität, dass das wirklich, ich sag mal, willkommen ist, könnte ich mir schon, also stelle ich mir zumindest vor, dass das sehr selten ist.

Tom Bartel (00:28:20 - 00:28:33)

Möglich. Ich habe da wenig Erfahrung mit anderen Firmen, aber ich würde mir wünschen, dass es heutzutage zumindest in vielen IT- oder IT-nahen Firmen eigentlich kein Problem mehr ist.

Wolfi Gassler (00:28:33 - 00:28:55)

Was würdest denn du sagen als Hiringmanager jetzt, wenn du ein CV bekommen würdest? Und da sieht man Entwickler, Engineeringmanager, dann HR, Productowner, dann wieder JavaScript-Entwickler, dann wieder Lead und das womöglich bei immer bei anderen Firmen. Würdest du dann dir denken, oh der springt oder würdest du das positiv empfinden?

Tom Bartel (00:28:56 - 00:29:48)

Ich glaube, das würde ich erstmal neutral sehen. Kommt halt ein bisschen auf die zeitlichen Abstände an. Wenn es jetzt alle zwei Monate was anderes ist, dann wird es mir schon ein bisschen komisch vorkommen. Aber ich würde den Bewerber oder die Bewerberin dann halt fragen, wie das kam. Manchmal gibt es gute Gründe, vielleicht in einem Start-up, da muss ja jeder mal alles machen. Da kann das schnell passieren, dass man so eine Rolle wechselt und dann zeugt das ja auch von der Einsatzbereitschaft von der Person eventuell, von der Flexibilität und dann kann es auch was Positives sein. Und ich hatte das schon. Also ich hatte schon Bewerber, die sind vom Entwickler dann in eine Produktrolle gegangen und dann irgendwie wieder zurück. Und in dem Fall war das wirklich, weil es halt betriebliche Veränderungen gab und es musste halt jemand den Job machen und sie haben den gemacht.

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

Hat dir jemand diese Flexibilität gedankt?

Tom Bartel (00:29:51 - 00:30:12)

Oh, da muss ich nachdenken. Ich weiß es nicht mehr. Ich kann mich jetzt nicht ausdrückliches Dankeschön erinnern, aber es war auf jeden Fall, wo ich dann wieder zurück bin, weil, auch wieder Beispiel, ich bin dann wieder in die Entwicklungsabteilung zurück.

Wolfi Gassler (00:30:12 - 00:30:14)

Dann als IC oder als Lead?

Tom Bartel (00:30:14 - 00:30:32)

Als IC zunächst, für ein paar Monate dann wieder als Lead. Und da hat sich dann der CEO schon bedankt, auch für meine Flexibilität, weil da hatten wir gerade ein Problem mit Entwicklern, hatten wir zu wenig Kapazität. Von dem her, ja, also kurze Antwort, ja.

Andy Grunwald (00:30:32 - 00:30:46)

Sprechen wir mal ganz kurz über die Zeit, da wo du wieder vor dem Computer saßt und eine IDE offen hattest. Wie war die erste Woche? Wenn ich das richtig in deinem Lebenslauf entlebne, ... ... warst du knapp vier Jahre weg vom Code.

Tom Bartel (00:30:46 - 00:31:34)

Vom täglichen Coding auf jeden Fall. Ich habe so ein bisschen Nebenprojekte gemacht, ... ... nebenher mit Coding. Aber so im alltäglichen Coding, ... ... ja ein paar Sachen muss man halt mal nachfragen. Wie macht man dies, wie macht man jenes? Aber so schlimm war es nicht. Also man hatte das Verständnis für Code ja immer noch. Die meiste Zeit verbringst du ja damit, Code zu lesen. Als Entwickler liest du viel mehr Code, als dass du Code schreibst. Und das kriegst du auch dann noch hin, wenn du nicht jede CSS-Property genau kennst, die da verwendet wird. Dann weißt du auch, wo du das nachschauen kannst und so. Von dem her war ich wahrscheinlich nicht genauso produktiv und schnell wie andere, aber ich bin vorangekommen.

Andy Grunwald (00:31:34 - 00:32:17)

Ich habe ja auch mal das Pendulum mitgemacht. Das bedeutet, ich hatte auch eine Engineering-Management-Rolle, war auf Director-Level und irgendwann war ich wieder Individual-Contributor. Und ich gebe zu, meine erste Woche, da habe ich festgestellt, wie sich mein Hirn in der Management-Rolle umfunktioniert hat. Weil auf einmal sitzt du wieder mehrere Stunden vor der IDI. Du musst wieder einen sehr großen Kontext in deinem Kopf behalten, in sehr kurzer Zeit. Diese Callstacks und allem drum und dran. Und ich war effektiv knallhart müde in der ersten Woche oder vielleicht sogar in den ersten zwei Wochen, weil ich das, ich hab das Gefühl gehabt, mein Hirn muss sich neu verkabeln. Und ich wurde knallhart wieder daran erinnert, warum das mit dem Programmieren immer alles so lange dauert. Kommt jetzt bekannt vor.

Tom Bartel (00:32:18 - 00:33:30)

Das ist manchmal gut, die Erfahrung zu machen. Ja, es ist auf jeden Fall eine ganz andere Belastung. Also als Engineering Manager, da hast du mehr, du triffst andere Entscheidungen. Als Entwickler musst du auch dauernd Entscheidungen treffen. Nenne ich diese Variable? Wie nenne ich diese Funktion? Wo packe ich die Funktionalität hin? Welche Datenstruktur verwende ich? Und so weiter. Dutzende, hunderte Entscheidungen jeden Tag. Und das ist ermüdend. Auf jeden Fall stimme ich dir hundertprozentig zu. Und wenn du nicht aufpasst und ein paar Pausen machst ab und zu, kann es schon sein, dass du drei Stunden am Stück am Rechner sitzt und dich intensiv reindenkst, ohne auch nur einmal aufzustehen vom Computer. Und als Engineering Manager, da hast du halt ein bisschen mehr Unterbrechungen und du hast hier ein Meeting, da ein Einzelgespräch, dann musst du irgendwie was schreiben oder Tasks erstellen oder Listen durchgehen und irgendwas überprüfen und so weiter. Das ist auch ermüdend manchmal. Aber die Gespräche zwischendurch, die lockern es irgendwie auf. Also das ist was anderes.

Wolfi Gassler (00:33:30 - 00:33:34)

Andi, es ist jetzt dein Einsatz für deinen Lieblings-Blog-Post von Paul Graham.

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

Oh ja, ein wundervolles Beispiel hast du gerade genannt für Maker-Schedule, Manager-Schedule von Paul Graham. Verlinken wir natürlich auch. Immer noch einer meiner Top-Blog-Posts.

Wolfi Gassler (00:33:45 - 00:33:50)

Ich glaube, wir verlinken den jetzt schon bald in jeder zweiten Episode. Ist wirklich, glaube ich, dein Lieblings-Artikel von heute.

Andy Grunwald (00:33:50 - 00:33:53)

Ja, aber ich glaube, Paul Graham bietet keine Affiliate-Links an.

Tom Bartel (00:33:53 - 00:33:54)

Aus gutem Grund.

Wolfi Gassler (00:33:55 - 00:34:31)

Aber wenn wir gerade bei Blogartikel sind, kann ich gleich einen Satz zitieren aus dem Charity Mayers Blogpost. Und zwar, keine Ahnung, ob der von ihr kommt oder vielleicht so ein allgemeines Saying auch in der Industrie ist, aber dieses wird fast Sprichwort sagen. besagt, dass man eigentlich der beste Engineering Manager ist, wenn man gerade so zwei Jahre weg ist vom Code. Also man gelernt hat, wie man Engineering Manager ist, aber doch noch die Nähe zu dem Code hat. Und der beste Individual Contributor oder der beste Developer ist der, der Management-Erfahrung hat. Könnt ihr das nachvollziehen beide oder bestätigen?

Tom Bartel (00:34:31 - 00:35:46)

Ich komme zuerst zum zweiten Teil. Also ich denke, wenn man mal Manager war und so Teamverantwortung hatte und dann wieder IC wird, man hat immer noch diese Denkweise, dieses Mindset von einem Manager. Man weiß, okay, mein Manager, der ist auch nicht allwissend, weil ich war es als Manager auch nicht. Wenn ein Engineer zum Manager kommt und sagt, ich habe da so und so ein Problem, dann hat der Manager nicht die Antwort parat, weil er meistens auch nicht, er steckt ja nicht so tief drin wie der Engineer in der Regel. Er kann oft nur helfen, dem Engineer die Lösung selber zu finden. Und wenn du das als Engineer weißt, dann sparst du dir manchmal den Schritt, ... zu deinem Manager zu gehen ... ... und den um die Lösung anzubetteln quasi, ... ... sondern du weißt, okay, ... ... der ist auch nicht schlauer als ich ... ... oder allwissend, ... ... dann probiere ich erst mal selber ... ... eine Entscheidung zu fällen ... ... und eine Lösung zu finden ... ... und das erhöht ... ... ganz enorm deine Selbstständigkeit, ... ... glaube ich, als IC ... ... und es entlastet halt wiederum ... ... deinen Manager dann. Und das ... ... macht dich zu einem wertvolleren IC, ... ... das denke ich schon.

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

Und die andere Richtung?

Tom Bartel (00:35:47 - 00:36:41)

Die andere Richtung ist auch wichtig. Wenn du Manager wirst, dann solltest du Empathie haben können für deine Entwickler. Du solltest wissen, was für Probleme, was für Schwierigkeiten die im Alltag bewältigen müssen. Andi hat es vorhin gesagt, du weißt dann mal wieder, warum dauert Softwareentwicklung manchmal so verdammt lange, obwohl es so von außen betrachtet eigentlich straightforward aussieht. Und das hast du, diese Fähigkeit oder dieses Wissen und das Gefühl hast du natürlich am stärksten, wenn du gerade erst den Übergang gemacht hast, vom IC, vom Entwickler zum Manager. Dann ist das noch frisch in deinem Kopf und du weißt, wie haarig manche Probleme sind, wie was für Schwierigkeiten in der Codebase lauern, dass dieses Thema immer heikel ist und so weiter. Und mit der Zeit, wenn es dumm läuft, verliert sich das halt so mit der Zeit ein bisschen.

Wolfi Gassler (00:36:41 - 00:36:47)

Aber diese Weisheit sagt dann ja auch, dass du nach zwei Jahren quasi schlechter wirst, wenn man das eigentlich richtig weiter befolgt, das Ganze.

Tom Bartel (00:36:48 - 00:37:24)

Ich denke, das ist ein bisschen überspitzt formuliert. Du wirst vielleicht in der Hinsicht schlechter, dass du vielleicht ein bisschen weniger Verständnis hast für manche Sachen, die dann länger dauern. Aber du gewinnst ja auch in anderer Hinsicht dazu an Erfahrung als Manager generell. Du hast mehr schwierige Gespräche zum Beispiel bewältigt oder mehr Umstrukturierungen in der Organisation navigiert und deine Leute beruhigt dabei und Führung gegeben. Das kann dann das so ein bisschen kompensieren, denke ich mal.

Wolfi Gassler (00:37:24 - 00:38:03)

Also das Ganze ist ja die Argumentation für dieses Pendel, dass ich eigentlich auch wieder zurückgehen kann und wieder zum Engineering Manager und wieder zum IC und hin und her wechsel, dann bin ich eigentlich immer in diesem Optimum drinnen. Ich bin vielleicht zwei Jahre weg von der Engineering-Rolle und dann bin ich aber auch wieder ein guter Engineer, weil ich eben diese Management-Erfahrung habe. Jetzt, wenn man das konsequent fortführen würde, würde das ja heißen, dass man das fast machen muss und dass es zum Beispiel auch keine guten Manager gibt, die keinen Engineering-Background haben und gar keine guten Engineers geben kann, die keine Management-Erfahrung haben. Andi schnauft schon seit drei Minuten, der will sowieso dringend was loswerden.

Tom Bartel (00:38:03 - 00:38:36)

Also ich könnte dazu gerade nochmal sagen, ich denke, dass ... spiegelt halt den speziellen ... ... Werdegang von Charity Majors auch wieder, ... ... die das so gemacht hat. Sie beschreibt ja in dem Text auch, ... ... dass sie, sie wird halt immer unruhig, ... ... wenn sie ... ... dann so in einem Startup ... ... den Textwerk aufgebaut hat, ... ... dann das Team aufgebaut hat und dann ... ... hat sie irgendwann das Gefühl, ... ... oh, ich weiß, was ich hier tue, ... ... ich bin in ruhigem Fahrwasser, relativ gesehen. Jetzt werde ich unruhig. Das ist immer ein Zeichen für sie, ... ... dass es Zeit wird, was Neues zu tun.

Wolfi Gassler (00:38:36 - 00:38:40)

Also wenn es langweilig wird eigentlich. Oder wenn man sich wohl fühlt eigentlich.

Tom Bartel (00:38:40 - 00:39:34)

Genau. Sie hat so das Gefühl, ja ich weiß was ich hier tue, alles geht so mehr oder weniger seinen geregelten Gang. Aber ich glaube das ist halt individuell verschieden auch. Das ist bei ihr, sie wird dann halt ruhelos, rastlos und muss zur nächsten Station. Aber das hat ja vielleicht nicht jeder und das ist auch nicht in jeder Firma so möglich. Ich denke, wenn du halt im Konzern bist oder so, dann gibt es dann halt da noch weitere Level, wie du aufsteigen kannst als technischer Manager. Und das bringt ja dann auch wieder was Neues mit sich, wenn du vom Line Manager zum Director wirst oder dann noch weiter höher aufsteigst zu irgendwelchen Abteilungsleiter oder Divisionsposten oder sonst was und deshalb bist du nicht automatisch ein schlechter Manager glaube ich, wenn du nicht zwischendurch mal wieder ein Jahr als IC machst.

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

Aber kannst du guter Manager sein ohne technischen Background?

Tom Bartel (00:39:38 - 00:39:54)

Ja, ich glaube schon. Also ich habe zum Beispiel eine, meine Vorgesetzte in der Zeit, als ich Produktmanager war, die war auch eine sehr gute Managerin und die hatte keinen technischen Background. Und ich denke, dass es möglich ist.

Wolfi Gassler (00:39:54 - 00:39:57)

Aber die war keine Managerin von Engineers?

Tom Bartel (00:39:58 - 00:40:02)

Nicht direkt, aber sie war für den Output von den Engineers verantwortlich.

Wolfi Gassler (00:40:02 - 00:40:08)

Kennst du irgendwelche Direct-Manager von wirklich Entwicklerteams, die gut waren?

Tom Bartel (00:40:09 - 00:40:10)

Da muss ich überlegen.

Wolfi Gassler (00:40:10 - 00:40:12)

Andi, kennst du welche?

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

Ich habe jetzt keinen direkten Namen zur Hand, aber ich denke wirklich, dass... Du.

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

Musst mir auch keinen Namen sagen, ob du jemand mal kennengelernt hast, oder?

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

Ich hatte mal einen Vorgesetzten, er hatte... Als IC? Genau, ich war IC und hatte einen Manager und er war kein Software-Ingenieur oder ähnliches und er war ein enorm guter, ich würde sagen, General Manager. Und ich würde so weit gehen, dass jeder gute Manager auch Domänen fremder Teams leiten kann. Weil bei gutem Management, natürlich muss man sich in die Fachdomäne, was manage ich denn hier schon, was sind die Business-Kriterien und als Manager, das muss man alles auf dem Zettel haben und das kann jeder gute Manager sich drauf schaffen. Aber das tun auch Manager, die jetzt von Coca-Cola nach Apple wechseln. Ja, Apple hat nichts mit Softdrinks zu tun, aber sie werden es trotzdem hinkriegen, wie das Hardware-Business läuft. Also von daher, deswegen denke ich, Fachdomäne ist nicht notwendig, sondern da kommt wirklich dann das Key-Kriterium vom Management. Leute führen, Kommunikation, den richtigen Leuten vertrauen, Chancen geben, aber auch einen Rahmen setzen und Co. Also ich denke, das ist möglich. Und ich kenne auch einen und ich würde auch mal so geführt, Ich war auch ehrlich, am Anfang hatte ich sehr starke Skepsis. Was soll der mir hier erzählen? Aber der hat mich auch nie gefragt, ob ich da ein Heck einbauen kann oder ähnliches.

Tom Bartel (00:41:31 - 00:42:17)

Ich denke, wenn man direkt Entwickler unter sich hat, ist es schon ein großer Vorteil selber auch zu können, was die können, oder zumindest theoretisch. Weil Untersuchungen zufolge steigert das erstens die Zufriedenheit der Leute selber. Wenn die wissen, mein Manager kann das tun, was ich tue, dann Das erhöht in der Regel ihre Zufriedenheit, weil dann haben sie keinen Druck, sich irgendwie zu rechtfertigen, wenn was länger dauert, weil der Manager eben intuitiv versteht, warum das jetzt komplex ist. Und idealerweise sollte der Manager halt auch daran arbeiten, seine Leute besser zu machen. Und wenn du einen Entwickler besser machen willst, dann solltest du idealerweise auch ein bisschen was technisches Verständnis haben.

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

Ich glaube, der zweite Punkt, den du ernannt hast, ist super wichtig und ein General Manager wird damit Schwierigkeiten haben. Aber ich muss auch sagen, dass ein fachfremder Manager einfach den riesen Vorteil hat, dass er niemals die Grenzen überschreitet und niemals sagt, ... Bau das so oder niemals in Pull-Requests gucken wird. Das bedeutet, das ist halt ein riesen Vorteil ... ... und auch ein Nachteil von Leuten, die ... ... sich mit Code auskennen. Man kann mal relativ schnell die Grenze überschreiten ... ... und somit in das Territorium ... ... der Individual Contributor gehen. Und dann ... ... kommt auch das böse Wort ... ... böse Wort Micromanagement vielleicht irgendwann auf den Tisch ... ... und allem drum und dran.

Wolfi Gassler (00:42:58 - 00:43:09)

Es kann ja auch positiv sein, wenn du das verstehst und ... ... dich vielleicht Leute auch fragen, wie würdest du es machen ... ... oder mit dir diskutieren. Aber ich glaube, man müsste dann halt eine andere Person finden, die das, den Teil ersetzt.

Andy Grunwald (00:43:09 - 00:43:23)

Es kann positiv sein, aber ich würde das auf einem anderen Level deklarieren. Und zwar, du musst schon verstehen als Manager, was deine Leute von dir wollen, aber das würde ich als Bullshit-Filter irgendwie deklarieren.

Tom Bartel (00:43:24 - 00:44:00)

Ich wollte auch sagen, was du gesagt hast, Wolfi, es kommt dann halt aufs Umfeld auch an. Wenn jetzt der direkte Manager diese Funktion nicht übernehmen kann, dann gibt es vielleicht einen Staff-Engineer oder sowas, einen hohen, hochrangigen, technischen Spezialisten, der halt dann das Training mit übernehmen kann, die Weiterbildung von den Leuten. Feedback geben zu deren Coach, gucken, dass die Richtlinien eingehalten werden und so weiter. Und am besten ist halt, wenn der Staff-Engineer und der People-Manager, der Engineering-Manager sich dann auch austauschen entsprechend.

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

Also ich denke mir auch damals, wie wir da 20 Leute unter uns gehabt haben, 20 Reports, da macht man kaum mehr irgendwas Technisches. Vielleicht hat man den Vorteil, dass man in den ganzen One-on-Ones super schnell versteht, wo das Problem ist und vielleicht dann schneller reagieren kann als jemand anderer. Aber was willst du mit 20 Reports noch irgendwie in den technischen Details drin sein oder verstehen können, was da die Teams im Detail machen oder auch helfen können, ist dann schon sehr, sehr schwierig.

Tom Bartel (00:44:26 - 00:44:28)

Ja, richtig.

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

Hast du schon mal als Engineering Manager Leute geleitet, die bei dem Pendel aktiv waren? Das bedeutet, hast du schon mal Leute geleitet, die mal Engineering Manager waren und zurück zu IC gependelt sind? Ja.

Tom Bartel (00:44:43 - 00:44:45)

Ja, hatte ich.

Andy Grunwald (00:44:45 - 00:44:54)

Was würdest du sagen, welche Skills hatten diese Leute gegenüber Leuten, die noch keine Leadrolle hatten, die das Pendel noch nicht durchlaufen haben?

Tom Bartel (00:44:55 - 00:45:31)

Ich würde sagen, tendenziell haben die einen größeren Fokus auf Value Creation. Also, dass wirklich was hinten dabei rauskommt für ein Business Value. Nicht einfach nur, okay, ich programmier hier was und es funktioniert jetzt vielleicht nicht so perfekt, aber es hat halt seine Eigenheiten, es ist aber ein schöner Code und ich lass das jetzt so, sondern die haben manchmal mehr den Fokus halt drauf auf dem Ergebnis, weil manche Entwickler haben das nicht immer.

Andy Grunwald (00:45:31 - 00:46:14)

Das, was ich mal festgestellt habe, ich habe das Gefühl, die sind bessere ICs, weil die deine Probleme verstehen. Und zwar deine tägliche Arbeit als Manager, Konflikte lösen, sich mit Politik rumschlagen vielleicht sogar, auch mal ein Argument mit gegen einen anderen Team zu verlieren, Oder vielleicht so ganz simple Dinge, dass du als Manager im Teammeeting einfach nur Engagement haben möchtest, dass Leute dabei sind, dass du da keinen Monolog hältst. Und da habe ich immer das Gefühl, diese ICs, die mal Manager waren, die wissen um deine Probleme und deswegen sind das bessere ICs, weil die dich implizit immer so ein bisschen unterstützen. Die wissen, dass du willst, dass andere Leute ihren Senf dazugeben.

Tom Bartel (00:46:15 - 00:46:51)

Ja, ich glaube, da hast du einen guten Punkt, dass man als Engineering Manager halt nicht immer die ganze Show alleine moderieren will, Teammeetings. Ich weiß noch am Anfang, ich habe die auch gehasst wie die Pest, immer wenn es still ist, musst du derjenige sein, der irgendwas sagt. Und das Ganze am Laufen hält, damit nicht diese sehr unangenehme Stille 10 Sekunden, 20 Sekunden dauert oder sowas. Und ja, da ist glaube ich was dran, dass die Leute, die schon mal selber in der Position waren, dass die dann eher aus ihrer Komfortzone kommen und auch was dazu beitragen.

Wolfi Gassler (00:46:51 - 00:46:59)

Geht dir das mit dem ganzen Recruiting jetzt auch so, dass du die Welt besser verstehst oder besser nachvollziehen kannst, was deren Probleme sind, weil du dort gearbeitet hast?

Tom Bartel (00:46:59 - 00:47:01)

Was die Probleme der Recruiter sind?

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

Ja, ganze HR und du hast ja dann doch viel mitbekommen wahrscheinlich.

Tom Bartel (00:47:06 - 00:47:26)

Ja doch, denke ich schon. Also sogar auch schon dadurch, dass ich nur in der Nähe von den Teams saß und das so ein bisschen mit einem Ohr mitbekommen habe und die Recruiterinnen waren es meistens, so in der Küche getroffen habe und so. Ja, schon, ich glaube, schon allein dadurch hat man ein bisschen besseres Gefühl dafür.

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

Hast du dann jetzt auch vor, durch die Design- und Data Science Teams zu pendeln?

Tom Bartel (00:47:30 - 00:47:33)

Bis jetzt nicht, aber man weiß ja nie.

Wolfi Gassler (00:47:33 - 00:48:00)

Aber mir ist das damals auch so gegangen, also wie einmal beim Patrick gesessen bin, den wir auch interviewt haben in Episode 88, der damals Business Partner war. Und ich bin ja mal neben dem gesessen in seinem Office, weil die waren ja sogar in einem anderen Gebäude, wie er da mit der Ausländerbehörde oder irgendwas telefoniert hat. Diese paar Minuten haben mir alleine so gezeigt, wie schlimm dieser Beruf ist, für mich zumindest, und was da alles geleistet werden muss und was man da machen muss. Man hat also wirklich so wenig Einblick.

Tom Bartel (00:48:01 - 00:48:03)

Man gewinnt eine andere Wertschätzung nochmal.

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

Genau, genau. Also ich glaube, so ein Einblick ist ganz, ganz wichtig und mir ist es persönlich auch da zum Beispiel mit der Universität immer so gegangen, weil ich habe halt dann erlebt, wie schlecht diese Welt teilweise gesehen wird unter Leuten, die nicht an der Uni waren und wie abschätzig sich da halt teilweise auch Leute äußern und so weiter. Also umso mehr man halt andere Welten kennt, umso eher versteht man die halt alle und ich glaube, dass das ein großer Vorteil ist, auch wenn das oft nicht so gesehen wird. Und da kann ich dir auch gleich nochmal Danke sagen, weil du warst in meinem Interview damals bei Trivago, wie ich mich beworben habe. Und du hast sehr wohl irgendwie den Sinn darin gesehen, dass ich auf der Universität und so weiter zum Beispiel Erfahrung hatte mit Leadership und so weiter, obwohl es ja offensichtlich eigentlich nicht der Fall ist, weil ihr habt damals noch nie irgendwie ein klassisches Team geleitet oder so. Klar, im Freelancing-Bereich und an der Uni und du hast die Studenten und alles, was da mitspielt. Aber daraus dann zu sehen, dass das in irgendeiner Form Leadership-Erfahrung ist, bin ich mir nicht sicher, ob das so viele machen würden. Und ich habe ja mal das zufällige Glück gehabt, damals hat es ja kein GDPA gegeben, deine Comments über mich zu finden. Von dem Interview und da ist es ja drinnen gestanden. Also da war ich ja sehr positiv überrascht. Nebenbei negative Dinge, die du auch gefunden hast.

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

Also eigentlich möchtest du gerade sagen, der Tom ist dafür verantwortlich, dass diese Scheiße hier gerade existiert.

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

Ja genau.

Andy Grunwald (00:49:31 - 00:49:34)

Und er hat Sinn in dem, was du getan hast gesehen.

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

Ist in dem Kommentar damals zumindest gestanden, ja.

Tom Bartel (00:49:37 - 00:49:40)

Ja, ich war betrunken an dem Tag, keine Ahnung, nichts dafür.

Andy Grunwald (00:49:40 - 00:49:43)

Ich habe so viele Fragen, Tom. So viele Fragen.

Tom Bartel (00:49:44 - 00:50:56)

Ich glaube, ich muss sofort weg. Aber du hast, Wolfi, vorhin gefragt, was denn mir das gebracht hat, so mit diesem Wechsel zu Product Management und so weiter. Eins wollte ich noch hinzufügen, sofern das in derselben Firma ist, es ist auch extrem hilfreich, das Netzwerk, das man da bei aufbaut. Du hast dann, ich war in einer komplett anderen Abteilung, komplett andere Funktionen, komplett andere Leute um mich rum. Aber du hast natürlich immer noch gute Verbindungen jetzt so bei mir eben in die Webentwicklung. Und wenn du da mal Infos brauchst oder irgendwas erledigt haben möchtest oder so, oder du brauchst irgendwie Feedback über irgendein Projekt, was jetzt die Personalabteilung plant, dann hast du da sofort die passenden Leute. weil du die alle kennst oder du kannst fragen, wer da passen würde und so weiter. Und umgekehrt, wenn jemand von deinen alten Kumpels in der Entwicklungsabteilung was von der Personalabteilung will, dann fragen sie dich und dann läuft halt viel Kommunikation durch dich und da kriegst du auch extrem viel mit. Und das hat mir auch beim Nach-Mein-Wechsel-Zurück auch oft geholfen, vor allem wenn es um Recruiting ging.

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

Du sprichst hier vom berühmt-berüchtigten kurzen Dienstweg, oder?

Tom Bartel (00:51:00 - 00:51:17)

Ganz genau, ja. So Hinterzimmer-Kanäle und so. Die sind halt oft viel effizienter als irgendwelche offiziellen Kanäle. Oder in manchen Fällen gibt es auch gar keine offiziellen Kanäle. Und dann ist es halt in einer Firma von ein paar hundert Leuten nicht ganz unwichtig, wen du kennst.

Wolfi Gassler (00:51:17 - 00:51:28)

Also nimm dir ein Beispiel, Andi. Wechsle jetzt mal ins Design. Werde Designer, damit du mal eine andere Welt kennenlernst und da auch endlich Kontakte hin hast. Weil immer, wenn wir irgendwen suchen, der Design macht, haben wir keine Kontakte.

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

Ich hatte gerade schon so ein bisschen Angst, dass du sagst, nimm mir mal ein Beispiel, Sinn in meiner Arbeit zu sehen. Ne, Wolfgang, da sehe ich keinen Sinn.

Tom Bartel (00:51:37 - 00:51:38)

Das habe ich schon lange aufgegeben.

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

Wenn ich mir dein Lebenslauf so ansehe.

Tom Bartel (00:51:41 - 00:51:41)

Ihr habt meinen Lebenslauf?

Andy Grunwald (00:51:42 - 00:51:53)

Natürlich, das Internet. Dann bist du jetzt wieder vier Jahre in einer Lead-Position und laut dem Pattern deines Lebenslaufes wäre es mal wieder Zeit für ein Pendel. Könntest du dir das nochmal vorstellen?

Tom Bartel (00:51:53 - 00:51:57)

Die Frage habe ich mir vorhin selber gestellt, ja.

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

Aber du bist ja jetzt Director, oder? Also du bist ja jetzt Lead von Leads.

Tom Bartel (00:52:01 - 00:52:10)

Ich bin Lead von Leads seit August. Das ist jetzt eben nochmal eine Änderung. Das ist eine coole Abwechslung.

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

Eine Flughöhe höher.

Tom Bartel (00:52:12 - 00:52:13)

Ja, wenn man so will.

Wolfi Gassler (00:52:13 - 00:52:16)

Aber jetzt bist du ja noch weiter weg vom eigentlichen Coding.

Tom Bartel (00:52:16 - 00:52:42)

Sozusagen, ja. Aber ich muss sagen, davor hatte ich auch schon wieder, ich glaube, acht oder neun Direct Reports. Da war auch schon so langsam nicht mehr viel mit Hands-on. Von dem her ist der Unterschied gar nicht so groß. Ich mache immer noch relativ viele Code Reviews und das ist zumindest ein Weg, mit Code in Kontakt zu bleiben. So bleibe ich ein bisschen verbunden.

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

Moment, aber ist es deine Aufgabe als Director, Code Reviews zu machen?

Tom Bartel (00:52:46 - 00:53:01)

Das weiß ich nicht, das definiere ich ja letzten Endes selber und ich finde das einen guten Weg, nicht zu weit abzuheben und dann halt komplett distanziert zu werden von den Engineers.

Wolfi Gassler (00:53:01 - 00:53:09)

Aber wie verhinderst du, dass es dann kein Micromanagement wird, dass sie sagen, der da oben will jetzt auch noch unseren Code reviewen?

Tom Bartel (00:53:09 - 00:54:25)

Ich mache meistens nur, konzentriere mich auf gewisse Sachen. Also ich mache jetzt zum Beispiel nicht tiefgreifende Architecture Reviews oder sowas. Was mir wichtig ist, ist, dass Sachen gründlich sind, dass die Funktionalitäten sinnvoll aufgeteilt sind, dass zum Beispiel nicht eine Funktion auf 300 Seilen alles Mögliche macht, sondern dass das sinnvoll in kleine, kohärente, zusammenhängende Stücke aufgeteilt ist, dass das Naming stimmt. dass Konventionen eingehalten werden, solche Sachen. Und ich glaube, wenn die Leute wissen oder wenn die sehen, da steckt jemand Zeit da rein, mehr Feedback zu geben, wenn das halt auf eine wertschätzende Art passiert und man schreibt nicht einfach nur, this is wrong oder this is right oder irgendwie sowas, dann nehmen die das auch an und wissen das auch zu schätzen, dass halt jemand, der jetzt so in der Rangordnung über ihnen steht, zwei Level, dass der sich die Zeit nimmt und Feedback gibt, weil letzten Endes will jeder Feedback haben und braucht jeder Feedback. Und wenn man die sehen, man investiert ja auch da Zeit rein, denen Anregungen zum Lernen zu geben.

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

Da muss ich mal ganz, ganz hart mit dir sein. Also ich denke, du hast nichts in Code Reviews zu verlieren. Ich finde das sehr beachtlich.

Wolfi Gassler (00:54:32 - 00:54:33)

Zu verlieren.

Andy Grunwald (00:54:33 - 00:55:08)

Zu suchen, zu verlieren. Ich denke, du hast nichts in Code Reviews zu suchen, weil ich stimme dir zu, all das, was du wegen Code Struktur gesagt hast. Aber ich denke, deine Aufgabe auch schon als Engineering Manager ist es, die Leute unter dir zu enablen, darauf zu achten, anstatt dass du in Code Reviews springst. Weil im Endeffekt bist du auch schon als Engineering Manager auf einer Flughöhe und als Director nochmal eine Flughöhe höher, der mehr Guidance und Richtung vorgeben sollte und jemand anders soll die Straße bauen. Und das ist meine harte Meinung, weil ich denk mir so, Ich bin jetzt Software-Ingenieur.

Wolfi Gassler (00:55:08 - 00:55:11)

Ich glaube, der Andi hat viel gelitten schon darunter.

Andy Grunwald (00:55:11 - 00:55:22)

Ja, vielleicht auch, aber ich bin Software-Ingenieur. Und dann kommt mein Chef-Chef in den Code-Review. Ich bin mir nicht sicher, wie wohl ich mich damit fühle, auch wenn ich gerade dem Team neu gejoint bin und dich noch nicht kenne.

Wolfi Gassler (00:55:23 - 00:55:28)

Aber vielleicht gerade nochmal als Kontextfrage, wie viele ICs sind dann wirklich unter dir?

Tom Bartel (00:55:28 - 00:55:30)

22.

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

Also eigentlich das, was du früher schon als Direct ICs gehabt hast.

Tom Bartel (00:55:35 - 00:56:17)

Sozusagen. Sieben Engineering Manager und 22 ICs. Ja, Andi, ich verstehe deine Position. Ich denke, das ist auch immer ein bisschen vom Umfeld abhängig. Vielleicht ist es bei mir auch nur übergangsweise noch so, dass ich das mache. Ich bin in der Position jetzt seit einem halben Jahr ungefähr. Kann sein, dass ich das in Zukunft sein lasse. Im Moment, glaube ich, ist es noch Gut, weil wir auch so mit Codereviews so ein bisschen am struggeln sind noch, das alles am Laufen zu halten und ja, sodass die zeitnah gemacht werden. Aber ja, werde ich mal drüber nachdenken.

Wolfi Gassler (00:56:17 - 00:56:22)

Springst du da eigentlich einfach rein? Also nimmst du dir da einfach um PR?

Tom Bartel (00:56:22 - 00:56:42)

Nee, ich werde angefragt. Also wir haben da auf GitHub eine automatische Verteilung und da stehe ich halt, bin in dem Team mit drin von Entwicklern, die an der Codebase arbeiten und entsprechend werde ich zufällig in Code Reviews mit reingezogen und Ja, ich werde mich mal umhören.

Andy Grunwald (00:56:42 - 00:58:09)

Das hört sich aber eher so nach Altlast an für mich. Das hört sich an, dein Name steht noch in einem Code-Owners-File oder ist noch in irgendeinem GitHub-Engineering-Team zugeordnet, wo dann das Round-Robin-Feature aktiviert ist. Also ich sehe das so. Ich denke, wenn du wirklich von den Entwicklern angefragt wirst, weil du das Billing-Feature geschrieben hast, Dann denke ich, ist das was anderes. Wenn sie deinen Input wirklich ziehen, dann bin ich bei dir, dann soll man da reingehen. Wenn du aber auch durch ein Round-Robin-Verfahren dann da reingeholt wirst, dann habe ich immer so das Gefühl, hm, weiß ich nicht. Ich glaube, was sinnvoll ist, wenn ihr wirklich dann, ich sag mal, Code-Probleme habt und so weiter, dass du dir jetzt zwar die Code-Reviews anschaust, Aber niemals öffentlich in Pull-Requestern da irgendwas machst und das dann vielleicht mit deinen Leads in One-on-Ones besprichst. Weil dann hast du nämlich eine Faktenbasis, eine Datenbasis und dann andere Leute enables. Ich bin aber auch ganz ehrlich, das ist eine Meinung von vielen. Ich sag nicht, du machst das falsch. Du hast gerade gesagt, dass Henk von der Umgebung abhängt. Ich glaub dir sogar und das ist super. Ich denk mir halt nur immer, was ist, wenn ich die Firma wechseln würde, ich kenn dich nicht, ich komme in dein Team, mache ein Pull-Request, ich wäre vielleicht am Anfang ein bisschen beängstigt, wenn du als Director mir Feedback geben würdest, auch wenn das Feedback valide ist und gut ist, versteh mich nicht falsch, ich würde mich trotzdem fragen, was ist das hier, warum springt mein Chef-Chef in meinen Code-Reviews rum? Das ist so das Gefühl, was ich, glaube ich, haben würde.

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

Es gibt ja, oder es hat, der ist leider schon verstorben, ein bekannter Journalist in Österreich, der mal gesagt hat, die Geheimwaffe jedes Journalisten ist das Archiv. Und wir haben ja alle Folgen transkribiert. Und da gibt es in Folge 60, wo wir über On Call gesprochen haben, habe ich die gefragt, Andi, was haltest du von Engineering Managern in On Call? Und du hast gesagt, du bist ein riesengroßer Fan davon, weil man nicht den Kontakt verliert und weil man näher am Geschehen ist.

Andy Grunwald (00:58:37 - 00:58:43)

Ja, Engineering Manager, aber Director ist ja immer noch eine Höhe darüber. Als Engineering Manager... Ja, wobei es ja.

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

Ein sehr kleines Team vom Tom, muss man auch sagen, jetzt für einen Director sonst.

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

Mit 22 Leuten finde ich, das ist nicht ein kleines Team.

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

Ja, das haben wir beide früher jeweils einzeln gehabt.

Andy Grunwald (00:58:52 - 00:58:57)

Ja, nur weil ihr früher schlechte Strukturen hattet, heißt das nicht, dass das ein kleines Team ist.

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

Okay, als Engineering Manager ist es okay.

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

Aber... Also, ich bin inzwischen... Können wir mal ganz kurz sagen, wann wurde Folge 60 aufgenommen? Auch 2024 ist nicht das Jahr des Linux-Desktops.

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

Hey, scrollen muss ich immer noch in Linux auch. 28. Februar 23, also genau vor einem Jahr.

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

Genau vor einem Jahr. Ich bin immer noch der Meinung, dass Engineering-Manager Verantwortung dafür übernehmen sollen, was das Software-Engineering-Team und das Ops-Team und das Reliability-Engineering-Team leistet. Das bedeutet, komplett hands-off ist schwierig. Ich bin nicht mehr der Meinung, dass Engineering Manager bei mehr als drei bis vier Direct Reports hands-on sein sollten und coden sollten. On-Call und ich sag mal völlig Operations ist dann auch eine schwierige Geschichte. Das bedeutet, ich kann auch meine Meinung ändern.

Wolfi Gassler (00:59:48 - 00:59:56)

Das heißt bei, also das Google-Modell, wo jeder Engineering Manager auch hands-on sein muss, findest du nicht gut oder fast jeder eigentlich.

Andy Grunwald (00:59:56 - 01:00:14)

Da würde ich dann jetzt gerne die Wunderwaffe vom Tom nehmen und sagen, das Umfeld ist wichtig, denn nennen wir mal im Operations-Bereich eine standardisierte Infrastruktur mit Runbooks und allem drum und dran, dann könnte ich sogar jeden von euch sofort on Call setzen. Und es läuft.

Tom Bartel (01:00:14 - 01:00:15)

Das glaube ich nicht.

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

Aber es kommt auf die... Ja, solange.

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

Kein Inzident ist, ist ja kein Problem.

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

Es kommt dann wirklich darauf an, wie erwachsen ist die Infrastruktur und wie erwachsen sind die Operations und die Toolings. Scheiß Antwort, aber it depends.

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

Aber dieses Argument nahe dran zu sein, finde ich schon eigentlich ganz gut. Die Frage ist immer, wie viel Zeit benötigt das? Und Code Reviews, keine Ahnung, wie viel Zeit investierst du in Code Reviews, würdest du sagen?

Tom Bartel (01:00:41 - 01:01:09)

Pro Woche vielleicht so fünf Stunden oder so. Und ich meine, Andi hat schon einen Punkt. Ich könnte die Reviews auch machen, ohne zu kommentieren. Mir das einfach nur so anschauen und mich da durchklicken. Ja, könnte ich auch machen. Also ich mache das schon auch für mich, um halt an der Technik ein bisschen dran zu bleiben, zu sehen, was in der Codebase vor sich geht. Aber dann denkt man sich auch wieder, Ja, ich habe da aber eine bessere Lösung und das sollte anders gemacht werden.

Wolfi Gassler (01:01:09 - 01:01:20)

Aber in Schluss daraus zu ziehen, was vielleicht das Problem ist, zum Beispiel, wenn jetzt du sagst, okay, es wäre schöner, Clean Code verbreiteter zu haben und dann vielleicht auch zu reagieren und da irgendwie was Richtung.

Tom Bartel (01:01:21 - 01:01:55)

Ja klar, man macht sich ein Bild daran, was sind häufige Fehler oder Auffälligkeiten, die in unserer Codebase zu Problemen führen über die Zeit. Und dann überlegt man sich mit dem Team, was könnte man als Gegenmaßnahme machen, brauchen wir spezielle Trainings, sollten wir uns mal gemeinsam irgendwelche Videokurse anschauen oder sonst was. Dafür finde ich es auf jeden Fall wichtig, dass ich auch als Director in den Code reinschaue. Ob das jetzt mit Kommentaren ist oder ohne, da kann man drüber streiten, ja.

Andy Grunwald (01:01:55 - 01:03:06)

Völlig valide Punkte, völlig valide Punkte. Doch ich denke halt, dass du als Engineering Manager A, Multiplikator bist und das bedeutet, das ganze Team educaten solltest und in der Regel passiert das nicht durch Kommentare in einem Pull-Request. weil das meist eine 1 zu 1, 1 zu 2 Kommunikation ist. Auf Director-Ebene wird das Multiplikator-Dasein sogar noch gesteigert, weil du einen deutlich größeren Hebel hast durch die Strategie und Co. Das ist das, was ich denke. Die zweite Geschichte ist, ich bin Hardliner, dass ein Lehrer immer dafür sorgen sollte, dass die Schüler und Schülerinnen besser werden als der Lehrer und dass du ein Team so aufbauen solltest, dass du gar nicht mehr benötigt wirst. Und umso mehr du aktiv im Hands und im Operations involviert bist und nicht der Bittsteller bist, in welche Richtung wir gehen, desto weniger erfüllst du diesen Job, denke ich. Weil die Schülerinnen und Schüler in diesem Sinnbild, was ich hier gerade male, sollen intrinsisch darauf kommen. Die sollen das selbst machen, ohne dass man immer gesagt, ah, da war aber, da hast du das Naming, war wir da nicht. ordentlich gemacht, was eh subjektiv ist. Das ist dann was anderes.

Wolfi Gassler (01:03:06 - 01:03:23)

Aber glaubst du dann, dass das Pendel negativ das Ganze beeinflusst, dass man schlechter loslassen kann, weil man ja quasi nicht nur in eine Richtung wächst, sondern immer wieder mal zurück und hin und her und irgendwie immer mehr involviert ist? Ohne jetzt zu sagen, dass der Andi recht hat, weil ich glaube, es ist gar nicht so einfach.

Tom Bartel (01:03:24 - 01:04:10)

Es kann schon sein, dass man aufpassen muss, in welcher Rolle man gerade ist. Das schreibt Charity in ihrem Artikel ja auch. Man kann immer eines gut machen und in einem besser werden, aber nicht in beiden gleichzeitig. Das würde dann mehr Andis Positionen untermauern, dass man sich darauf konzentrieren soll, Okay, wenn man Engineering Manager ist, dann baue ich ein Team auf, trainiere das Team, gucke, dass das Team besser wird, mache mich selber überflüssig. Wenn ich Engineer bin, dann arbeite ich an der Technik und am Code und dann müssen mich auch Kommunikation und Planung und Strategie und People Management nicht groß interessieren.

Wolfi Gassler (01:04:11 - 01:04:23)

Also meine Meinung dazu ist, dass Code Reviews, glaube ich, noch am besten geeignet sind, weil man den Kontakt nicht verliert und auch keine Abhängigkeit aufbaut, weil wenn du jetzt keine Code Reviews mehr machst, dann passiert nichts.

Tom Bartel (01:04:24 - 01:04:25)

Ja, wird keiner groß merken.

Wolfi Gassler (01:04:25 - 01:05:18)

Genau. Und es gibt ja keinen Prozess, dass irgendwas durch dich durchgehen muss. Also auch da blockt man eigentlich wenig. Also ich sehe das auch schon eher so, dass man den Kontakt nicht verliert. Und gleich wie man Skip-Level-Meetings macht, also wenn der Chef-Chef mit einem IC oder so, also in deinem Fall als Director eben jetzt mit einem IC ein Meeting hat, das wäre sowas ähnlich wie Code-Review. Man schaut mal rein und solange das zeitlich geht, finde ich das eigentlich ganz in Ordnung. Aber es ist natürlich, Sobald sich Leute beschweren anfangen, dann wird es sicher ein Problem. Aber jetzt nur mal, um den Kontakt zu halten. Und ich glaube, es wäre für mich, wenn ich es sehen würde, da schaut jemand auch in meinen Code rein, der viel Erfahrung hat, der mir vielleicht eine Hilfestellung gibt, wo ich dann auch zu dem gehen kann und sagen, hey, wir haben im Team dieses Problem. Also wo ich auch irgendwie einen Kontakt zu dem nach oben habe, vom IC-Level aus. Finde ich nicht grundsätzlich so schlecht.

Andy Grunwald (01:05:19 - 01:05:31)

Ich glaube, der Tom hat gerade den Key-Satz gesagt, dass es zwei verschiedene Jobs sind. Vom Software-Engineer zum Engineering-Manager. Ist keine Promotion, sagt man so schön. Man sagt ja immer so schön, es ist ein Karrierewechsel.

Wolfi Gassler (01:05:31 - 01:05:34)

Es ist eine ganz andere Position, ja.

Andy Grunwald (01:05:34 - 01:06:47)

Und in dem Charity Mayers Artikel, der ist auch in den Show Notes verlinkt, da steht auch drin, dass wenn du das machst, dass du vom Senior Engineer in einen Junior Engineering Manager wechselst, weil das ist eine andere Profession, man braucht andere Skills. Und ich glaube, es ist wichtig, bei diesem Pendel im Sinn zu haben, in welcher Rolle bin ich gerade, welchen Hut trage ich gerade. Ich vergleiche das immer so mit DevOps. Ja, wir wissen alle, es ist kein Job, es ist eine Kultur. Developer und Operations müssen zusammenarbeiten. Aber es gibt immer noch DevOps-Engineers inzwischen. Und bei einer DevOps-Engineer-Rolle mag ich gern zu fragen, okay, das sind zwei Jobs, Softwareentwickler und Operations-Systemadministrator, in einer Person. Das funktioniert einfach nicht. Du kannst nicht zweimal 100 Prozent den Job haben. Da frage ich immer, okay, du hast zwei Mützen und du musst 100 Prozent. Welche Mütze trägst du denn öfter? Wie viel Prozent? Weil im Endeffekt ist es ja auch das. Ich glaube es ist sehr schwierig diese Grenzen nicht kontinuierlich zu überschreiten und auch diese, ich habe das Wort Flughöhen schon sehr oft erwähnt, ich mag das sehr eigentlich, weil man halt über nicht den Detaillevel nachdenkt, sondern wirklich dann über was bringt denn jetzt uns als Gruppe weiter und nicht mich jetzt gerade in diesem Pull Request und was bringt uns als Organisation weiter und all sowas.

Wolfi Gassler (01:06:47 - 01:07:27)

Deswegen, Aber jetzt den Unterschied zwischen Entwicklerin und Engineering Manager, der ist ja klar. Also da gibt's, das ist eine andere Position und keine Beförderung. Ich glaube, da sind wir uns ja alle einig. Aber von Engineering Manager auf Director-Ebene, das ist ja eine sehr ähnliche Rolle. Das ist ja nur ein kleiner Schritt weiter. Du brauchst da ähnliche Skills, die du schon auf der Engineering-Manager-Ebene gelernt hast, brauchst du dann im nächsten Schritt ja auch wieder und entwickelst weiter. Also das ist ja eher dieselbe Richtung, als wie wenn du jetzt von der IC-Seite kommst zu einem Engineering-Manager. Andi schüttelt schon den Kopf.

Andy Grunwald (01:07:27 - 01:07:28)

Ich frage mich, wo bin ich hier gelandet?

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

Das fragst du dich ja erst jetzt nach 100 Episoden.

Tom Bartel (01:07:32 - 01:07:38)

Ja, es ist derselbe Track. Also Engineering Manager und dann Engineering Director.

Andy Grunwald (01:07:38 - 01:07:50)

Also das ist keine Karriere wechseln. Das stimmt schon. Das ist jetzt die klassische Treppe und Leiter hoch. Das ist richtig. Aber ich würde schon sagen, dass du dich nochmal mehr vom Hands-on entkoppeln solltest.

Wolfi Gassler (01:07:51 - 01:08:12)

Das stimmt schon, aber du hast natürlich genauso 101s, du versuchst deine Leute weiterzubringen, du shapest die Kultur, du machst das richtige Environment, dass alle gut arbeiten können und das machst du halt an einem Level höher. Klar bist du noch weiter weg, aber es ist dieselbe Idee, würde ich mal sagen, und dieselbe Richtung und Skills auch.

Tom Bartel (01:08:13 - 01:08:29)

Aber da gibt's jetzt auch wieder alle Strömungen, ne? Also du hast das ganze Meinungsspektrum. Es gibt auch viele, die schreiben, na, man soll immer noch coden, selber auch. Natürlich an nix Zeitkritischem und so, weil man halt öfter unterbrochen wird als Engineering Manager und als Director wahrscheinlich sowieso.

Wolfi Gassler (01:08:29 - 01:08:31)

Am besten in deiner Freizeit einfach.

Tom Bartel (01:08:31 - 01:08:50)

Ja, genau, in der Freizeit. Aber dass man irgendwie sowas auch noch seine vier Stunden Maker-Time pro Woche reserviert oder so, gibt es auch viele, die das sagen. Also vielleicht gibt es nicht die eine richtige Antwort. Vielleicht kommt es auf den eigenen Charakter, die eigenen Stärken und auch auf das Umfeld halt an.

Wolfi Gassler (01:08:51 - 01:08:57)

Also ich glaube, dass es einfach wichtig ist, dass es nicht die Micro-Management ausartet. Und das würde ich bei Code Reviews auf keinen Fall sehen.

Andy Grunwald (01:08:57 - 01:09:39)

Also da sind wir uns, glaube ich, alle einig. Ich glaube, wir sollten, wenn du eine Lead-Position hast, dann versuch halt einfach nicht besser zu sein als die Leute, die den realen Job machen. Versuch denen zu vertrauen. Und wenn du denkst, die machen es nicht zu deinem qualitativen Anspruch, ... dann sag nicht, wie sie es tun sollen, sondern ... ... verfalle in eine Coaching-Rolle und versuche, ... ... dass diese Personen selbst darauf kommen. Wenn wir uns auf sowas einigen, dann sind wir alle d'accord ... ... und ich glaube auch, ... ... Größe der Firma spielt eine große Rolle, ... ... inwieweit ein Director-Level ausgelebt wird. Umfeld, dynamisches Umfeld, ... ... finanzielles Umfeld der Firma, ... ... wie stabil ist das oder wie hektisch ist das. Also ich glaube, ... ... da kommen viele It-Depends zusammen, das ist richtig.

Tom Bartel (01:09:40 - 01:09:57)

Wo ich großen Wert drauf lege in den Code Reviews, also ich lobe auch viel. Man kritisiert ja nicht nur oder gibt Anregungen, wie man was anders und besser machen kann, sondern es ist in einem Code Review auch wichtig, dass wenn man was Gutes sieht, dass man es auch benennt. Das vergessen viele.

Andy Grunwald (01:09:57 - 01:10:03)

Hast du da mal ein Beispiel? Ich stell mir gerade vor, du kommst in einen Code Review und so. Geiles Observer-Pattern. Finde ich geil.

Tom Bartel (01:10:03 - 01:10:51)

So noch nie gesehen. Ne, wenn jemand zum Beispiel Boy Scout-mäßig was aufräumt. Wenn irgendwas angefasst und gerade gezogen wird, was jetzt eigentlich gar nicht Thema war. Und es ist klar, wenn es jetzt nicht gerade 50 Dateien bedeutet anzufassen, aber wenn irgendwas mit relativ wenig Aufwand vereinheitlicht werden kann. Zum Beispiel eine Funktion, einen Namen verbessert oder irgendwas an eine Konvention angepasst wird, die sich mittlerweile geändert hat. Dann sage ich auch, cool, great Boy Scouting oder irgend sowas und noch ein entsprechendes Emoji nebendran. Und da, denke ich, hilft mir dann meine Director-Rolle schon wieder, weil wenn du halt so ein Lob Dann von deinem Chef-Chef bekommst, dann denke ich, motiviert das auch ein bisschen.

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

Und es gibt ja eigentlich Leading by Example. Man könnte das ja auch so argumentieren, wenn du das deinen Engineering-Managern beibringen willst, dann musst du das ja selber mal vorzeigen.

Tom Bartel (01:11:00 - 01:11:01)

Und den Engineers auch.

Wolfi Gassler (01:11:01 - 01:11:02)

Und den Engineers natürlich.

Tom Bartel (01:11:02 - 01:11:05)

Es gibt ja keinen Grund, warum die Engineers das nicht machen sollten.

Wolfi Gassler (01:11:05 - 01:11:05)

So, Andi, jetzt.

Andy Grunwald (01:11:06 - 01:11:24)

Also beim Tom muss ich sagen, Kudos, du hast einen sehr guten Punkt gebracht, warum Director in Code Reviews sein sollten und da bin ich d'accord. So habe ich das noch nicht gesehen, danke dafür. Beim Leading by Example beim Wolfgang war ich wieder vorne und hinten nicht dabei. Aber ich würde mich interessieren, welches Emoji packst du dann da hin?

Tom Bartel (01:11:24 - 01:11:25)

Klatschende Hände.

Andy Grunwald (01:11:25 - 01:11:30)

Achso, ich dachte irgendwie so ein Vater mit so einem Keks oder so. Die verkaufen ja auf Kekse irgendwie.

Tom Bartel (01:11:30 - 01:11:31)

Ja, nee, nee, kenne ich nicht.

Wolfi Gassler (01:11:31 - 01:11:39)

Pauli bekommt ein Keks. Was war jetzt das Leading by Example Problem? Ja, ich denke, ich denke man... Kassettenaussagen ist schlecht, du musst schon mit einer Argumentation kommen.

Andy Grunwald (01:11:39 - 01:11:51)

Jaja, okay. Also nur weil ich meine Leute dafür enablen möchte, Public Speaking zu machen, heißt das nicht, dass ich ein guter Speaker sein muss. Ja? Also Leading by Example ist eine tolle Geschichte, aber ich denke nicht... Ja, du.

Wolfi Gassler (01:11:51 - 01:11:59)

Solltest nicht leaden, wo du keine Ahnung hast oder es selber nicht gut machen kannst. Aber wenn du es gut machen kannst, warum nicht? Dann kannst du ja auch als Public Speaker zeigen, wie es geht.

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

Ja ja richtig aber vielleicht ist der Tom ja auch nur von sich überzeugt, dass er denkt er hatte gerade da tolles Boyscouting entdeckt aber er hat's gar nicht, weil das war ein realer Buck und man könnte auch argumentieren und ich sehe auch schon die Kommentare von dieser Podcast Episode, dass Leute sagen, ja pass mal auf aber wenn du ein Feature entwickelt hast und dann noch in dem PR ein Comment fürs Boyscouting machst, nee nee das sollte ein eigener PR sein, die Argumentation könnte man auch auspacken also von daher. Ich bin nicht so ganz der Freund von immer leading by example, deswegen lasse ich Wolfgangs Punkt nicht so gelten, mit dem Loben, dass das viel zu selten in Pull Request stattfindet. Also die Kultur, Kudos, bitte weiterführen und auch bitte in weiteren Firmen in deiner Zukunft integrieren, weil ich denke, darüber sprechen wir alle viel zu selten und ich habe auch seltenst sowas mal miterlebt.

Tom Bartel (01:12:47 - 01:12:54)

Ja, loben und auch mal Dankeschön sagen, wenn jemand was besonders schön macht und besonders gründlich.

Andy Grunwald (01:12:54 - 01:13:04)

Kommen wir mal ein bisschen weg von diesem Micro-Management-Thema und was ein Director tun sollte und was nicht. Wieder hin zum Pendel. Und zwar, jetzt stell dir mal vor, jemand hört diese Episode.

Tom Bartel (01:13:05 - 01:13:06)

Hört da wirklich jemand zu?

Andy Grunwald (01:13:06 - 01:13:12)

Hier hört, glaube ich, hoffentlich jemand zu. Wir sprechen immer in so einem Void, aber ab und zu kommt mal was zurück.

Wolfi Gassler (01:13:12 - 01:13:26)

Wir waren gerade in Brüssel und haben die Leute wirklich getroffen. Es gibt wirklich Leute aus Mensch und Blut. Wie nennt man das? Aus Fleisch und Blut. Ihr als Vegetarier habt da Probleme damit. Es gibt sie wirklich.

Andy Grunwald (01:13:27 - 01:13:54)

Die Person hört diese Episode und fragt sich, hm, von diesem Pendel hab ich noch nie gehört und ich hab das noch nie so gesehen, dass das kein Rückschritt ist, sondern vielleicht einfach wieder zurück zu dem, was ich liebe. Jetzt hattest du den großen Luxus, dass deine Umgebung sehr supportive da war. Das ist aber ja nicht überall so und deswegen, welchen Tipp würdest du mal einer Person geben, wenn er oder sie darüber nachdenkt, zu pendeln? Das bedeutet, man ist in einer Liedrolle und hey, ich liebe Coding wieder, weil.

Wolfi Gassler (01:13:54 - 01:13:59)

Also zurückpendeln in dem Fall. Zurückpendeln.

Tom Bartel (01:13:59 - 01:14:52)

Am allerbesten ist es, glaube ich, wenn die Bedenken schon vorher da sind und thematisiert werden können. Also bevor man in der Engineering Manager Stelle ... gebeten wird. Das gibt es ja manchmal auch. Es gibt keinen, der das machen will. Und dann werden Leute aktiv gefragt. Und dass man dann sagt, ja ... ... ich würde es mal ausprobieren, ... ... aber ich hätte gerne erst mal so eine Art ... ... Probezeit auf sechs Monate. Nach sechs Monaten ... ... möchte ich dann die Option haben, ... ... wieder zurückzugehen in meine alte Rolle. Wenn ich merke, das ist nichts für mich. Das kann man wirklich nicht unbedingt vorher wissen. Und da hilft es, wenn der Manager halt da unterstützend ist und einem zugesteht und einen da nicht verheizen will und unglücklich in der Position festhalten und so weiter.

Wolfi Gassler (01:14:52 - 01:14:57)

Ist jetzt sechs Monate, was du für sinnvoller achtest, war das eine random number?

Tom Bartel (01:14:57 - 01:15:47)

Das würde ich mal als Minimum sagen, weil wenn man jetzt nach einem Monat sagt, das gefällt mir aber alles nicht, dann ist es vielleicht ein bisschen verfrüht. Dann hat man das noch nicht hat man sich noch nicht richtig drauf eingelassen, glaube ich. Nach sechs Monaten hat man dann schon so langsam eine Ahnung, wie der Job abläuft. Besser ist vielleicht noch ein Jahr, aber so die Zeitspanne sollte es schon sein. Also am besten ist es, wenn schon vorher so eine Vereinbarung da ist. Wenn das nicht der Fall ist, dann trotzdem muss man sich ja früher oder später jemandem anvertrauen, ob das denkbar wäre, wie sieht das mein Manager, mein Mentor, irgendjemanden, zu dem man Vertrauen hat in der Firma. Und ich glaube, wichtig ist es halt, mindestens mal einen Unterstützer zu haben bei der Sache. Und wenn man den gar nicht findet, dann wird es schwierig, denke ich.

Andy Grunwald (01:15:48 - 01:16:01)

Würdest du denn sagen, dass so Überlegungen auch valide sind, dass man nicht in sein vorheriges Team zurückgeht, sondern vielleicht innerhalb der Organisation in ein anderes Team geht und ich sag mal einen Neustart macht?

Tom Bartel (01:16:02 - 01:16:58)

Das ist auf jeden Fall denkbar. Ich glaube, die Frage ist, ist das vorherige Team das, das ich auch gemanagt habe? Ich glaube, schwieriger ist es, in das Team zu wechseln, das man bis eben noch gemanagt hat selber. Das könnte vielleicht, ich weiß nicht, wenn es da ... Vielleicht gab es mal irgendwelche Auseinandersetzungen, wo man dann als Manager für eine Seite Partei ergreifen musste oder so, und dann wird man wieder ... normaler Kollege oder Kollegin, sag ich mal, in dem Team. Vielleicht ist da dann noch ein bisschen Animosität übrig von der einen oder anderen Seite. Das könnte eventuell schwierig sein. Ansonsten, wenn es das vorherige Team war, das man aber in der Zwischenzeit nicht gemanagt hat, dann sollte es ja im Prinzip kein Problem sein. Aber kann sein, je nachdem, wie da die personellen Strukturen sind, dann ist es vielleicht auch sinnvoll, ein anderes Team zu wechseln und da neu anzufangen.

Andy Grunwald (01:16:59 - 01:17:03)

Aber die Empfehlung ist grundsätzlich erstmal Firmen intern zu bleiben, oder?

Tom Bartel (01:17:03 - 01:17:33)

Sehe ich nicht zwingend so. Es kann manches leichter machen, zum Beispiel den Wechsel zurück macht es wahrscheinlich leichter in der gleichen Firma, falls es dann doch nichts ist. Aber ansonsten hat es auch ein paar Vorteile in eine andere Firma zu gehen, denke ich. Weil man halt nicht belastet ist durch vorher, oh hey, wir waren immer gute Kumpels und wir gehen am Wochenende zusammen feiern, jetzt bin ich aber dein Boss. Das kann auch für Probleme sorgen und das hast du halt in einer fremden Firma tendenziell nicht.

Andy Grunwald (01:17:34 - 01:17:45)

Meine Empfehlung für die Trial-Phase im Engineering-Management ist eigentlich immer ein Jahr. Und der Grund ist relativ einfach, weil innerhalb eines Jahres hat man dann einmal den kompletten Life-Cycle durch.

Tom Bartel (01:17:45 - 01:17:46)

Machst du alles mal mit, ja.

Andy Grunwald (01:17:46 - 01:18:30)

Recruiting, Gehaltsverhandlungen, Performance-Review und so weiter. Und vielleicht mag es besonders in den ersten zwei, drei Monaten schmerzhaft sein, aber dazu haben wir auch schon einige Episoden gemacht. Meine Frage, wir reden die ganze Zeit vom Pendulum, ich bin Individual Contributor. werde Managerin und pendel wieder zurück als Individual Contributor. Es gibt aber auch Leute, die kommen aus dem Consulting oder direkt auch von der Uni und steigen dann direkt in eine Managementrolle ein. Vielleicht sogar haben sie ein MBA oder ähnliches. Ist dir schon mal ein Fall auf den Tisch gekommen, wo jemand direkt in eine Managementposition eingestiegen ist und will dann in eine Software Engineering Position pendeln?

Tom Bartel (01:18:31 - 01:18:32)

Aus dem Management.

Andy Grunwald (01:18:32 - 01:18:48)

Also eigentlich, man startet das Pendel, weil irgendwo muss man ja starten, aber man startet halt nicht klassisch von Software-Ingenieur zum Manager, sondern von Manager auf Basis der akademischen Ausbildung als individueller Contributor. Und muss jetzt auch nicht Software-Ingenieur, kann auch Designer, Produktmanager.

Tom Bartel (01:18:49 - 01:19:42)

Wir leben ja mittlerweile im Zeitalter der Bootcamps. Viele IT-Spezialisten haben keine klassische Ausbildung oder IT-Studium oder sowas, sondern die haben ein einjähriges Bootcamp oder sowas durchlaufen und sind quasi Quereinsteiger ins Software Engineering. Und das habe ich schon mehrfach erlebt jetzt, dass die zum Beispiel aus dem Wirtschaftsbereich kommen, haben Bachelor of Economics oder irgendwas, sind dann ein, zwei Jahre im Beruf gewesen, haben gemerkt, das ist jetzt nicht so das, was sie bis Lebensende machen wollen und die haben dann umgesattelt auf Software Engineering. Das habe ich zum Beispiel schon erlebt. Ich bin jetzt aber nicht sicher, doch in einem Fall weiß ich, dass der auch so eine Art Management-Position hatte und der ist dann jetzt halt Individual Contributor als Software-Engineer. Gibt's auf jeden Fall, denke ich.

Andy Grunwald (01:19:42 - 01:20:05)

Ich meine, das Too-Long-Didn't-Read von dieser Episode ist ja schon so ein bisschen, dass man mit dem Engineering-Management-Pendulum so ein bisschen alte Zöpfe abschneidet. So die ganzen alten Konzernstrukturen, es geht nur nach oben und ich hoffe, dass dies auch in unserer Gesellschaft auch so ankommt, auch wenn die Generation Z natürlich auch von Boomern erzogen wird, denen das auch so in die Wiege gelegt wurde.

Wolfi Gassler (01:20:05 - 01:20:09)

Man könnte ja fast sagen, Tom, du warst ein Thought Leader, wie das so schön da drauf liegt.

Tom Bartel (01:20:11 - 01:21:00)

Und freiwillig. Aber ich glaube auch, dass das eine gesunde Entwicklung ist insgesamt, dass man wegkommt von diesem Up or Out. Entweder wirst du befördert oder du musst irgendwann die Firma wechseln. Das nimmt auch so ein bisschen Druck raus und es ist ja irgendwo auch dämlich, wenn eine Firma die Leute unter Druck setzt und mit Gesichtsverlust bedroht, ob jetzt ausdrücklich oder nur implizit, die Rolle nicht mehr machen wollen, weil die haben ja wertvolles Wissen angesammelt über ihre Zeit in der Firma. Und wenn die raus durch die Tür gehen, dann hast du auch einen gehörigen Wissensverlust und Qualitätsverlust. Dann behalte ich die doch lieber in der Firma und die werden wieder IC. Also da haben alle was davon letzten Endes.

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

Ich denke auch, dass man den möglichen Nachteil, dass das komisch auf dem eigenen Lebenslauf aussieht, so ein bisschen umschiffen kann, sofern man denn von Großkonzernen noch die Möglichkeit kriegt, sich im Interview zu beweisen. Denn ich denke immer, beziehungsweise habe ich die Erfahrung auch selbst gemacht, Sobald man immer eine Story parat hat, warum man diesen Wechsel gemacht hat und valide Gründe hat und valide Gründe sind auch, ich liebe die Technik einfach und ich bin anscheinend auch nicht so schlecht da drin und ich kann mich davon nicht lösen.

Wolfi Gassler (01:21:28 - 01:21:41)

Ich glaube es ist auch akzeptiert worden langsam, dass man das einfach ausprobieren muss und viele finden einfach raus und dass das nichts für sie ist. Und ganz viele würden es nicht machen, wenn sie den Schritt gar nicht zurück machen dürfen.

Andy Grunwald (01:21:42 - 01:21:47)

Ja, ich hoffe, das ist inzwischen auch bei Tregema angekommen, wo Wolfgang Gruppe jetzt endlich abgedankt hat.

Wolfi Gassler (01:21:48 - 01:21:50)

Was heißt endlich? Du zitierst ihn immer so gerne.

Andy Grunwald (01:21:50 - 01:22:02)

Ja, aber ist er schon Hardliner in Bezug von 1960 Arbeitsregeln. Von daher, also ich glaube, wenn du mit ihm und dem Engineering Manager Pendulum sprichst, dann sagt er, bist du deppert?

Wolfi Gassler (01:22:03 - 01:22:06)

Aber zumindestens in der IT hoffen wir mal, dass es angekommen ist in irgendeiner Form.

Tom Bartel (01:22:07 - 01:22:22)

Und auf dem Arbeitsmarkt sieht es ja auch so aus, dass die Firmen sich die Leute im Moment nicht gerade aussuchen können. Die Verhandlungsmacht liegt eher bei den Arbeitnehmern, bei den Entwicklern. Von dem her dürfte das noch weniger ein Problem sein eigentlich.

Andy Grunwald (01:22:22 - 01:22:30)

Tom, vielen lieben Dank, dass du den weiten, weiten Weg in die schönste Stadt des Ruhrgebiets nach Duisburg auf dich genommen hast.

Wolfi Gassler (01:22:30 - 01:22:35)

Du beendest jetzt schon, weil dein Hund ständig im Hintergrund schon jaulen beginnt.

Andy Grunwald (01:22:35 - 01:22:42)

Also genau, der hat sich zwischenzeitlich die Pfoten gelegt, der hat gerade mal eine Runde gejault und naja gut, dann nehmen wir den Podcast halt.

Wolfi Gassler (01:22:43 - 01:22:44)

Also falls jemand die Hintergrundgeräusche hört.

Tom Bartel (01:22:45 - 01:22:52)

Ich danke euch, hat sehr viel Spaß gemacht und ich habe den Weg gerne auf mich genommen. Und ja, bis zum nächsten Mal.

Andy Grunwald (01:22:52 - 01:23:05)

Wir verlinken natürlich die Kontaktdaten auch in den Show Notes, falls wer mal First-Hand-Experience von Tom erfahren möchte. Ich glaube, wenn ihr ihm eine Nachricht schreibt, ich glaube so lieb ist er, dass er dann auch mal antwortet.

Wolfi Gassler (01:23:06 - 01:23:08)

Und sonst, dein Blog ist sehr zu empfehlen.

Tom Bartel (01:23:08 - 01:23:10)

Auch wenn er langsam in die Jahre kommt.

Wolfi Gassler (01:23:11 - 01:23:15)

Ja, wir sind Evergreens. Kann man wirklich immer wieder lesen, gar keine Frage.

Andy Grunwald (01:23:15 - 01:23:17)

Ich sage immer wieder, einmal alle zwei Jahre ist auch regelmäßig.

Tom Bartel (01:23:18 - 01:23:24)

Richtig, ja. Vielleicht sollte ich mich daran halten. Vielen Dank, Tom.

Wolfi Gassler (01:23:24 - 01:23:24)

Tschüss.

Andy Grunwald (01:23:24 - 01:23:27)

Danke euch. Danke, ciao.

Wolfi Gassler (01:23:27 - 01:23:38)

Und nicht vergessen, wer mal pendeln will oder sonst eine neue Herausforderung sucht in einem internationalen Team, schaut mal bei unserem Episodensponsor Eurowings digital vorbei. Link in den Show Notes.