#33 Andy im Team Lead Bewerbungsgespräch

Wie können Engineering Manager und Tech-Lead-Interviews aussehen?

Jeder, der vom Individual Contributor in eine Engineering Manager und Tech-Lead-Rolle wechseln möchte, muss sich Fragen aussetzen, die nichts mit Code zu tun haben. Fragen über Leadership Styles, Motivationen, Team-Entscheidungen, Business-Prioritäten, Selbst-Reflektion und Schwächen. Denn als Engineering Manager oder Tech-Lead gilt man als Multiplikator. In dieser Episode stellt Wolfgang seinem Co-Host Andy einfach mal die Fragen, die er damals Bewerbern gestellt hat, um sich selbst als Engineering Manager bei trivago zu ersetzen. Dies gibt einen guten Einblick, mit welchen Fragen Ihr so rechnen könnte, falls Ihr euch in eine ähnliche Situation begebt.

Bonus: Warum Wikingerschach der neue Sport ist und was eine Straßenampel mit Continuous Integration zu tun hat.

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

Sprungmarken

(00:00:00) Intro

(00:00:33) AI-Generiertes Episoden-Cover mit DALL-E 2

(00:07:09) Das heutige Thema: Leadership styles, eine Art Engineering Manager Interview und Wikingerschach (Kubb)

(00:11:03) Kontext zu dem Interview, dem Team und den Interviewfragen

(00:14:46) "Warum möchtest du überhaupt eine Lead-Rolle übernehmen?"

(00:19:10) "Was wären deine ersten drei Aktionen als neuer Engineering Manager?"

(00:22:29) "Was ist dein Leadership-Style?"

(00:27:39) "Wo ziehst du denn aus dem Alltag als Engineering Manager die Energie raus?"

(00:29:14) "Wie verteilst du Projekte an Mitarbeiter, die keiner machen möchte?"

(00:38:20) "Wie würdest du die Innovation / Innovations-Bereitschaft in deinem Team erhöhen?"

(00:45:14) "Hast du eine Herangehensweise, wie man mit anderen (hartnäckigen) Meinungen umgeht bzw. eine Pattsituation auflöst?"

(00:53:31) "Warum sollte ich dich nicht anstellen?"

(00:56:02) Interview-Abschluss und Retrospektive Betrachtung der Fragen

(00:59:40) Outro und Feedback

Hosts

