#51 Was ist das Staff (Engineer) Level?

Was ist ein Staff-Engineer und wo ist der essentielle Unterschied zum Senior-Engineer?

Karriere-Titel wie Junior- oder Senior-Engineer sind weit verbreitet. Staff-, Principal- oder sogar Distinguished-Engineer sind weniger bekannt. Aus den USA schwappt diese Art des Karrierepfades für Fachkräfte (Individual Contributor) immer mehr als Alternative zum Management-Pfad nach Europa rüber. Doch was ist eigentlich ein Staff-Engineer? Wo ist der Unterschied zum Senior-Engineer? Welche neuen Anforderungen werden an Staff-Engineers gestellt? Wo ist der Unterschied zu einem klassischen Engineering Manager? Was ist Leading by Influence? Wie wird der Titel des Staff-Engineers in verschiedenen Firmen definiert? Und haben Jobtitel überhaupt Relevanz?

Bonus: Was Social-Media-Influencer mit Staff-Engineering zu tun haben und warum Legacy-Code das Geld verdient.

Sprungmarken

(00:00:00) Intro

(00:00:42) Österreichische Titel Landschaft

(00:03:20) Das heutige Thema: Was ist ein Staff Engineer

(00:04:05) Wo ist der Unterschied zum Senior Engineer zum Staff Engineer?

(00:07:45) Warum gibt es denn überhaupt weitere Level über dem Senior-Level?

(00:12:20) Übernehmen wir einfach die Kultur aus den USA? Netflix ändert ihren Karrierepfad

(00:17:10) Was ist der konkrete Unterschied zwischen Senior- und Staff-Engineer?

(00:20:05) Die größten Unterschiede: Big Picture, Execution und Leveling up auf Basis von gutem technischen Wissen

(00:23:03) Leadership by Influence (ohne Personalverantwortung)

(00:26:45) Das große ganze verstehen (das Big Picture)

(00:29:55) Execution (komplexere Projekte, Legacy code, unklare Problemstellung)

(00:32:25) Leveling up (Coaching, Mentoring, Role-Model, Objektiv- und Lösungsorientiert zu denken)

(00:34:25) Die Rolle des Staff-Engineers ist nicht für jeden

(00:37:15) Der Unterschied eines Staff Engineers zu einem Engineering Manager

(00:39:05) Kein Industrie-Standard bei der Definition von Karriere-Level am Beispiel von Dropbox und CircleCI

(00:41:45) Was sind die Erwartungen an euch? Gespräch mit eurer Vorgesetztin

(00:45:10) Welche Relevanz haben Job-Titel?

(00:48:25) Outro: Mastodon

Hosts

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

Feedback (gerne auch als Voice Message)

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.

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

Hast du gewusst, dass Netflix ausschließlich Senior Engineers hat? Zumindest bis vor ein paar Monaten. Denn auch jetzt haben sie sich dem Staff-Level geöffnet. So wie viele andere Tech-Firmen auch. Sogar in Deutschland. Aber was ist eine Staff-Engineering-Stelle? Wo ist der Unterschied zum Senior und wie hat denn die ganze Programmierwelt früher ohne den Staff-Level überleben können? Ist das Ganze vielleicht nur eine Marketing-Erfindung? All das klären wir in dieser Episode vom Engineering Kiosk. Und nebenbei auch noch, was ein Hofrad oder eine Kommerzialrätin ist. Also ab geht's in die Welt der Titel. Andi, ihr habt dich ja schon in viele österreichische Dinge eingeführt, kürzlich gerade in die österreichische Politik, wo man sich ja so Chat-Messages schickt wie, du bist die Hure der Reichen oder so ähnliche Dinge. Heute will ich dich mal einführen in die österreichische Titellandschaft. Und da hätte ich gleich ein paar Fragen.

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

Bist du bereit? Immer.

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

Was ist ein Post-Oberadjunkte? Das ist ein offizieller österreichischer Titel.

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

Darf ich Kontextfragen stellen?

Wolfi Gassler (00:01:08 - 00:01:13)

In Österreich stellt auch niemand die Frage, wenn du sagst, ich bin der Herr Post-Oberadjunkte.

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

Ist die Post bei euch noch verstaatlicht?

Wolfi Gassler (00:01:14 - 00:01:16)

Ja, es kommt aus der Zeit.

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

Ist das noch ein aktueller Job?

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

Keine Ahnung, ob man das noch wirklich werden kann, aber grundsätzlich steht das einfach für jemanden, der Beamter bei der Post ist. Dann bekommt man diesen Titel nach einer gewissen Zeit.

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

Ich hatte mir schon irgendwie sowas gedacht, dass das mit der Verstaatlichung oder mit der staatlichen Post zu tun hat, aber ich dachte jetzt nicht an irgendwie jeder Beamter kriegt den Titel, sondern halt irgendwie, weiß ich nicht, ich stell mir grad so ein Postlager vor und da sitzt oben jemand auf so einem Hochstand und der schaut, dass jeder die Post ordentlich einordnet oder ähnliches, ja sowas hätte ich gedacht, der kriegt den Sondertitel.

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

Vielleicht hat es damals nicht jeder bekommen, das kann schon sein, aber so Sachen wie Hofrat zum Beispiel oder Kommerzialrat, das ist immer noch eine Sache, da schreiben sich viele Leute vor ihren Namen und das ist auch ein Ding, was üblich ist.

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

Ist Hofrat und Kommerzialrat dasselbe?

Wolfi Gassler (00:02:02 - 00:02:13)

Nein, es sind zwei unterschiedliche Titel. Kommerzialrat bekommt man, wenn man länger in der Wirtschaftskammer irgendwie oder in der Wirtschaft tätig ist und die Wirtschaftskammer verleiht ist dann glaube ich irgendwie.

Andy Grunwald (00:02:13 - 00:02:17)

Und ein Hofrat hat irgendwas mit einem Schloss zu tun, weil die haben auch einen Innenhof oder?

Wolfi Gassler (00:02:17 - 00:02:24)

Also es wird vom Bundespräsidenten verliehen und für Verdienste im kulturellen Leben, in der Wirtschaft oder im Sport.

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

Ist das nicht so, dass euer letzter Bundespräsident jetzt irgendwie persönlicher Assistent von Peter Thiel ist oder so?

Wolfi Gassler (00:02:29 - 00:02:42)

Ja, aber der hatte keinen einzigen Titel. Weil der hat, glaube ich, irgendwie sein Studium abgebrochen, der gute Herr Kurz. Aber ich hätte noch eine Frage als letztes. Was ist ein HSDIR-IR-DIPL-BET-OSR?

Andy Grunwald (00:02:42 - 00:02:48)

Also DIPL für Diplom, glaube ich, obwohl habt ihr überhaupt ein Diplom. HSDIR Hochschuldirektor.

Wolfi Gassler (00:02:48 - 00:02:49)

Ja, sehr gut, sehr gut.

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

Hochschuldirektor Diplom. Was war das noch?

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

I.R.

Andy Grunwald (00:02:55 - 00:02:56)

Im Rektoriat.

Wolfi Gassler (00:02:56 - 00:03:15)

Also ist ein Hochschuldirektor im Ruhestand und diplomatischer Pädagoge Oberschulrat. Genau Oberschulrat. Das sind diese Dinge, was die Lehrer bekommen. Aber das ist jetzt keine extrem crazy Auswahl. Bei uns sind Titel wirklich gang und gäbe und das steht auch am Türschild Hofrat oder so. Das ist ganz üblich.

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

Aber ein Oberschulrat haben wir auch in Deutschland.

Wolfi Gassler (00:03:18 - 00:03:18)

Wenigstens etwas.

Andy Grunwald (00:03:19 - 00:04:06)

Okay, Titel, Titel, Titel. Worum geht es heute? Heute geht es auch um Titel. Wieder speziell um Jobtitel. Und zwar haben wir in Episode 40 bereits schon mal über sowas gesprochen. Und zwar haben wir da speziell darüber gesprochen, wie man denn zum Senior Developer, Senior Engineer, Senior Developerin wird. Heute gehen wir einen Schritt weiter, denn die Industrie entwickelt sich ein bisschen weiter. Und mehr und mehr schwappt ein Karrierepfad über dem Senior Engineer rüber nach Europa. In Amerika schon gang und gäbe. Deswegen wollen wir heute mal ein bisschen Licht ins Dunkle bringen und erklären mal ein bisschen, wie der Karrierepfad eines Individual Contributors nach dem Titel Senior aussieht. Und zwar fängt man da in der Regel an, die ganze Sache Staff Engineer, Staff Plus, Principle und so weiter zu nennen.

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

