Engineering Manager oder Team-Lead: Eine Position die sehr motivierend, aber auch abschreckend wirken kann.
Was erwartet einen? Was ist die Aufgabe einer Engineering Managerin? Wie verändert sich der Arbeitsalltag? Ist die Stelle überhaupt etwas für mich? Und was passiert, wenn ich doch lieber Software Entwickeln möchte? Gibt es einen alternativen Karrierepfad?
All das und noch über viel mehr Erfahrungen sprechen Andy und Wolfgang in Episode 05 vom Engineering Kiosk.
Bonus: Warum Andy Muskelkater im Arsch hat
Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Feedback an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk
Erwähnte Artikel
- Mitchell's New Role at HashiCorp: https://www.hashicorp.com/blog/mitchell-s-new-role-at-hashicorp
- Tom Bartel mit "A Year Ago, I Stepped Away From a Leadership Position. Here Are 7 Things I Learned From That": https://www.tombartel.me/blog/leadership-position-to-individual-contributor-what-i-learned/
- "What is a Staff (or Staff-Plus or Principal) Engineer?": https://mikemcquaid.com/2021/10/01/what-is-a-staff-plus-principal-engineer/
Bücher über das Engineering Management
- "The Managers Path" von Camille Fournier
- "Turn the ship around" oder "Reiß das Ruder rum!" von David Marquet
- "Drive" von Daniel H. Pink
- "Start with Why" von Simon Sinek
- "High Output Management" von Andrew S. Grove
- "An elegant puzzle" von Will Larson
Sprungmarken
(00:55) Hörer Feedback
(01:43) Wann bist du das erste mal in eine Teamlead-Stelle gerutscht?
(03:15) Kann man bereits Aufgaben eines Teamleads übernehmen, ohne ein Teamlead zu sein?
(04:18) Wie viel Zeit hast du mit Hands-On und wie viel mit People Management verbracht?
(04:52) Wie lang warst du Individual Contributor bevor du Teamleiter wurdest?
(05:42) Was hat sich am meisten an deinem Arbeitsalltag geändert?
(09:22) Was ist ein 1 on 1 Meeting und warum ist dies sinnvoll?
(13:27) Was ist eine gute Teamgröße für den Start als Engineering Manager?
(14:50) Woher wusstest du, was du als neuer Engineering Manager machen musst?
(20:51) Empfehlungen um die Entscheidung "Möchte ich den Job einer Engineering Managerin machen?" treffen zu können
(24:25) Feedback-Loop eines Software Engineers und eines Engineering Managers
(25:50) Was solltest du nicht wollen, wenn du ein Engineering Manager werden möchtest?
(27:42) Ist es ab und zu notwendig, seine eigene Entscheidung im Team durchzusetzen?
(28:36) Schwierige Konversationen als Engineering Manager
(30:49) Ist es ein Rückschritt wenn man als Engineering Manager zurück zum Software Engineer wechselt?
(34:42) Wie sieht ein möglicher Karriereweg aus, wenn der Engineering Manager-Weg nichts für mich ist?
Hosts
- Wolfgang Gassler (https://twitter.com/schafele)
- Andy Grunwald (https://twitter.com/andygrunwald)
Engineering Kiosk Podcast: Anfragen an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk
Transkript
Andy Grunwald (00:00:02 - 00:00:35) 
Willkommen bei einer neuen Episode des Engineering-Kiosks. Habt ihr euch eigentlich schon mal gefragt, was bei euch der nächste Karriere-Schritt ist? Ihr seid schon seit ein paar Jahren Software-Engineer und wisst nicht, ob ihr den nächsten Schritt zum Engineering-Manager, zur Engineering-Managerin gehen sollt? Das ist das Thema der heutigen Folge. Wolfgang und ich sprechen über unsere Erfahrungen, was es heißt, ein Engineering-Manager zu sein, wie man entscheidet, ob dies der richtige Schritt für einen ist, welche Vorteile, welche Nachteile gibt es und ob es ein Rückschritt ist, wenn man wieder zum Software-Engineer wechselt. Wir springen direkt rein und los geht's. Guten Morgen Wolfgang.
Wolfi Gassler (00:00:35 - 00:00:36)
Guten Morgen.
Andy Grunwald (00:00:36 - 00:00:59)
Von den letzten Episoden haben wir viel Hörer-Feedback bekommen und auch sehr, sehr viele Themenvorschläge. Vielen Dank dafür. Und eines der meistgenannten Themen war Engineering Management, die eigene Karriere und sollte ich den nächsten Schritt wagen und ins Engineering Management gehen, ein Team übernehmen, Teamleiter werden, Teamleiterin werden.
Wolfi Gassler (00:00:59 - 00:01:26)
Und was die Hörerinnen ja nicht wissen, ist, dass du, Andi, ja da der perfekte Spezialist bist für dieses Thema, nachdem du ja einige Engineering-Manager-Stellen, Team-Lead-Stellen gehabt hast, aber auch zwischendrin wieder auf normale Stellen gesprungen bist. Also du kennst ja wirklich alle Arten von Positionen extrem gut und vor allem auch den Wechsel zwischendrin. Wann bist du denn das erste Mal eigentlich in so eine Team-Lead-Rolle gerutscht, würde ich fast sagen?
Andy Grunwald (00:01:27 - 00:02:56)
Das erste Mal, als ich vom Individual Contributor zum Engineering Manager zum Teamleiter gewechselt bin, war Mitte, Ende 2013. Die Story ist eigentlich relativ lustig, weil damals, ich war noch gar nicht so lange bei Trivago, Und das war die Zeit, wo wir die Infrastruktur ziemlich hoch skaliert haben mit TV-Werbung. Das war so Mitte 2013. Das war so die Zeit, wenn man noch TV-Werbung zu Primetime, also 2015, auf ProSieben und RTL geschaltet hat, dass man noch richtige Traffic-Spikes auf den Graphen auf der Webseite hatte. Auf jeden fall eines morgens kam unser chef in die stand up und sagte wir haben kontinuierlich probleme mit der datenbank, die sysadministratoren, das ops team hat uns gesagt wir müssen da irgendwie was optimieren kann sich das mal wer ansehen. Ich war ziemlich grün hinter den ohren hab einfach meine hand gehoben und hab gesagt jo ich schau mir das mal an ich hatte keine ahnung was mich erwartet. Ein paar Wochen später hatte ich ein paar Probleme gelöst, ging um Skalierung von MySQL-Datenbanken, Query-Optimierung, sowas halt. Irgendwann sagte ich zu meinem Chef, okay, da sind aber noch eine ganze Menge andere Probleme, die schaffe ich alle gar nicht alleine. Ich brauche Hilfe. Jemand sollte mir am besten helfen, dass wir da zu zweit oder zu dritt mal reingucken. Mein Chef sagte einfach, okay, ich habe aber gerade keinen, deswegen fang an, Leute anzustellen. Ich muss zugeben, wie mache ich das? Also ich hatte keine Ahnung, wie ich Leute anstelle, was ich dafür brauche, ob ich eine Stellenausschreibung brauche, etc.
Wolfi Gassler (00:02:56 - 00:03:04)
Da sind wir schon bei einem sehr guten Thema. Das heißt, du warst eigentlich noch kein Teamlead, hast aber schon Leute angestellt, seht ihr das richtig?
Andy Grunwald (00:03:05 - 00:03:14)
Ich hatte die Aufgabe, ja. Also ich war ein Ein-Mann-Team sozusagen. Ich war das Ein-Mann-Team, was sich dann um die Verfügbarkeit von Plattformen und die Realierbarkeit kümmern sollte.
Wolfi Gassler (00:03:15 - 00:03:22)
Das heißt, man kann auch schon Teamlead sein, ohne ein Team zu haben oder zumindest Aufgaben eines Teamleads machen müssen, ohne ein Team zu haben.
Andy Grunwald (00:03:22 - 00:03:28)
Also ich habe mich selbst geleitet, wenn du so möchtest, aber ich hatte jetzt keine Weiterentwicklungsgespräche mit mir.
Wolfi Gassler (00:03:28 - 00:03:32)
Aber du hast neue Leute probiert zu finden und Recruiting gemacht.
Andy Grunwald (00:03:32 - 00:04:01)
Genau, dann hat die ganze Schose angefangen. Ich hab mich mit der Personalplanung hingesetzt, die haben mir ein bisschen erklärt, was notwendig ist, ein Stellenprofil ausgeschrieben, Interviews geführt, beziehungsweise mal angefangen, Interviews zu führen. Ohne Training, muss ich zugeben, das tut mir total leid für die Leute, die ich damals interviewt hab. Und so hat man nach und nach dieses Team dann aufgebaut. Und über dann die nächsten sechs, sieben, acht Monate kamen dann zwei, drei, vier Leute ins Team. Und so fing ich dann an, als Neuling ein Team zu leiten.
Wolfi Gassler (00:04:03 - 00:04:15)
Wie viel Zeit hast du da hands-on noch gemacht und wie viel wirklich Team-Management oder People-Management, die wirklich mit deinen Leuten oder dich um deine Leute gekümmert?
Andy Grunwald (00:04:15 - 00:04:38)
Die Anfangszeit war schon sehr, sehr hands-on getrieben. Auf der einen Seite natürlich, weil ich noch selbst noch nicht wusste, worauf ich mich da einlasse als Teamlead und was dann eigentlich mein richtiger Job ist. Weil am Anfang dachte ich, okay, wir holen uns ein paar Leute und arbeiten einfach an den Problemen zusammen. Deswegen war die erste Zeit schon sehr, sehr hands-on getrieben, aber auch, weil ich die neuen Leute natürlich in die Problemthematik mit einarbeiten musste.
Wolfi Gassler (00:04:39 - 00:04:45)
Wie lange warst du da davor schon hands-on als individual Contributor unterwegs?
Andy Grunwald (00:04:45 - 00:04:51)
Zirka vier bis fünf Jahre, also auch Vortrieb auch in meinem vorherigen Job.
Wolfi Gassler (00:04:51 - 00:05:00)
Würdest du sagen, das ist eine Zeitspanne, die Sinn macht, dass man dann überwechseln kann zu so einer anderen Position? Oder war das zu früh, zu spät?
Andy Grunwald (00:05:01 - 00:05:30)
Sehr gute Frage, da habe ich eigentlich gar keine Antwort drauf. Ich denke, es hilft, wenn man von der Domäne, von der Problemdomäne, die das Team beackert, eine Ahnung hat. Aber ich denke, das ist nicht 100 Prozent notwendig. Vier bis fünf Jahre ist, glaube ich, schon eine okayische Zeit. Mehr schadet, glaube ich, nie. Es gibt aber sehr wahrscheinlich auch Leute, die deutlich besser sind als ich in meinem Job und das auch nach einem Jahr hinkriegen.
Wolfi Gassler (00:05:31 - 00:05:59)
Wenn du jetzt rückblickend betrachtest, wie du die neue Position angenommen hast, was sich am meisten geändert hat von den Arbeitsfeldern? Du hast schon erwähnt Recruiting. Ich glaube Recruiting ist ein riesen Punkt und für ganz viele Engineering Manager oder Teamleads ist das ein Bereich, wo sie extrem viel Zeit investieren müssen oder dürfen, wie man das auch immer sieht. Aber hat es noch andere Bereiche gegeben, die wichtig waren oder die sich stark geändert haben?
Andy Grunwald (00:06:00 - 00:07:59)
Als individueller Contributor hatte ich immer nur die Technik im Sinn und das war mein Hauptaugenmerk, gute Software zu schreiben, hochkreative Software, die testbar ist, gute Metriken hat, etc. Mit der Zeit habe ich einfach festgestellt, dass die Technologie zwar schwierig ist oder beziehungsweise schwierig sein kann, aber nicht die Herausforderung, weil ich denke, wenn man jetzt nicht gerade bei SpaceX ist und wiederverwendbare Raketen baut, Ist das alles keine Rocket Science? Es ist schwierig, verstehe mich nicht falsch, aber es ist nicht die Herausforderung. Ich denke, Menschen sind die größte Herausforderung und welche Themenfelder haben dann größeren Stellenwert gekriegt? Ganz klar sowas wie Kommunikation, Expectation Management, also die richtigen Erwartungen setzen, Zieldefinition, Kommunikation ganz im Allgemeinen, aber auch zu verstehen, was Menschen motiviert. auch nach mehreren jahren in dem job ist das noch ein feld womit ich mich sehr sehr viel beschäftige was motiviert jemanden das zu tun was er oder sie gerade tut und diese ich würde sie fast ich würde sie nicht esoterische themen nennen aber diese meta themen. die bekommen einen höheren Stellenwert, Empathie und genau, diese Themen, die hatte ich vorher als Individual Contributor gar nicht so stark auf dem Schirm, obwohl ich denke, als Engineering Manager oder Managerin sind das Themenfelder, wo man sich sehr, sehr stark darauf fokussieren sollte, aber auch als Individual Contributor, wenn man die Leiter hoch geht, das bedeutet, Senior-Engineer, Staff-Engineer, Principal-Engineer. Umso mehr Erfahrung man hat, umso weniger Code schreibt man eigentlich, umso mehr implizites Leadership sollte man da auch übernehmen, wo die Themen dann wieder reinspielen. Wolfgang, mich würde man aber deine Sichtweise auf diese Frage interessieren. Ich meine, du bist direkt von der Uni gekommen, du bist 2016 bei Trivago eingestiegen, direkt als Engineering-Manager. Hat sich für dich groß was geändert?
Wolfi Gassler (00:08:00 - 00:08:38)
Natürlich hat sich für mich stark was geändert. Ich war ja auch als Freelancer viel unterwegs und habe da in größeren Projekten mit Freelancern zusammengearbeitet und da das Projektmanagement auch gemacht. Auch auf der Uni macht man klassisches Projektmanagement. kleinem anderen Ausmaß und du arbeitest mit Studenten zusammen, also es war mir jetzt nicht alles komplett fremd, aber so ein klassisches Team zu übernehmen war natürlich auch für mich komplett neu, muss ich zugeben, und war sehr froh, dass das Trivago mir das Vertrauen geschenkt hat damals. Also ich bin in einer ähnlichen Situation gewesen wie du eigentlich am Anfang, dass es sehr neu für mich war.
Andy Grunwald (00:08:38 - 00:08:40)
Also du hast ein existierendes Team übernommen, richtig?
Wolfi Gassler (00:08:41 - 00:09:14)
Ja, korrekt. Ich glaube, es waren schon irgendwie sechs, sieben Leute oder so vorhanden und das habe ich übernommen, dann natürlich auch ausgebaut und da hat sich dann natürlich einiges geändert. Aber so habe ich gestartet. Es war aber auch für mich jetzt insofern neu, dass mir diese ganzen Themen neu waren, weil zum Beispiel Klassische 101-Meetings mit Leuten, die machst du als Freelancer nicht. Die machst du auch mit Studenten weniger, dass du einfach über nicht technische Sachen sprichst und mehr über Dinge, die dich beschäftigen, wenn du wirklich fulltime in einem Team arbeitest.
Andy Grunwald (00:09:15 - 00:09:19)
Kannst du mal ganz kurz für die Hörer erklären, was ein 101-Meeting ist und warum das sinnvoll ist? Warum sollte man das tun?
Wolfi Gassler (00:09:20 - 00:11:19)
One-on-ones sind regelmäßige Treffen oder Meetings. Im deutschsprachigen Raum nennt sich das öfters Mitarbeitergespräch oder Sure-Fix. Da gibt es mehrere Varianten davon. Meiner Erfahrung nach ist es dann eher weniger regelmäßig, sondern nur einmal im Jahr oder so. Es gibt natürlich auch Gott sei Dank mittlerweile bessere Firmen, die das auch regelmäßiger machen und ich glaube das ist auch sehr wichtig von so einem 101, dass es wirklich regelmäßig stattfindet, also zum Beispiel alle zwei Wochen würde ich mal sagen oder vielleicht sogar wöchentlich, je nachdem. Und das ist eigentlich einfach ein Meeting, eine fixe geblockte Zeit, die man zusammen hat als Manager mit dem jeweiligen Teammitglied. Und in diesem Meeting kann man einfach alle Sachen ansprechen. Probleme, man kann sich aber auch Feedback holen. Coaching. Man hat natürlich als Manager auch die Möglichkeit, da dementsprechend steuernd einzuwirken oder halt auch das Feedback zu geben. Also es ist wirklich ein offenes Gespräch und beide Seiten sollten sich da wirklich einbringen und Themen klären, die halt aktuell gerade wichtig sind, egal von welcher Seite oder was es betrifft. Teamzusammenarbeit, aber auch durchaus technische Sachen, wenn es gerade wichtig ist. Also es ist sehr frei und nicht hart definiert. Aber meiner Meinung nach extrem wichtig, dass es das gibt, regelmäßig einfach um zu checken, ist man am richtigen Weg, gibt es irgendwo Sachen, die man ändern muss oder wo will ich mich hin entwickeln, dass man auch das mit dem Manager bespricht und da dementsprechend Hilfe bekommt, Support. dass man da einfach eine gute Zusammenarbeit hat. Und vor allem, wenn die Teams größer werden oder die Firmen größer werden, ist es einfach wichtiger, weil man sich nicht mehr tagtäglich trifft und so eng zusammenarbeitet, dass man diese Möglichkeit vielleicht in anderen Bereichen hat, sondern dass man halt einfach eine geblockte Zeit hat, alle zwei Wochen, halbe Stunde, Stunde, um da einfach diese ganzen Dinge zu besprechen.
Andy Grunwald (00:11:19 - 00:11:45)
Jetzt hattest du gesagt, du hast ein existierendes Team von sechs bis sieben Leuten übernommen und dass du es ausgebaut hast. Jetzt sprichst du auch von One-on-ones, die du mit den jeweiligen Teammitgliedern hast, das bedeutet Einzelmeetings. Das klingt mir nach einer ganzen Menge, nach einem recht großen Zeitinvestment, was du pro Woche aufbringst, wenn du mit sechs, sieben Leuten jeweils ein One-on-one hast, jede Woche, und du hast das Team noch ausgebaut.
Wolfi Gassler (00:11:46 - 00:12:40)
Also zu Spitzenzeiten hatte ich mal 25 Reports, Direct Reports, das heißt Leute mit denen ich eigentlich direkt zusammenarbeiten hätte sollen. Ist meiner Meinung nach absolut Harakiri, würde ich niemandem empfehlen, ist auch keine gute Struktur. Aber das sieht man dann sofort, wenn du 25 solche One-on-ones regelmäßig halten musst. Erstens hast du zu wenig Kontakt natürlich mit den Leuten, aber auch die Zeit, die da einfach drauf geht, um diese ganzen Meetings zu machen, das ist extrem viel und man hat dann einfach viel zu wenig Zeit, um sich um andere Sachen zu kümmern. Also ich glaube 101 sind sehr sehr wichtig, aber sind auch ein großes Zeitinvestment und ich sage bewusst Investment, weil man bekommt auch viel zurück dafür. Aber ich glaube das ist ganz ganz wichtig, dass man das als Manager dementsprechend einplant und das kostet auch viel Zeit.
Andy Grunwald (00:12:41 - 00:12:47)
Wie kam es zu der Situation, dass du auf einmal 25 Direct Repos hast? Also ich meine von 6 bis 7 auf 25.
Wolfi Gassler (00:12:47 - 00:13:24)
Ja, das war natürlich in dieser extremen Wachstumsphase bei Trivago und es waren einfach viel zu wenig Leads vorhanden. Und wir haben zwar probiert, auch Leads zu recruten, ist aber natürlich extrem schwierig, gute zu finden. Und es ist einfach sehr, sehr stark gewachsen, das ganze Team. War auch eine andere Struktur, muss man dazu sagen. Also es war jetzt nicht, dass ich da irgendwie dann technisch noch involviert gewesen wäre. Aber trotzdem war das auf lange Sicht natürlich nicht haltbar und haben wir dann auch sehr schnell geändert, dass da andere Teamleads Teile übernehmen, weil mit der Größe funktioniert das einfach auf Dauer nicht mehr.
Andy Grunwald (00:13:24 - 00:13:37)
Was würdest du sagen, wenn jemand neu als Engineering Manager einsteigt bzw. einsteigen möchte oder Engineering Managerin einsteigen möchte? Was ist eine gute Teamgröße zu starten für jemanden, der das neu macht?
Wolfi Gassler (00:13:38 - 00:14:47)
Ich glaube, es gibt zwei Varianten, wie man in so eine Rolle reinwachsen kann oder wie solche Rollen normal entstehen. Also es gibt entweder schon Teams, die einen neuen Lead brauchen, warum auch immer, oder so wie in deiner Variante, wo man einfach reinwächst. Man sieht, okay, da braucht es mehr Leute, wir wollen noch mehr Leute anstellen und dann wird man so langsam in diese Rolle reingeschoben. In beiden Varianten würde ich auf jeden Fall sagen, man sollte mit weniger Leuten anfangen. Ich glaube, es gibt jetzt kein Minimum oder so, aber ich glaube, man sollte jetzt keine 15 Leute übernehmen, wenn man da überhaupt keine Erfahrung drin hat. Also es wäre schon besser, das Ganze kleiner zu starten, weil dann hat man auch mehr Zeit und auch weniger Risiko, weil wenn du einfach mit zehn Leuten zusammenarbeitest, dann hast du einfach extrem viele Probleme. Es sind von zehn Leuten und wenn du die dann alle in irgendeiner Form bearbeiten musst oder mit den Leuten sprechen musst, das ist für den Anfang wahrscheinlich einfach zu viel. Also ich würde schon empfehlen, irgendwie mit, keine Ahnung, drei Leuten oder so, das ist sicher eine gute Größe, mit der man verstarten kann und langsam in die ganze Sache reinwachsen kann.
Andy Grunwald (00:14:47 - 00:14:48)
Ja, da stimme ich zu.
Wolfi Gassler (00:14:48 - 00:15:06)
Aber wenn wir jetzt nochmal auf unsere Anfänge zurückgehen, wir waren ja beide in dieser Situation, dass es relativ neu war für uns. Woher hast du denn die Informationen bekommen, was du überhaupt machen musst oder wie das Ganze funktioniert? Hattest du selber einen guten Lead oder hast du die Informationen irgendwo anders herbekommen?
Andy Grunwald (00:15:07 - 00:17:39)
Das ist mir jetzt total peinlich zu sagen, aber das war knallhartes Learning by Doing, was ich inzwischen ganz anders machen würde. Und wie, erzähle ich, erwähne ich gleich. Aber wenn man in der neuen Position ist, ist man natürlich auch wieder motiviert. Oder beziehungsweise die Motivation steigt natürlich an, man setzt sich selbst sehr hohe Erwartungen, man will den Job ja gut machen. Und was macht man in der Regel? Man fängt an zu googeln, wenn man keine Ahnung hat über ein Thema. Und am Anfang habe ich mir ziemlich viele Blogposts durchgelesen, was man tun sollte, was man nicht tun sollte und habe mich ein bisschen daran orientiert. Ich habe zugegebenerweise sehr viele Fehler gemacht, die mir auch leidtun, wenn ich ganz anders machen würde inzwischen. Dafür bin ich dann aber auch dankbar an Trivago, dass sie mir die Chance gegeben haben, in diese Rolle so rein wachsen zu dürfen. Wie ich es aber heute machen würde, ist ein bisschen anderer Weg. Auf der einen Seite gibt es natürlich inzwischen deutlich mehr Ressourcen, weil die ganze Tech-Industrie mitgewachsen ist, weil das Jobprofil des Engineering-Managers sich geändert hat und deutlich mehr Fokus darauf ist, auf gutes Leadership, auf gutes Management. Also die ganze Industrie rund um dieses Job-Profile hat sich sehr entwickelt. Dazu gibt es deutlich mehr Bücher. Ein paar dieser Bücher werden wir in den Shownotes verlinken, die wir sehr, sehr stark empfehlen. Eins der einfachsten Mittel wäre, man schaut einfach mal links und rechts in der Firma nach, wer hat denn schon ein bisschen Engineering-Management-Leadership-Erfahrung und geht mit dieser Person öfter mal Kaffee trinken oder Mittagessen. Oder vielleicht auch einfach ganz offiziell, man fragt diese Person vielleicht einfach ganz offiziell, hey, hättest du Lust mich zu mentoren? Ich habe jetzt gerade eine neue Engineering Manager Stelle angetreten oder werde eine antreten in einem Monat und würde gerne von deinen Erfahrungen lernen. Die Frage mag zwar schwierig sein, immer wenn ich sie gestellt habe, habe ich aber immer sehr positives Feedback bekommen und das kann ich wirklich jedem empfehlen, von Leuten mit Management-Erfahrung zu lernen, weil da kann man nämlich ganz einfach in einem sicheren Umfeld jede Frage stellen, die man vielleicht nicht so offen im Internet stellen möchte oder ähnliches. Eine andere Idee ist natürlich, seinen eigenen Lead zu fragen. Kann eine sehr gute Option sein, je nachdem, was man für ein Verhältnis zu seinem Lead hat. Wenn das natürlich eine stark wachsende Firma ist, dann kann es sein, dass der eigene Lead auch nicht so viel Erfahrung hat. Ab und zu ist es aber auch ganz gut, einfach mal eine andere Perspektive zu kriegen aus einem anderen Bereich, von einer anderen Person oder vielleicht sogar von mehreren Personen, vielleicht von einem Mentor und seinem eigenen Lead.
Wolfi Gassler (00:17:40 - 00:18:21)
Ich glaube, man braucht auch gar nicht unbedingt immer diese Mentorenrolle, Leute, die sich extrem gut auskennen, sondern eben auch einfach Leute, die vielleicht auf der gleichen Ebene sind, die die Peers sind und mit denen man sich austauschen kann, die die gleichen Probleme haben, vielleicht auch gar nicht so viel wissen, aber wenn man über die gleichen Probleme diskutieren kann, wir haben das zum Beispiel sehr oft gemacht, Andi, da kann man natürlich auch extrem viel lernen, weil man einfach gemeinsam Ideen analysieren kann und Ideen hin- und herschmeißen, weil man einfach gemeinsam Ideen hin- und herschmeißen kann. Wie kann man Probleme lösen? Man sitzt im selben Boot und das macht es natürlich auch gleich viel einfacher.
Andy Grunwald (00:18:21 - 00:19:06)
Sehr, sehr guter Einwand. Die ganze Thematik nennt sich Peer Coaching. Praktisch kann sowas so aussehen, ... ... ihr macht 2-wöchentlich ein 1-Stunden-Meeting ... ... mit allen Engineering-Managern in der Firma ... ... oder mit einer kleinen Gruppe mit 5 Leuten, ... ... je nachdem, wie groß die Firma ist, ... ... und redet einfach über Probleme. Das ist halt ein sicherer Ort. Das sind alles Leute, die haben dieselben Herausforderungen. Und dort könnt ihr euch wirklich ... ... gegenseitig Ideen und Tipps geben, ... ... wie man diese Probleme lösen kann, ... ... diese Herausforderungen lösen kann. weil diverse Manager haben diverse Erfahrungen gemacht. Bei Trivago wurde das unter anderem auch in der Personalabteilung getrieben, was ich sehr begrüßt habe. Es kostet in der Regel sehr wenig Aufwand, sehr wenig Vorbereitung, bringt aber der ganzen Organisation eine ganze Menge Vorteile.
Wolfi Gassler (00:19:07 - 00:20:44)
In einer großen Firma wie Trivago war das natürlich strukturell auch ganz anders möglich. Wir hatten da Agile Coaches, die das unter Umständen auch unterstützt haben oder wo es halt auch so viele Leute waren, dass da einer wirklich die Moderation übernehmen hat können. Wenn man jetzt das runterbricht auf kleinere Firmen, es muss nicht immer so. perfekt organisiert sein. Ich glaube, da ist es auch okay, wenn man zu dritt einfach einen Kaffee irgendwo trinkt, gemütlich, und über die Probleme spricht. Also man braucht es nicht immer so groß aufziehen, natürlich. Man kann es auch klein starten. Aber ich glaube, es ist ganz wichtig, dass man eben grundsätzlich das Netzwerk sich aufbaut zu anderen Leuten, die das gleiche Problem haben und so wie man sonst sein Netzwerk aufbaut, sein technisches Netzwerk zu anderen Programmierern, so muss man das eben in einer anderen Position dann auch mit den ähnlichen Leuten in einem ähnlichen Umfeld machen. Es gibt natürlich jetzt auch noch das Problem bei ganz kleinen Firmen, dass es vielleicht gar keine Peers gibt, mit denen man sprechen kann, aber auch da kann man wieder nach außen gehen Man kann sich überlegen, vielleicht hat man in seinem Netzwerk irgendwo Leute, die in einer anderen Firma in der gleichen Position sind und es ist durchaus auch üblich, das Firmengrenzen überschreitend zu machen mit einer anderen Firma und man kann da normalerweise auch sehr offen vielleicht sogar teilweise noch offener über Probleme sprechen, vor allem wenn es ein kleines Team ist, weil dann kennen sich die Leute nicht und es ist auch einfacher darüber zu sprechen. Also man kann da auch wirklich nach außen gehen oder auch versuchen Leute einfach mal anzuschreiben in seinem Netzwerk und üblicherweise sind die Leute eigentlich sehr offen dafür, weil man ja gegenseitig sich bereichert und auch vom anderen jeweils wieder was zurückbekommt.
Andy Grunwald (00:20:45 - 00:20:55)
Kleiner Tipp, wenn ihr ein sehr lautes Organ habt, macht das am besten nicht in der Bahn oder im Starbucks. Das sind alles Informationen, die mit der großen Öffentlichkeit am besten nicht geteilt werden sollten.
Wolfi Gassler (00:20:55 - 00:21:38)
Bevor wir da jetzt zu sehr in die Details der Arbeit eines Engineering Managers abdriften, vielleicht nochmal zurückgehend. Hast du für dich damals, also es hat sich eher so angehört, du bist einfach reingerutscht und wurdest auch fast gar nicht gefragt. Aber wenn jetzt Leute vor dieser Entscheidung stehen, soll ich in so eine Position rein? Soll ich in so eine Manager-Position rein? Hast du irgendwelche Empfehlungen, wie man diese Entscheidung für sich einfacher treffen kann? Weil ich glaube, ganz grundsätzlich ist es ein großes Problem für viele Techniker. Soll ich überhaupt in so eine Manager-Rolle rein? Ist es eine Promotion, die ich da habe, in eine höhere Position? Macht es Sinn? Soll man dazusagen? Soll man darauf hinarbeiten? Hast du irgendwelche Tipps dafür?
Andy Grunwald (00:21:39 - 00:22:04)
In der Tat, ich kann mich jetzt gerade gar nicht mehr so daran erinnern, ob ich damals die Entscheidung so bewusst getroffen habe oder nicht. Aber um die Frage zu beantworten, ich würde gerne einen Mythos mal entzaubern, und zwar der Wechsel vom Software-Engineer zum Engineering-Manager ist keine Beförderung. Er ist ein ganz klarer Jobwechsel, weil es sind einfach zwei unterschiedliche Jobs mit zwei unterschiedlichen Prioritäten.
Wolfi Gassler (00:22:04 - 00:22:05)
Und die zwei Prioritäten wären?
Andy Grunwald (00:22:07 - 00:25:50)
Meiner Definition nach ein Software-Engineer ist die Hauptaufgabe, das Hauptziel, die Vision der Firma mittels Technologie, mittels Software nach vorne zu treiben. Das bedeutet, ganz praktisch gesagt, Software zu entwickeln, Software zu designen, Software zu maintainen. Die Aufgabe eines Engineering-Managers ist auf der einen Seite Menschenführung, auf der anderen Seite Strategieführung. Natürlich kann dies mit technischer Relevanz geschehen, und sagt ja auch schon der Name, Engineering Management ist es auch in irgendeiner Art und Weise. Dennoch ist die Hauptaufgabe nicht, selbst die Software zu entwickeln. Es ist ein anderes Problemfeld mit anderen Herausforderungen. Das heißt nicht, dass ein Engineering Manager nicht mehr Hands-on sein kann, doch die Zeit, die ein Softwareentwickler mit Softwareentwickeln verbringt, ist deutlich höher als ein Engineering Manager. Wie findet man jetzt raus, ob man das machen möchte oder welche Gedankengänge sollte man anstoßen? Das ist eine sehr gute Frage. Ich denke, als erstes sollte man sich die Frage stellen, ob man offen dafür ist, neue Felder kennenzulernen. Das bedeutet, viel in Kommunikation zu investieren, viel in das Verständnis zu investieren, was Menschen antreibt, wie man diese weiterentwickeln kann. aber auch sich deutlich mehr mit dem eigenen Business der Firma beschäftigt. Womit verdienen wir Geld? Was sind mögliche Wege, um die Firma erfolgreicher zu machen? Das sind alles Bereiche, in denen Software-Engineers zwar auch aktiv sein sollten, jedoch das Zeitinvestment, welches von Engineering-Managern investiert wird, ist deutlich höher als von Software-Engineers. Also, wenn man offen dafür ist, diesen Weg zu gehen, dann hat man schon ganz gute Voraussetzungen. Jetzt ist die Frage, ja, hey, ich habe aber keine Antwort auf die Fragen, wann weiß ich das denn? Ich würde jedem empfehlen, wenn ihr die Chance habt, mal ein Team zu übernehmen, tut das, macht es für sechs bis zwölf Monate und entscheidet dann. Nach einer Woche kann man das nicht sagen, nach zwei Wochen und nach einem Monat kann man das auch nicht sagen. Man braucht wirklich Zeit, weil auf der einen Seite ist man am Anfang ein bisschen überfordert, und hat ganz viele neue Eindrücke und alles ist noch neu und spannend und shiny. Aber irgendwann werdet ihr damit klarkommen, diese Herausforderung zu meistern und dann beginnt das Operative. Dann beginnt das, wo ihr euch wirklich mit dem Skill von People Management auseinandersetzen könnt. Und da erfahrt ihr erst, ob euch das Spaß macht. Ich hatte die Tage ein Gespräch mit einem ehemaligen Teammitglied von mir, der hat die Firma gewechselt und er ist jetzt seit circa einem Jahr, sagen wir mal so 10 bis 12 Monate, Engineering Manager und der hat mir über Instagram geschrieben und hat gesagt, hey Andi, ich habe mal eine Frage zum Engineering Management. Irgendwie in letzter Zeit schreibe ich nur noch Dokumente und connecte Leute. Ist das richtig? Ist das Engineering Management? Ich habe die Nachricht gelesen und musste ein bisschen grinsen, weil er war auch eine Person, die sehr, sehr viel Hands-On gemacht hat. Und es ist natürlich ein kompletter Wechsel, wie man die Zeit auf der Arbeit verbringt. Eins muss man sich bewusst werden als Engineering Manager. Der Feedback-Loop ändert sich. Was meine ich damit? Als Software-Ingenieur fixt man einen Bug, man entwickelt ein Feature, deployed das auf Produktion, geht auf Produktion und testet es. Da ist der Feedback-Loop teilweise Minuten. Beim Engineering-Management ist der Feedback-Loop länger. Das bedeutet, wenn du eine Person in eine Richtung entwickelst oder wenn du irgendwas anstößt, dann ist das in der Regel so, dass man erst ein bis drei Monate später das Ergebnis sieht. Man ist nicht mehr das direkte Feedback gewohnt, sondern muss das aushalten, dass das Feedback deutlich verzögert ist. Hast du auch so ähnliche Erfahrungen gemacht, Wolfgang?
Wolfi Gassler (00:25:50 - 00:26:26)
Mit dem Feedback-Loop gebe ich dir auf jeden Fall recht. Ich würde es sogar erweitern, wenn du mit einem Team zusammenarbeitest. Kann sein, dass du erst nach ein, zwei Jahren siehst, den ganzen Erfolg, den du reingesteckt hast, weil das Team dann erfolgreich wird. Also das kann sich extrem rauszögern. Ein anderer Punkt, den ich sehr oft gehört habe, das ist vielleicht von der anderen Richtung. Was solltest du nicht wollen, wenn du ein Engineering Manager werden willst? Ich habe das oft gehört, so Leute, die aus dem Bereich kommen, ja, ich habe so Schwierigkeiten in meinem Team, wenn es um technische Entscheidungen geht und ich möchte Manager werden, weil dann kann ich endlich entscheiden, was für Technologie eingesetzt wird.
Andy Grunwald (00:26:26 - 00:26:31)
Du sprichst das hier auf die Motivation und warum man Engineering Manager werden sollte, richtig?
Wolfi Gassler (00:26:31 - 00:27:10)
Genau, wenn du diese Motivation hast, dann solltest du kein Engineering Manager werden, weil ich glaube, ganz wichtig, und das hast du schon richtig gesagt, du bewegst dich dann auf einer menschlichen Ebene und probierst das Team nach vorne zu bringen und machst aber selten technische Entscheidungen. Natürlich, es gibt die Möglichkeit, wenn es jetzt irgendwie Probleme im Team gibt und es ist nicht ganz klar, was soll man verwenden, da musst vielleicht du am Ende die Entscheidung treffen. Aber klassisch ist es so eigentlich eher, dass du das Team probierst zu enablen, d.h. zu unterstützen, damit es schneller besser arbeiten kann und weniger ihnen vorgibst, was die zu tun haben. Zumindest ist das in moderneren Unternehmen so.
Andy Grunwald (00:27:10 - 00:27:17)
Du sprichst da so die Power ausleben, das sollte man nicht so tun, richtig? So ich bin der Chef und ihr macht jetzt genau das, was ich sage, richtig?
Wolfi Gassler (00:27:18 - 00:27:44)
Genau, ich glaube, du hast dann danach eigentlich weniger Power in dem Sinne. Also du kannst natürlich extrem viel bewegen, aber du hast weniger oder solltest weniger Einfluss auf die Leute nehmen, solltest dich eher zurückhalten und versuchen, dass dieses Team möglichst gut arbeiten kann, schnell vorankommt. Und da geht es nicht darum, dass du alle Entscheidungen triffst und die dann nur wie die Minions vor sich hinarbeiten und dir die Klassen schreiben, die du entscheidest.
Andy Grunwald (00:27:45 - 00:27:47)
Würdest du sagen, das ist der Unterschied zwischen Management und Leadership?
Wolfi Gassler (00:27:47 - 00:28:01)
Da kommen wir jetzt natürlich in einen ganz anderen Bereich von Engineering Kultur, aber ich würde auf jeden Fall sagen, das ist ein Unterschied und das ist auf jeden Fall die präferierte Variante, meiner Meinung nach, mehr Leadership zu zeigen und weniger Management.
Andy Grunwald (00:28:02 - 00:28:11)
Denkst du denn, es ist ab und zu auch notwendig, einfach mal ein Machtwort zu sprechen und die Diskussion zu stoppen und einfach zu sagen, wir gehen jetzt diesen Weg?
Wolfi Gassler (00:28:12 - 00:28:57)
Es gibt sicher Situationen, da muss man das auf jeden Fall machen. Je nachdem, wie weit du im Team noch involviert bist, kannst du entweder wirklich die technische Entscheidung treffen, aber die bessere Entscheidung wäre wahrscheinlich, dem Team einfach zu helfen, eine Entscheidung zu finden und da vielleicht den Weg vorzugeben oder beim Weg behilflich zu sein, wie kommt man denn eigentlich zu einer Entscheidung, wo das ganze Team dann im Endeffekt dahinter steht. Aber es gibt natürlich ganz oft Situationen, wo sich dann einfach zwei Lager bilden in einem Team und da muss man dann früher oder später einfach eingreifen, weil sonst das Team wahrscheinlich zu keiner Entscheidung kommen würde und ewig lang nur streitet oder sich noch mehr Mauern bilden im Team und das natürlich für das ganze Team negativ automatisch dann endet.
Andy Grunwald (00:28:57 - 00:29:31)
Ich habe die Erfahrung gemacht, dass es gar nicht so einfach ist, ein solches Machtwort zu sprechen und dass ich in dem Job als Engineering Manager es auch zu Situationen kommen kann, wo ich wirklich nervös bin, wo ich, ich würde schon fast sagen, ein bisschen Angst habe, diese Sache auszusprechen oder in diese schwierige Konversation hereinzugehen. Hattest du auch schon mal Situationen, kannst du vielleicht mal ein oder zwei Situationen beschreiben, wo du richtig nervös warst, weil du wusstest, okay, es steht mir eine schwierige Konversation hier bevor und wie du dich da verhalten hast?
Wolfi Gassler (00:29:31 - 00:30:50)
Du sprichst da, glaube ich, an ganz einen wichtigen Punkt, an die Verantwortung, weil wenn du eine Managerrolle annimmst, dann hast du mehr Verantwortung und diese Verantwortung Bedeutet dann auch, dass du zum Beispiel Leute entlassen musst oder dass du wirklich schwierige Gespräche führen musst, weil bei jemandem die Performance zum Beispiel nicht stimmt oder irgendwie Probleme im Team sind. Und das ist alles andere als einfach. Also wer glaubt, dass es einfach ist, Leute zu entlassen oder solche schwierigen Gespräche zu führen, weil man ist eh nur der böse Manager und will die Leute rauskicken, der hat wirklich da eine falsche Vorstellung. Das kann schon sehr an den Nerven zehren und vielleicht sogar schlaflose Nächte bereiten. Aber man kann dann natürlich auch wieder ein Erfolgserlebnis haben, wenn man zum Beispiel schafft, dass jemand, der irgendwie Performanceprobleme hat oder Probleme im Team hat, dass man den in irgendeiner Form unterstützt und wieder auf Schiene bringt. Und das ist dann natürlich ein Erfolgserlebnis für alle Beteiligten, wenn dann alle wieder happy sind in ihrem Job und gemeinsam im Team weiterarbeiten können und das Team einfach super Leistung erbringt. Dann ist das wirklich was Schönes, aber das kann natürlich dauern und kann extrem viel schwierige Gespräche, Nervosität, andere Dinge mit einschließen, die man da am Weg hat. Es ist ein harter Weg, aber man kann da natürlich auch dann Erfolgserlebnisse haben am Ende. Aber es sind andere Erfolgserlebnisse, als man deployed irgendwas und es läuft dann was am Service.
Andy Grunwald (00:30:51 - 00:31:10)
Was mir persönlich immer hilft ist, sich bewusst zu werden, dass man hier mit dem Job als Engineering Manager und Engineering Managerin über die Zukunft und Karriere von Leuten entscheidet oder beziehungsweise einen Einfluss hat und dass man da auch immer sehr sehr vorsichtig und bedacht vorgehen sollte.
Wolfi Gassler (00:31:10 - 00:31:36)
Jetzt, wenn wir mal annehmen, diese ganzen Gespräche, die man da so führen muss und das Leben eines Engineering Managers ist vielleicht das falsche für einen. Du hast ja auch einige Male gewechselt zwischen Engineering Manager mit Personenverantwortung und normalen Rollen ohne Personalverantwortung. Glaubst du, das ist ein Rückschritt? Kann man grundsätzlich wechseln? Hat man dadurch Nachteile? Wie siehst du das Ganze?
Andy Grunwald (00:31:36 - 00:34:14)
Das ist eine sehr gute und eine sehr wichtige Frage. Genau. Ich war Individual Contributor, war dann für mehrere Jahre Teamleiter. Danach habe ich mein Chef das Unternehmen verlassen. Dann habe ich mich auf seine Stelle beworben und wurde Abteilungsleiter für eine gewisse Zeit. Und vom Abteilungsleiter bin ich dann wieder zurück zum Individual Contributor, zum Software Engineer. Das war komplett meine Entscheidung. Und der Grund war ganz einfach. Ich denke, du solltest das tun, was du wirklich liebst. Es ist ein Unterschied, ob du Teamleiter bist oder Abteilungsleiter. Umso höher du die Managementleiter gehst, umso weiter entfernst du dich von den technischen Details. Und ich habe damals für mich herausgefunden, dass ich die Technik zu sehr liebe und dass ich nicht mehr auf oder nicht nur auf High Level entscheiden möchte. Und deswegen habe ich mich dazu entschieden, vom Abteilungsleiter zurück als Individual Contributor zu wechseln. Bei Trivago ist das nicht als Rückschritt gesehen, weil dort die Kultur so ist, dass man das tun sollte, was du selbst liebst und nur weil es heißt, dass du ein guter Software-Ingenieur bist, heißt das nicht, dass du ein guter Engineering-Manager bist. In traditionelleren Unternehmen, oder Unternehmen, die wirklich sehr stark auf eine Karriereleiter pochen, kann das ab und zu als Rückschritt gesehen werden. Ich würde aber jedem nahelegen, dies nicht so zu sehen. Und es gibt mehr und mehr Beispiele, die das auch zeigen. Nehmen wir mal der ehemalige CEO von HashiCorp, Mitchell Hashimoto. Vor kurzem ist er von seinem CEO-Posten wieder zum Software-Engineer gewechselt, aus sehr ähnlichen Gründen wie ich, weil er einfach die Technologie und das Software-Engineering zu sehr liebt. Ich denke nicht, dass es ein Rückschritt, ich denke eher, dass es eine Stärke ist. eine stärke zu sich zu stehen und das was man das was man liebt und ich denke es ist auch kein rückschritt im cv im lebenslauf denn solange man die stelle und den wechsel begründen kann warum man das gemacht hat denke ich wird das von sehr sehr vielen unternehmen als stärke wahrgenommen das ist auch meine erfahrung inzwischen. Es hilft einem sogar auch, wieder zu wachsen, weil umso länger man in der Engineering Manager Position ist, desto mehr kommen so Fragen auf wie, das ist doch nicht so kompliziert, warum dauert das so lange? Und ja, als Software Engineer habe ich diese Frage auch gehasst, inzwischen weiß ich, man verliert einfach den Blick fürs Detail. Und wenn man dann wieder als Individual Contributor arbeitet, dann merkt man, oh, das ist doch deutlich komplexer und bedarf mehr Arbeit, weil der Teufel im Detail steckt. Und dann ist man sich mehr und mehr bewusst, dass man diese Frage einfach nicht stellen sollte, warum es so lange dauert.
Wolfi Gassler (00:34:14 - 00:35:13)
Wir können da auch einen Blog-Eintrag verlinken von einem Kollegen von uns bei Trivago, der genau durch diese Achterbahn gegangen ist, sag ich mal, und das auch in einem schönen Blog-Post verwandelt hat, dass ihm das am Ende eigentlich sehr viel gebracht hat, dieser Wechsel, dieser Rückschritt, wenn man es bösartig so nennen will. dass das also wirklich im Endeffekt sehr viel bringt und ich glaube, man muss heutzutage auch einfach weiter weggehen von diesem klassischen Hierarchie-Modell, dass man da als Entwickler anfängt, dann wird man Entwickler-Manager und dann wird man Abteilungsleiter und das ist die einzige Möglichkeit, die es gibt. Am Ende sollte man glaube ich das machen, was man natürlich am liebsten macht und dass man halt auch für die Firma ein Output liefert, dass die Firma auch am Ende was davon hat und das ist dann glaube ich auch der Firma egal, ob du das als Engineering Manager oder als Individual Contributor machst, ist glaube ich dann am Ende im Endeffekt egal.
Andy Grunwald (00:35:14 - 00:35:29)
Was würdest du Leuten empfehlen, die den mutigen Schritt gemacht haben, Engineering Management einmal auszuprobieren, die nach sechs bis zwölf Monaten festgestellt haben, das ist nichts für mich? Ist da der Karrierepfad für die dann Ende? Oder was würdest du den Leuten empfehlen, die dann wieder zurück zum Software Engineering gehen wollen?
Wolfi Gassler (00:35:29 - 00:36:39)
Also ich glaube, ganz wichtig ist, dass man weiß, warum er diese Position nicht will, weil es gibt da extrem viele unterschiedliche Gründe dafür. Ich kenne zum Beispiel einen, der hat der Engineering Manager an den Nagel gehängt und ich glaube, dass das eigentlich der Hauptgrund war, weil er extrem schlechten Support von der Firma bekommen hat, von seinem eigenen Lead. Und dadurch war das einfach viel zu komplex und eine Aufgabe, die er nicht wirklich machen hat können. Bei demjenigen würde ich zum Beispiel empfehlen, okay, vielleicht sollte er es irgendwann wieder mal probieren. Hat jetzt nicht funktioniert, man kann wieder in die in die IC-Rolle zurück, kann sich dort weiterentwickeln. und vielleicht mal in einem Jahr wieder oder in eineinhalb Jahren probiert man es wieder mal, wenn man es noch machen möchte. Also ich glaube, es ist ganz wichtig, dass man aus diesem Versuch auch was mitnimmt, dass man wirklich weiß, okay, was will man eigentlich, was liegt einem, was liegt einem vielleicht überhaupt nicht, weil man natürlich extreme Probleme hat mit dem ganzen menschlichen Aspekt von so einer Rolle. dann ist es wahrscheinlich die falsche Rolle, dann soll man vielleicht eher in der technischen Rolle sich weiterentwickeln.
Andy Grunwald (00:36:39 - 00:36:43)
Du sagst in der technischen Rolle weiterentwickeln, wie würde sowas aussehen?
Wolfi Gassler (00:36:43 - 00:37:46)
Was jetzt technische Weiterentwicklung bedeutet und heißt, das ist glaube ich ein ganz eigener Folgewert natürlich, aber ich glaube grundsätzlich in gerade modernen Unternehmen gibt es ja mittlerweile wirklich eine Karrierepfade auch auf der technischen Ebene, also so, dass man halt ein Senior Engineer wird oder Principal, Staff, whatever. Wir können da gerne auch mal einen Blogartikel dazu verlinken, was es da so gibt. Es ist natürlich immer die Frage, gibt es sowas in einer Firma? Aber man kann sich ja auch grundsätzlich technisch weiterentwickeln, ohne dass man jetzt irgendwie einen neuen Titel bekommt. Also auch wenn die Firma kleiner ist, kann man ja da durchaus wachsen im technischen Umfeld und kann dann zum Beispiel Tech Lead in dem Team sein oder das Ganze halt auf technischer Ebene betreuen, ein Team oder ein Projekt, ohne dass man automatisch Personalverantwortung hat oder halt wirklich Engineering Manager wird. Also es gibt, glaube ich, in fast allen Firmen irgendwo Möglichkeiten, dass man in seiner Rolle wächst und in größeren Unternehmen natürlich mittlerweile auch wirklich eine Karrierepfade, wo man dann auch einen Titel dazu bekommt, dass man, wenn man wächst.
Andy Grunwald (00:37:46 - 00:38:06)
Und wenn es die Strukturen in eurer Firma noch nicht gibt, scheut nicht diese Strukturen zu schaffen, beziehungsweise anzustoßen, dass das Management oder die Personalabteilung mal drüber nachdenkt. Denn ihr habt mehr Power im Unternehmen als ihr denkt und andere Abteilungen sind sehr, sehr froh, wenn ihr mit solchen neuen Impulsen auch mal an sie herantritt.
Wolfi Gassler (00:38:06 - 00:38:46)
Das möchte ich vielleicht auch noch gleich nachlegen, um wieder ganz an den Anfang zu springen zu unseren 101s. Wenn ihr jetzt keine 101 zum Beispiel habt, regt es mal einfach an bei eurem Lead. Lest mal einen Blogpost darüber und überlegt euch, ob euch das vielleicht weiterbringen würde in der Firma. Also egal welche Strukturen Es sind, ich glaube, man kann schon auch in kleinere Firmen durchaus sowas anstoßen, um die Strukturen, den Karrierepfad zu verbessern, seine eigene Weiterentwicklung, was es auch immer ist. Und üblicherweise wird es hoffentlich bei den Chefitäten auch willkommen geheißen, dass ihr euch darum kümmert und die Firma auch damit weiterentwickelt.
Andy Grunwald (00:38:46 - 00:39:16)
Ich glaube, zum Thema One-on-ones können wir in Zukunft auch mal eine eigene Podcast-Folge machen, weil das Thema ist auch sehr, sehr komplex. Genauso wie Engineering-Management. Und ich frage, ist das ein Weg für mich oder nicht? Wir können darüber noch stundenlang reden, aber ich denke, wir sind am Ende angekommen. Vielen Dank fürs Zuhören. Wolfgang und ich hoffen, dass wir euch einen kleinen Einblick in die Rolle des Engineering-Managers geben konnten, ob das was für euch ist und vielleicht ein paar Gedankengänge anstoßen konnten für euren weiteren Karriereweg.
Wolfi Gassler (00:39:16 - 00:39:48)
Und wenn ihr natürlich Tipps habt, wie man diese Entscheidung vereinfachen kann oder hilfreiche Fragestellungen für diese Entscheidung, sind wir natürlich immer froh, wenn ihr das kommuniziert in irgendeiner Form auf Twitter oder auch, wenn ihr irgendwelche Anmerkungen habt, uns das direkt zukommen lasst unter stetisch.engineeringkiosk.dev oder eben auch öffentlich auf Twitter, damit sich da vielleicht auch eine Diskussion ergibt. Ich glaube, es gibt viele Leute, die sich die Frage stellen und auch froh sind über hilfreiche Tipps oder Anregungen diesbezüglich.
Andy Grunwald (00:39:48 - 00:39:53)
Habt keine Scheu, schreibt uns einfach an, auch mit jeglichen Fragen, die ihr habt. Ansonsten wünsche ich euch noch einen schönen Tag und bis bald.
Wolfi Gassler (00:39:54 - 00:39:58)
Genießt die Woche, das Wochenende oder wann ihr auch immer diesen Podcast hört, die nächste Zeit. Ciao.