Wolfgang Gassler (https://twitter.com/schafele)
Andy Grunwald (https://twitter.com/andygrunwald)

Feedback (gerne auch als Voice Message)

Email: stehtisch@engineeringkiosk.dev
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:02 - 00:00:37)

Wir suchen Andis Leadership-Style. Und dafür muss er durch die Interviews fragen, mit denen ich auch meine Nachfolger gesucht habe. In Andis Bewerbungsgespräch treffen wir nicht nur auf Straßenlampen, die an Jenkins angeschlossen sind, sondern sprechen auch über CV-Driven Development, wie man langweilige Projekte für das Team interessanter gestalten kann und wie man die Innovationskraft zurück in ein Team bringt. Aber vor Andis Interview starten wir zuerst mit künstlicher Intelligenz und Wikinger-Schach. Hast du schon unser geniales Episoden-Image gesehen von der letzten Episode?

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

Du meinst das mit dem Kran, oder?

Wolfi Gassler (00:00:39 - 00:00:50)

Nein, das ist die vorletzte. Du musst jetzt auf diese Episode gehen, die eigentlich jetzt schon released ist, wenn Leute das hören, aber sie eigentlich noch nicht released, weil sie erst morgen released wird.

Andy Grunwald (00:00:50 - 00:01:11)

Nee, habe ich noch nicht. Ich weiß noch nicht, was für ein Bild da kommt. Liebe Hörerinnen und Hörer, ihr müsst wissen, der Wolfgang ist unsere Marketingabteilung. Der Wolfgang ist unsere Designabteilung und unsere Schnittabteilung, unsere Audioabteilung. Und deswegen lasse ich mich da immer wieder jeden Dienstag erneut überraschen, was der Wolfgang da für ein Bild rauskramt.

Wolfi Gassler (00:01:12 - 00:02:05)

Ihr wart gehofft, ich bin auch Host, aber scheinbar bin ich nur Marketingabteilung und Schnitt. Aber okay, schaut ihr mal das Image an. Es war eigentlich gar nicht so einfach, da ein Bild zu finden. Ich hab natürlich extrem lang probiert, irgendwie Pipelines zu malen. Irgendwie Leute, die in einer Pipeline sind, die in einem Filter sind. Und ich hab mir immer gedacht, das ist alles unmenschlich. Ich kann da ja nicht irgendwelche Leute aus irgendeiner Pipeline rausputzen lassen. Und hab dann eigentlich ein sehr langweiliges Image ausgewählt. Und dann bin ich mit einem Freund zusammengesessen und der gemeint, hast du denn schon diese neue AI ausprobiert, was die ausspuckt, wenn du da eingibst Person, Pipeline, Illustration oder sowas in der Richtung. Und wir haben da ein bisschen rumgespielt und ich hab eigentlich einen Output recht cool gefunden, wo so ein Strichmännchen auf einer Pipe eigentlich sitzt. Also damit ist das jetzt unser erstes Episoden-Image, was von einer AI kreiert worden ist, Andi.

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

Das sieht aber eher so aus als für das Strichmännchen pfeifen.

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

Ja dann stimmt Pipe ja auch irgendwie, ist ja auch ne Pfeife.

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

Aber hast du denn den genauen Satz den du da eingegeben hast noch parat?

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

Natürlich verlinken wir auch gerne.

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

Ist das reproduzierbar, also ist das idempotent, wenn ich den Satz eingebe, kommt immer dasselbe Bild raus?

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

Ich gehe davon aus, dass das Model eigentlich immer dasselbe ausspuckt, weil du gibst einen Satz ein, Wörter ein und dann bekommst du ein Image. In dem Fall war es ganz einfach person in pipe illustration. Danke Herrn Barner, der mir dabei geholfen hat. Und wir haben ein paar Sachen ausprobiert. Und das war das einzig Sinnvolle, was da irgendwie rausgekommen ist. Und ich find eigentlich das Strichmännchen ganz nett. Schaut irgendwie nett aus. Hat mich an dich erinnert, Andi.

Andy Grunwald (00:02:48 - 00:03:14)

Die Kollegen von der ProgrammierBar, auch ein anderer Podcast, die haben das nämlich auch schon gemacht. Und zwar haben die im Deep Dive 108 sich über dieses Webframework Astro unterhalten. Und dort haben sie dann mit Dolly 2 ebenfalls ein Episoden-Image generiert. wo dann ein mensch im astronautenanzug auf einer rakete sitzt und einen laptop auf dem schoß hat und der gerade ins.

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

Weltraum ist wieder typisch bis jetzt haben jetzt alle geglaubt wir sind so kreativ und das erste podcast was sowas macht und jetzt kommst du in die ecke die programmierbar hatte schon lange gemacht na super. Was aber definitiv neu ist, was ich jetzt an News verkünden kann, weil diese News ist glaube ich erst heute rausgekommen, ist DALI2 ist ja ein AI-Projekt von OpenAI und damit Closed Source. Es gibt jetzt auch ein Startup, das das Ganze offen macht und scheinbar, behaupten sie zumindestens, ein ähnlich gutes Modell hat, das man verwenden kann und das heißt, stability.ai aber jetzt noch nicht ganz rausgefunden wie ob man das verwenden kann man muss da irgendwie zuerst apply und ist noch nicht so einfach zu zu verwenden wie das von openai natürlich.

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

Okay das model halten die aber trotzdem closed du darfst das nur dann frei benutzen oder ist das model auch komplett ist das trainierte model komplett auch offen.

Wolfi Gassler (00:04:09 - 00:04:38)

So wie ich das verstanden habe, ist alles offen, weil DALI kannst du ja auch einfach verwenden. Deshalb habe ich mich übrigens auch gefragt, wie schaut es denn aus Copyright-technisch? Wem gehört denn jetzt dieses Strichmännchen? Gehört es DALI, weil das die AI createt hat? Gehört es mir? Vor allem dürfen wir das jetzt verwenden? Gibt es da irgendwie Copyright? Also ich habe auf der Webseite gecheckt, solange man Menschen, woher man das bekommen hat, ist das okay in dem Fall. Aber ganz allgemein, wenn so eine AI was kreiert, mit deinem Input, wem gehört das dann?

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

Die Frage geht ja weiter. Also, wem das jetzt wirklich gehört, weiß ich nicht. Aber ich glaube, da geht es dann wirklich mit Intellectual Property und so weiter, dann noch irgendwelche Länderregeln und Gesetze aus Amerika, ist bestimmt anders als in Österreich, als in Holland, wo du jetzt gerade sitzt, oder Deutschland. Das ist auch mal die Frage, welches Gesetz gilt denn jetzt gerade eigentlich für uns hier? Ich meine, du hast das Bild generiert, du sitzt jetzt gerade in Amsterdam, aber welches Gesetz gilt denn für dich dann in der Hinsicht?

Wolfi Gassler (00:05:05 - 00:05:41)

Das ist eine gute Frage. In dem Fall wahrscheinlich einfach das von Dali. Ich habe mir zuerst gedacht, eigentlich müsste das ja denen gehören, OpenAI, weil die haben das erstellt. Auf der anderen Seite, wenn ich jetzt eigentlich ein Tool verwende wie Photoshop, dann gehört ja das, was ich in Photoshop erstellt habe, auch mir und nicht Adobe. In dem Fall habe ich ja diesen wahnsinnig kreativen Text-Input geliefert oder unsere Gruppe sogar und eigentlich hat das ja erst bewirkt dann den Output. Also es ist gar nicht so leicht festzustellen. Bin eigentlich gespannt, wie das da in Zukunft gehandhabt wird. Es wird immer komplizierter, diese ganzen Dinge durch die AI.

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

Ich gebe aber zu, ich bin jetzt nicht so wirklich beeindruckt von diesem Strichmännchen, was auf der Pipe sitzt. Weil offengesprochen sieht das schon echt bescheiden aus. Ich denke, du hättest da schon etwas Fotorealistischeres nehmen können.

Wolfi Gassler (00:05:55 - 00:06:15)

Ich habe die Beschwerden bekommen, die letzten paar Male, wo ich was Fotorealistisches verwendet habe, dass der Style vom Engineering-Kiosk gebrochen wurde, habe ich sofort auf Twitter dann einen halben Shitstorm bekommen und von Freunden, die irgendwie gemeint haben, ich soll den Designer doch rausschmeißen, weil das, was da daherkommt, das schaut aus wie Comic Sans.

Andy Grunwald (00:06:15 - 00:06:19)

Und genau dieses Strichmännchen, was auf dieser Pipe sitzt, schaut aus wie Comic Sans, genau.

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

Ja, das ist inspiriert, weil ich heute von einem anderen Kollegen gerade gehört habe, unsere Intro-Musik passt zu unserem Engineering-Kiosk-Title wie ein Comic Sans-Logo zu einem Anwaltsbüro.

Andy Grunwald (00:06:32 - 00:06:51)

Dann sag deinem Kollegen mal bitte, so werden inzwischen Logos von Anwaltskanzleien aussehen, denn Generation Z kommt auf den Markt. Auch die studieren Recht und werden Juristen. Und das erste, was sie machen werden, Word auf, Müller und Richter. Ah, Arial sieht doof aus. Comic Sans, drucken.

Wolfi Gassler (00:06:52 - 00:08:18)

Genau, und darum haben wir jetzt dieses coole Strichmännchen aus einer AI. Aber kommen wir zum eigentlichen Thema heute. Jetzt sind wir schon sehr in die AI-Ecke abgeschweift. Ich habe mir heute etwas sehr tolles vorbereitet. Und zwar haben wir uns überlegt, wir könnten mal etwas über Leadership-Styles machen. und vielleicht auch mal überprüfen, wo da unsere Leadership-Styles so liegen. Und dann ist mir eingefallen, ich habe ja gar nicht so lange her, okay sind auch schon wieder ein paar Jahre, aber damals wie ich bei Trivago abgetreten bin, hatte ich noch das Vergnügen Nachfolger zu suchen. Zwei Leute, die mein Team übernehmen und habe da intern recht viele Interviews geführt mit Developern, die den Schritt machen in die Leadership-Richtung und wirklich Team-Lead werden und das Team also einen Teil von dem Team übernehmen können, also so acht Leute jeweils pro Team. Und die haben mir da ein paar Fragen überlegt, abseits der technischen Themen, weil ich habe die Leute ja einigermaßen gut gekannt, habe gewusst, wie die arbeiten, aber ich wollte halt wissen, wie ticken so die Leute, die sich bewerben intern, wenn es um Leadership-Themen geht. Und dann haben wir gedacht, ich stelle jetzt einfach diese Fragen Andi, und der Andi erklärt uns über dieses Interview, wie sein Leadership-Style aussieht und wie er durch dieses Interview kommen würde. Er kennt die Fragen noch nicht. Ich habe sie bewusst nicht in unser Dokument kopiert. Sie sind auch sehr generisch, muss ich dazusagen, aber ich bin mal gespannt, wie du dich schlägst.

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

Als der Wolfgang mir das Thema vorgeschlagen hat, habe ich eigentlich gesagt, eieiei, ich bekomme ja nie wieder einen Job irgendwo.

Wolfi Gassler (00:08:24 - 00:08:30)

Aber du bist heute Gott sei Dank so müde, dass du keine Chance hast, dich zu wehren und hast einfach akzeptiert.

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

Meine Stimme ist auch ein bisschen angeschlagen, deswegen entschuldige ich mich dafür.

Wolfi Gassler (00:08:35 - 00:08:44)

Ich würde jetzt fragen, warst du irgendwie krank oder so, aber ich bin mir sicher, du warst einfach, es hat irgendwie mit viel Alkohol oder so zu tun und demnach gibt es kein Mitleid.

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

Ich war auf einer sportlichen Veranstaltung, also ich war nicht krank. Weißt du, was Wikingerkegeln ist?

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

Ich weiß, was Kegeln ist, ich weiß, was Wikinger sind, aber die Kombination ist mir noch nicht bekannt.

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

Oder Schwedenkegeln wird das, glaube ich, auch oft genannt.

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

Moment, ist dieses Saufspiel?

Andy Grunwald (00:08:59 - 00:09:01)

Nee, das nennt sich KUB.

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

Das sind so... Ist aber auch schwedisch, oder?

Andy Grunwald (00:09:03 - 00:09:11)

Ja, Schweden, Wikingerkegeln. Das ist sowieso alles da, kommt aus dem Norden. Ich glaube, das Spiel KUB kann man sogar bei Ikea kaufen.

Wolfi Gassler (00:09:11 - 00:09:14)

Okay, aber dein Schwedenkegeln, was ist jetzt das?

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

Nee, das ist ja KUB.

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

Ah, das ist KUB.

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

Aber das ist ein und dasselbe Spiel. Und davon haben wir hier auf dem Dorf zwei Kegelclubs. Einmal der Kegelclub, in dem ich bin, der hat das mitorganisiert, und dann noch ein befreundeter Kegelclub. Die machen jedes Jahr ein kleines internes Turnier.

Wolfi Gassler (00:09:31 - 00:09:33)

Also es hat doch mit viel Alkohol zu tun.

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

Es ist eine sportliche Veranstaltung.

Wolfi Gassler (00:09:35 - 00:09:38)

Ich kann mich nur wiederholen. Es hat also doch mit viel Alkohol zu tun.

Andy Grunwald (00:09:39 - 00:10:03)

Wir bleiben dabei, es ist eine sportliche Veranstaltung. Na ja, auf jeden Fall haben wir unter anderem da auch ein bisschen was für das leibliche Wohl getan, nämlich was zu essen besorgt. Und ich musste das Essen natürlich auch in den Mann bringen. Und meine Ehefrau sagte mir, ich wusste gar nicht, dass du ein Talent als Marktschreier hast. Und ja, deswegen ist meine Stimme etwas angeschlagen. Aber für ein paar Fragen bin ich doch immer noch bereit.

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

Ja, ich würde schon mal fragen in dem Interview, Herr Grunwald, sind Sie noch ganz bei Sinnen, da am Vortag saufen und irgendwelche Sachen, sportliche Veranstaltungen machen, wenn heute dieses wichtige Interview ansteht?

Andy Grunwald (00:10:14 - 00:10:18)

Ich wusste bis vor zehn Minuten gar nicht, dass ich heute ein Interview mit dir habe.

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

So spontan ist der Andi, das ist perfekt.

Andy Grunwald (00:10:21 - 00:10:59)

Ich hatte mich mental auf ein ganz anderes Thema vorbereitet und dann sagte der Wolfgang, ich habe eine bessere Idee. Lass mal darüber sprechen. Und ich denke so, okay. Also ich habe wirklich keine Ahnung, was er jetzt gleich für Fragen stellt. Ich weiß leider auch nicht, wen oder für was er seinen Ersatz bei Trivago gesucht hat, weil in dem ganzen Prozess war ich nicht involviert, weil zu der Zeit war der Wolfgang Irgendwie drei Abteilungen weiter rechts, mit denen ich recht wenig zu tun hatte. Auf jeden Fall, also ich weiß jetzt gar nichts, deswegen bin ich mal gespannt. Leadership-Styles, Kategorisierung finde ich auch immer eine schwere Sache. Micromanager, Leisure-Fair, etc., etc., was es da nicht nur alles gibt, aber keine Ahnung.

Wolfi Gassler (00:10:59 - 00:11:24)

Aber vielleicht um den Kontext noch zu setzen, das sind ganz allgemeine Fragen, wo es wirklich um Leadership geht und mir war es eigentlich wichtig, die Motivation von den Leuten zu verstehen, warum die in so eine Leadership-Rolle überhaupt wechseln wollen von einer normalen Developer-Rolle und ob die auch mit den Problemen vielleicht sich schon mal Gedanken gemacht haben, was es da für Probleme geben kann und vielleicht dann dementsprechend auch schon Antworten drauf haben.

Andy Grunwald (00:11:25 - 00:11:33)

Lass uns mal kurz den Kontext geben für welches Team du gesucht hast. Du warst ein Engineering Manager von wieviel Direct Reports?

Wolfi Gassler (00:11:33 - 00:11:44)

Keine Ahnung mehr. Ich schätze mal 18 Leuten oder so oder 16 und meine Idee war das aufzuteilen auf zwei, weil das einfach viel zu viel ist. Da haben wir schon öfters drüber gesprochen.

Andy Grunwald (00:11:44 - 00:11:47)

Du hattest fachliche und disziplinarische Führung?

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

Theoretisch ja.

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

Und praktisch?

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

Ja, praktisch ist es fachlich dann einfach schwierig, weil du kannst nicht in vier verschiedenen Teams in allen Themen irgendwie drin sein und fachlich anteilen.

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

Waren das Software-Engineering, Product-Engineering-Teams? Waren das Data-Science-Teams? War das Business Intelligence Quality Assurance? War das ein Design-Team? Von welchen Teams reden wir hier gerade? Womit haben die sich beschäftigt?

Wolfi Gassler (00:12:12 - 00:12:49)

Das hat sich auch über die Zeit geändert. Am Anfang waren noch Data Science Leute auch in meinem organisatorischen Team, das dann in verschiedenen Product Teams gearbeitet hat. Später sind die dann zu einem Data Science Lead gewandert. Das heißt, bei mir waren dann nur mehr SREs, die sich um den ganzen DevOps-Gramm gekümmert haben, auch normale Developer. Aber es waren am Ende natürlich Cross-Functional Teams. Also die Data Scientists waren dann genauso in den Teams und haben mit allen zusammengearbeitet. Und es hat auch einen Product Owner gegeben. der sich um das gekümmert hat. Also es waren mehrere Product Teams, aber als Engineering Manager sind die Developer und SREs offiziell mir unterstanden.

Andy Grunwald (00:12:49 - 00:12:59)

Von diesen 18 Leuten, was war da für eine Verteilung von Junior-, Mid-Level- und Senior-Leuten, damit man auch mal weiß, wie viel, vielleicht sogar wie viel Betreuung die noch brauchen oder Mentoring oder ähnliches?

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

Auch da war es wichtig, dass das andere Seniorleute übernommen haben. Also auch da ist von mir eher die Organisation gekommen und dass man eben in den Teams das einigermaßen gleich verteilt, Leute, die mehr und weniger Erfahrung haben. Aber das hat auch im Team stattgefunden primär und die mehr Seniorleute, seniorigeren Leute haben dann eben auch dementsprechend mit den Juniors zusammengearbeitet und haben die sozusagen ein bisschen an die Hand genommen teilweise.

Andy Grunwald (00:13:27 - 00:13:30)

Okay aber voll hardcore technische teams.

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

Das auf jeden fall aber wie gesagt die fragen sind ganz allgemein gehalten das ist egal ob es jetzt ein technisches team ist oder ein anderes team aber es war für so eine rolle aber nachdem das alles developer schon waren die sich dort beworben haben. Und wir haben leider keine weibliche Bewerbung gehabt, wenn ich es richtig im Kopf habe, von internen Leuten. Aber die waren natürlich alle Developer, haben den Ablauf schon gekannt, intern, die Firma, und die aber auch gewusst, was die ungefähr technisch leisten. Das heißt, für mich war dann eher wichtig die Motivationsfrage, warum willst du denn überhaupt Teamlead werden?

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

Die Stelle war nur intern ausgeschrieben. Das bedeutet, du hattest nur interne Kandidaten.

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

Das war aus Zeitgründen, war die nur intern ausgeschrieben, ja. Weil wir in sehr kurzer Zeit zwei Leute gesucht haben, die eben das übernehmen können von mir, ja.

Andy Grunwald (00:14:16 - 00:14:21)

Weil du deinen Scheiß wieder nicht ordentlich im Griff hattest und alles ganz weit nach hinten rausgeschoben hast.

Wolfi Gassler (00:14:21 - 00:14:29)

Genau, es waren nur drei Monate Zeit und das war einfach extra jemand reinzubringen, der zwei Teams übernimmt, ist einfach schwierig in drei Monaten.

Andy Grunwald (00:14:29 - 00:14:31)

Okay, genug Kontext, fangen wir mal an.

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

Okay, eine klassische Frage, die ich immer gerne stelle, mit der man einfach mal einsteigen kann, ist, warum du überhaupt eine Lead-Position übernehmen willst. Also warum willst du eine Lead-Rolle haben und keine Developer-Rolle mehr? Du hast ja übrigens auch ähnlich, gerade kürzlich, solche Fragen wahrscheinlich beantworten müssen, weil du ja auch wieder aus einer Individual Contributor-Rolle in eine Team-Lead-Rolle gewechselt bist. Das Schöne an Podcasts ist ja, dass die editiert werden und man immer die Pausen rausschneiden kann. Also Andi kann jetzt extrem lange überlegen und die Pausen werden dann sogar automatisiert rausgeschnitten. Das heißt, es klingt jetzt, als würde der Andi immer sofort schnell antworten, aber ich kann euch garantieren, da ist viel Wartezeit und Denkzeit dazwischen.

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

Ich beantworte dir die Fragen jetzt so, wie ich die denke, warum ich den Job toll finde, oder? Und nicht, dass ich jetzt deinen Job haben möchte. Also, wir spielen jetzt hier nicht, sondern du stellst mir aktuell die Fragen und wir versuchen dadurch, dann irgendwie herauszufinden, was mein Leadership-Style ist oder so, wie ich so ticke in der ganzen Richtung, oder?

Wolfi Gassler (00:15:34 - 00:15:41)

Ja, ganz allgemein, eine coole Lead-Position. Warum willst du überhaupt eine Lead-Position und keine Developer-Position mehr haben?

Andy Grunwald (00:15:41 - 00:18:30)

Also erstens möchte ich klarstellen, nur weil ich eine Lead-Position habe bzw. haben möchte, heißt das nicht, dass ich keine Developer- oder Individual-Contributor-Position haben möchte. Es ist zwar ein anderer Job, dennoch halte ich beide für sehr spannend. Dennoch muss ich sagen, warum habe ich jetzt eine Lead-Position und warum finde ich die jetzt gerade interessant? Und Achtung, ich komme jetzt gleich auch nochmal auf das Wort jetzt gerade. Das ist ganz einfach. Ich mag den Split zwischen technischen Diskussionen, technischen Implementierungen, aber auch die andere Perspektive von Planung, Strategie. Und speziell mit Leuten arbeiten und auch mal Devils Advocate spielen. Aber auch zu sehen, wie Leute selbst wachsen. Ich sag immer, ich zieh meine Motivation aus dem Mantra, do awesome things with awesome people. da hab ich auch einfach Bock drauf, und ich hab einfach Bock drauf mit Leuten, die wirklich daran glauben, was sie machen, und nicht nur das machen, weil das im Prozess so steht, sondern weil die wirklich an's Ziel glauben und wirklich Bock haben, was auf die Straße zu bringen. Und wenn du dann in der Lage bist, so eine Truppe auch motivieren zu können und auch denen das Gefühl zu geben, dass deren Arbeit gewertschätzt wird, was super oft nicht der Fall ist bei vielen Managern, Und du auch zeigst, dass du dich um deren Weiterentwicklung kümmerst. Das heißt nicht immer, dass du genau den Plan hast, wie die sich weiterentwickeln können. Aber wenn du denen das zeigst und du dann später mal Feedback bekommst und dann erst mal merkst, was du möglicherweise für einen positiven Impact auf diese Leute hast, und dann vielleicht sogar am Ende noch einen Fall draus machst, dass die eine Beförderung kriegen zum nächsten Titel oder eine Gehaltserhöhung oder, oder, oder. Ist einfach was wunderschönes. Muss ich zugeben, da freue ich mich wirklich, weil du hast einen positiven Impact auf das Leben von diesen Menschen. Also wirklich coolen Kram mit coolen Leuten machen. Aber ich mag auch den Split zwischen sich mit denen in einen Raum zu setzen, vielleicht mal deren Pull-Request zu challengen, aber auf der anderen Seite dann auch die Strategie fürs nächste Quartal festzusetzen und einfach zu sagen, okay, Jungs und Mädels, wo sehen wir uns denn mal in zwei Jahren? das ist das ist ist schon cooler mix und warum ist das ein cooler mix weil er sehr abwechslungsreich ist meines erachtens nach und du konstant den muskel trainierst dass du auf der einen seite ein problem rein zoomen kannst sofern du einen technischen background hast aber auch raus zoomen musst um einfach mal das große ganze zu sehen zum beispiel dein team zu beobachten und einfach mal beobachtest, wer kommuniziert eigentlich wie mit wem, wie sind eigentlich die Kommunikationskanäle und Kommunikationsströme und wo musst du gegebenenfalls mal ein bisschen einlenken, dass du eine gesunde Kommunikation im ganzen Team hast und Co. und nicht nur drei kleine Gruppen. Also für mich ist es, glaube ich, der Mix aktuell.

Wolfi Gassler (00:18:30 - 00:18:36)

Okay, man hört auf jeden Fall, du machst es nicht zum ersten Mal. Würde mir jetzt wahrscheinlich erst eine Notiz aufschreiben.

Andy Grunwald (00:18:36 - 00:18:38)

Die Frage zu beantworten, meinst du?

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

Ja, oder dass du auch dementsprechend Erfahrung hast, ja. Also so eine umschweifende, im positiven Sinne umfängliche Antwort habe ich, glaube ich, bei niemandem von den Kandidaten bekommen.

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

Auch, ich muss auch sagen, Engineering Management kann auch unglaublich negative Positionen haben.

Wolfi Gassler (00:18:52 - 00:18:55)

Jaja, aber jetzt ist es mal nur um die Motivation gegangen.

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

Das ist meine Motivation.

Wolfi Gassler (00:18:57 - 00:19:13)

Wenn du jetzt diese Stelle dann anfangen würdest, in dem Team, neues Team, SRE-Devs verteilt über mehrere Product-Teams hinweg, wie wir das im Vorhinein beschrieben haben, was wären denn deine ersten drei Aktionen? Wie würdest du das Ganze angehen?

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

In den ganzen Management-Blogs oder in den ganzen Software-Engineering-Blogs, wo Leute dann irgendwie mal Individual Contributor waren und jetzt irgendwie CTO von irgendwas sind, dann die posten immer so Blogartikel wie, in den 90, in den ersten 90 Tagen als Manager und CTO musst du das machen und das machen und irgendwie kommt dann immer, du musst gefühlt den ganzen Laden auf den Kopf stellen und erstmal alles, was der Vorgänger gemacht hat, erstmal wegschmeißen und abändern.

Wolfi Gassler (00:19:35 - 00:19:44)

Ja, aber das ist ja long term. Ich will ja wirklich nur wissen, was wären deine ersten drei Aktionen, wie würdest du das Ganze angehen? Also sehr kurzfristig, die ersten drei Aktionen.

Andy Grunwald (00:19:44 - 00:20:16)

Die erste Aktion ist, ich würde mir erstmal jedem eine Monoman machen. Und dort erstmal so ein Status Quo abholen, aber auch mich erstmal vorstellen und die Möglichkeit geben, Fragen zu stellen. Und mit Status Quo abholen meine ich, Wir erst mal versuchen ein Bild zu machen, wie denken die Leute, was läuft gut im Team, was läuft schlecht im Team und auch, was würden sie ändern. Aber auch, um die einzelnen Leute mal kennenzulernen, wer hat welche Motivation, wer hat welche Ziele. Erst mal so die Grundstimmung vom ganzen Team aufnehmen.

Wolfi Gassler (00:20:16 - 00:20:26)

Würdest du das nur mit den Leuten im Team machen, die wirklich dir jetzt zugeordnet sind, in Direct Reports, oder auch mit den anderen in den Cross-Functional-Teams? Wie würdest du das anlegen?

Andy Grunwald (00:20:27 - 00:22:18)

Im ersten Schritt würde ich es mit den einzelnen Teammembern machen in meinem Team. Dadurch bekomme ich hoffentlich auch mal eine erste kleine Liste an Projekten, die das Team gerade auf dem Zettel hat. Als zweiten Schritt würde ich mich mit den Stakeholdern von diesen Projekten auseinandersetzen und auch ebenfalls mal One-on-ones führen und dann auch mit meinem Vorgesetzten beziehungsweise mit dem Management, was die dann unter anderem eigentlich von dem Team auf der einen Seite halten, wie das aus deren Sicht gerade performt oder nicht performt und was das Management eigentlich auch mal denkt, was das Team eigentlich machen sollte oder ob alles perfekt läuft. Also ich würde mir erstmal so eine Rundumsicht holen. Danach würde ich mir, glaube ich, ein bisschen Zeit nehmen zu schauen, wie das Team selbst arbeitet, wie organisiert sich das Team, Scrum, Kanban, gar keine Methode. Wo kommen eigentlich die Arbeitspakete her? Was für Workstreams gibt es? Ist schon alles gefunnellt? Und gibt's da nur einen Backlog im Jira? Oder findet die Hauptkommunikation in irgendwelchen Slack-Channels statt? Oder, oder, oder? Also, in wie sieht die Arbeit hier eigentlich aus? Und wie ist diese eigentlich organisiert? Um einfach nur mal so, ich mag das Wort jetzt nicht, aber so eine Kapazitätsplanung mal zu kriegen. Weil ich mag das Wort nicht, weil ich denke, Menschen sind keine Ressourcen, sondern Menschen sind Menschen. Und man kann nicht mit einem Menschen mit 40 Stunden rechnen, weil Urlaub, Krankheit, Wellbeing, die Personen müssen auch lernen während des Jobs, etc., etc. Deswegen mag ich das Wort Kapazitätsplanung im Kontext von Menschen eigentlich nicht. Aber ich würd mir erst mal schauen, was sind eigentlich realistische Ziele, die man dem Team setzen kann? Oder wird nach OKAs gearbeitet? Wenn ja, wie war der Status von den vorherigen Quartalen? Was gibt's für eine Fluktation im Team? Wie viele Leute gehen da pro Quartal rein? Wie viele gehen pro Quartal raus? Wie sieht die Staffing-Situation aus? Ich würd mir erst mal so einen Überblick geben.

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

Jetzt, wenn du diesen Überblick hast und in das normale Tagesgeschäft reingehst, dann kommen wir dann eben irgendwann zu dieser Schlüsselfrage, was ist denn dein Leadership-Style? Auch wenn du jetzt schon gemeint hast, du bist kein großer Fan von dieser Frage, aber wenn du das irgendwie beschreiben müsstest, was macht deinen Leadership-Style denn aus?

Andy Grunwald (00:22:40 - 00:22:56)

Wenn ich meinen eigenen Leadership Style beschreiben müsste, kommt der glaube ich am nächsten an Lassie Fair ran, nicht weil ich faul bin, mich auf meinem Stuhl hinsetze, mich zurücklehne, die Füße auf den Tisch packe und Kaffee trinke, das tue ich.

Wolfi Gassler (00:22:56 - 00:23:12)

Zwar auch, Jetzt muss ich da kurz reingrätschen für unsere Hörerinnen und Hörer, die alle nicht wissen, was der Laissez-Faire-Stil ist. Kannst du das kurz erklären? Auch wenn du eigentlich im Interview bist, wird dir das alles gegeben voraussetzen in so einem Kontext.

Andy Grunwald (00:23:12 - 00:23:18)

Also an alle Hörerinnen und Hörer, ich google das jetzt einfach mal, damit ich jetzt hier keinen Blödsinn sage.

Wolfi Gassler (00:23:19 - 00:23:39)

Da sieht man schon, wenn man sich auf ein Interview gut vorbereitet und einfach so ein paar Fragen durchgeht, die sehr üblich sind, dann hat man eben auf genau diese Dinge auch recht schnell eine Antwort. Also darum ist halt Vorbereitung auch wichtig, weil diese Dinge weiß man halt nicht vielleicht alle immer auswendig und wenn man sie nicht tagtäglich behandelt, auch wenn man sie lebt vielleicht, sie zu beschreiben ist dann doch nochmal eine andere Geschichte.

Andy Grunwald (00:23:39 - 00:25:00)

Okay, ich habe jetzt eine englische Beschreibung gefunden, die habe ich jetzt einfach mal in DeepL geknallt. Mal gucken, was da jetzt rauskommt. Also, Führungskräfte mit einem Laissez-faire-Leadership-Stil haben eine Haltung des Vertrauens und der Verlässlichkeit gegenüber ihren Mitarbeitern. Sie führen kein Micromanagement durch und mischen sich nicht zu sehr ein. Sie geben nicht zu viele Anweisungen oder Anleitungen. Stattdessen lassen Leisure-Fair-Führungskräfte ihrer Mitarbeiter ihre Kreativität, Ressourcen und Erfahrung nutzen, um ihre Ziele zu erreichen. Und ich sage, dass ich nicht hundertprozentig in diesem Stil passe, aber ich komme dem am nächsten. Und der Grund ist, warum ich das sage, Weil ich denke, je nachdem, in welchem Staat hier der Mitarbeiter ist, bin ich mehr auf der Seite oder weniger. Was meine ich damit? Leute, die noch nicht so lange im Job sind oder Leute, die zum Beispiel einige Herausforderungen mit der Umgebung haben. Damit meine ich zum Beispiel Leute, die Probleme mit unabhängigen Arbeiten haben, Leute, die sehr gerne sich mit Teammitgliedern in den Raum setzen, aber jetzt in einem Remote-Work-Environment arbeiten oder Ähnliches. diesen leuten gebe ich gebe ich schon sehr viele nicht anweisungen ich und auch nicht anleitungen ich weiß gar nicht was das deutschwort für guidance ist aber, Unterstützung.

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

Vielleicht einfach oder ja Unterstützung ich gebe.

Andy Grunwald (00:25:02 - 00:27:28)

Dir da schon eine Richtung um einfach zu helfen dass sie ihre Kreativität und ihre Erfahrung nutzen können ohne direkte Anweisungen zu geben wohingegen wenn ich einen kompletten Junior habe da gebe ich schon sehr viele Anweisungen setze mich aber auch mit dieser Person sehr viel hin und stelle einfach Fragen hey was wäre denn jetzt der nächste Schritt den du machen würdest und so weiter also ich versuche da schon durch so Basis-Coaching-Technik würde ich mal sagen, die Leute so zu erziehen, dass sie komplett alle Entscheidungen selbst treffen können. Und umso mehr Erfahrung der Mitarbeiter und die Mitarbeiterin hat, desto mehr erwarte ich natürlich Eigenverantwortlichkeit, selbstständiges Arbeiten und so weiter. Das heißt aber nicht, dass ich die Zügel aus der Hand gebe, sondern dass ich eigentlich primär meine Informationen durch gute Mitarbeit von den jeweiligen Leuten beziehe. Das bedeutet ordentliche Stand-ups, hier und da vielleicht mal One-on-ones, Tickethygiene, Designdokumente und so weiter und so fort. Sowas lese ich natürlich auch alles im Hintergrund. Das bedeutet, ich lese sehr viel in meinem Job und beobachte sehr viel. Das gibt mir dann in der Regel einen guten Überblick. Das bedarf aber auch, das klingt total böse, was ich jetzt sage, aber so mache ich das gar nicht. Und zwar, ich versuche, die Leute dahingehend zu erziehen. Und erziehen nicht im negativen Sinne, sondern eigentlich im positiven Sinne. Ich versuche den Personen immer den Sinn und Zweck zu erklären, warum es sinnvoll ist, wirklich alles aufzuschreiben. Warum es sinnvoll ist, den Leuten immer Kontext zu geben. Warum es sinnvoll ist, zu fragen, was die Personen bereits über ein Projekt wissen oder ähnliches. Und wenn das gegeben ist, wenn die Leute den Sinn verstehen, dann machen die das alles von ganz alleine, weil die merken, hey, ich kann in Urlaub gehen, ohne dass mein Projekt auf die Nase fällt. Und warum mach ich das so? Der Grund ist auch recht simpel. Mein Job als Engineering Manager ist es eigentlich, ein selbstheilendes und performantes Team zu erziehen, ohne dass ich benötigt werde. Wenn ich mich obsolet gemacht habe, dann hab ich meinen Job gut gemacht. Und das ist eigentlich mein Ziel. Ich versuche so in die Richtung von Simon Simic zu gehen. Ich erkläre denen, warum wir das machen und versuche dann die Guidance zu geben bis zum Verständnis, dass das alles so richtig ist. Aber das ist natürlich dann auch damit verbunden, dass die Leute sehen, dass sie mit ihrem Verhalten dann natürlich auch Erfolg haben. Also das bedeutet natürlich dann auch nach oben hin managen für das Team.

Wolfi Gassler (00:27:28 - 00:27:41)

Was macht dich denn in deinem, Alltag als Teamlead, was macht dich denn da glücklich? Oder was ist das, wo du wirklich Energie rausholen kannst, wenn was passiert?

Andy Grunwald (00:27:41 - 00:27:43)

Wo hole ich Energie raus, nur damit ich den Kontext habe?

Wolfi Gassler (00:27:43 - 00:27:53)

Ja, aus deinem Job. Also was macht dich glücklich? Wo kannst du Energie schöpfen, wenn XY passiert? Was ist dieses XY, was dich glücklich macht?

Andy Grunwald (00:27:53 - 00:29:06)

In der aktuellen Firma, wo ich gerade arbeite, haben wir jeden Freitag um 14 Uhr eine Demo-Session. Da kann jeder hingehen und kann das demon, was man die Woche gebaut hat oder was ein Team die Woche gebaut hat. Was mich mega stolz macht, wenn da einer meiner Teammitglieder ist, irgendeine Kleinigkeit zeigt und da ein, zwei, drei Leute sagen, das ist wirklich cooles Zeug. Das macht mich stolz, wenn die Leute was gebaut haben und Leute aus anderen Teams sagen, wow, das ist cool. Oder wir haben Regelmäßige Town Halls, so All Hands, ein anderes Wort ist Firmenweite Meetings, wo Company Updates gegeben werden. Und da gibt es dann öfter mal eine Kudos Session, das bedeutet, dass ein Top Level Manager spezielles Dankeschön an irgendwen ausspricht und wenn, gute Arbeit oder exzeptionelle Arbeit in einem solchen Forum gewertschätzt wird vom Top-Level-Management, ohne dass ich jemals irgendwas nach oben kommuniziert habe, sondern dass das C-Level-Management sieht, wow, diese Person oder dieses Team hat da leider mal die Show gerockt und sehr gute Arbeit geleistet. So was macht mich stolz. Oder wenn ich proaktives Feedback vom C-Level-Management über Teammitglieder bekomme.

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

Wenn wir jetzt mal tiefer reingehen in das Tagesgeschäft. Ich hatte mal so eine Situation, wo es um die Verteilung von Projekten gegangen ist in den Teams und den Leuten. Und da hat es zum Beispiel ein Projekt gegeben, was großen Business Impact gehabt hätte, aber es wollte niemand machen. Und wir hatten damals in dem Team eigentlich die Regel, man kann sich einfach für gewisse Projekte melden und das hat eigentlich immer ganz gut funktioniert. Aber in diesem Quarter hat es einfach ein Projekt gegeben, super wichtiges Projekt, Großer Business Impact, aber war halt relativ langweilig von der technischen Seite und es wollte einfach niemand machen. Wie würdest du unser Problem lösen?

Andy Grunwald (00:29:45 - 00:29:53)

Sehr Klassiker. Ist jetzt nicht so, als hatte ich das noch nie, aber ja. Vielleicht ein bisschen Kontext. Ich gebe dir jetzt nicht sofort die Lösung, aber ich gebe dir mal meinen Gedankengang dazu.

Wolfi Gassler (00:29:54 - 00:29:55)

Ich bitte darum.

Andy Grunwald (00:29:55 - 00:31:39)

Die Prioritäten eines Engineering Managers sind die folgenden. Die erste Priorität ist das Business. Die zweite Priorität ist das Team. Und die dritte Priorität ist das Individuum. Was bedeutet das? Wenn wir ein Projekt haben, was einen positiven, großen Business-Impact hat, dann muss ich leider sagen, obwohl es mir im Herzen weh tut, das ist Prior 1. Und mir tut das nicht im Herzen weh, weil ich nicht der Firma helfen möchte. Ich meine, dafür bezahlen die mich ja, dass ich der Firma helfe. Mir tut es im Herzen weh, weil es ja anscheinend ein langweiliges Projekt ist. Auf der anderen Seite, also das mal nur zur Priorität, auf der anderen Seite müssen wir auch mal ganz ehrlich sagen, IT-Fachkräfte werden gut bezahlt. Das bedeutet, wir sind alle erwachsen und wir wissen alle die Definition von Arbeit. Die Definition von Arbeit ist, du tauscht Zeit und Fähigkeit gegen Geld. Plus, also das ist mal so das bare Minimum von Definition von Arbeit, plus, Du hilfst jemandem anders, ihren oder seinen Traum zu verwirklichen. Nämlich dem CEO und dem Top-Level-Management. Und die haben dich eingestellt, damit du hilfst, diesen Traum zu bauen. Wenn ihr den Traum teilt, super, dann nennt man das Passion und allem drum und dran. Punkt ist aber, du hilfst primär bei der Umsetzung von einem Traum von jemand anders. Und deswegen erkläre ich dieses ganze per Minimum, weil in dieser Hinsicht, wir sind hier nicht auf einem Ponyhof und die kriegen auch alle sehr, sehr viel Geld. Deswegen, man darf sehr viel Freiheiten setzen, man muss aber auch Grenzen setzen. Und das wäre dann gegebenenfalls so etwas. Das ist jetzt ein Projekt, was eine sehr hohe Chance am Business Impact hat oder Business Uplift. Und deswegen müssen wir das machen. Die Frage ist nur, welches Projekt stoppen wir dafür oder pausieren wir? Denn immer nur oben drauf catern ist halt auch nicht.

Wolfi Gassler (00:31:39 - 00:31:53)

In dem Fall war es wirklich so, es gibt jetzt mehrere Projekte, die können wir alle gleichzeitig machen, aber es ist darum gegangen, wer macht welches Projekt, also die Zuteilung von den Personen auf die Projekte. Und es will einfach niemand auf dieses Projekt von sich aus freiwillig.

Andy Grunwald (00:31:53 - 00:32:01)

Okay, die Projekte von den Teammitgliedern, sind die alle gleich wichtig? Sind die ganz genau alle gleich wichtig und haben die alle den gleichen Business Impact?

Wolfi Gassler (00:32:01 - 00:32:24)

Natürlich nicht, aber du hast jetzt, keine Ahnung, nehmen wir mal, um das zu simplifizieren, zehn Projekte. Jedes Projekt braucht genau eine Person und du hast zehn Personen. Und zehn Personen melden sich für die neun Projekte und das eine Projekt will niemand machen. Also du hast die, du hast die Zeit. Es will nur niemand machen. Es will jeder lieber das Projekt eins und zwei machen oder irgendwas von den anderen neun Projekten, aber nicht dieses Projekt zehn.

Andy Grunwald (00:32:24 - 00:32:51)

Okay, dann zwei Möglichkeiten. Entweder wir finden als Team eine Lösung und irgendeinen Modus operandi, sei es auch auslosen. Irgendeine Methode, um herauszufinden, wer dieses Projekt macht, die dann für alle fair ist, weil auch einer meiner Liederschritt-Mantras ist, sei nicht nett, sei fair. Das bedeutet, das Team darf bestimmen, wie das jetzt selektiert wird. Von mir aus auch durch Streichhölzer ziehen oder ist ja egal wie.

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

Aber ist das die beste Lösung, wenn man sich das überlegt, für das Business? Wenn man jetzt irgendeinen wahllos auswählt oder eine?

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

Es kommt immer ganz auf die umgebung an ist das ein projekt was sehr einfach umzusetzen ist wo du einen fähigen projektmanager und projektmanagerin drauf hast der wo wo wo alles gut ist und was jetzt vielleicht auch nicht so super schwer umzusetzen ist dann vielleicht schon wenn das wirklich jede person machen kann wenn das aber ein kritisches projekt ist wo auch ein gewisses risiko auf technischer seite ist, wo ganz klar eine taffe deadline hinter ist und so weiter dann würde ich da jetzt keine junior person draufsetzen sondern schon eine erfahrene person es kommt immer ganz auf die umgebung an was ist das für ein projekt was ist die projekt dauer weil wenn das nämlich so ein ding ist was sechs oder neun monate läuft, dann sollte man auch mal fragen, okay, rotiert man nicht mal vielleicht die Person zwischenzeitlich durch, aber dann ist generell erstmal die Frage, ob ich überhaupt eine Person draufsetzen würde, wegen dem Busfaktor, oder vielleicht nicht sogar mehrere.

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

Ja, das wäre nur das Beispiel, also es sind einfach mehr Personen.

Andy Grunwald (00:33:52 - 00:34:01)

Ja, aber da spielen natürlich sehr viele andere Faktoren eine Rolle. Ich habe jetzt einfach mal die Assumption getroffen, jeder kann das hier machen.

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

Das heißt, du würdest eher in Richtung auslosen gehen und nicht, dass du entscheidest?

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

Wenn es von jeder Position unter dem gleichen Risiko.

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

Du kannst ja auch auslosen unter denen die die fähig sind das zu machen zum Beispiel.

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

Das stimmt.

Wolfi Gassler (00:34:14 - 00:34:27)

Würdest du dann mit deinen Leuten irgendwie ein Deal machen oder sowas? Warum? Dass man irgendwie sagt okay du beißt jetzt mal in den sauren Apfel und wenn das nächste mal sowas kommt dann bist du mal raus und jemand anderer soll in den sauren Apfel beißen.

Andy Grunwald (00:34:27 - 00:34:54)

Ich würde es fair machen. Ich würde erst dem Team die Möglichkeit geben, einen Weg zu finden, zu bestimmen, wer es macht. Nehmen wir mal Auslosen. Und jetzt wirst du gelost, Wolfgang. Du bist jetzt in meinem Team. Dann würde ich gegebenenfalls schon die Regel setzen, okay, wenn wir so was noch mal haben, dann ist der Wolfgang nicht mit dem Pool. Nicht mit dem Auslosenpool, damit du nicht zweimal in die Scheiße greifst. Wenn das Team aber zu keinem Konsensus kommt, wie das bestimmt wird, dann bestimme ich.

Wolfi Gassler (00:34:55 - 00:35:41)

Was da glaube ich auch noch ganz ganz wichtig ist in in so einem fall ist einfach zu verstehen warum niemand dieses projekt will also an was liegt es kann ich auch sein dass dieses projekt zum beispiel schlecht erklärt ist schlecht verkauft wird auch den leuten nicht klar ist wie wichtig es ist dass das einen hohen impact hat dass vielleicht sogar sie level projekt ist wo man vielleicht Manche Leute springen auch auf sowas an, dass man sagt, okay, das ist ein Projekt vom CEO und der wird dann happy sein. Also manche Leute arbeiten auch gerne an beschissenen Projekten, nur weil sie wissen, das kommt irgendwie von oben, ist jetzt vielleicht nicht die beste Motivation, aber kann auch eine Motivation sein. Also man kann auch versuchen, da die Motivationen noch in irgendeiner Form einzubauen, wenn das nicht schon versucht worden ist. Das habe ich da jetzt natürlich offen gelassen, aber das wäre natürlich noch eine Möglichkeit.

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

Das ist ja genau der Punkt, wo ich sage, ich gebe erstmal Kontext, warum wir jetzt überhaupt dieses Projekt haben. Das bedeutet, ich versuche das in meinen eigenen Worten zu erklären, ich versuche das auch selbst zu verstehen, warum das wichtig ist für die Firma. Weil wenn ich das nicht verstehe, wie soll ich das denn dem Team verkaufen?

Wolfi Gassler (00:35:56 - 00:35:58)

Und ob es wirklich wichtig ist.

Andy Grunwald (00:35:58 - 00:36:37)

Ja, das ist dann die nächste Frage. Das setze ich als gegeben voraus, dass wir die Firmenumgebung haben, dass das durch genug Gremien und durch genug Challenger gegangen ist, um jetzt wirklich mal Pläne zu zerstören. Weil du zerstörst ja auch das Team-Commitment für dieses Quartal, wenn was von links reingereicht wird. Also das habe ich jetzt einfach mal alles gegeben angesehen. Und wenn das dann der Fall ist, dann erkläre ich, warum das wichtig ist. Und wenn das immer noch keiner machen möchte, dann geht man halt, es tut mir total leid, aber ich sage, die harte Route. Und deswegen habe ich auch die, meines Erachtens nach, Prioritätenliste eines Engineering Managers so erwähnt, um einfach den Gedankengang nachzuvollziehen.

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

Andere gute Möglichkeit finde ich auch in dem Problem noch, dass man zum Beispiel das Problem interessanter machen kann. Also das könnte auch sowas sein, wenn jetzt Leute zum Beispiel Mentoring machen wollen, weil sie eben mehr Senior sind und in die Richtung gehen wollen, dass man sagt, okay, Du bekommst jetzt jemanden an die Hand, der ist Junior, dort kannst du Mentoring betreiben, aber ihr macht dafür gemeinsam dieses Projekt, sodass man vielleicht auch so Motivation aus einem anderen Eck herausholt und dem Projekt überstülpt. Das kann dann natürlich auch helfen, dass man einfach damit Motivation schafft. Aber am Ende glaube ich auch, man muss hart entscheiden und im schlimmsten Fall muss man das irgendwie machen, ja.

Andy Grunwald (00:37:17 - 00:38:07)

Man muss halt auch aufpassen, klar kann man das Projekt interessanter machen, aber da muss man ganz klar aufpassen, dass das Projekt nicht komplexer wird oder nicht irgendwo in irgendein Risiko gerät, wie mit der Deadline oder ähnliches. Natürlich kann man alles overengineeren oder immer eine neue Technologie reinpacken, aber wenn das Ding wirklich wichtig ist für die Firmen und so schon ein hohes Business-Risiko hat, dann eine neue Technologie zu nehmen, wo man die Failure-Patterns nicht kennt, ist halt auch ein zusätzlich hohes Risiko, nur um das Projekt spannend zu machen. Und auf der anderen Seite, umso erfahrener die Person, also meine Erfahrung, also umso länger die Person im Job ist, desto mehr wird Borrowing-Software auch wieder interessanter. Von daher, man muss nicht immer Hacker-News-Driven-Development machen oder eine neue Programmiersprache einsetzen oder eine neue Datenbank-Engine oder eine neue Cloud. Vielleicht setzt man auch einfach nur das ein, was man kennt, was einfach gut genug ist und das einfach funktioniert.

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

Und in dem Fall schnell hinter sich bringt, ja. Das kann auch eine gute Lösung sein. Okay, dann hätte ich noch eine andere Frage.

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

Ich muss noch mal ganz kurz einhaken. Du hattest am Anfang gesagt, wir starten mal mit einer leichten Frage. Die Dinger werden immer härter. Okay, aber hauen wir raus.

Wolfi Gassler (00:38:24 - 00:38:35)

Ja, jetzt kommen wieder leichte, keine Angst. Wie würdest du denn Innovation in deinem Team erhöhen oder die Innovationsbereitschaft oder ganz allgemein Innovationsoutput?

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

Was verstehst du unter Innovation? Für mich ist das auch so ein Basswort-Bingo wie Technical Debt.

Wolfi Gassler (00:38:40 - 00:39:04)

Ja, ist natürlich ein Passwort, aber dass deine Innovationskraft erhöht wird. Du hast jetzt vielleicht ein Team, was einfach nicht sehr motiviert ist, was auch keine neuen Dinge ausprobiert, was auch keine großartigen Ideen hat und nur so dahin arbeitet irgendwie und du willst halt da wieder ein innovatives Team draus machen, dass da auch ein bisschen was Innovativeres rauskommt als nur diese 1 zu 1 Umsetzung von irgendwas.

Andy Grunwald (00:39:04 - 00:39:15)

Okay, mit innovativ meinst du jetzt nicht klassisch Forschung oder wir machen jetzt neuen Business Zweig auf, sondern aufs Team begrenzt eigentlich.

Wolfi Gassler (00:39:15 - 00:39:17)

Schon eher jetzt auf den Teamscope, ja.

Andy Grunwald (00:39:17 - 00:39:24)

Also Innovation in Bezug auf, dass die Motivation zurückkommt, dass die Leute wieder Bock haben und Feuer in den Augen und Motivation.

Wolfi Gassler (00:39:24 - 00:39:30)

Genau, mal was Neues ausprobieren, auch von sich aus irgendwie Features vorschlagen, dass da halt wieder Innovationskraft vorhanden ist.

Andy Grunwald (00:39:31 - 00:41:23)

Mehrere Optionen. Und was jetzt die genaue Option ist, kann ich dir jetzt nicht genau sagen, weil ich das Team nicht im Detail kenne. Aber mehrere Optionen. Das, was auf der Hand liegend ist, einfach mal ... Und das ist so die low-hanging fruit. Einfach mal für ein oder zwei Tage komplett was anderes machen. Vielleicht einen teaminternen Hackathon, einfach mal wild gehen. Einfach mal ein bisschen Zeit für ... den inneren Forschungsdrang freimachen. Bedarf natürlich dann ein bisschen Arbeit von meiner Seite, man muss sich die Zeit freigeben lassen von seinem Manager, man muss gucken, dass alle Projekte nicht schlittern und so weiter und so fort. Aber das ist immer so der No-Brainer, dass die Leute mal einfach mal was komplett anderes machen. Ich denke da an sowas wie früher, als wir im Büro waren, fand ich die Idee immer ganz geil, die habe ich mal bei Flickr gesehen. Du kaufst dir für 80 Euro eine Straßenampel auf Ebay, Und dann kaufst du nochmal für 20 Euro ein Arduino oder ein Raspberry Pi. Und was dann gemacht wird, der Jenkins wird an die Straßenampel connectet und die Straßenampel zeigt dann rot im Büro, wenn der Build failt, grün wenn der grün ist und gelb wenn der Build baut. Das ist so ein bisschen Innovation, ein bisschen was motivierendes, einfach mal was anderes machen. Im Remote Setup müsste das dann gegebenenfalls anders aussehen, aber keine Ahnung, jetzt mal ein billiger Vergleich, der leider nicht an den Hype einer Straßenampel im Büro rankommt, aber weiß ich nicht, so eine Mac-Toolbar-Applikation, einfach mal in Zwift schreiben oder so, die kann das gleiche machen. Also das ist so die low hanging fruit. Was ich eher machen würde, wovon ich wirklich ein Fan bin, ist Arbeitsoptimierung und Arbeitsautomatisierung. Und zwar im Detail herausfinden, warum sind die Leute so demotiviert und was ist eigentlich langweilig an deren Job? Warum haben die keine Motivation? Wo ist der Forschungsdrang hin? Wo ist der Hype hin, weswegen diese Damen und Herren Programmiererinnen und Softwareentwicklerinnen geworden sind? Weil der war ja mal da.

Wolfi Gassler (00:41:23 - 00:41:25)

Würdest du irgendwas strukturell ändern?

Andy Grunwald (00:41:26 - 00:44:20)

Ja, vielleicht auch das, ja. Je nach Auslastung des Teams. In einem SAE-Team ist immer was ganz Klassisches. Reliability-Engineers haben immer das Ziel, den sogenannten Toil zu reduzieren. Toil ist alles das, was man manuell macht. Alles. Sei es, eine Datenbank stürzt jeden Tag um 15 Uhr ab. Warum auch immer. Sagen wir mal, um 15 Uhr laufen drei Cronjobs gleichzeitig und die knallen so auf die Datenbank, deswegen läuft die immer out of memory. Natürlich können wir jetzt Root Cause Behebung durchführen, würde uns aber drei Monate dauern. Einfach mal gegeben. Was man jetzt als Intermediate Toll Reduzierung machen kann, ihr baut doch einfach einen Cronjob, der um 3 Uhr, wenn das Ding abkachelt, das Ding wieder hochhebt. Und nicht immer nur, dass das Monitoring anschlägt, man lockt sich ein, bla bla bla. Es war jetzt das super kleinste Beispiel, aber einfach mal mit dem Team hinsetzen und sagen, okay, was ist denn das, was uns am meisten Zeit frisst? Was können wir denn mal automatisieren, um einfach unser Leben leichter zu machen? Und glaub mir, in jeder Firma gibt es super viel Kram, den man einfach nur durch kleine Skripte von seiner, von seinem Tisch schaffen kann. Aber dann, dann, dann geht's in die nächsten Probleme. Wir haben jetzt hier diese zehn kleinen Skripte, aber wo lassen wir die denn laufen? Ja, dann machen wir das mal eben auf der Cloud. Die Cloud, machen wir eine Lambda-Funktion. Einfach mal ein bisschen wild gehen. Klar, muss man gucken, passt das alles in die IT-Infrastruktur von der Firma. Geht man da nicht irgendwie off, weil die Firma eigentlich eine GCP-Firma ist und die machen was auf Amazon. Das verstehe ich alles und das muss man alles so ein bisschen mit einbeziehen. Aber durch Babyschritte einfach mal wieder ein bisschen, hey, ich habe meine Arbeit leichter gemacht. Das bedarf ein bisschen mehr Planung, das bedarf auch ein bisschen mehr Gedanken meines Erachtens nach als so ein Hackathon, weil du das eigentlich als das neue Normal in die Arbeitsstruktur mit einbringen möchtest, dass die nämlich kontinuierlich daran denken, wie sie sich das Leben kontinuierlich einfacher machen können. Und das ist schwierig, das dauert ein paar Monate. Aber so was bin ich mal ein Freund von. Ich versuche immer, die Motivation herauszufinden, was nervt diese Leute, warum sind die unmotiviert. Und ja, vielleicht geht es sogar so weit hin, dass im Management ein neues Projekt für das Team gepitcht wird. Vielleicht switcht man auch einfach mal die Teams. Wenn du nur eine Person hast, die dir motiviert ist, dann gehe ich auch so weit, ich muss die Person nicht bei mir halten. Ich hab lieber, dass die Person für die Firma arbeitet. anstatt für eine andere Firma. Und warum dann nicht einfach mal mit der Person sprechen, ob diese Person nicht das Team wechseln möchte, um in einem komplett anderen Bereich der Firma zu arbeiten. Deswegen sagte ich ja, die erste Priorität als Engineering Manager ist das Business, danach das Team und danach das Individuum. Und da habe ich dann lieber eine, wenn die Person bei mir unmotiviert ist, wäre der Teamwechsel eine Möglichkeit. Dafür arbeitet die Person dann immer noch für die eigene Firma. Beantwortet das deine Frage, Wolfgang?

Wolfi Gassler (00:44:20 - 00:44:20)

Jep.

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

Das hört sich jetzt so an, als hätte ich dich totgequatscht.

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

Ich bin schon am Vorbereiten der nächsten Frage natürlich.

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

Ich denke, du hast einen fertigen Fragenkatalog.

Wolfi Gassler (00:44:28 - 00:44:54)

Ja, aber das Problem ist ja, dass mein Fragekatalog erstens in Stichpunkten vorliegt und nicht in ausformulierten Fragen, dann noch in Englisch und ich bei manchen gar nicht mehr hundertprozentig weiß, was eigentlich die Frage war, beziehungsweise absichtlich, damit man die auch in verschiedene Richtungen fragen kann. Aber ist ja doch schon ein paar Jahre her. Und außerdem habe ich relativ viele Fragen noch, die wir gar nicht alle unterbekommen und jetzt muss ich die interessantesten rauspicken.

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

Stellst du den Fragenkatalog in die Show-Notch später?

Wolfi Gassler (00:44:56 - 00:45:31)

Ah, das machst du sowieso mit deinen Sprungmarken. Da hast du ja die Fragen dann sozusagen sowieso ausformuliert. Aber ich kann natürlich alle zusammen dann nochmal reinstellen. Das geht schon. Hast du eine Herangehensweise, wenn du mit anderen Meinungen oder mit anderen hartnäckigen Meinungen umgehen musst? Wenn du zum Beispiel mit einem Teamkollegen oder Chef oder auch im Team, wenn es da irgendwie harte Fronten gibt, unterschiedliche Meinungen, um diese Bad-Situation aufzulösen? Hast du da eine allgemeine Herangehensweise? Oder wie würdest du herangehen an so ein Problem?

Andy Grunwald (00:45:31 - 00:45:52)

Ich bin erst mal ein Freund von gesundem Konflikt. Und ein gesunder Konflikt ist a, objektiv und nicht subjektiv, also immer auf Fakten basierend, b, nie persönlich werden, weil es geht immer nur um die Sache und nicht um die Person selbst. Stopp. Natürlich kann es ab und zu auch um die Person selbst gehen, aber ich hoffe mal, wir sind jetzt bei einem zweihartnäckigen Meinung, wie man etwas umsetzt oder so.

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

Bleiben wir mal bei dem Thema, eher technischer Konflikt.

Andy Grunwald (00:45:54 - 00:46:56)

Und solange diese Diskussion offen und objektiv und ruhig bleibt, bin ich da auch gerne dabei, dazuzuhören, weil ich denke, da kann man immer sehr, sehr viel lernen. Wie man eine PAD-Situation auflöst, ist eine gute Frage. Ohne jetzt ein spezifisches Beispiel zu haben, ist das recht schwierig. Aber nehmen wir mal Folgendes an. Wir haben ein ... Sieben-Mann-Team oder fünf-Mann-Team, zwei Leute streiten sich gerade darüber, wie man ein Feature am besten umsetzt. Bei einem solchen Punkt spielen eine ganze Menge Faktoren außerhalb dieser Diskussion eine Rolle. Wie zum Beispiel, welche Lösung kann denn vom Team und auch vom Wissensstand des Teams denn mittel- bis langfristig maintained werden? Oder müssen alle im Team eine neue Programmiersprache lernen? Ist das zeitlich machbar? Ist die Firmenstrategie, die Firmen-Tech-Strategie überhaupt mit dieser neuen Programmiersprache in line? Oder bist du jetzt das erste Team, was Rust einsetzen möchte, nur weil das einer in seiner Freizeit ein bisschen programmiert? Nehmen wir mal als Beispiel.

Wolfi Gassler (00:46:57 - 00:47:00)

Also zusammenfassend, du würdest dir auch eine Meinung dazu bilden.

Andy Grunwald (00:47:00 - 00:47:08)

Ich würde mir das alles erstmal anhören, weil nur, ich brauche ja eine Meinung, um die ganze Sache ein bisschen zu guiden, um auch das Problem des Konfliktes mal zu verstehen.

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

Okay, jetzt hast du da fünf Leute links, fünf Leute rechts sitzen, die streiten da um irgendwie, was sie für Sprache zum Beispiel verwenden. Du hast dir jetzt auch eine Meinung gemacht, was passiert dann?

Andy Grunwald (00:47:19 - 00:47:25)

Du hast gerade die Anzahl gehört von meinen Teammitgliedern, oder? Fünf oder sieben. Warum habe ich das gemacht?

Wolfi Gassler (00:47:25 - 00:47:32)

Dein siebter ist gerade krank. Aber es ist ja egal, sogar wenn du drei gegen vier hast, willst du dann einfach sagen, die Mehrheit bestimmt?

Andy Grunwald (00:47:32 - 00:49:19)

Wenn es nicht komplett auf ist wenn es nicht komplett auf ist mit den informationen die ich habe die ich dann versuche soweit wie möglich zu teilen ja das bedeutet mit der firmenstrategie mit der it infrastruktur mit kosten oder budgets etc etc das muss ja auch alles noch im rahmen bleiben und auch noch in die vorhandene infrastruktur mit einspielen ja Prinzipiell bin ich immer immer immer ein freund davon dass das team selbst zu einer lösung kommt und ich bin auch immer noch da fest überzeugt die verdienen allen schweine geld das sind alles erwachsene menschen ja deswegen ich höre mir die meinung an wenn beide meinungen ok sind. Wenn beide Lösungen möglich sind und die kommen einfach nicht zu einem Ergebnis, dann stelle ich mögliche Optionen wie zum Beispiel, wir können die Entscheidung vertagen bis morgen und dann voten wir. Oder ihr könnt jetzt noch zwei Stunden diskutieren und kommt dann geschlossen mit einer Meinung raus, ohne dass ich. Und wenn wir bis Datum und Zeit X keine Entscheidung haben, dann treffe ich eine Entscheidung. Weil im Endeffekt bin ich die verantwortliche Person. Das Team ist jedoch die ausführende Kraft und meines Erachtens nach sollte ich die Motivation von dem Team nicht zerstören. Aber da kommt es wieder drauf, das sind alles erwachsene Menschen. Die wissen den Kontext der Firma, die wissen was Arbeit ist und ich möchte nur verstehen, wer die besseren Daten an der Hand hat, um seinen Punkt klar zu machen. Ich gehe davon aus, dass beide Lösungen bereits ein Designdokument haben, dass mögliche Alternativen durchleuchtet wurden, inklusive Vor- und Nachteile und allem drum und dran. Das setzt sich gerade voraus. Weil du kannst nicht einfach mit einer fixen Schnapsidee, die du morgens bei der Dusche hattest, für ein großes Projekt da reinkommen und dann so einen Knatsch aufmachen. Das geht nicht.

Wolfi Gassler (00:49:19 - 00:49:23)

Bei verhärteten Fronten sollte das schon der Fall sein, dass das alles im Vorhinein passiert.

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

Ganz genau, das bedeutet, wir haben alle mal unsere Daten niedergeschrieben, wir hatten alle genug Zeit, das alles zu lesen, das Dokument zu durchzukommentieren, zu challengen, alternative Implementierungen anzusehen, et cetera, et cetera. Das ist alles passiert.

Wolfi Gassler (00:49:39 - 00:50:28)

Eine interessante Antwort, die ich auch bekommen habe oder eine von vielen auch von dieser Person war, ich hole mir einfach mal einen Agile Coach rein, um einfach frischen Wind von außen zu bekommen, dass irgendwer neuer mal diesen Konflikt sieht und vielleicht auch aufbricht. Der Teamlead ist vielleicht auch eh auch so eine Person. Aber ich finde, das vergisst man ganz oft, dass es ja auch ganz viele andere Leute in der Firma gibt und man denkt immer so geschlossen im Team, vor allem wenn es wirklich verhärtete Fronten sind und es gibt einen Agile Coach, dann warum sollte man den nicht auch einbinden und vielleicht fragen. Also ich finde sowas auch immer ganz gut, irgendwie nicht zu vergessen, dass es vielleicht auch andere Leute gibt in der Firma, die helfen können. Es muss nicht ein Agile Coach sein und es kommt immer darauf an, wie fortgeschritten das Ganze ist, aber man kann alle Ressourcen nutzen, die halt so in der Firma irgendwie verfügbar sind und auf die sollte man auch zugreifen.

Andy Grunwald (00:50:29 - 00:51:34)

Unglaublich guter Punkt und muss ich auch zugeben, ich schließe mich da nicht aus, dass ich das auch öfters vergesse, doch ich möchte auch noch zwei Punkte mit reinbringen. Ab und zu, je nach Diskussion, kann es vom Vorteil sein, aber auch ab und zu von Nachteil, wenn man weiß, worüber die Diskussion gerade geht. Das bedeutet, wenn man das Wissen über die technischen Details hat, kann es ab und zu von Vorteil sein, ab und zu von Nachteil. Je nach Situation. Der zweite Punkt ist, mit Agile Coaches tue ich mich ab und zu ein bisschen schwer. Nicht, weil ich die nicht mag, doch, weil ich in meiner Karriere noch nicht so unglaublich viele gute Agile-Coaches gesehen habe. Und mit gute meine ich nicht Leute, die jetzt gerade das Scrum-Zertifikat haben und sagen, wir müssen jetzt alles in Story-Point-Log genau nach Prozess machen und so weiter. Sondern die wirklich eine Dynamik des Teams verstehen, die wirklich eine Dynamik der einzelnen Teammitglieder verstehen, wirklich Leute, die coachen können und Konfliktsituationen auch beruhigen können und allem drum und dran. Leute mit solchen Hardskills habe ich schon gesehen, aber selten.

Wolfi Gassler (00:51:35 - 00:52:02)

Ich muss sagen, die Agile Coach oder beinahe alle Agile Coach, zumindest der Großteil, mit denen ich gearbeitet habe, waren eigentlich sehr, sehr hilfreich und sind vom Team auch so als hilfreich wahrgenommen worden, weil ich das halt auch probiert habe, oft nachzufragen. Also kann ich eigentlich nicht bestätigen. Klar, es gibt einfach schwierige Situationen und nur wenn man Agile Coach ist, kann man da deswegen auch nicht irgendwie zaubern. Aber so eine externe Person zu haben, ist durchaus ganz, ganz hilfreich. Aber es kommt natürlich immer auf das Setup drauf an, ganz klar.

Andy Grunwald (00:52:03 - 00:52:22)

Da stimme ich dir zu. Im Operations-Bereich sieht's ab und zu natürlich ein bisschen anders aus. Da hat man sehr, sehr viel ungeplante Arbeit versus geplante Arbeit wie in einem Software-Entwicklungsteam, in einem klassischen ... Ich will nicht sagen, dass Operations nicht Softwareentwicklung ist, sondern eher die Balance an geplanter versus ungeplanter Arbeit ist einfach anders.

Wolfi Gassler (00:52:22 - 00:52:34)

Ja, definitiv. Es ist schwieriger dort einfach, keine Ahnung, Scrum zum Beispiel anzuwenden. Wobei jetzt wahrscheinlich ganz viele Rückmeldungen kommen, wie einfach Scrum ist im SRE-Bereich. Aber lassen wir das mal dahingestellt.

Andy Grunwald (00:52:34 - 00:53:04)

Man kann auch Kanban anbieten, aber man muss auch ganz ehrlich sagen, Kanban richtig und produktiv in einem Team einzusetzen, ist nicht einfach. Es reicht nicht, wenn alle Leute sich immer nur ein Ticket von links nehmen. Sondern das Ziel ist, dass ein Ticket von links nach rechts möglichst schnell geht. Das bedeutet auch, dass jemand, der out of work ist, der gerade neue Arbeit sucht, der sollte eigentlich rechts an Bord anfangen, um jetzt zu gucken, welchen Teammitgliedern kann ich helfen, ihr Ticket anzublocken und weiterzumachen. Und dieses Mindset reinzukriegen, ist nicht immer einfach.

Wolfi Gassler (00:53:05 - 00:53:50)

Also meine Erfahrung mit Kanban war bisher immer so, dass einige Teams auf Kanban wechseln wollten, die haben auch wechseln können und haben dann aber sehr viele Schwächen gesehen bei Kanban oder hatten Probleme in gewissen Bereichen und haben dann angefangen entgegenzusteuern und haben dann so viele Regeln und Meetings drauf gelegt, dass man am Ende fast wieder bei Scrum war. Also man ist dann fast wieder selbstständig zurückgekehrt zu dem Bereich, hat es aber immer noch Kanban genannt. Aber gut, das ist ein anderes Thema. Ich habe jetzt noch relativ viele Fragen, die wir alle nicht mehr behandeln können. Darum möchte ich eine ganz kurze einfache stellen. Was ist der Unterschied zwischen Senior und Junior? Na Spaß, okay. Da machen wir eine eigene Sendung drüber, das ist keine kurze Frage. Aber eine kurze Frage vielleicht ist, warum sollte ich dich nicht anstellen oder in diesen Job nehmen, Andi? Das ist meine Lieblingsfrage.

Andy Grunwald (00:53:51 - 00:54:18)

Das ist eine Killerfrage, die wurde mir so noch nie gestellt, aber die mag ich sehr und ich glaube, die werde ich auch mal übernehmen. Du solltest mich nicht einstellen, wenn du nicht magst, gechallenged zu werden. Denn wenn du mein Vorgesetzter bist, werde ich dich auch herausfordern, nicht um eine Rangfolge oder ähnliches, sondern ich bin eine Person, die Sachen nicht halbgarmacht. Ich bin eine Person, die für ihre Sachen kämpft, aber auch weiß, wo meine Grenzen sind, sofern sie mir gesetzt werden.

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

Aber das ist jetzt so eine positive Sache umformuliert in eine negative, die eigentlich jeder als positiv sehen würde. Okay, okay.

Andy Grunwald (00:54:25 - 00:54:33)

Dann, das ist kein Geheimnis und das sage ich auch meinen Vorgesetzten. Ich kommuniziere sehr direkt und ich bin sehr ungeduldig.

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

Ja, das ist schon besser. Das kann ich auch bezeichnen.

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

Ich verstehe nicht, wenn Leute ihre Arbeit nicht ordentlich machen. Das verstehe ich einfach nicht. Ich bin sehr ungeduldig und ich bin auch sehr direkt in meiner Kommunikation. Ich sage öfters, das ist scheiße, anstatt, das ist optimierungsbedürftig. Das ist meine Schwäche.

Wolfi Gassler (00:54:49 - 00:54:53)

Das hast du, glaube ich, in einem Interview als Feedback bekommen, oder? Dass du zu direkt bist.

Andy Grunwald (00:54:53 - 00:54:56)

Das weiß ich ja auch selbst. Aber auf der anderen Seite... Ich sehe.

Wolfi Gassler (00:54:57 - 00:55:01)

Das als Vorteil eigentlich, aber Gott, nicht jeder ist so, ja.

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

Inzwischen verstehe ich schon, dass das besonders im internationalen Umfeld schwierig sein kann, weil ziemlich viele Kulturen halt nicht so sind.

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

Da können wir übrigens unsere Folge... Wir haben schon so viele Folgen gemacht, dass ich nicht einmal mehr diese Folgen finde. Es ist Folge 26. Folge 26 in Folge 26, wo es auch um die Arbeit in internationalen Teams geht.

Andy Grunwald (00:55:21 - 00:55:53)

Direkt darf man aber nicht mit impulsiv verwechseln. Das sind zwei unterschiedliche Attribute. Aber ich kommuniziere sehr direkt. Mir wird auch nachgesagt, ich kümmere mich zu viel. Nicht um einzelne Mitglieder, sondern mir liegt die ganze Sache zu sehr am Herzen. Das wird mir nachgesagt. Das wären vielleicht so die zwei negativen Punkte, die ich hätte, weswegen du, Wolfgang, mich nicht als ein Nachfolger einstellen solltest. Ob das dann jetzt positiv oder negativ ist, kannst du selbst für dich beurteilen.

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

Ich werde mir das überlegen, ja. Ich glaube, es ist eine gute Abschlussantwort zu dem Ganzen.

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

Jetzt würde ich aber gerne mal wissen, hättest du mich eingestellt?

Wolfi Gassler (00:56:02 - 00:56:05)

Natürlich hätte ich dich eingestellt, aber dazu hätte ich auch nicht dieses Interview gebracht.

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

Oh, das hast du schön gesagt.

Wolfi Gassler (00:56:08 - 00:56:49)

Aber ich glaube, es war auch relativ real, auch von der Länge her. Ich habe auch nicht allen Leuten immer alle Fragen gestellt. Es war so immer eine Stunde circa. Von dem her sind wir, glaube ich, gut in der Zeit. Und man merkt schon, dass es eigentlich relativ allgemeingültige Fragen sind, die gar nicht so jetzt irgendwo ins Detail gehen. Aber wo man schon sehr viel rausfindet, meiner Meinung nach zumindest von den Leuten, wie sie arbeiten, wie sie in dem Team arbeiten, wie sie Leadership sehen, was das für die jeweilige Person ist. Also man braucht da gar keine fancy Fragen eigentlich stellen oder ganz konkrete Szenarien bringen. Meiner Meinung nach, wenn man darüber diskutiert, über diese Dinge auch ganz offen, vielleicht gegenseitige Meinungen abklopft, dann findet man da schon viel raus bei so einem Interview.

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

Und ich bitte alle Hörerinnen und Hörer, macht euch mal eine eigene Meinung über die.

Wolfi Gassler (00:56:53 - 00:57:03)

Über Andi, eine eigene Meinung über Andi. Jetzt wisst ihr genau, was der Andi da so denkt. Und jetzt kommen sicher ganz viele Anfragen. Die wollen dich alle einstellen, Andi.

Andy Grunwald (00:57:03 - 00:58:13)

Macht euch auch eine eigene Meinung über mich. Ich hoffe, die habt ihr schon. Auf jeden Fall, kopiert niemals solche Antworten, weil solche Antworten spiegeln sich eigentlich in eurem täglichen Doing wieder. Wenn ihr die Erfahrung noch nicht habt, sagt da ganz offen, hey, weiß ich grad noch nicht, aber was ich mir denken könnte, ich würde das so oder so angehen. Auch in Interviews, wenn ihr das sagt. Und der Wolfgang sagte am Anfang, okay, Podcasts werden geschnitten, und ja, wir schneiden auch diverse Äs und Ös raus, Pausen auch. Dennoch, auch in einem Interview könnt ihr sagen, einen Moment, ich muss kurz drüber nachdenken und dann 10, 20, 30 Sekunden. Das ist alles kein Problem, denn ihr wollt ja auch eine gute Antwort geben und besonders bei solchen Fragen ist das nicht immer einfach, denn das sind oft subjektive Antworten auf Basis eurer Erfahrung oder wie ihr denkt, dass ihr euch verhaltet. Deswegen nehmt euch da ruhig Zeit, um das zu antworten. Es gibt leadership styles gibt es wie noch und nöcher da gibt es super viele der wolfgang hatte mir während des podcast auch einen link geschickt was glaube ich dann sehr nah an meine beschreibung kommt nennt sich servant leadership ist wird unter anderem von simon zimmig geprägt.

Wolfi Gassler (00:58:14 - 00:58:20)

Könnten wir eigentlich mal eine eigene Folge drüber machen oder? Das geht so in die Tiefe und ist sehr breit.

Andy Grunwald (00:58:20 - 00:59:14)

Ist aber ein Leadership-Style, der sportlich ist, würde ich sagen. Der fordert und der muss auch meines Erachtens nach von der Firma unterstützt werden. Denn ich hatte auch schon Leute, die wollten unbedingt in eine Leadership-Position, weil die die Kontrolle haben wollen. Und ja, es gibt auch solche Firmen, die sehr strikt geführt sind. Die modernen Start-ups oder modernen Tech-Firmen sind es eher nicht. Die gehen mehr und mehr in diesen Servant-Leadership-Style. Macht euch einfach mal ein Bild. Ich bin kein großer Freund von dieser dauerhaften Leadership-Style-Kategorisierung. Es ist gut, diese mal zu kennen. Googelt einfach mal, was für sieben oder acht diverse Leadership-Style-Kategorien es gibt. Lest ihr euch mal durch ein paar Attribute. Das ist ganz gut, um das mal zu wissen. Ob man da jeder in so eine Schublade schieben muss, weiß ich nicht. Und ich denke, es ist auch wichtig, Pro-Person-Erfahrung und Co. einen anderen Leadership-Style anwenden zu können, nicht müssen.

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

Sollen.

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

Von mir aus auch sollen. Die Erfahrung müsst ihr alle selbst machen. Der Punkt ist, all diese Antworten, die ihr heute gehört habt, das ist mein Style, das ist meine Antwort. Könnt ihr gerne kopieren. Macht euch aber bitte ein paar Gedanken, wie ihr das seht. Weil wenn ihr euch als eine Person ausgibt, die ihr nicht seid, das fällt euch immer auf die Füße.

Wolfi Gassler (00:59:36 - 01:00:07)

Und wir würden uns natürlich auch interessieren über eure Meinung, wie ihr das Ganze gefunden habt, dieses Format. Es war wirklich sehr kurzfristig und wir haben uns einfach überlegt, okay, wir machen mal so eine Art Interview-Session in dem Podcast. Also wenn das sinnvoll ist, wenn ihr auch dabei viel mitnehmt, können wir auch so etwas Ähnliches nochmal in die Richtung machen. Gerade im Interview-Bereich haben wir Möglichkeiten, da noch einiges zu bringen. Also bitte lasst uns das wissen, Feedback wie immer bei Twitter, ING, Kiosk oder städtisch at engineeringkiosk.dev per E-Mail.

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

Ich würde mich natürlich auch freuen, wenn ich auch mal gechallenged werde, deswegen auch gern objektives Feedback.

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

An Ruhrbot Assi, was haben wir da für eine E-Mail eingerichtet?

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

Wolfgang darf das aber auch lesen. Ansonsten, ich hoffe ihr hattet Spaß. Auch wenn ihr in keiner Leadership Position seid, das hat nicht nur mit Engineering Management zu tun, sondern auch Senior und Staff Engineers sollten meines Erachtens nach solche Attribute an den Tag legen. Wenn ihr also ein Senior, Staff oder Principal oder Distinguished Engineer seid und ihr habt dadurch ein bisschen Inspiration geholt, trainiert das doch einfach mal ein bisschen oder unterhaltet euch mit eurem Leadership oder Agile Coach mal darüber. Das gibt auch immer ganz schöne Shads. Ansonsten wünschen wir einen schönen Tag.

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

Bis bald. Ciao.