In der Vorbereitung für die Episode, wie ich mir so ein bisschen die ganzen Definitionen durchgelesen habe, habe ich mir ganz oft gedacht, wo ist denn jetzt wirklich der Unterschied zum Senior? Weil das, was ich bisher immer so als Senior im Kopf gehabt habe und was wir auch teilweise in der letzten Episode über Seniors besprochen haben, habe ich in dem Staff-Level jetzt wiedergefunden. Und dann war für mich wirklich die Frage, wo ist denn jetzt wirklich der Unterschied zum Senior? Weil das, was ich bisher immer so als Senior im Kopf gehabt habe und was wir auch teilweise in der letzten Episode über Seniors besprochen haben, habe ich in dem Staff-Level jetzt wiedergefunden. Und dann war für mich wirklich die Frage, wo ist denn jetzt eigentlich der Unterschied und warum braucht man das dann überhaupt?

Andy Grunwald (00:04:48 - 00:05:11)

Ich glaube, das geht nicht nur dir so, ich glaube, das geht einer ganzen Menge Leuten so. Und zwar sind wir hier in Europa, speziell in Deutschland, eigentlich mit den Begriffen Junior-Engineer, Mid-Level-Engineer und Senior-Engineer vertraut. Und wenn man sich die aktuellen Job-Ads anschaut, dann sieht man auch, alle Leute suchen irgendwie nur noch Senior-Engineers. Nun ist es aber so, dass das Modell des Staff Engineers oder Staff Plus...

Wolfi Gassler (00:05:11 - 00:05:13)

Was ist denn schon wieder Staff Plus?

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

Ist es so wie LGBT Plus? Nee, ist es nicht. Bei LGBT Plus heißt ja das Plus noch für weitere Formen. Bei Staff Plus ist es eigentlich das Level eines Staff Engineers und alles da drüber. Weil es ist nicht so, dass über dem Senior Level noch nur ein Level introduced wurde, also eingeführt wurde, sondern mehrere Level. Kommen wir jetzt gleich zu.

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

Ja, aber warum hat man dann das Plus und erwähnt nicht die anderen Levels? Warum gibt es dieses Plus?

Andy Grunwald (00:05:39 - 00:06:34)

Also über dem Senior und Staff Level gibt es noch mehrere Levels und der Unterschied zwischen einem Senior und dem Staff ist ein recht großer, wohingegen der Unterschied zwischen Staff Level und darüber, Senior, Staff, Principal, Distinguished, Fellow und so weiter, Der wird dann immer kleiner bzw. immer granularer. Also da sind die Unterschiede jetzt nicht mehr so riesig wie zwischen einem Senior Engineer und einem Staff Engineer. Man muss natürlich aber auch mal sagen, Disclaimer, wenn es um diese Titel geht, die sind nicht industrieweit definiert. Jede Firma setzt andere Erwartungen an einen Junior-, Middle- oder Senior-Engineer, an einen Staff-, Senior-Staff-Principal und so weiter. Das bedeutet, nur weil man jetzt Staff-Engineer bei Google ist, heißt das nicht, dass das genau das gleiche ist wie ein Staff-Engineer bei Dropbox oder bei Trivago oder bei Check24.

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

Okay, aber der Unterschied zwischen Senior und Staff ist relativ groß, aber da gehen wir dann eh gleich noch darauf ein. Jetzt nochmal zurück zu meiner Frage, warum ist denn das Ganze entstanden? Warum sprießt das jetzt irgendwie aus dem Boden und warum gibt's jetzt plötzlich Staff? Weil bisher hat's ja eigentlich nur Senior gegeben, jeder war glücklich mit diesem Senior und jetzt kommt plötzlich Staff, Senior Staff, Principal, whatever.

Andy Grunwald (00:06:58 - 00:07:17)

Ja genau, fangen wir mal vorne an. Also die normalen Joblevels sind eigentlich Junior-Engineer, das sind so die Einsteiger, die kommen gerade entweder aus der Uni oder aus der Ausbildung oder Quereinsteiger. Dann die Mid-Level, nach ein paar Jahren Erfahrung, wenn man dann schon irgendwie die ersten paar Projekte mitgemacht hat und dann Senior. Das ist so die drei Level, die der europäische und deutsche Markt immer kennt.

Wolfi Gassler (00:07:18 - 00:07:29)

Wobei man ja dazusagen muss, dass Mid-Level eigentlich auch erst kürzlich so entstanden ist. Früher hat's ja eigentlich auch nur so Junior, Senior gegeben. Und dieses Mid-Level ist irgendwo dazugekommen in den letzten Jahren.

Andy Grunwald (00:07:29 - 00:08:01)

Ja, hat sich aber mehr so eingeschlichen. Ich hab das Gefühl, mit den neuen Leveln, also das bedeutet Senior, Staff, Senior, Staff, Principal oder Distinguished und dann in manchen Firmen sogar Fellow, die kommen schon mit so einer Art Big Bang und schleichen sich nicht so ein wie den Mid-Level-Ingenieur. Naja, auf jeden Fall, die Level von Staff und Senior-Staff und allem drum und dran wurden prinzipiell eingeführt, weil die Leute, die das Senior-Level erreicht haben, die waren eigentlich am Ende der Karriereleiter. Und danach hieß es...

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

Werde Manager.

Andy Grunwald (00:08:02 - 00:09:07)

Werde Manager. Du wirst jetzt Engineering-Manager. Und so wird's sehr wahrscheinlich auch vielen von euch gehen. Viele von euch sind sehr wahrscheinlich, die schon ein bisschen länger im Beruf sind, genau diesen Weg gegangen. Sie waren Software-Entwicklerinnen, Sagen okay, wie geht's denn jetzt weiter? Ich bin jetzt Senior, hm, meine Karriereleiter ist irgendwie zu Ende, ich muss jetzt Manager werden. Und dann haben wir alle festgestellt, uh, das ist ja ein ganz anderer Job. Das ist ja gar nicht mehr entwickeln. Und da die IT in den letzten paar Jahren immer wichtiger wurde, immer größer wurde, immer mehr Leute in den Markt geströmt sind, wurde natürlich auch der Bedarf größer einer weiteren Karriereleiter. Also wie steigt man also nach Senior Engineer, Senior Entwickler auf? Da wurden dann, man kann auch böse sagen, künstlich ein paar Level draufgesetzt, wie gesagt Senior, Senior Staff und so weiter, um einfach einen Karrierepfad zu unterbreiten und diesen Menschen natürlich auch irgendwie die Weiterentwicklung zu ermöglichen. Es ist aber nicht so, als wurde da oben einfach nur etwas draufgesetzt und man entwickelt sich mit betriebszugehörigkeit in jahren einfach nur klettert man die leite hoch es ist schon so dass mit diesen levels eine ganz andere art von anforderungen.

Wolfi Gassler (00:09:07 - 00:09:20)

Ankommen das heißt in der in der vergangenheit waren also durchaus senior leute auf dem staff level aber das hat es halt nicht gegeben und daher waren es einfach seniors die haben aber dann die tätigkeiten von staff mit erledigt oder es kann auch immer noch so sein in.

Andy Grunwald (00:09:20 - 00:10:30)

Vielen firmen Kann so sein, muss aber nicht, weil da müssen wir mal ganz kurz gucken, wie sieht denn eine IT-Abteilung, eine Entwicklungsabteilung aus Firmensicht aus. Im guten alten deutschen Mittelstand ist nämlich die IT und auch die Entwicklungsabteilung ein ordentliches Cost-Center. Das bedeutet, die kriegen irgendwelche Anforderungen und treiben in der Regel nicht die Innovation von dem Unternehmen. hat sich natürlich in den letzten Jahrzehnten ein bisschen geändert, wo die IT kein Cost-Center ist, sondern wo die IT wirklich ein Innovationstreiber ist, wo die IT der Kern des Produktes für die Firma ist und nicht die Maschine und CNC-Fräse in der Halle. Und wenn wir uns eine solche Firma mal vorstellen, dann kommen da ganz andere Anforderungen auf einen zu, als nur Schreibt mal bitte diesen Code und macht mal dieses Feature. Auf einmal kommt es dann nämlich hin zu Mentoring, zu Alignment über Business Abteilungen, auch ordentlich Kommunikation oder vielleicht einfach mal ordentlich mit dem Manager arbeiten, um eine Entwicklungs- und Softwareentwicklungsstrategie aufzubauen. Jetzt ist meine Frage, in deinem klassischen ursprünglichen Verständnis von einem Senior Engineer, würdest du sagen, das sind alles Attribute, die ein Senior Engineer immer abgedeckt hat?

Wolfi Gassler (00:10:30 - 00:11:00)

In meinem alten Verständnis, wo es nur Senior gegeben hat, war das eigentlich der große Unterschied zu einem Junior zum Beispiel. Ein Senior, der einfach auch nach außen geht, das Ganze auf einer anderen Ebene sieht und auch das Team weiterbringt. Aber du hast natürlich schon recht, ich glaube ganz allgemein, dass die IT-Teams jetzt viel erwachsener werden in letzter Zeit und vielleicht auch aus ihrem Pizza-essenden Nerd-Image da im Keller irgendwie rauskommen und eben, wie du richtig sagst, zu einem starken Team werden, die auch Innovation liefern.

Andy Grunwald (00:11:00 - 00:11:58)

Man muss ja auch ganz einfach sagen, dass die IT und die Systeme, die wir alle betreuen, ja umweltenkomplexer geworden sind. Wo man früher eine einfache Webseite hatte und dann war man Internet-first, mit PHP, vielleicht auch WordPress, Hast du heute irgendwie ein komplexes Content-Management-System sofort angebunden als ERP-System. Hinten noch ein E-Commerce-Shop, der ist an die komplette Warenwirtschaft mit allem drum und dran. Und dann kriegt der Vertriebs- oder der Ausnehmensmitarbeiter noch eine Nachricht auf seinem iPad und dann wird das alles aus dem CMS mit Cross-Publishing gesüngt und was weiß der Geier nicht, was da noch hinter steckt. Und ich rede noch gar nicht von Microservices und Co. Und meine Frage ist eigentlich, wer schaut denn da mit dem Wissen der Fachdomäne denn mal drauf? Ist das denn immer nur der Senior? Weiß ich jetzt nicht, weil viele Seniors haben auch einfach nur das Interesse, einfach nur dort zu sitzen und schönen, sauberen, testbaren Code zu schreiben, was auch völlig in Ordnung ist. Nur das ist halt unter anderem einer der Unterschiede.

Wolfi Gassler (00:11:59 - 00:12:19)

Und ist das Ganze, wenn es jetzt von Amerika so rüberschwappt, war Amerika da einfach viel früher dran? Haben die eine andere Kultur? Übernehmen wir jetzt einfach ihre Kultur oder sind die einfach früher draufgekommen, dass es irgendwie stärkere IT braucht oder auch Entwicklung produktgetriebener, dass das Ganze wichtiger ist, das Digitale in Firmen?

Andy Grunwald (00:12:19 - 00:12:44)

Also die Antwort ist ja und nein. Es gibt sehr viele amerikanische Firmen, die hatten von Anfang an sehr viele Level. Google, Microsoft, Uber und so weiter und so fort. Und ja, man muss auch sagen, diese ganze Innovationskraft kommt sehr wahrscheinlich sehr viel aus dem Silicon Valley. Es gibt aber auch andere Beispiele, wie zum Beispiel Netflix. Netflix hatte bis vor kurzem immer nur ein Level und zwar Senior Engineer, weil die wollten immer die Besten von den Besten hirnen und deren Credo war immer, one level across all of engineering.

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

Also die haben nur Seniors in der gesamten Firma.

Andy Grunwald (00:12:48 - 00:12:51)

Dort wurde jeder gleichgestellt, die hatten nur Seniors.

Wolfi Gassler (00:12:51 - 00:12:56)

Das war so ähnlich wie bei uns bei Trivago damals. Bei Trivago hatten wir auch keine Titel, da war jeder nichts.

Andy Grunwald (00:12:56 - 00:13:49)

Ist eigentlich vergleichbar. Jetzt ist es aber so, Anfang des Jahres hat Netflix das Ganze geändert. Und jetzt kann man sich die Frage stellen, okay, warum sollte ein Unternehmen, neue Level einführen, was in den letzten 25 Jahren ohne sie ausgekommen ist und auf fast 2.000 Software-Developer angewachsen ist. Warum brauchen die jetzt Junior-, Middle-Level- oder Staff- oder Principal? Und ja, ihr habt richtig gehört. Netflix ist 25 Jahre alt. Netflix wurde 1997 gegründet, damals noch mit DVD-Verleih. Der weise Wolfgang erinnert sich. Und soviel ich weiß, waren die der größte Konkurrenz vom amerikanischen Geschäft Blockbuster. Das war so das amerikanische Penedat, vorher das deutsche Videoland. Also ich bin auch immer früher noch zum Videoland gegangen. Und Achtung, die hatten nicht nur Videos, sondern irgendwann auch DVDs und Playstation 1 oder Playstation 2 Spiele. Ich bin immer ausgeliehen. Wahnsinn. Ich durfte aber nie in den Raum für 18 Jahre, weil da war ich noch keine 18.

Wolfi Gassler (00:13:49 - 00:13:57)

Der Unterschied ist eben, ich wollte gerade sagen, dieser 18 Jahre Raum von Porn, den gibt es bei Netflix nicht, interessanterweise, aber ist ein anderes Thema. Okay, kommen wir zurück zu Seniors.

Andy Grunwald (00:13:58 - 00:15:26)

Die Frage ist, warum haben sie es gemacht? Und zwar hatten sie eigentlich drei Herausforderungen. Eine Herausforderung war, sie konnten neuen Software-Engineers keinen Karrierepfad bieten, weil sie konnten kaum Leute von Stanford und Co einstellen, weil die halt sofort natürlich ins Senior-Level eingestiegen sind. Und wenn man jetzt aber Leute ein bisschen selbst ausbilden möchte und so weiter, dann fängt man halt in der Regel damit an, Juniors einzustellen. Die zweite Herausforderung war, Netflix attraktiv zu machen für andere Top-Talente von anderen Silicon Valley Firmen. Jetzt stell dir mal vor, du bist irgendwie Principal oder Staff Engineer bei Google. Warum solltest du denn jetzt nach Netflix wechseln? Klar, gehaltstechnisch schon. Vielleicht ist das ein Unterschied. Vielleicht kriegst du bei Netflix mehr Geld. Auf deinem Lebenslauf sieht dies aber aus wie ein Downleveling, weil Karrierepfade, das müsst ihr euch bitte auch in Erinnerung rufen, gehen nicht immer nur in eine Richtung, es geht auch in die andere Richtung. Das bedeutet, ihr seid jetzt Senior Staff bei einer Firma, wechselt den Job und die Anforderungen an einen Senior Staff sind höher bei der neuen Firma, dann kann es sein, dass ihr in der neuen Firma nur noch Staff Engineer seid oder vielleicht sogar nur noch Senior Engineer. Sowas nennt man Downleveling. Für ziemlich viele Leute sieht sowas auf dem Lebenslauf ziemlich doof aus, wenn man sich das aber einmal ganz kurz durchdenkt. Ich hatte am Anfang gesagt, die Anforderungen an die Joblevel sind nicht gleich. Es gibt keine Industrienorm. Deswegen ist das in der Regel auch nichts Schlimmes.

Wolfi Gassler (00:15:26 - 00:15:32)

Aber das heißt auch Netflix hat sich da von außen sehr stark treiben lassen vom Markt und ist einfach gezwungen worden eigentlich da umzusteigen.

Andy Grunwald (00:15:32 - 00:16:03)

Ja, und da kommen wir nämlich direkt zum dritten Punkt. Der Haupttreiber der ganzen Sache waren Kosten, weil das Problem war einfach, wenn du jemanden neu eingestellt hast, musstest du ihn sofort auf Senior-Level bezahlen. Natürlich gab es Unterschiede, ja. Es gibt Leute, die sind Koryphäen in ihrem Bereich, die werden dann sehr wahrscheinlich ihre 400.000, 500.000 verdienen. Und wenn ich da jetzt ankomme, dann werde ich keine 400.000, 500.000 verdienen. Dennoch würde ich sofort mehr verdienen als, wenn wir Junior Levels hätten.

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

Das heißt, sie wollten auch einfach billige Arbeitskräfte sich holen, direkt von der Uni zum Beispiel und die selber auch ausbilden. Das hat natürlich auch einen großen Einfluss auf die Diversity, wenn wir da wieder sind, weil wenn du natürlich nur Seniors hast und irgendwelche alten Leute in deinem Team, dann fehlt dir dann natürlich der ganze Unterbau, der da von unten nachkommt, auch frische Ideen vielleicht hat, junge Ideen, das fehlt dann natürlich auch alles.

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

Du sagst das jetzt so böse, billige Arbeitskräfte von der Uni. Es ist halt nun mal so... Ja.

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

Du hast gerade mit den Kosten angefangen.

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

Ich habe das Wort billig oder günstig nicht in den Mund genommen. Es ist doch nun mal so, dass...

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

Dann sagen wir kosteneffizient.

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

Kosteneffizient, da würde ich mich drauf einlassen. Es ist ja nun mal so, dass ein Junior-Engineer einfach nicht denselben Output hat oder Outcome wie ein Senior-Engineer. Beide aber mindestens gleich zu bezahlen, ist dann ein bisschen ungleich, würde ich mal so sagen.

Wolfi Gassler (00:16:54 - 00:17:09)

Aber kommen wir mal jetzt wirklich zu den konkreten Unterschieden. Wenn du jetzt sagst Staff plus zu Senior, wo ist denn da jetzt der große Cut, der Unterschied zwischen diesen zwei Levels? Warum hat man Staff eingeführt? Was will man da abgrenzen?

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

Ich hatte vorhin schon gesagt, der Unterschied zwischen Senior- und Staff-Level ist schon enorm. Bis zum Senior-Level, sagt man so in der Industrie, ist es relativ leicht. Mit relativ leicht meine ich, man fängt an, Code zu schreiben, man fängt an, ein paar Tickets zu schreiben, man ist involviert in größeren Projekten, in komplexeren Projekten, man löst komplexere Probleme, debuggt und so weiter. ohne große Hürden relativ schnell bis zum Senior aufsteigen bei, ich nenne es mal gute Craftmanship. Das bedeutet, wenn ich mein Handwerk, meine Programmierung, mit allem drum und dran, Debugging, Monitoring und Co., Debugging, Monitoring, Softwarearchitektur, Testing und was nicht noch alles dazugehört, Teamwork, dann ist es nur eine Frage der Zeit und eine Frage der Erfahrung, bis ich das Senior-Level erreiche. Um die Hürde zum Staff-Engineer zu überbrücken, da kommt dann die ganze die ganze welle was alles unter dem thema leadership unter anderem schwimmt damit so bei das.

Wolfi Gassler (00:18:12 - 00:18:32)

Heißt bis zum senior bleibt man eigentlich in seinem eigenen metier dem eigenen handwerk dem coden und ab staff plus verlässt man diese welt und tritt in andere bereiche ein wo man dann auch dementsprechend lernen muss leistung zeigen muss aber das ist was neues und nicht mehr das klassische programmieren die welt verlassen würde ich.

Andy Grunwald (00:18:32 - 00:19:56)

Nicht sagen es wird bestimmt immer noch phasen geben wo man auch noch mal mit seinem handwerk wirklich eingreifen muss und programmieren muss und das ist ja auch gewollt es ist nur so dass du ganz andere anforderungen hast und natürlich auch viel mehr mit reingezogen wirst In meinem mentalen modell ist ein staff engineer der technische kompanion vom engineering manager engineering manager wenn diese person technisch ist das super verstehe mich nicht falsch doch es ist nun mal so dass eine engineering manager eine engineering managerin dass diese person auch unglaublich viel Teamführung, People-Verantwortung hat und so weiter und so fort. Das bedeutet, ein Engineering-Manager oder eine Engineering-Managerin kann unter Umständen, je nach Komplexität des Projektes und Co., gar nicht mehr die fachliche Expertise an den Tag legen, um das Projekt richtig zu steuern. Und in meinem mentalen Modell ist zum Beispiel unter anderem ein Staff-Engineer dafür da, teilweise die technische Leadership sogar zu geben. Und ich sag mal so, der 1-zu-1-Kompanion vom vom Management zu sein, um das ganze Thema auch domänetechnisch zu leiten. Das muss nicht in jeder Firma so sein, in manchen Firmen ist es aber so aufgebaut. Joblevel sind auch sehr stark an die Kompensation verbunden. Das bedeutet, wie viel Gehalt kriegst du? Kriegst du Firmenanteile? Wenn ja, wie viele? Und so weiter und so fort. Und in der Regel ist das so, dass Staff Engineers auf demselben Kompensationslevel sind wie Engineering Manager.

Wolfi Gassler (00:19:57 - 00:20:08)

Okay, versuchen wir mal ein bisschen konkreter zu werden. Wo würdest du denn jetzt konkret die größten Unterschiede sehen zwischen diesem Senior-Bereich und dem Staff-Plus-Bereich?

Andy Grunwald (00:20:08 - 00:21:15)

Ich könnte hier mein eigenes Modell erfinden und die größten Unterschiede irgendwie selbst definieren. Doch ich habe mal ein Video gesehen von einer Dame namens Tanja Raley, die hat ein Buch geschrieben bei O'Reilly. Das ist jetzt kein Witz, die Dame heißt wirklich so grandios. Und ihr Metallus-Modell finde ich eigentlich sehr schön. Und zwar definiert sie eigentlich drei Bereiche, in dem sich Staff Engineers von Senior Engineers unterscheiden. Das eine ist Big Picture, da geht es um Prioritäten, die Bedürfnisse des Businesses und so Fragen, wo sind wir eigentlich nächstes Jahr oder beziehungsweise wo sollten wir nächstes Jahr sein. Dann geht es um die Execution. Ja, das machen auch Senior Engineers, aber da geht es natürlich nicht nur um die technischen Skills, sondern auch um die menschlichen Skills. Teamzusammenhalt, Kommunikation, Leadership. Und im dritten Bereich, da geht es um Leveling Up, da geht es um Mentoring, das Team vorwärts bringen und Leuten halt einfach auch was beibringen. Das kann man alles natürlich nicht ohne eine gute Basis schaffen, der sogenannten Foundation. Das bedeutet, man braucht halt schon das technische Wissen, um einzuschätzen können, macht das jetzt Sinn, macht das jetzt keinen Sinn.

Wolfi Gassler (00:21:16 - 00:21:42)

Das heißt, man braucht für diese drei Bereiche schon ein technisches Grundverständnis, auch dieses ganze Wissen, was man sich da angesammelt hat. Also das kann jetzt demnach niemand machen, der keinen technischen Background hat und das Ganze versteht, sondern nur der im Prinzip davor auch Senior war oder die Senior war und dann übergeht eine Ebene höher, um das dann auch wirklich zu nutzen, was man sich davor angeeignet hat in den Jahren davor.

Andy Grunwald (00:21:42 - 00:21:57)

Ich habe noch nie jemanden gesehen, der ein Level übersprungen hat. Das bedeutet, der direkt von Mittel-Level auf Staff-Engineer gegangen ist. Und Quereinsteiger auf Staff einzustellen ist auch vielleicht ein bisschen schwierig, weil denen halt die Grundlage, diese jahrelange Erfahrung... Also ich meine, du bist ja auch nicht Senior mit zwei Jahren Berufserfahrung.

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

Und man muss auch in dem Bereich tätig sein oder? Also ich kann jetzt nicht als Psychologe plötzlich Staff Engineer oder sowas werden. Also es ist schon soweit die Technik noch nötig in dem Job.

Andy Grunwald (00:22:09 - 00:22:33)

Also als Psychologe verstehst du sehr wahrscheinlich schon einen guten Teil von dem was ein Staff Engineer verstehen sollte in Bezug auf Teamzusammenhalt, Teamdynamiken, Mentoring und Co. Die fehlt aber ganz einfach das komplette Verständnis, was braucht das Business eigentlich, wie sieht eine IT- oder Entwicklungsstrategie aus und was sind eigentlich die technischen Skills. Also die hat ja ein Psychologe ja jetzt nicht im Bereich Softwareentwicklung.

Wolfi Gassler (00:22:34 - 00:23:02)

Jetzt hat ja so ein Staff-Engineer üblicherweise keine Personalverantwortung. Also im Gegensatz zu einem klassischen Manager oder Engineering-Manager, die ja üblicherweise Personalverantwortung haben und dann auch wirklich in der Hierarchie darüber sind, haben ja die Staff-Engineers meistens keine Personalverantwortung. Wie können die denn jetzt mit dem Team überhaupt zusammenarbeiten, weil die können dem Team jetzt in dem Sinne nichts befehlen oder durch die Hierarchie anleiten oder leiten.

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

Das ist richtig. Personalführung haben Staff Engineers in der Regel nicht beziehungsweise keine Personalverantwortung. Und da kann ich dir mal eine ganz kurze Story erzählen, wie ich zu dem Mysterium, wovon wir jetzt sprechen, gekommen bin. Und zwar, bei Trivago hatte ich eine Leadership-Position, und irgendwann bin ich von dieser Leadership, also ich war Abteilungsleiter, konnte man das jetzt in dem Sinne nennen. Und irgendwann nach einem Jahr hab ich gedacht, hey, ich bin so weit weg von den technischen Details, ich lieb die aber zu sehr. Da hab ich mit meinem damaligen Vorgesetzten gesprochen, und dann gab's die Möglichkeit, dass ich wieder Individual Contributor werde, also zurück an den Code. Und dann haben wir eine Rolle für mich gesucht, weil ich halt auch ziemlich viel Teammanagement-Erfahrung hatte und Co.

Wolfi Gassler (00:23:43 - 00:23:44)

Und keiner wollte dich, oder?

Andy Grunwald (00:23:44 - 00:24:15)

Ich bin schon gut untergekommen und dann auch als Individual Contributor wieder ohne Personalführung. Aber durch meine vorherige Erfahrung wurden mir halt ein paar Aufgaben gegeben, die schon, ja, ich würde fast sagen, einem Staff-Engineer gleich kommen würden. Da ging es dann um Cross-Team-Projekte und auch ein paar Initiativen in der Firma weitertreiben, die zur Engineering-Kultur ein bisschen was beisteuern. Und da kam er zu mir und sagt Andi du musst jetzt leading by influence ausführen not by authority.

Wolfi Gassler (00:24:15 - 00:24:24)

Hast du dir wieder nicht ausgekannt weil du dein ganzes Leben nur Befehle gegeben hast den ganzen Teammitgliedern und jetzt kommt er plötzlich an du sollst Befehle geben ohne Autorität zu haben.

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

Ich war ja noch nie so einer gesagt hast du machst das du machst das du machst das sondern, Natürlich in meinen vorherigen rollen war ich engineering manager wenn ich gesagt habe okay dann lass uns das doch mal tun dann hatte mein lass uns das doch mal tun natürlich ein anderes gewicht weil ich der vorgesetzte war, aber jetzt war es halt nicht so ich hatte keine personalführung mehr und ich sollte leading by influence durchführen und das ist einer dieser mysterien, bei engineering und jeder muss dann irgendwie herausfinden okay wie leite ich denn leute einfach nur bei influence und ich rede jetzt hier nicht von influencer auf instagram obwohl es natürlich schon so ein bisschen ähnlich ist generell geht es halt darum Andere Leute von etwas zu überzeugen, ohne ihnen direkte Befehle zu geben. Und das bedeutet natürlich auch, man muss über Themen sprechen, bis die Leute natürlich den Sinn in diesem Thema verstehen, den Kontext haben, die Gründe verstehen, warum wir das denn machen und warum das Ganze denn wichtig ist. Oder auch, warum das Ganze nicht nur fürs Team oder für die Applikationen, sondern auch für die Firma wichtig ist. Man könnte es schon irgendwie so ein bisschen Marketing nennen und so weiter ich darüber spreche, denke ich mir, Leading by Influence ist vielleicht der lokale Instagram-Influencer in der Firma. Ein bisschen böse ausgedrückt, aber eigentlich kann man das so nennen. Mit dem großen Unterschied, dass Influencer auf Instagram wenig zuhören, was man natürlich als Dev-Engineer dann umso mehr machen sollte, weil es ist natürlich auch wichtig zu verstehen, wo sind denn die technischen Probleme. Welche Probleme sieht denn die Person, die man gerade versucht zu überzeugen? Warum ist denn ein Projekt verzögert? Oder welche Needs hat denn eigentlich ein Team? Wer braucht Coaching, Mentoring, mehr Wissen? Oder fehlt vielleicht nicht einfach generell Domänenverständnis von der Applikation?

Wolfi Gassler (00:26:06 - 00:26:43)

Okay, also ich sehe schon, du hast es wieder geschafft, ein Job-Profil absolut unattraktiv zu machen, weil du das jetzt nicht mehr Staff-Engineer nennst, sondern nur mehr Marketing-Engineer. Der macht sowieso nur Marketing. Aber trifft wahrscheinlich durchaus zu. Der andere Punkt, den du erwähnt hast, ist dieses große Ganze zu verstehen, dieses berühmte Bigger Picture. Was bedeutet denn das? Und wir haben ja letztes Mal in der Senior-Episode auch eigentlich erwähnt, der Senior soll das Big Picture im Auge haben und verstehen, wie das Team arbeitet, wo man gerade steht, wo man hin will und diese ganzen Dinge. Also, was macht jetzt der Staff-Engineer oder Staff-Level ganz allgemein, wenn es um das Bigger Picture geht?

Andy Grunwald (00:26:43 - 00:27:04)

Im Rahmen von Big Picture geht es natürlich erstmal primär um Priorisierung. Da geht es nicht nur darum, Code zu schreiben, beziehungsweise anderen zu helfen, Code zu schreiben, sondern auch sich die Frage zu stellen, schreibe ich denn hier gerade den richtigen Code für das wichtigste Problem oder löst das Team denn gerade das wichtigste Problem, was nicht nur die Applikation und das Team weiterbringt, sondern auch die ganze Firma.

Wolfi Gassler (00:27:04 - 00:27:10)

Und wie findet man jetzt heraus, was das wichtigste Problem für die Firma ist? Also woher weiß das der Staff?

Andy Grunwald (00:27:10 - 00:28:06)

Da kommt ja gerade das Verständnis von Business Need zu Trage. Womit verdient die Firma Geld? Was ist die größte Herausforderung gerade im Markt? Und was ist wirklich der Haupttreiber für die Firma oder das Hauptproblem? Das heißt natürlich auch Netzwerk stecken zu den Produktmanagern und so weiter und so fort. und nicht nur als Techie in seiner Ecke zu sitzen und sagt, oh ja gut, wenn wir jetzt noch zwei Millisekunden rausholen, dann sind wir zwar alle glücklich, verdienen aber keinen Euro mehr, sondern Big Picture Business Verständnis bedeutet auch, sich mit den richtigen Leuten auszutauschen. Seid ihr in einer Firma angestellt, die Vertriebsvertriebler hat, Außenvertriebler? Sprecht mit denen. Was sind die Probleme wirklich vorne an der Front? Habt ihr Produktmanager und Produktmanagerinnen, Data Scientists, Data Analysten? Quatsch mit denen über die letzten Findings in den Daten. Versucht euch mehrere Inputparameter zu holen, um ein besseres Verständnis von der Firma und von den Needs der Kunden oder euren Partnern zu bekommen.

Wolfi Gassler (00:28:07 - 00:29:44)

Das Ganze klingt für mich schon auch ganz nach Team Lead, was ganz oft Team Leads übernehmen, die eben schauen, wird in die richtige Richtung gearbeitet, arbeitet das Team an den wichtigsten Problemen, auch diese Schnittstelle zu Business herstellen, zum C-Level und auch eben den Business Case besser verstehen und nicht nur auf der technischen Seite operieren, aber auch eben das Team in einer gewissen Weise koordinieren. Ich habe das auch ganz interessant gefunden, was die Tanya Rayleigh da in ihrem Buch schreibt, dass man zum Beispiel auch beachten muss, wer denn was im Team übernimmt. Sie hat da so ein Modell aufgestellt, dass man da fünf Punkte beachten muss. Einerseits die Energie einer Person, den Wachstum, Skills, Growth einer Person, also die Weiterbildung, Social Capital in der Firma, wie wichtig ist dieses Projekt, wird die Person dann besser angesehen, Credibility auch, Und eben Quality of Life, also die ganze private Komponente. Und man muss dann Tasks und Projekte so auswählen, dass das eben im Team für die richtige Person passt. Man kann es nicht immer alles erfüllen, dass alle fünf Punkte perfekt sind, dass man keinen Stress hat, dass die Energie möglichst drauf geht. Trotzdem, dass das aber ein ganz wichtiges Projekt ist. Das sind natürlich Sachen, die selten miteinander einhergehen, weil wenn ihr ganz ein wichtiges Projekt vom C-Level habt, dann wird es stressig werden und dann wird da die Energie eher nach unten gehen. Aber man muss halt versuchen über Dauer diese fünf Punkte abzuwägen und möglichst gut die Projekte auch zuteilen. Und meiner Meinung nach hat das früher ganz oft der Team Lead gemacht, Aber das ist auch ganz klar Staff plus Aufgabe, obwohl man keine Personalverantwortung hat.

Andy Grunwald (00:29:44 - 00:30:20)

Das heißt ja auch nicht, dass der Team das nicht mehr machen kann oder muss. Es bedeutet halt nur, dass man jetzt auch einen Kompanion hat, der in Zeiten, wo es notwendig ist, da einfach nur unterstützt auch. Im zweiten Punkt des mentalen Modells geht es um Execution. Da muss man halt ganz einfach sagen, die Projekte, wo Staff Engineers involviert sind, sind halt wirklich komplexer. Meistens nicht technisch, sondern eher, dass der Scope größer ist, mehrere Teams involviert, mehrere Firmen vielleicht sogar. Oder das Problem ist vielleicht noch gar nicht so kristallklar, dass man da jetzt wirklich 300 Tickets draus erstellen kann und dem Team einfach hinschmeißen kann.

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

Die Tanya Raley beschreibt das ganz nett, dass eigentlich die ganzen beschissenen Projekte die Stars bekommen, weil das sind die, wo alter Code mit dabei ist, die wirklich schwer zu verstehen sind, die nicht klar sind. Also alles das, was man im Junio nie geben würde, der irgendwie from scratch von der grünen Wiese ganz nett wegstarten kann, sondern halt die wirklich schwierigen Projekte, die sind für die Staff-Levels dann eher geeignet oder Dafür bezahlt man die Leute ja auch und darum brauchen sie auch diese Erfahrung, damit sie die halt wirklich reinnehmen können und dann dieses Projekt auf ein Level bringen oder aufspalten können, dass sie es eben auch dann Juniors weiter im Detail bearbeiten können.

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

Wo der Junior- und Mid-Level-Engineer oft sagt, boah ne, ich möchte mit dem Code nicht arbeiten, der ist so Legacy, der hat gar nicht die neuesten Standards drin, sagt dann der Staff-Engineer.

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

Ja, gut.

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

Legacy verdient halt das Geld, wa?

Wolfi Gassler (00:31:06 - 00:31:15)

Ja, das ist ja dein Lieblingsthema. Du hast ja auch immer auf Legacy gestürzt und hast immer hinten nach aufgeräumt. Andi war ja die Aufräummaschine bei Trivago.

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

Die Tage in einem anderen Podcast im Super-Duper-Developer-Club vom Nils, Grüße gehen raus, habe ich gehört, dass moderner Code in der Regel nur maximal drei Jahre hält, weil sich dann die Requirements wieder ändern oder wieder ein neues Framework um die Ecke kommt und dann eh alles umgeschrieben wird. Da hab ich mir so gedacht, hey, da bin ich doch mit meinem Mantra, Legacy verdient dat Geld und schneller Hack ist eh besser, doch viel besser dran, oder? Ich muss mir gar nicht so die Mühe geben, um superklar testbaren Test-Driven-Development- und-what-not-Code zu schreiben. Und Clean-Code und was weiß ich, was.

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

Es hier alles gibt.

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

Ganz im Ernst, ein guter Hack hält ja eh maximal drei Jahre. Sondern wird ja eh alles neu geschrieben. Also, Legacy verdient dat Geld.

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

Ich würde eher bezweifeln, dass das maximal drei Jahre sind. Also ich glaube, ich habe schon Hacks gesehen, die wesentlich länger irgendwo gelaufen sind als drei Jahre.

Andy Grunwald (00:32:04 - 00:32:22)

Vielleicht ist das aber auch gerade der Unterschied. Vielleicht, wenn man sagt, okay, ich schreibe jetzt enorm guten Code, man ist wirklich stolz, dann hält das drei Jahre, weil sich die Requirements ändern. Und wenn man sagt, ganz im Ernst, der hält ja eh nur drei Jahre, implementiert er die dreckigsten Hacks, dann überlebt er eh zehn Jahre. Vielleicht ist das halt immer so eine Sache.

Wolfi Gassler (00:32:23 - 00:32:34)

Das kann natürlich gut sein, ja. Okay, kommen wir zum dritten Punkt von diesem mentalen Modell, dieses Leveling up. Was ist da die Aufgabe vom Staff Level oder Engineer?

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

In vielen Filmen wird das auch ein bisschen gleichgesetzt mit dem vom Engineering Manager. Da geht es aber wirklich darum, die Engineering Kultur nach vorne zu treiben, erfahren zu sein, wie man eigentlich mit Konflikten umgeht, Probleme löst, interpersonelle Konflikte natürlich auch. Und vielleicht nicht in schwierigen Situationen auf, oh, das Team da drüben hat immer alles scheiße gemacht, zu zeigen, sondern einfach zu sagen, hey Jungs und Mädels, wir sitzen alle irgendwie im selben Boot, schön, dass das andere Team es da verkackt hat, hilft uns aber hier gar nicht weiter. Was können wir denn jetzt tun, um aus der Situation rauszukommen? Also, es geht nicht darum, andere zu blamen, es geht darum, objektiv zu bleiben, lösungsorientiert zu arbeiten, und nicht in so einem Tratsch und Klatsch wie bei der Bunte zu fallen.

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

Aber das ist ja jetzt nicht unbedingt, dass ich dann Leveling abbetreibe, oder? Das ist ja, ich bin ja dann nur nett.

Andy Grunwald (00:33:22 - 00:34:24)

Ja, nett und freundlich kann man natürlich auch sein, aber primär ist man natürlich ein Role Model in der Hinsicht, ja. Man arbeitet dann oft mit Leuten zusammen, die dann Junior, Mid-Level oder Senior sind und die schauen dann natürlich zu einem auf. Man muss aber auch sagen, nett sein kostet nicht so viel Energie, wie wirklich objektiv lösungsorientiert zu arbeiten und dem Team helfen, aus Situationen wieder rauszukommen. Es hat natürlich auch sehr viel mit Zuhören zu tun, zu verstehen, wie sehen die Teammitglieder denn die Probleme, warum ist das Projekt denn verzögert oder welche Needs hat das Team, wer braucht Coaching, wer braucht Mentoring, wer braucht ein Upskill, Das klingt jetzt alles so einfach, wenn wir darüber sprechen, es kostet aber enorm viel Energie und meines Erachtens nach macht das den Riesenunterschied zwischen erfahrenen Staff Engineers, die sich immer wieder auf diesen Track zurückziehen und versuchen das ganze Team nach vorne zu bringen und nicht in dieses Tratsch und Klatsch wie in der Bunte zu fallen gegenüber Leuten, die zu diesem Level aufsteigen wollen.

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

Ich glaube, das ist auch ganz wichtig, dass man sich das immer wieder in Erinnerung ruft, dass man da ein Role Model ist. Und ich kenne es auch aus dem ganzen Engineering Manager Bereich. Du sitzt am Abend mit einem Bier zusammen und fangst dann über irgendwen ranten an oder so. Das geht einfach nicht. Du musst auch am Abend bei einem Bier das Role Model sein. Du musst da klar sein, auch in einer größeren Runde, du darfst da nicht mit ranten. Ich glaube, das ist ganz, ganz wichtig. Und das macht am Ende die, Kultur aus. Und man kann jetzt sagen, okay, ich will gar kein Role Model sein, aber dann ist halt vielleicht die Position auch das Falsche. Also wenn man in so einer Position ist, dann ist man ein Role Model und alle schauen auf und auch egal wann, am Abend bei einem Bier, muss man, wie du richtig sagst, einfach möglichst neutral bleiben und das halt nüchtern sehen, subjektiv, falsch, objektiv, muss man das objektiv sehen natürlich und darf da auf keinen Fall in irgendeinen Rant-Mode verfallen. Das ist meiner Meinung nach eines der wichtigsten Punkte, wenn es wirklich um Role Model geht.

Andy Grunwald (00:35:19 - 00:35:38)

Und das ganze ist natürlich umso schwieriger, je mehr die Firma ein Familienleben lebt. Oft sieht man ja, we are all family und allem drum und dran. Oder wenn man wirklich starke Freundschaften im Job aufbaut und so weiter, dann fällt das natürlich unglaublich schwierig. Punkt ist, das ist aber der große Unterschied.

Wolfi Gassler (00:35:39 - 00:36:40)

Und ich möchte auch gar nicht sagen, dass man dann keine Fehler oder sowas machen kann. Das passiert jedem, aber da muss man halt auch dazu stehen. Also Role Model heißt nicht, man darf keine Fehler machen. Ich kann mich da zurückerinnern, das war ein Erlebnis, was ich nie vergessen werde. Das war noch zu Uni-Zeiten, wo ich mit einem Kollegen aus einem anderen Institut zusammengearbeitet habe. Und der hat einen Fehler gemacht. Und wir haben das besprochen in einer Vorlesung. Und er hat gemeint, wir geben den Fehler nicht zu. Die Studenten dürfen nicht sehen, dass wir Fehler machen. Ihr habt das gar nicht verstanden, was er meint zuerst. Warum kann man keine Fehler zugeben? Aber der war so auf diesem Trip, man darf keine Fehler zugeben. Und die Studenten müssen glauben, wir sind gut als Lehrende, die machen keine Fehler. Und ich glaube, das geht einfach komplett in die falsche Richtung. Also auch Fehler zugeben, ist komplett in Ordnung, auch wenn man ein Role Model ist, weil genau das macht dann am Ende die gute Team Culture und die Culture in der Company aus, wenn man mit Fehlern offen umgeht, aber natürlich eben nicht rantet oder in dieses Muster eben von Ranting verfeilt.

Andy Grunwald (00:36:41 - 00:37:12)

Man merkt schon, die Rolle des Devs ist weit mehr als Coden, Coden, Coden. Gegebenenfalls ist sie auch nicht für alle. In der Industrie sagt man eigentlich, dass jeder das Senior-Level anstreben sollte und bei vielen Firmen ist es auch völlig in Ordnung, wenn man 30, 35 Jahre auf dem Senior-Level bleibt. Ab dem Senior-Level gibt es in der Regel keine große Erwartung mehr, dass man an das Staff-Level herankommt. Wenn man sich aber dafür entscheidet, dann kommt natürlich ein ganzer Haufen neue Anforderungen mit und ein paar haben wir davon erwähnt.

Wolfi Gassler (00:37:12 - 00:37:31)

Jetzt, wenn man sich diese Bereiche so anschaut, und ich habe es ja schon erwähnt, viel erinnert mich da auch an einen Team Lead und an einen Engineering Manager. Wo siehst du denn jetzt die großen Unterschiede zu einem Engineering Manager, also zwischen Staff und Engineering Manager, der oder die dann auch Personalverantwortung hat? Wo siehst du da die großen Unterschiede?

Andy Grunwald (00:37:31 - 00:38:05)

Also wenn wir von Personalverantwortung reden, reden wir in der Regel natürlich von disziplinarischer Verantwortung. Und dazu zählt natürlich sowas wie Performancemanagement, aber auch die nicht so freundlichen Sachen wie Abmahnung und Entlassungen, Gehälter, Headcountplanning, das bedeutet, wie viele Leute plane ich über das nächste Jahr einzustellen oder halt auch nicht. Recruiting, das bedeutet entscheiden, wen man einstellt oder auch nicht. Aber natürlich auch Strategien entwickeln, team reviews und mit seinem vorgesetzten und mit seinen direkten peers auch darüber zu sprechen was die abteilung denn erreichen möchte und wobei.

Wolfi Gassler (00:38:05 - 00:39:07)

Man natürlich schon sagen muss dass die staff engineers da normalerweise immer in irgendeiner form mit eingebunden sind oder auch andere leute im team ganz allgemeines team also klar bei beim hiring oder recruiting entscheidet der Engineering-Manager wahrscheinlich, wer am Ende eingestellt wird, der oder die hat das letzte Wort. Aber das Team ist natürlich in Interviews dabei und kann sich da auch einbringen. Und ich glaube, auch bei Staff-Level ist man dann schon so weit, dass man auch sich nicht nur einbringt, wenn man gefragt wird, sondern dass man dann halt auch pusht und wirklich auch den Engineering-Manager pusht und vielleicht Sachen vorschlägt oder wirklich aktiv probiert mitzuwirken in dem Bereich vom Engineering-Manager oder wenn es irgendwo Probleme gibt, da auch wirklich Druck aufzubauen, wenn der Engineering Manager dafür verantwortlich ist oder andere Business Stakeholder oder wer auch immer in der Firma, dass man da so aktiv auch nach außen geht, auch wenn das vielleicht nicht direkt der eigene Einflussbereich ist, den man hat und die Aufgabe ist, aber die Kommunikation mit den anderen und Themen weiterzubringen, ist definitiv die Aufgabe von einem Staff Engineer.

Andy Grunwald (00:39:07 - 00:39:43)

Ich hatte am Anfang gesagt, Disclaimer, die Definition von diesen Leveln, da gibt es keinen Industriestandard. Und das ist auch sehr schön zu sehen, zum Beispiel bei zwei Leveling Guides, einmal von CircleCI, einer Continuous Integration Firma, und einmal bei Dropbox. Dort haben wir zum Beispiel unterschiedliche Verständnisse von dem Scope eines Dev-Engineers. Wo CircleCI sagt, okay, dein Scope, dein Bereich, in dem der Dev-Engineer eigentlich den Influence hat, ist innerhalb eines Teams, und er ist der Senior Dev-Engineer, dort ist die Erwartung gesteckt, dass der Scope über mehrere Teams hinweg sein soll.

Wolfi Gassler (00:39:43 - 00:40:08)

Wobei man dazu sagen muss, das sind technische Teams gemeint. Also der Staff Engineer bei CircleCI hat schon Kommunikation nach außen, muss mit dem Business zusammenarbeiten, mit den Stakeholders, das schon, aber nicht direkt dann mit anderen technischen Teams, dass das über technische Teams hinweg dann irgendwelche Projekte oder ähnliche sind. Das wäre dann der Senior Staff bei CircleCI. Hingegen bei Dropbox zum Beispiel ist das anders.

Andy Grunwald (00:40:09 - 00:40:19)

Bei Dropbox wird einfach ganz klar gesagt, okay, der Staff Engineer, der hat direkt die Anforderungen, seinen Scope, zum Beispiel Leading by Influence über mehrere Teams hinweg.

Wolfi Gassler (00:40:20 - 00:41:47)

Also da sieht man schon, dass sich das durchaus unterscheidet und wer sich die Dokumente mal anschaut unten in den Shownotes, für alle HörerInnen übrigens, die das nicht wissen, was Shownotes sind, ihr könnt da normalerweise unten etwas aufmachen, weil wir haben das Feedback bekommen, manche wissen nicht mal, was Shownotes sind. Also diese Beschreibung, die geht unten dann noch weiter und da findet ihr ganz viele Links, also bitte da auch immer mal reinschauen. Und wenn man sich diese zwei ansieht, dann ist das alles super genau definiert. Also das sind wirklich Vorzeigeguides natürlich, die das auf ganz vielen Ebenen ganz spezifisch dokumentieren und da fast wie eine Richtlinie das aufbauen. Aber man muss auch sagen, das macht nicht jede Firma so. Ganz klar, es machen auch ganz große Tech-Firmen nicht so. Ich habe gerade gestern noch mit einer Kollegin gesprochen in einer sehr, sehr großen Tech-Firma mit tausenden Mitarbeitern. Die haben gar keine Spezifikation zum Beispiel von sowas, obwohl sie es darf haben. Also auch da ist es nicht in jeder Firma so, also nicht abschrecken lassen von diesen extremen Guides und genauen Definitionen, es muss nicht immer so sein. Aber was man durchaus bei diesen Definitionen sieht, das ist eben vor allem in den anderen Bereichen, wie die wir erwähnt haben, diese Bigger Picture Execution Leveling Up, da sind sie eigentlich auf der gleichen Seite, die zwei Guides, weil die beide dort den Schwerpunkt von Staff sehen. Natürlich ist der Scope leicht anders definiert oder andere Schwerpunkte, aber im Großen und Ganzen diese drei Bereiche Leveling Up, Execution und Bigger Picture, da sind sie sich auf jeden Fall einig.

Andy Grunwald (00:41:47 - 00:42:54)

Wenn ihr euch in diesem Podcast bisher wiedergefunden habt und sagt, hey, eigentlich mache ich doch genau das, was ihr beschrieben habt, aber ich heiße jetzt gar nicht Staff Engineer. Vielleicht gibt es in eurer Firma sowas gar nicht, vielleicht gibt es auch gar keinen Leveling Guide oder was sind die Anforderungen? Quatscht auf jeden Fall mit eurem Vorgesetzten und fragt sie oder ihn, was sind eigentlich die Erwartungen, die an euch gesteckt werden? Was ist mein Job? Was soll ich machen? Was würde in meinem Jobprofil stehen? Und schreibt das mal bitte auf, weil auch wenn ihr Titel habt in der Firma und kein Leveling Guide, dann wird es relativ schwierig, wenn ihr gar nicht so wisst, ob ihr den aktuellen Erwartungen gerecht werdet. Wie soll das dann eigentlich bei den nächsten Performance Reviews sehen? Oder ihr denkt, ihr lauft in die richtige Richtung, macht einen Drupal-Job und deine Vorgesetztin sagt, hör mal, irgendwie erfüllst du die Erwartungen nicht. Nächste Frage wäre dann, was für Erwartungen? Werdet euch da mal im Klaren. Und vielleicht ist das auch mal ein Gespräch, was ihr Anfang des neuen Jahres mit eurer Vorgesetzten anfangen solltet. Die Zeit ist ungefähr so die beste Zeit, das mal zu starten, weil dann kann man nämlich das ganze neue Jahr planen. Der Vorgesetzte kann natürlich dann so Sachen einfließen lassen wie, hey, Wie kann ich dich eigentlich weiterentwickeln?

Wolfi Gassler (00:42:54 - 00:43:27)

Sollte sogar, würde ich sogar sagen. Das ist ein ganz wichtiges Element, weil dein Vorgesetzter oder deine Vorgesetzte sollte sich ja auch um das Leveling-up von dir kümmern. Aber ganz wichtig, versuch das immer schriftlich zu machen, weil dann kann man das einfach auch zum Review wieder der anderen Person geben, kann ein paar Mal Ping-Pong machen und das gemeinsam erstellen. Und wahrscheinlich haben die Firmen wie CircleCI und Dropbox genauso angefangen, und haben das dann einfach immer weiterentwickelt. Und das hilft dann vielleicht dem ganzen Team oder auch anderen Personen in der Firma auf jeden Fall weiter.

Andy Grunwald (00:43:27 - 00:44:29)

Und der Wolfgang hat das nur mal ganz kurz im Sebensatz erwähnt. Verschriftlichen. Ich meine das wirklich ernst. Das ist mein Pro-Tipp für euch. Das habe ich nämlich auch gemacht. Und zwar habe ich meinen Vorgesetzten mal vor ein paar Jahren gefragt, was sind eigentlich die Erwartungen, die an mich gesteckt wurden. Dann habe ich das aufgeschrieben und nach dem Meeting kurz zu ihm gesendet. Hey, ist das so richtig? Habe ich das so richtig verstanden? Nach einem halben Jahr oder nach vier Monaten habe ich das wieder in dem WannaOne rausgeholt. Hör mal, pass mal auf, das haben wir vor vier Monaten verschriftlicht. Erfülle ich die Erwartungen? Ist das noch der Fall? Und dann kam die Antwort, wieder kann ich mich gar nicht daran erinnern. Also es ist gar nicht unüblich, dass Vorgesetze, weil die so viel zu tun haben, sich an euer Gespräch gar nicht mehr erinnern konnten. Der Punkt ist aber, ihr habt es ja aufgeschrieben. Ja, ihr habt was verschriftlicht. Ich will nicht sagen, ihr müsst euch alle selbst beschützen, doch ab und zu ist das ganz hilfreich, wenn man etwas Schriftliches hat, worauf man sich beziehen kann, worauf ihr euch geeinigt habt. Am besten sogar noch irgendwie ein Shared-Dokument oder eine E-Mail verschriftlicht, weil die Leute, die in höheren Positionen, die haben einfach sehr viel um die Ohren und so könnt ihr euch auf euer Agreement zurückziehen.

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

Und man glaubt gar nicht, wie oft man aneinander vorbeiredet. Und schriftlich ist teilweise einfach schwarz auf weiß.

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

Und deswegen ist es so wichtig, ihr schreibt das auf, schmeißt das nochmal kurz rüber mit der Frage, haben wir hier das gleiche Verständnis? Weil wenn ihr das nur aufschreibt und die andere Person hat es noch nie gesehen, ist es auch schwierig. Und ganz im Ernst, euer Vorgesetzter und Vorgesetztin wird euch irgendwann auch dafür mal danken.

Wolfi Gassler (00:44:49 - 00:45:19)

Klar, du nimmst ihnen ja ihre Arbeit ab. Hoffentlich. Okay, Andi, jetzt hätte ich noch abschließend eine Frage, die wir jetzt eigentlich gar nicht besprochen haben. Wie findest du denn das Ganze mit den Titeln? Wir hatten ja bei Trivago gar keine Titel zum Beispiel. Jetzt gibt es Extrembeispiele wie Dropbox CircleCI, die das super genau definiert haben auf Strich und Punkt. Wieso siehst du die ganze Titelgeschichte? Wir in Österreich probieren ja langsam den Postoberadjunkten und den Oberbereiter loszuwerden. Wie siehst du die ganze Titelgeschichte?

Andy Grunwald (00:45:19 - 00:46:48)

Am Anfang habe ich gedacht, brauchen wir nicht. Mit den Jahren habe ich meine Meinung geändert. Ich denke, Titel haben eine Relevanz und zwar primär aus drei Punkten. Die erste Geschichte ist, es ist schon so eine Art Dankbarkeit für deine Arbeit und für deine Erfahrung, weil es zeichnet auch, wenn ich eine Promotion kriege, eine Beförderung, weil es ist ja eigentlich eine Beförderung in der Hinsicht. Man geht ja vom Junior zum Mittellevelingenieur und so weiter und irgendwann vielleicht zum Staffingenieur. Es ist halt schon eine Anerkennung für deine Arbeit. Die zweite Geschichte ist, In vielen modernen Firmen deine Vergütung, dein Gehalt, dein Boni, dein Equity, also die Anteile an der Firma, ist auch daran gebunden. Beispiel, die Tage bei der Vorbereitung auf diesem Podcast gelesen, in einer Firma haben Senior Engineers einen Boni-Anteil von ihrem Gehalt von 10%. Staff Engineers in derselben Firma einen Anteil von 20%. Du merkst schon, umso mehr prozentual von deinem Gehalt der Boni ist, umso mehr kommt es natürlich auf deine Zielerreichung, auf deine Performance an. Und der dritte, und das ist so fast der Kicker gewesen, warum ich eigentlich meine Meinung ein bisschen geändert habe, ist Titel können für unterrepräsentierte Gruppen wirklich hilfreich sein, in der Hierarchie, in der Organisation zu navigieren. Denn wenn man einen Staff Engineer im Meeting sitzen hat, dann ist es ganz einfach so, diese Person hat den Titel nicht ohne Grund. Und speziell für unterrepräsentierte Gruppen kann das natürlich ein leichterer Start sein, als jetzt für weiße, alte, privilegierte CIS-Männer zum Beispiel.

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

Wer sich mehr für alte weiße Zismänner interessiert, also wir zwei und unsere Meinung, dem empfehlen wir die Episode 50, wo wir über Diversity gesprochen haben.

Andy Grunwald (00:46:57 - 00:47:03)

Was war deine Meinung über Titel? Denkst du immer noch, die sind sinnfrei oder hattest du die jemals oder hast du auch deine Meinung geändert?

Wolfi Gassler (00:47:04 - 00:48:01)

Ich war eigentlich immer ein großer Gegner von Titeln, aber ich habe einfach gemerkt, dass es nicht ohne funktioniert, weil die Leute einfach ständig danach gefragt haben. Viele Leute brauchen diese Struktur, wollen diese Anerkennung. Und wir beide hatten dieses Beispiel in Trivago, wo es gar keine Titel gab. Und da kamen einfach ständig diese Requests. Und wenn man die ganze restliche Welt und vor allem der Arbeitsmarkt mit so Titeln reinpresst, wird es einfach extrem schwierig. Mittlerweile sehe ich die positiven Seiten davon, bin immer noch kein extrem großer Fan, aber ich glaube, man braucht es in irgendeiner gewissen Form, innerhalb der Firma zumindest. Es gibt keinen Industriestandard, ganz klar, aber man sollte sich wenigstens in der Firma einig sein, wie man das macht. In kleineren Firmen geht es sicher auch ohne Titel, aber ich glaube, umso größer und umso professioneller und umso mehr Spezialisten du an Bord hast und umso mehr du recruten musst, ist es ein großes Thema und dann wird es einfach irgendwann schwierig ohne Titel.

Andy Grunwald (00:48:01 - 00:48:19)

Ich merke halt, dass die ganze Sache im deutschen Bereich gerade so Einzuge erhält. Natürlich primär bei den tech-driven companies, wo die IT kein Cost-Center, sondern ein Innovationstreiber ist. Ich bin mal gespannt, wann dies flächendeckend auch beim guten deutschen Mittelstand ankommt.

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

Wie war das beim Manfred vom Mittelstand? Oder wie heißt dieser Spruch?

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

Beim Mittelstand Manfred, ja.

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

Beim Mittelstand Manfred.

Andy Grunwald (00:48:25 - 00:48:32)

Die Tage auch einen schönen Begriff gehört, Industrie-Johnny. Hat mich auch sehr zum Grinsen gebracht. Nun gut, das war's.

Wolfi Gassler (00:48:32 - 00:49:08)

Und ganz neu in dieser Episode gibt's mal jetzt einen neuen Feedback-Channel. Und zwar sind wir jetzt auf Mastodon, ingkiosk at podcasts.social. Wir freuen uns da natürlich auf viele Followers und wir werden, um ehrlich zu sein, keine Ahnung, ob wir einen Poll machen können auf Mastodon. Finden wir noch raus. Und sonst auf Twitter gibt's einen Poll, ob ihr Titel in der Firma habt oder nicht. Wir sind sehr gespannt, wie denn so die Rückmeldung aus dem deutschsprachigen Raum so aussieht. Und sonst gilt wie immer, bitte Sterne vergeben, Likes, Herzchen, was ihr auch immer in eurer Podcast-App habt und gerne weiterempfehlen.

Andy Grunwald (00:49:09 - 00:49:10)

Tschüss, bis zum nächsten Mal. Tschau.