#75 Evaluierung deiner Job-Performance, Team-Feedback und LNO Framework

Woher weißt du eigentlich, ob du einen guten Job machst? Wie erkennst du Blindspots oder ob du an den richtigen Dingen arbeitest?

Das ist eine Frage, die sich jeder im Arbeitsleben mal stellen sollte. Weiß ich, was von mir erwartet wird? Kann ich sagen, wie Erfolg in meiner Rolle aussieht? Bzw. Was ist das ursprüngliche Problem-Statement, welches ich mit meiner Rolle lösen soll? Alles keine einfachen Fragen, jedoch notwendig, um beim nächsten Performance-Cycle und Gehaltsgespräch nicht enttäuscht zu werden.

In dieser Episode sprechen wir genau darüber: Wir geben Tipps, wie du eine Art Selbst-Evaluierung zu deiner Arbeitsleistung durchführen kannst oder welche Schritte du gehen kannst, um den Prozess zu starten. Wir sprechen über die Schwierigkeit von gutem Feedback, über Job-Beschreibungen, Peer-Coaching, konkrete Arbeit als Team-Lead, Feedback-Cycle in deinem Job, wie wichtig es ist, das Business-Model der Firma zu verstehen und über Schubladendenken bei Leverage, Neutralen und Overhead-Aufgaben.

Bonus: Ob CV Driven Development was schlechtes ist und ob "Da kann man nicht meckern" das Lob der Deutschen ist.

Das schnelle Feedback zur Episode:

👍 (top) 👎 (geht so)

Sprungmarken

(00:00:00) Intro

(00:01:03) Imposter-Syndrom

(00:02:12) Selbstevaluierung, "Bin ich gut genug?" Und mach ich noch einen guten Job?

(00:04:20) Was ist denn eigentlich dein Job, hast du eine Job-Beschreibung und Selbst-Reflektion

(00:10:06) Was ist dein konkreter Beitrag zum Erfolg des Teams? Wie sieht Erfolg in deiner Rolle aus?

(00:17:01) Tech-Lead-Mythos: Keine Beförderung, sondern ein Karrierewechsel

(00:22:51) Konkrete Beispiele für deine Arbeit als Lead und messbare Ergebnisse

(00:28:08) Team-Umfragen

(00:30:17) Ehrliches Feedback benötigt Mut und was gutes Feedback eigentlich ausmacht

(00:34:15) 360°-Evaluierungen, Gruppen-Feedback und Blindspots finden

(00:41:57) Ergebnisse und Ziele transparent machen

(00:45:32) Peer-Coaching und Peer-Groups

(00:47:48) Nachdenken ist ein aktiver Teil deiner Arbeit und arbeite ich an den richtigen Dingen?

(00:51:56) Verstehe das Business-Modell deiner Firma und wer ist der Kunde

(00:56:13) LNO Effectiveness Framework

(01:00:03) Outro

Hosts

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

Feedback (gerne auch als Voice Message)

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

Transkript

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

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

Wo ich allergisch gegen bin, ist diese, ich liebe es Leute zu enablen. Ja, aber wie denn? Komm mal zum Punkt hier, komm, red Tacheles. Feedback erfragen und wirklich Feedback bekommen ist eine unglaublich schwierige Geschichte.

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

Als Junior erledigt man einen Task und bekommt direkt das Feedback von Lead oder auch den BenutzerInnen. Kaum hat man mehr Verantwortung als Tech Lead, Engineering Manager oder Staff Engineer, ist es vorbei mit dem kurzen Feedback-Zyklen. Und man fragt sich irgendwann, mach ich eigentlich noch einen guten Job? Eigentlich deliver ich doch gar nichts mehr. Und genau darum geht es in dieser neuen Engineering Kiosk Episode. Wirklich cool, dass du auch wieder dabei bist. Wir sprechen darüber, wie man trotzdem in diesen Positionen an Feedback kommt, wie sich Feedback-Zyklen ändern, wie man eigene Blindspots erkennt und wie man sich egoistisches CV-driven Development zunutze machen kann.

Andy Grunwald (00:00:58 - 00:01:10)

Los geht's! Frau Frank, in der Regel fragt man Frauen nicht nach ihrem Alter, aber du bist ja keine Frau, deswegen kann ich dich nach dem Alter fragen. Wie alt bist du inzwischen?

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

Ich glaube so zwei Musikgenerationen älter als du.

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

Warum stelle ich mir die Frage, wie alt du bist? Denn als du mir das heutige Thema vorgeschlagen hast, habe ich mich gefragt, hat der liebe Herr Gastler Irgendwie so eine so eine mit life crisis gerade weil es gibt ja dieses gewisse alter da wo fragt man sich okay Was mache ich hier eigentlich warum warum bin ich da wo ich bin und bin ich eigentlich gut genug dafür das was ich.

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

Hier tue Ich wollte gerade sagen, eigentlich frage ich mich das bei jeder Aufnahme, aber ich frage mich natürlich nicht, ob ich gut genug bin für die Aufnahme.

Andy Grunwald (00:01:40 - 00:01:42)

Leidest du unter dem Impostor-Syndrom?

Wolfi Gassler (00:01:42 - 00:01:49)

Bei ganz vielen Themen schon, die wir aufnehmen, ja das stimmt. Ich bin natürlich gut genug, um mit dir zu sprechen, da habe ich keine Probleme.

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

Hast du denn aktuell deine Lebenskrise, deine Midlife-Crisis?

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

Das war ja noch zu früh, oder? Ich weiß nicht, was das Durchschnittsalter derzeit ist. Naja, vom Durchschnittsalter, wie alt man wird, kommt es vielleicht fast hin.

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

Erklär uns doch mal bitte, welches Thema du dir für heute gewünscht hast und wie du auf dieses Thema kommst, damit nicht alle denken, dass du jetzt gerade in deiner Midlife-Crisis bist, es aber noch nicht erkannt hast.

Wolfi Gassler (00:02:12 - 00:03:24)

Ja, warum mir dieses Thema gerade so spontan eingefallen ist, weiß ich gar nicht, weil es ist eigentlich ein alter Hut und es kommt immer, immer wieder und es kommt vor allem immer wieder an die Oberfläche, wenn man in irgendeinen neuen Job oder in eine neue Position reinkommt, wo man vielleicht mehr Verantwortung übernimmt, wo man in gewisser Weise in irgendeine Lead-Rolle reinkommt, dass man sich fragt, okay, macht man eigentlich einen guten Job und wie finde ich denn heraus, ob ich überhaupt einen guten Job mache? Weil das Problem ist ja, umso weiter man weg von der IC, also von diesem Individual Contributor, von dem klassischen Junior, wo ich beginne in einem Team und irgendwie ständig Feedback bekomme vom Team und von meinem Manager, wenn ich aus dieser Rolle herauswachse und weiter nach oben gehe, in welcher Form auch immer, umso schwieriger wird es eigentlich einzuschätzen, ob man noch einen guten Job macht und umso weniger Feedback bekommt man auch, weil man hat nicht mehr den Manager, der sich um alles kümmert. der einem tagtäglich erklärt, ob man einen guten Job macht oder nicht. Und dann wird es irgendwann schwierig zu wissen, okay, bin ich eigentlich noch am richtigen Weg, mache ich noch einen sinnvollen Job. Ich weiß, das fragst du dich nie, Andi, weil du natürlich immer einen guten Job machst, ist schon klar. Aber manche Leute fragen sich das.

Andy Grunwald (00:03:25 - 00:03:57)

Aber was heißt denn überhaupt einen guten Job machen? Also ich meine, in der deutschen Kultur, du hast einen guten Job gemacht, wenn nicht gemeckert wird. Also was heißt denn für dich jetzt einen guten Job machen? Und ich sag mal so, die jährliche Gehaltserhöhung und der Boni und so weiter und so fort, das ist ja schon irgendwie implizit, das sagt ja schon irgendwie implizit aus, hey, du hast einen guten Job gemacht, deswegen kriegst du jetzt eine Gehaltserhöhung. Also nicht jedes Jahr kann man eine Gehaltserhöhung auf Basis von Inflationsausgleich geben. ist das nicht irgendwie du hast einen guten job gemacht oder also was was verstehst du denn ich mache einen guten job was verstehst du darunter.

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

Ja das problem mit dem bonus ist ja auch immer so eine sache die manager von dieser schweizer bank die gerade pleite gegangen ist die haben ja dann auch noch einen bonus bekommen nachdem sie das in die pleite getrieben haben dieses ganze unternehmen, Und man bekommt ja dieses Feedback dann vielleicht auch nur einmal im Jahr und noch dazu nur von einer Richtung, von dem Manager. Und meistens ist halt ein Job viel, viel mehr als diese eine Dimension, die es da gibt. Und da sind wir eigentlich schon bei der Gretchenfrage. Was ist denn eigentlich der Job, wie du richtig sagst? Und wie ist denn der Job definiert? Habe ich überhaupt eine Job-Positionsbeschreibung? Bin ich mir selber im Klaren drüber? Hat mir mein Manager mal eine Beschreibung gegeben? Gibt es irgendwie in der Firma eine Beschreibung von dieser Position? Oder ist das wie in ganz ganz vielen Firmen einfach so ganz vage definiert oder einfach mach mal? Was gerade bei den höheren Positionen, wenn es in Richtung Tech Lead geht, Staff, Principal Engineer, ganz oft der Fall ist, dass man einfach nur hört, ja start mal los, ist eh einigermaßen klar, oder?

Andy Grunwald (00:04:56 - 00:06:05)

Aber das ist ganz interessant, was du gerade angesprochen hast. Natürlich, wenn ich gerade Berufseinsteiger bin, ich bin Junior, dann werde ich in der Regel an die Hand genommen. Und umso länger ich dabei bin, umso mehr Erfahrung ich kriege, umso höhere Gehaltsbinder ich habe, umso größere Projekte ich mache, desto mehr wird natürlich erwartet, dass ich selbst die ganze Sache treibe mit möglichst wenig Anweisung. Und das sagt mir auch irgendwie, dass wenn ich die Frage stelle, mach ich eigentlich einen guten Job bzw. wie kann ich eigentlich selbst evaluieren, ob ich einen guten Job mache, dass da auf jeden Fall ein gewisser Grad an Reife und Selbstreflexion vorhanden sein muss. Ich bin mir nicht sicher, ob die Frage als Junior oder Juniorin, also als Berufseinsteiger wirklich Sinn macht, weil da ist irgendwie der Fokus auf Lernen, wie funktioniert das Business, wie baut man IT-Projekte und so weiter. Deswegen sollte man die Frage, glaube ich, als Berufseinsteiger einfach nicht stellen, aber wenn man sagt, ich bin jetzt schon fünf Jahre, sechs Jahre dran und frage mich schon, okay, mache ich jetzt hier eigentlich meinen Job ganz gut, kann ich auf die nächste Beförderung hoffen oder wohin möchte ich mich weiterentwickeln? Ja ein gewisses Grad an Reife wird da schon glaube ich erwartet oder?

Wolfi Gassler (00:06:05 - 00:06:59)

Ja ich glaube teilweise zu viel und oft ist es ja auch so eine Ausrede ja wir sind ein junges dynamisches Startup mit ein paar tausend Mitarbeitern und wir sind noch so flexibel das heißt lauf mal einfach los wir machen das immer so in deiner Position du machst es schon. Das hört man ja immer wieder mal und ich bin erstaunt, auch in großen Firmen, Tech-Firmen mit über 10.000 Mitarbeitern, dass teilweise keine Definitionen von einem Staff zum Beispiel existieren. Ist einfach so. Und das sind aber Vorzeigeunternehmen in der Branche. Und da muss man dann wirklich Selbstreflektion, eine gewisse Reife an den Tag bringen, um sich mal überhaupt zu überlegen, was ist eigentlich mein Job und wie finde ich denn das heraus? Weil, keine Ahnung, von den zehn Jahren bei dir, wo du in einer Lead-Rolle warst, in wie vielen Jahren von den zehn hattest du eine schriftliche Definition von deiner Rolle?

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

Das ist eine sehr gute Frage und ich muss jetzt gerade auch ganz kurz überlegen. Es wurden Erwartungen an mich kommuniziert, aber auch oft, nachdem ich erst gefragt habe. Aber ich hatte noch nie einen One-Pager, wo draufsteht, das sind deine Key-Aufgaben und so sieht Erfolg aus. Man muss ja auch sagen, die Erwartungen, die an mich gestellt wurden, die haben sich dann quartalsweise oder halbjährlich wirklich auch teilweise stark geändert, weil das Umfeld sehr dynamisch war. was ist natürlich dann in irgendeiner art und weise schwierig gemacht hat gut in meinem job zu sein ich glaube ein key kriterium durch meine letzten zehn jahre war eigentlich dass ich sehr flexibel war beziehungsweise mich nicht gegen änderung gesträubt habe ich glaube das war ein kriterium dass ich gut in meinem job war.

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

Und wie hast du dann rausgefunden was deine deine rolle war weil du gesagt hast du hast nachgefragt.

Andy Grunwald (00:07:48 - 00:10:05)

Lustigerweise habe ich eigentlich, Mir die selbe Frage gestellt, wie in diesem Podcast. Wann weiß ich, dass ich eigentlich gut bin? Beziehungsweise, was wird von mir erwartet? Beziehungsweise, angenommen wir leben in der perfekten Welt, wie sieht denn Erfolg in meiner Rolle aus? Beziehungsweise, woran werde ich gemessen? Und diese Frage habe ich mir gestellt und die habe ich auch immer hochgeschmissen. Also nicht hochgeschmissen und ich fange es wieder auf, sondern wirklich die Leiter hoch. Ich habe das immer meinem Manager gestellt. Und in der Regel waren diese Personen dann aber auch sehr überrascht von diesen Fragen. Denn das sind zwar Fragen, die sehr einfach gestellt sind, aber sehr, sehr schwer zu beantworten sind. Was von mir erwartet wird, okay, das kann man gegebenenfalls noch formulieren. Ab und zu kommen da Floskeln, ab und zu kommt da was Konkretes, aber zum Beispiel kann man ja aktive Kommunikation erwarten, dass wenn Probleme auftreten, dass man früh genug Bescheid weiß, dass man immer lösungsorientiert arbeitet, dass wenn man was challenge das objektiv challenge aber nicht subjektiv und so weiter und so fort ja dann natürlich auch dass man das operative wenn bei einem lied zum beispiel das people management macht gehaltserhöhung und blabli blub ja sowieso also da all das was ich sag mal zum job dazu das kann man glaube ich noch recht gut formulieren aber dann die frage wie sieht eigentlich erfolg in der rolle aus beziehungsweise woran wirst du gemessen Und das ist natürlich eine Frage, die sehr, sehr schwer zu beantworten ist, denn obwohl wir alle Technikerinnen und Techniker sind und hoffentlich alle sehr, sehr data-driven arbeiten, arbeiten wir in einem kreativen Job. Wir arbeiten mit Menschen, wir arbeiten sehr viel mit Subjektivität, mit Gefühlen und Co. Und die ganze Sache kann man halt nicht wie zum Beispiel Memory Usage auf dem Server in einem Graph messen. Und deswegen ist es natürlich sehr schwer klar festzustellen woran du gemessen wirst deswegen haben ja auch zum beispiel zielsetzungen wie okas und ko du bringst dieses projekt über die bühne oder irgendwelche produkt businessmetriken werden von dir getrieben wie zum beispiel. Jetzt bei mir im SAE und Cloud und DevOps Bereich ist es dann sehr oft, hat das irgendwas mit Cloud Spend zu tun, also wie viel Geld geben wir bei Google und Amazon aus, was können wir optimieren. Das sind halt objektive Metriken, die man messen kann, aber das hat dann weniger mit der People Management selbst zu tun, sondern eher mit der funktionalen Rolle deiner Suborganisation.

Wolfi Gassler (00:10:06 - 00:10:55)

Das Problem ist ja auch, umso weiter du von der IC-Rolle weg wächst, umso schwieriger ist es dir irgendeinen Erfolg klar zuzusprechen. Weil wenn Teams erfolgreich sind und du bist der Engineering Manager oder du bist der Tech Lead von mehreren Teams oder bist Cross-Functional, vielleicht über mehrere Teams hinweg verantwortlich für irgendwelche Architekturen und die Teams sind erfolgreich, die Teams sind schneller, dann ist es nicht so klar dir zuordnenbar, weil da halt ganz viele Leute involviert sind. Und das macht die Sache natürlich dann auch nochmal schwieriger, weil es nicht klar ersichtlich ist, du hast nicht genau dieses Projekt delivered, sondern die Teams haben das vielleicht delivered, für die du verantwortlich bist oder du hast in irgendeiner Form mitgewirkt, aber scheinst gar nicht auf, weil du im Hintergrund die Teams aligned hast oder irgendwo supported hast im Hintergrund.

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

Da stimme ich der Vorstellung ganz zu, somit werden deine Ziele vielleicht auch ein bisschen nebliger, würde ich mal sagen. Deswegen bin ich in letzter Zeit davon weggegangen, wirklich eine Bullet-Point-Liste zu erwarten, was von mir erwartet wird, sondern ich habe den Approach gestartet, ich habe meinen Vorgesetzten gebeten, einmal das Problemstatement, welches ich lösen soll, weswegen ich eingestellt wurde, zu formulieren.

Wolfi Gassler (00:11:17 - 00:11:18)

Und hast du eines bekommen?

Andy Grunwald (00:11:19 - 00:11:24)

Ich hab eine erste Version bekommen, und da hab ich ein bisschen weiter gefragt. Wir iterieren grade drüber.

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

Ist ein spannender Ansatz, ist, glaub ich, ziemlich gut. Aber wir haben ja auch eine eigene Episode zu Wischen und Mischen gemacht. Und es ist natürlich schwierig, alles in einen Satz sozusagen hineinzubacken. Aber das ist natürlich eine super Aufgabe, weil du alles kondensieren musst auf einen kleinen Bereich oder auf einen Satz. Und dazu musst du dir natürlich extrem viele Gedanken machen. Was ist eigentlich die Kernaufgabe?

Andy Grunwald (00:11:48 - 00:13:18)

Der Riesenvorteil dabei ist natürlich auch, du bist ja lösungsorientiert und proaktiv und das wird meist von Leads oder von höheren Engineer Level erwartet. Es wird nicht erwartet, dass du das Problem aufzeigst, sondern es wird zusätzlich erwartet, dass du auch schon lösungsorientiert an das Problem herangehst mit einem positiven Mindset. Nehmen wir mal das Beispiel, ich kann meinem Chef sagen, hey, pass mal auf, schreib mir mal bitte auf, was von mir erwartet wird und wie Erfolg aussieht. Dann lagere ich das Problem auf ihn oder auf sie ab, aber wenn ich sage, hey, was ist das Problemstatement, weswegen ich eingestellt wurde, und dann arbeitet man zusammen daran an der Lösung, um das wirklich konkret zu machen und zu definieren. Das hat natürlich den riesen Vorteil, dass du auch deinen eigenen Job ein bisschen mitshapst. Weil du sagst es ja auch gerade, dein dynamisches Startup mit einer vierstelligen Anzahl an Mitarbeitern hat noch kein Leveling Guide oder ähnliches. Du grinst da jetzt vielleicht und manche Leute werden sagen, hey, hey, hey, das ist meine Firma. Genau. Machen wir uns nichts vor. Das ist halt einfach die Industrie, weil auch Leveling Guides sind toll für deine Rolle, aber Leveling Guides sind halt auch ein bisschen fluffy gehalten, weil wir arbeiten immer noch in einem kreativen Job. Dennoch sollte man in der Lage sein, beziehungsweise ein paar Tools an der Hand haben, wie man weiß, dass ich einen guten Job mache. Und ich glaube, der Key ist, dass man das halt hier und da mal macht, so alle sechs Monate oder ähnliches, weil am Ende des Tages hat man halt irgendein Feedbackgespräch oder eine Gehaltsverhandlung oder was weiß ich gar nicht und dann kriegt man halt die Quittung und wird gegebenenfalls enttäuscht.

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

Und was natürlich noch dazu kommt ist, dass dein Manager meistens gar nicht mehr den Einblick hat, weil wenn du jetzt mit deiner Managerin zum Beispiel vereinbarst, du kümmerst dich um das Team oder um das Alignment zwischen den Teams, dann können die meistens gar nicht beurteilen, ob sich das in irgendeiner Form verbessert hat, weil die haben den Einblick gar nicht, ob dein Team glücklich ist, wie glücklich dein Team ist, ob sich das irgendwie verbessert hat in der Zusammenarbeit mit anderen Teams. Da bist du da meistens auch selber gefordert, die Info irgendwie rauszubekommen oder das zu evaluieren, weil deine Managerin, die ist auf Director Ebene und die hat da null Einblick.

Andy Grunwald (00:13:55 - 00:14:04)

Aber was ist das denn auch für ein Ziel? Du musst die Kommunikation zwischen Teams verbessern. Also welches Problem löst dies? Ja, die Teams arbeiten besser zusammen, aber.

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

Ja, aber das steht ganz oft in so Rollenbeschreibungen drin, dass du verantwortlich bist, um die Kommunikation zu verbessern zwischen Teams, in der Alignment zwischen den Teams oder so, als Tech Lead oder als Architekt oder was, wie du die in Rollen auch immer nennst, im Prinzip ist ja sehr ähnlich alles.

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

Ja, wie macht man das? Man setzt one-on-ones auf, man spricht über gemeinsame Probleme und bildet ein bisschen Vertrauen. Ja, und dann? Dann hat man's. Aber was bringt das denn dem Business, beziehungsweise des Teams? Klar, die kennen sich jetzt besser und können dann gegebenenfalls schneller interagieren und schreiben sich vielleicht auch mal selbst im Slack an, weil die dann die Barrieren ein bisschen gesenkt haben. Alles super. Aber sollte man nicht eher daran arbeiten, dass diese zwei Teams gegebenenfalls sogar in der perfekten Welt ohne Kommunikation miteinander zusammenarbeiten können? sagen wir mal technisch gesehen API-Schnittstellen oder Design-Dokuments oder einem Pull-Request-Workflow oder oder oder.

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

Ja, aber egal wie es funktioniert, es ist schwierig messbar am Ende. Und das ist ja auch das große Problem. Es gibt ja bei Engineering Managern oder bei People Leads vor allem dieses klassische Problem, dass die irgendwann nicht mehr wissen, ob sie überhaupt sinnvoll sind. Weil die Teams leisten etwas, aber du als People Lead hast gar keinen direkten Bezug zu dieser Leistung. Und irgendwann fragen sich ganz viele People Leads, warum bin ich denn überhaupt da? Bringe ich denn da überhaupt was weiter? Weil gerade wenn du mit Teams zusammenarbeitest, auch jetzt gar nicht, wenn du BIPL-Verantwortung hast, dann hast du natürlich einen ganz anderen Zyklus und darüber haben wir ja schon in einigen Episoden gesprochen. Wann du denn, was heißt denn Gratification auf Deutsch?

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

Liebe Hörerinnen und Hörer, wir googeln jetzt, was Gratification auf Deutsch heißt. Befriedigung, Belohnung.

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

Belohnung ist ein gutes Wort. Wann du denn überhaupt diese Belohnung, was du geleistet hast, bekommst aus einem Team heraus, aus einer langwierigen Änderung von irgendeinem Prozess, wie die Teams zusammenarbeiten, dass die mehr APIs verwenden, wie du jetzt gesagt hast. Also das kommt ja erst ganz später heraus, wenn überhaupt, wenn das überhaupt messbar ist, was du da geleistet hast oder dass du da überhaupt etwas gemacht hast am Ende. Und darum fragen sich ja ganz viele Leads, okay, warum bin ich überhaupt da? Weil wenn alles perfekt funktioniert, und im Idealfall ist es ja so und es wird immer noch besser, fragt man sich dann natürlich, warum hat man überhaupt Leads? Und das ist ja auch ganz oft in Teams, dass sich die Teammembers fragen, warum gibt es denn den Lead überhaupt? Der bekommt auch noch ganz viel bezahlt. Und was macht der eigentlich die ganze Zeit? Also das fragen sich sehr viele Beteiligte. Und gerade in solchen Rollen muss man wirklich aufpassen, meiner Meinung nach. dass man eben selbst gar nicht da hinein verfällt, in diese Gedanken, warum bin ich denn überhaupt da, mache ich überhaupt Sinn? Aber natürlich auch alle anderen können sich diese Gedanken machen und da muss man halt irgendwie beweisen, okay, wo liegt meine Leistung? Wie man in Österreich sagt, wo war meine Leistung? Ist ja ein bekannter Spruch, führe jetzt nicht näher aus, alle Österreicher wissen Bescheid.

Andy Grunwald (00:17:01 - 00:18:45)

Aber ich meine, wovon du gerade redest, ist ja dieser typische Engineering-Manager-Tech-Lead-Staff-Engineer-Mythos. Das bedeutet, ich wechsle in eine höhere Rolle, ich wechsle in die Staff-Principal-Engineer-Rolle, ich wechsle in die Tech-Lead-Architekt-Rolle, ich wechsle in die Engineering-Management-Teamleiter-Rolle und sehe das als Beförderung an, als Promotion. Und das haben wir schon mehrmals in diesem Podcast erwähnt. Nochmal alle zum Mitschreiben. In der Regel ist das keine Promotion, sondern ein Karrierewechsel, weil dein Arbeitsfokus ändert sich halt. Dein Feedback-Cycle ändert sich. Das, was du gerade als Instant Gratification bzw. als Belohnung bezeichnet hast. wo du vorher als Software-Engineer ein Bug gefixt hast, hast den committed, der wurde in main gemerged und dann deployed und der Bug ist in Produktion gefixt. Das ist ein Feedback-Cycle, der kann wenige Stunden dauern, wohingegen du dann in einer People-Lead-ähnlichen Rolle natürlich ganz andere Feedback-Cycle hast, da du das Mindset von Leuten änderst und Guidance vorgibst etc. bis du da einen Effekt siehst. Also das ist ja auch der große Unterschied oder einer der großen Unterschiede zwischen Rollen wie Senior Engineer und Staff Engineer, dass in der Industrie gesagt wird, alles was über Senior hinausgeht, involviert deutlich mehr Soft Skills, Inter-Team-Kommunikation, Planung, Strategie und Co. Und noch kurz als Disclaimer, wenn ich jetzt hier von Soft Skills rede, das sind dann nicht die Soft Skills, sondern das sind dann die eigentlichen Hard Skills in der Staff Engineer Rolle, aber Das gleiche trifft dann natürlich auch auf Engineering-Manager, Tech-Leads und Architekten zu und Co. Das bedeutet, die Leute denken, sie schreiben mehr Code. Es geht aber genau in die andere Richtung, dass in diesen Rollen weniger Code geschrieben wird und es mehr auf Alignment, auf effiziente Zusammenarbeit und Co. ankommt.

Wolfi Gassler (00:18:45 - 00:18:56)

Aber muss ich dann einfach damit leben, dass ich in diesen Rollen weniger Feedback bekomme und weniger Instant Gratification, also sofort irgendwie sehe, was ich geleistet habe, weil einfach alles länger dauert?

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

Leben muss man damit nicht. Ich denke, man sollte aber verstehen, dass sich deine Art der Belohnung, deine Gratification ein bisschen ändert und gegebenenfalls nicht nur ein bisschen ändert, sondern wirklich ändert. Also für mich kommt es da immer auf die Motivation an, warum man denn Engineering Manager oder Tech Lead oder ähnliches wird. die meisten leute geben so die standard antwort ja sie ziehen all ihre freude und erfüllung daraus andere leute zu befähigen und den erfolg von anderen leuten zu beobachten aber im endeffekt bauen die ja selbst dann nichts mehr greifbares auf also sie sind ja dann nicht mehr hands on sondern sind ja nur noch enabler so. Ich kann das zu einem bestimmten Grad ja auch nachvollziehen, weil ich ziehe ja meine Motivation auch aus diesem dieser Art Sprichwort, dass ich seit Jahren vor mich her schiebe und auch nenne, ich habe einfach nur Bock cooles Zeug mit coolen Leuten zu machen. Das ist richtig und da ziehe ich das auch nicht. Ich liebe das ja auch, wenn du nach zwei, drei, vier, fünf Monaten die Entwicklung von Leuten siehst. Dennoch ziehe ich nicht all meine Energie daraus, sondern auch als Engineering Manager bin ich teilweise noch in Projekten tief drin. Und das meine ich gar nicht mit Micromanagement oder Coding, aber ich denke, Nur auf dieser Metaebene dabei zu sein, das fühlt sich so ein bisschen esoterisch an, muss ich zugeben, weil du bist ja immer noch eine Fachkraft, du bist ja immer noch technischer Manager und eine technische Managerin und ich bezweifle, dass man all seine Energie nur aus People Management ziehen kann. Zumindest wenn man einen technischen Background hat, weil ich glaube, dafür lieben wir alle Softwareentwicklungen zu viel.

Wolfi Gassler (00:20:24 - 00:22:50)

Es gibt einen netten Artikel zu dem Thema von der Charity Mayors, die ist CTO von HoneyCamp, so eine Observability-Firma, aber die schreibt wirklich sehr gute Blog-Einträge über diese ganzen Themen. Und die hat auch das irgendwie so absoluten Bullshit genannt, diese Antwort, die viele People-Manager von sich geben, dass man daraus die ganze Erfüllung zieht, indem man die Leute erwachsen sieht, scheinbar so wie du auch. das als nicht sehr gut findest. Ich finde die Antwort eigentlich sehr gut, ich habe die auch oft gegeben. Und es ist auch ganz interessant, weil sie erklärt dann in dem Blogartikel auch, wo sie sieht, wo man vielleicht die Belohnung und Erfüllung rausziehen kann und im Endeffekt sind es dann genau wieder diese Punkte. Also wenn das Team performt, wenn man sieht, dass das Team irgendwas Sinnvolles geleistet hat oder auch die kleinen Momente, wie sie es nennt, wenn man irgendwie eine gute Beziehung zu den Leuten aufgebaut hat, wenn man das eine oder andere Problem gelöst hat oder wenn die Leute einfach mit einem zufrieden sind. Also die kleinen Momente, die man immer hat, so in 101 oder so, wo man einfach viel Energie rausziehen kann. Und da würde ich sagen, das ist auch, wo ich sehr viel Energie rausziehen kann. Also wenn man einfach dieses persönliche Feedback wieder bekommt, was man sich aber unter Umständen auch holen muss oder verdienen muss und was man nicht mehr so automatisch bekommt, so wie früher als IC. Ich glaube, da ist der große Unterschied. Und sie nennt zum Beispiel auch noch einen anderen Punkt, das Krisenmanagement, was glaube ich auch ganz wichtig in dieser Rolle ist, was sehr sehr hart ist, weil man wird in Krisen hineingeschmissen, egal in welcher Leadrolle, als Tech Lead, als Team Lead, als Engineering Manager, was es auch immer ist. und muss dann Krisen lösen, sei es auf technischer Ebene, sei es auf personeller Ebene, was es auch immer ist. Und wenn man die Krise dann übersteht, kann man da vielleicht Energie draus ziehen. Aber man muss natürlich die Person dafür sein, weil nicht jeder kann mit Krisen so gut umgehen. Und vielleicht sage ich das jetzt auch als Feuerwehrmann, dass man da irgendwie dann ein gutes Gefühl hat, wenn man eine Krise irgendwie gut gemeistert hat und vielleicht auch Leuten geholfen hat. Aber nicht jede Person ist so. Ich glaube, da ist auch dann der große Unterschied, wenn man in so eine Rolle hineinwächst und dann die eine oder andere Krise zu bewältigen hat und dann aber keine Energie aus dem Ganzen danach natürlich zieht. Die Krise an sich ist immer hart. Dann ist halt auch die Frage, ob man als Lead gut geeignet ist oder in diese Position reinwachsen kann oder will am Ende.

Andy Grunwald (00:22:50 - 00:24:01)

Ich sage nicht, dass das kompletter Bullshit ist, dass man nur die Energie daraus zieht und so weiter, so wie du es gerade beschrieben hast. Was ich sage ist, ich mag diese Aussage nicht, die viele Manager nutzen, warum sie den Job tun, ohne konkreter zu werden. Denn das ist so eine allerwelts Aussage. Wenn jemand um die Ecke kommt mit ganz ganz ganz konkreten Beispielen, wo sie oder er jemandem geholfen hat oder das Team zum Performance gebracht hat oder oder, also wirklich konkrete Beispiele, da muss man natürlich dann ein bisschen ausholen, den Kontext erklären und dann sagen, was die Grundsituation war und was du als Manager bzw. Managerin geleistet hast. Wenn du da konkret werden kannst und dann auch begründen kannst, was der positive Moment für dich da war, dann ist ja alles gut. Wo ich allergisch gegen bin, ist diese, ich liebe es, Leute zu enablen. Ja, aber wie denn? Komm mal zum Punkt hier, komm, red Tacheles, ja? Also, dass wir, dass wir mal weg von diesem Fluffy Fluffy kommen, sondern was, was hast du denn gemacht, beziehungsweise was war die Grundsituation, Probleme analysiert und so weiter, also wirklich von konkreten Aktionen sprechen und das fehlt mir halt oft so ein bisschen bei der ganzen Thematik.

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

Und dazu muss man eben wissen, was man eigentlich macht und was die Position ist, die eigene.

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

Also zum Beispiel, da bin ich voll bei dir und deswegen sag dich ja auch, dass auch wenn du jetzt gerade neuer Manager bist, also zwei, drei Monate im Job, Setz dich erstmal und werde dir erstmal bewusst, was du hier machst. Also das bedeutet, mach den Job erstmal ein Jahr. Ich hatte das ja vorhin schon erwähnt, dass man eine gewisse Reife braucht, um das alles zu erkennen. Denn als Lead ändert sich ja der Feedback-Cycle. Wohingegen haben wir ja gerade schon gesagt, dass Deployment in Stunden möglich ist, sind Teamänderungen in der Regel nach drei Monaten sichtbar. Dass sich das Team besser verhält, eigenständiger ist, performanter oder oder oder.

Wolfi Gassler (00:24:43 - 00:25:49)

Und dann muss es erstmal messbar sein. Das ist ja nochmal die andere Sache. Und du musst es vielleicht auch messbar machen, weil es gibt vielleicht noch keine Messpunkte, die automatisch erfasst werden, wo du sagen kannst, okay, das Team wird schneller. Oder auch wenn das ganz weiche Kriterien, würde ich es mal nennen, sind, wenn du jetzt sagst, okay, du willst Vertrauen in deinem Team schaffen, zum Beispiel. Das ist natürlich superschwer messbar. Und meistens gibt es jetzt keine Datenpunkte, die schon automatisch erhoben werden. Und da kann man natürlich als Lead dann auch selbstständig solche Messpunkte definieren und dann vielleicht Messungen durchführen, regelmäßig, damit man überhaupt etwas in der Hand hat. Nicht nur für sich selber, damit man vielleicht dann auch Energie rausziehen kann, wenn sich irgendwo was verbessert. Oder man das von außen auch gespiegelt bekommt, dass das okay ist, weil oft hat man ein Gefühl, aber es ist immer besser, wenn man das irgendwie schriftlich hat, durch eine Umfrage zum Beispiel. Und man kann die Daten dann natürlich auch nützen für die Vorgesetzten, wenn es dann um irgendwelche Gehaltserhöhungen geht oder wenn man sich halt unter Umständen beweisen muss oder zeigen muss, dass man auch etwas leistet, nicht nur für sich selber.

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

Die Messbarkeit von deinen Aktionen sollte auf jeden Fall gegeben sein und das ist unglaublich hart, weil du hast ja gerade schon darüber gesprochen, wie misst man das Vertrauen innerhalb von einem Team. Und da gibt es natürlich verschiedene Arten, aber es ist sehr kontextabhängig von deinem Team. Zum Beispiel, was man machen kann ist, das klingt jetzt total doof, aber wenn du ein neues Team hast und du merkst, da ist noch kein Vertrauen im Team, Sachen anzusprechen, warum misst man nicht einfach mal über die Zeit die Anzahl der Tickets während einer Retrospektive. Das könnte unter anderem ein Signal dafür sein, wie offen Probleme angesprochen werden. Und umso mehr Vertrauen da sind und umso mehr Vertrauen da ist, so ist zumindest meine These, umso mehr Probleme werden offen angesprochen, weil jeder den Mut hat, diese offen zu diskutieren. Ist jetzt nur mal eine These oder wie oft shippt das Team eine Änderung am Produkt, die man Celebraten kann, also die man feiern kann. Beispiel, wie oft trinkt das Team ein Glas Sekt nach einem kleinen Product Feature oder ähnliches. Also dass man, dass man, das hört sich jetzt total komisch an, aber im Endeffekt muss in einem Team ein vertrauensvolles Verhältnis geschaffen werden, denn jeder im Team muss sich auf den anderen verlassen können. Das sind dann jetzt so soziale Metriken und gegebenenfalls sollte man die jetzt nicht, weiß ich nicht, ob man die dem Team transparent zur Verfügung stellen sollte, weil sonst spielt man auch irgendwie die Metriken aus, aber Auf der Business Seite kann man natürlich auch noch ein paar Metriken machen, wie zum Beispiel in Infrastruktur-Teams ist es oft so, wie viel Alerts und Escalations kriegst du, wie viel Toil hast du oder halt auch die Dora-Metriken, wie mit Deployment Frequency, Time to Restore a Service, Change Failure Rate und so weiter und so fort. Also sowas kannst du ja natürlich auch einführen und da kann man zumindest für Infrastruktur-DevOps-SE-Teams sagen, okay, ist das Team performanter geworden. Aber das ist ja genau die Aufgabe eines Leads.

Wolfi Gassler (00:27:41 - 00:30:15)

Wobei man das eben oft vergisst in den Aufgaben eines Leads und man kommt dann immer später drauf und denkt sich, jetzt funktioniert es besser, aber ich habe natürlich keine Messpunkte aufgesetzt und dann ist es halt und bleibt es nur ein Gefühl und das ist halt extrem schwierig dann zu verkaufen, ein Gefühl das man selber hat, im Idealfall hat, der Manager das selbe Gefühl, dann passt es meistens, aber es ist halt immer besser, irgendwelche Datenpunkte zu haben. Und ich habe das in einem Team relativ spät eigentlich mal probiert, beziehungsweise dann aufgesetzt, dass ich einfach regelmäßig eine Umfrage gemacht habe, und zwar neben den ganzen 360-Evaluierungen und so, die jährlich durchgeführt werden, weil man dann einfach eine gezielte Abfrage machen kann. Und ich habe das, glaube ich, ursprünglich meine Fragen aus diesem Work Rules Buch von Laszlo Buk, heißt er, glaube ich, der bei Google recht viel gemacht hat und das dann zusammengefasst hat in dem Buch. Ich glaube, der hat das vorgeschlagen. Und im Prinzip habe ich da, kann mich nicht mehr erinnern, so um die 8 bis 10 Fragen gestellt in Google Docs damals. Einfach, ob ich zum Beispiel Feedback gebe zur Performance für die Leute, ob ich micromanage, ob ich relevante Informationen dem Team immer mitteile, ob die gut informiert sind, ob es offene und gute Diskussionen gibt, ob die Kommunikation klar ist, ob meine technische Expertise ausreicht als Lead und ich habe auch so einen klassischen NPS, so einen Net Promoter Score gemacht, so eine klassische Frage, würdest du Wolfgang als Lead weiterempfehlen oder jemanden anderen als Lead empfehlen? Und das waren ganz simple 10 Fragen, man muss natürlich trotzdem nachlaufen, man muss dem Team 10 mal sagen, bitte füllt das Formular aus, bitte füllt das Formular aus, war natürlich alles anonym, aber man bekommt da super gutes Feedback, was einem selbst einfach hilft, ist die eigene Wahrnehmung, auch die Wahrnehmung vom Team. Und man kann die Fragen ja dementsprechend anpassen, je nachdem was die eigene Rolle ist, ob es mehr technisch, mehr People Lead ist, aber man bekommt da super schnelles Feedback. und kann einfach bestätigen, ob man am richtigen Weg ist. Und das war für mich persönlich sehr hilfreich und das Team hat es auch wirklich wertgeschätzt, dass sie auch gefragt wurden, auch obwohl man trotzdem nochmal nachlaufen muss und jedem einen Arschtritt verpassen muss, dass man bitte dieses Formular ausfüllt, weil Formular ausfüllen, das machen wir alle nicht gerne. Aber im Endeffekt hat es die Gesamtsituation stark verbessert und hat mir auch den einen oder anderen Blindspot zumindest aufgezeigt oder gewisse Schwachstellen natürlich aufgezeigt und das war natürlich auch das Ziel.

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

Jetzt antworte mir bitte sehr, sehr ehrlich. Wie oft hast du von einem Teammitglied, was dir unterstellt ist, gesagt bekommen, ja, Wolfgang, du micromanagest?

Wolfi Gassler (00:30:26 - 00:30:47)

Also, ich habe mir gerade eine Umfrage herausgesucht als Antworten. Da habe ich 14 Antworten bekommen. Und da hatte ich bis auf dreimal strongly agree, dass ich nicht micromanage, und dreimal agree. Also, es waren alle der Meinung, dass ich nicht micromanage. Was aber nicht so schwer ist, weil wenn du ein Team hast mit 18, 19 Leuten, wie du da noch micromanagen.

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

Kannst, würde mich wirklich interessieren. Bei 18, 19 Leuten bist du eh überlastet, wenn du alle selbst leitest. Also von daher, das kann man nicht wirklich Teamleadership nennen, sondern Chaos pur und dass das Team dich managt, so nach dem Motto. Weil das Team schreit dann so viel, dass du dich um die ganzen Brände kümmern musst. Also das ist nicht wirklich managing. Okay, aber das bedeutet, du hast das über ein anonymes Formular rumgesendet. Meine Frage war eigentlich eher dahingehend, wie oft hat dir das jemand wirklich effektiv gesagt, entweder face-to-face oder halt nicht anonymisiert?

Wolfi Gassler (00:31:19 - 00:31:57)

Ja, nachdem ich nie das Problem mit Micromanage hatte, Gott sei Dank. Und ich glaube, das ist mir persönlich auch immer wichtig, dass ich absolut nicht micromanagen will. hat mir das nie jemand auch persönlich sagen können. Aber die Frage ist, ob sich jemand getraut hätte. Und es gibt natürlich andere Punkte, wie zum Beispiel den Klassiker, der bei einem großen Team auch immer das Problem war mit der Strategie-Definition in so einem großen verteilten Team über mehrere Product Teams hinweg. Das war immer ein Kritikpunkt und den hat mir eigentlich auch nie jemand so direkt gesagt. Im Formular ist es dann aber schon rausgekommen, dass das ein Problempunkt ist.

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

Und das ist genau der Punkt, auf den ich hinaus möchte mit meinen Fragen bezüglich des Micromanagements. Feedback erfragen und wirklich Feedback bekommen, ist eine unglaublich schwierige Geschichte. Die meisten Personen haben entweder nicht den Mut oder das Interesse, dir ehrliches Feedback zu geben. Und mit ehrlichem Feedback, ich beschreibe jetzt eine Situation, wie jemand spricht zu dir in einem Gespräch, du weißt, wer dir jetzt also gerade Feedback gibt. Die meisten Personen würden dir niemals ehrliches Feedback geben. Wahrscheinlich aus verschiedenen Gründen, die wollen dich nicht verletzen oder ähnliches.

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

Es ist eine schwierige Situation, schwieriges Gespräch und du bist natürlich Vorgesetzter. Das ist natürlich das größte Problem.

Andy Grunwald (00:32:36 - 00:33:29)

Und das größte Problem, dass du der Vorgesetzte bist, du hast also einen direkten Einfluss auf die Karriere einer Person. Deswegen, ich will jetzt nicht sagen, jeder möchte Arsch kriechen, ganz so gar nicht, doch es ist, also da gehört schon Mut zu, das ist die eine Baustelle. Die andere Baustelle ist konkretes Objektives Feedback anhand von Beispielen zu geben das ist was also wirklich die Königsklasse ist ist unglaublich schwer also dass ich sage Wolfgang ich finde Meetings mit dir super angenehm weil, Du kommst immer sehr vorbereitet, hast immer eine ganz klare Agenda und hast ein gutes Gespür dafür, während den Meetings zu verstehen, wann wir vom Thema abdriften und du schreitest dann auch immer ein und leitest uns zurück auf den Pfad. Das finde ich super angenehm. Vielen Dank, dass du das machst. Immer wenn du Meetings leitest, habe ich das Gefühl, das ist keine Zeitverschwendung.

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

Gut, dass du das mal wertschätzt.

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

Das war ein Beispiel. Für alle, das war ein Beispiel. Meetings mit Wolfgang sehen oft nicht so aus. Aber, so eine Art Feedback, wirklich mit einem ganz konkreten Beispiel, so nach dem Motto, das habe ich beobachtet, was war gut und was hat das mit mir gemacht. Ja, so in diesem Zyklus. Super wenig Leute machen das und nehmen sich die Zeit dafür, aber so Feedback wie, du kommunizierst gut oder es macht Spaß mit dir zu arbeiten oder ich möchte nicht mit dieser Person zusammenarbeiten. Was ist das denn für Feedback? Bullshit ist das. Damit kann keiner was anfangen, damit kann keiner was verbessern, damit kann keiner entscheiden, nehm ich das jetzt an und verbesser ich da was, weil ich weiß ja nicht, was das Problem ist. Oder das Positive.

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

Das ist halt das große Problem, dass es auch viel Zeit benötigt, gutes Feedback und sich da mal die Gedanken drüber zu machen. Wir hatten ja, du kannst dich ja noch gut erinnern, bei Trivago dieses 360, Tool und die Evaluierungen, die einmal im Jahr stattgefunden haben, was der absolute Horror war, weil alle waren eine Woche beschäftigt damit nur Feedback zu schreiben und da hat man wirklich gespürt, dass die Produktivität extrem nach unten gegangen ist, obwohl ich jetzt natürlich sagen will, ich hab das sehr cool gefunden, dass wir so viel Feedback bekommen haben.

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

Bevor du jetzt weiterredest, kannst du mal ganz kurz alle Hörerinnen und Hörer abholen, was 360 Feedback ist, wie es bei Trivago umgesetzt wurde und was das eigentliche Problem war mit deiner Ein-Woche-Zeitspanne, die jeder gehasst hat.

Wolfi Gassler (00:34:57 - 00:35:44)

Ja, also ich glaube, 360-Evaluierungen sind heutzutage eigentlich recht weit verbreitet und in ganz vielen Firmen Standard, würde ich fast sagen. Ich habe auch jetzt kurz, ich habe gerade mal nachgeschaut, das kommt ursprünglich von der Wehrmacht, von 1930 ist das eingeführt worden, um Offiziere auszuwählen, dass man also wirklich eine große Gruppe nach Feedback fragt, welcher Offizier gut wäre und im Prinzip funktioniert das gleich in Firmen, man fragt, Leute, die miteinander zusammenarbeiten. Oder mehrere auf jeden Fall nach einem tiefergehenden Feedback. Und bei Trivago war's wirklich so organisiert, dass man selbst Personen ausgewählt hat, die einen evaluiert haben. Die Listen wurden natürlich noch kontrolliert vom Manager und so weiter, dass das möglichst ausgewogene Listen sind.

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

Was heißt eine ausgewogene Liste? Wer sollte da rein?

Wolfi Gassler (00:35:47 - 00:37:24)

Also, im Idealfall die Leute, mit denen du viel zusammenarbeitest. Das heißt, Auf der einen Seite natürlich dein Manager, aber deine Teamkollegen, Kolleginnen aus anderen Teams, mit denen du zusammenarbeitest. Also alle, mit denen du tiefergehend zusammengearbeitet hast im letzten Jahr. Und das waren natürlich teilweise schon viele Leute, aber im Idealfall war die Idee, dass das so 10 bis 15 Leute sind. Das heißt, mich evaluieren dann 10 bis 15 Leute und die füllen dann einen Fragenkatalog aus, bewerten mich in gewissen Themen auf einer Skala und geben dann aber wirklich auch positives und konstruktives Feedback zu jedem einzelnen Punkt textuell. Das wird dann am Ende zusammengefasst von einem Lead nochmal, dass das nicht nachvollziehbar ist, dass das alles anonym bleibt, der sollte das dann zusammenfassen und schriftlich dann wirklich ausliefern. Also man bekommt dann, bei mir waren es wirklich viele ausgedruckte Seiten am Ende, so irgendwie zehn, zwölf Seiten wirklich mit viel, viel textuellem Feedback von Personen, mit denen man zusammengearbeitet hat. Da sieht man schon, da müssen viele Leute sich den Kopf zerbrechen. Was schreibt man? Und da sieht man schon, wenn man das ernsthaft macht, sitzt man da schon pro Person, würde ich mal sagen, 45 Minuten, um so eine Evaluierung durchzuführen, mindestens. Und darum waren da dann ganz viele in der Firma, weil jeder hatte natürlich ganz viele Evaluierungen zu machen und teilweise als Lead oder so hattest du 50, 60 Evaluierungen, die du eigentlich machen müsstest, auf so einem Detailgrad, was fast unmöglich ist in einer sinnvollen Zeit.

Andy Grunwald (00:37:24 - 00:38:26)

Ich glaube, mein Horrorjahr war auch so. Ich glaube, ich hatte 50 Evaluierungen offen. Da habe ich dann auch ganz klar priorisiert die Leute, mit denen ich sehr engen Kontakt habe, wo ich sehr viel dazu sagen kann und auch konkretes Feedback geben kann. Und bei manchen Leuten habe ich dann einfach die Person, die mich ausgewählt hat, Vielen Dank, dass du mir deine Evaluierung geschickt hast. Ich würde sie nicht ausfüllen, weil wir hatten nur vor drei Monaten eine Woche Kontakt wegen diesem Projekt. Das ist mir ein bisschen zu wenig Interaktion, damit ich hier wirklich konkretes actionable Feedback geben kann. Und da habe ich dann ganz einfach die Begründung gesagt, warum ich nicht in der Lage bin, konkretes Feedback zu geben. Und das haben die Leute dann auch sehr dankbar angenommen und dann auch verstanden. Also die waren dann auch nicht böse, aber ich finde das wichtig dann, dass man auch ein bisschen seine Zeit priorisiert in diesen Performance-Zeiten und sagt, hey, ich fühle mich gerade nicht in der Lage, konkretes actionable Feedback zu geben. Da, wo ich es kann, tue ich es. Und ich kann das gerne auch so schreiben, aber ob sich das dann jetzt wirklich ein kompletter 360-Fragebogen rechtfertigt, ist dann auch wieder Frage.

Wolfi Gassler (00:38:26 - 00:41:10)

Und darum war mir eben auch wichtig, meinen eigenen Fragebogen für mein Team als Lied, dass ich den möglichst kurz halte. Der hatte natürlich auch eine Commentsbox und wir hatten ja 101s, aber ich wollte trotzdem immer so ein Gefühl bekommen rein, auf einer Skala von gut bis schlecht, einfach wo stehe ich als Lied gerade. Und man muss das den Leuten natürlich auch erklären, warum er das macht, weil die sagen natürlich auch, hey, wir haben die 360s, warum machst du das überhaupt noch, warum soll ich jetzt noch ein Formular ausfüllen? Und man muss das halt dementsprechend auch gut kommunizieren, was dann auch damit passiert. Ich habe zum Beispiel auch dann natürlich konkret irgendwelche weiterführenden, tieferen Meetings gemacht, zum Beispiel zu der Frage, die du jetzt erwähnt hast mit dem Micro-Managen, dadurch mein Team so groß war, zeitweise über 20 Leute, hatte ich auch mal wirklich so eine Session gemeinsam mit dem ganzen Team gemacht. Wo es darum gegangen ist herauszufinden, habe ich noch genug Kontakt mit den Leuten? Mische ich mich noch genug ein? Erwarten sich die Leute mehr? Und ich habe da wirklich in der großen Gruppe gefragt, alle haben auf einer Skala mit zwei Achsen, wo die eine Achse war, was erwarte ich mir an Einmischung? Also im positiven Sinne, wie oft und wie viel Zeit kann ich investieren in die einzelnen Leute? Wie groß ist die Erwartung? Auf der einen Skala und auf der anderen Achse war dann, wie viel Zeit ich wirklich investiere, gefühlt von den Leuten. Und die haben dann einen Punkt draufkleben können bei den zwei Achsen, wie verhält sich die Erwartung zu dem, was wirklich passiert. Sind sie zufrieden mit der Zeit, die ich investiere in die jeweilige Person, wenn es um technische Leadership, was es auch immer ist, geht. Und das wirklich in der großen Gruppe. Und da waren die Leute, weil du sagst eben, es ist schwierig wirklich Feedback zu bekommen, da waren die wirklich sehr ehrlich und haben den Punkt geklebt, auch vielleicht durch die Gruppendynamik, die dann entstanden ist. Und es hat eigentlich im Großen und Ganzen sehr gut funktioniert und da kann man dann auch wertvolles Feedback nochmal einsammeln, qualitatives Feedback. wenn eben in so einem fragenbogen sich herausstellt okay irgendwo ist ein bereich wo vielleicht bedarf ist und dann kann man den angehen und sich überlegen wie macht man dort weiter und wie bekommt man da dann mehr feedback oder man fragt einfach in 101 und sagt hey diese frage war eindeutig im team dass das ein problem darstellt und ich bin vielleicht schwach in wenn es um technical Strategie geht oder sowas, was würdest du dir denn erwarten oder was würde dir helfen in deinem täglichen Leben? Was bräuchtest du da für Informationen? Also man kann ja danach auf die Leute zugehen und ich glaube das ist nur der Indikator, damit man eben seine eigenen Blindspots findet, die man sonst vielleicht gar nicht am Schirm hat, weil die guten Sachen kennt man ja eh.

Andy Grunwald (00:41:10 - 00:43:19)

Aber das ist jetzt total faszinierend. Du fragst, was sind die Erwartungen, wie oft du dich einmischen sollst und wie real mischst du dich ein? Ich hab ne ähnliche Frage bzw. zwei ähnliche Fragen, die ich oft in One-on-ones stelle und an alle Hörerinnen und Hörer, das ist jetzt nicht abgesprochen, das ist wirklich reiner Zufall. Und zwar frage ich öfters, womit solle ich mich mehr beschäftigen und womit solle ich mich weniger beschäftigen. Das ist eine recht offene Frage, es geht nicht wirklich an Projekt einmischen oder ähnliches, sondern da kommt irgendwie alles darum. Hey, pass mal auf, ich brauche ein bisschen mehr Backup hier in diesem Projekt, oder es wäre toll, wenn du ein bisschen mehr Hands-on in diesem Projekt wärst, oder es wäre toll, wenn du dich ein bisschen mehr um eine Weiterentwicklung kümmern könntest. Einfach nur irgendwelche Beispiele. Und es kommen sehr, sehr interessante Antworten auf diese Fragen. Also womit sollte ich mich mehr, womit sollte ich mich weniger beschäftigen? Einfach mal in One-on-ones fragen. Und ich hatte vorhin erwähnt, es ist super schwierig, Feedback zu bekommen und du hattest erwähnt, die Leute hassen es, Formulare auszufüllen. Meine These ist ja, Formulare oder Umfragen werden oft nicht ausgefüllt, weil man nicht weiß, was mit den Ergebnissen passiert. Du füllst etwas aus, gibst da deinen Input und dann verschwindet das in diesem Void. Du hörst da nie wieder was von, du weißt nicht, ob dein Feedback irgendwie angenommen wurde, du weißt nicht, ob daran gearbeitet wurde oder oder oder. Und das geht voll in diese Transparenz-Schiene rein. Und was ein paar Manager bei Trivago damals gemacht haben, was ich heute auch noch mache, ist, immer wenn du, ich sag mal, eine groß angelegte Feedback-Umfrage hast, sei es ein 360 oder Performance-Reviews oder, oder, oder, oder Peer-Feedback oder irgendwas, dass man sich danach ein paar Ziele rausschreibt, woran man selbst arbeiten möchte. Sei es an deiner Managerfähigkeit, sei es an Projekten und so weiter. So ein paar Headlines. ich sag mal, deine persönlichen OKRs für deine Weiterentwicklung im Job. Und dass du die dann unter anderem im Team auch teilst, transparent zur Verfügung stellst, denn dein Team hat in der Regel das Feedback dazu gegeben. Das ist natürlich was auch sehr viel Mut braucht, deine eigenen Ziele und deine, weil du legst auch eigentlich deine Schwächen auf, aber das ist so eine Art und Weise, wie du zum Beispiel das Feedback-Ergebnis transparent darstellen kannst und dass die Leute wissen, hey, mein Feedback ist da angekommen, das ist jetzt das Ziel meiner Managerin für das nächste halbe Jahr.

Wolfi Gassler (00:43:19 - 00:43:51)

Und das motiviert dann natürlich auch die Leute im Idealfall, dann bei der nächsten Umfrage wieder mitzumachen, weil die halt einfach sehen, okay, es wird was gemacht damit. Und im Idealfall hat sich vielleicht sogar was geändert. Und das schafft dann natürlich auch gewisses Vertrauensverhältnis. Vor allem, wenn man dann in One-on-Ones drüber spricht, finde ich eigentlich immer eine gute Variante. Und da halt wirklich nochmal die Details durchgeht mit den Leuten und wirklich nach konkretem Feedback oder Hilfe vielleicht sogar in dem Fall fragt, um dann sich eine Strategie zurechtzulegen, wie man die ganze Situation verbessern kann.

Andy Grunwald (00:43:52 - 00:44:54)

Jetzt darf man natürlich all solche Feedback-Cycles nicht zu oft machen. Also sowas jeden Monat oder jeden zweiten Monat wäre vielleicht ein bisschen zu viel, denn dein Change-Feedback-Cycle als Managerin, als Manager ändert sich natürlich. Ich sage immer so aus dem Bauch heraus, wenn du jetzt Line-Manager bist, ein Line-Manager ist, wenn du Individual Contributor leitet, also Leute, die wirklich die Arbeit machen. Wenn du jetzt Teamleiter bist und nicht Director, ein Director ist in der Regel jemand, der andere Teams mit anderen Teamleitern leitet. Also wenn du jetzt Line Manager bist, dann hat jeder Change so ungefähr eine Dauer von circa drei Monaten, bis der einen Effekt hat. Wenn du jetzt alle halbe Jahre zum Beispiel mal Feedback einholst oder 360-Grad-Feedback, dann ist das glaube ich ganz okay. Die meisten Firmen haben, soviel ich weiß, einen jährlichen Feedback-Cycle, manche Firmen haben halbjährlich. Ich finde beides okay. Natürlich im Halbjährlich kannst du mehr justieren, alles super. Aber es kann dann auch wirklich in sehr viel Arbeit ausarten, je nachdem wie das 360-Grad-Feedback dann executed wird. Besonders wenn man immer halt 50, 60 Leute einlädt, dann ist das vielleicht ein.

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

Bisschen zu viel, Und wenn dann die HR-Abteilung auch noch irgendwie ein anderes Formular sich einfällen lässt, was man dann monatlich bekommt, oder wir bei Trivago hatten auch mal Office Vibe, das war so ein Tool, was über Slack noch nachgefragt hat, wie denn gerade so eben der Office Vibe ist, so gewisse Fragen gestellt hat und am Ende beantwortet man ständig nur mehr irgendwelche Fragen und dazu hat keiner Lust, muss man ja auch ganz klar sagen. Aber ich hatte immer das Gefühl, im eigenen Team hat es noch am besten funktioniert, weil das Team halt auch will, dass man sich weiterentwickelt und das war am nähersten dran sozusagen an den Leuten. Eine andere gute Möglichkeit, um Blindspots zu finden, beziehungsweise um auch Feedback zu bekommen und auch zu wissen, ob man einen guten Job macht, ist meiner Meinung nach mit Peers zu sprechen. Also der Andi war damals so einer, wir waren beide Engineering Manager und man kann dann einfach gewisse Fälle miteinander besprechen, man kann gewisse Aktionen besprechen, die man so gemacht hat und kann einfach mal auch so Feedback von außen bekommen, Was hält denn eine andere Person in der gleichen Position in einem anderen Team davon? War das eine gute Aktion? Hat man richtig reagiert? Hat man überreagiert? Also wie wird das so von außen wahrgenommen? Und das ist meiner Meinung nach auch ganz, ganz wertvoll. Die können auch einem Tipps geben. Okay, ich mache das bei mir im Team so. Ich mache andere Dinge. Die könntest du ja eigentlich auch noch machen. Auch da habe ich eigentlich als Lead am meisten gelernt. Am wenigsten habe ich von meinem Manager gelernt und am meisten habe ich von meinen Peers gelernt. Und da ist halt wichtig, dass man sich einfach so ein Netzwerk zurechtlegt, früh genug, weil wenn man dann ein Problem hat, ist es zu spät, wenn man dann probiert, Leute zu finden. Man braucht die Vertrauensbasis, die man aufbaut über längere Zeit. Und da können eben so Außenstehende von anderen Teams schon sehr hilfreich sein. Oder wenn man auf der Tech-Lead-Rolle ist, dass man sich eben andere Tech-Leads sucht und über die Probleme spricht und wie man reagiert. Also da hat man schon viel Input, der für mich zumindest früher immer sehr hilfreich war.

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

Was natürlich essentiell bei so einer Peer-Coaching-Gruppe ist, dass jedem klar ist, was das Ziel dieser Gruppe ist und dass alles, was hier besprochen wird, auch nur in diesem Kreis bleiben muss, weil...

Wolfi Gassler (00:47:04 - 00:47:11)

Wenn es jetzt ein Kreis ist, also man kann da ja auch One-on-One machen, aber auch da soll es klar sein, dass es nicht herumerzählt wird oder dass man da in einem Safe-Space ist natürlich.

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

Also das Vertrauen muss auf jeden Fall da sein und es muss jedem klar sein, worum es hier geht.

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

Gerade wenn es um Job Descriptions geht, also was ist eigentlich der Job von einem, hilft es natürlich auch, wenn man andere Leute hat, die in der gleichen Position sind, in der offiziell gleichen Position, weil man da natürlich auch nachfragen kann, okay, ist das auch dein Verständnis von dem Job? Haben wir da dasselbe Verständnis? Machst du dasselbe? Machst du ganz andere Tätigkeiten? Also wenn es keine firmenweite Definition gibt, kann man so wenigstens über viele Kontakte, über Nachfragen auch so langsam eine Definition bilden, die sich dann so inhärent über die Firma irgendwie herauskristallisiert.

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

Jetzt haben wir natürlich ziemlich viel darüber gesprochen mit wie kriegt man Feedback, wie erkennt man eine eigene Blindspot. Das ist auch alles wichtig und ich denke der Großteil eines jeden Leads ist nachdenken. Also weg vom Computer.

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

Unter der Dusche.

Andy Grunwald (00:48:01 - 00:50:44)

Dusche. Ich gehe gerne auf den Spaziergang oder laufe einfach mal mit einem Kaffee durch meinen Garten oder ähnliches. Also wirklich nachdenken wie Ist das Team aufgebaut? Wo siehst du das Team in sechs bis zwölf Monaten? Was sind die wichtigen Projekte und Co., um wirklich, ich sag mal, ein mentales Modell in deinem Kopf aufzubauen? Wenn du jetzt nur an deinem Rechner sitzt und nur von anderen Leuten getrieben wirst und sagst, ich habe überhaupt keine Zeit nachzudenken, weil mein ganzer Kalender voll Meetings ist, gegebenenfalls solltest du nochmal drüber nachdenken, ob du nicht zu viel auf dem Tisch hast, in den Diskurs mit deiner Vorgesetzten und mit deinem Vorgesetzten zu gehen, um da mal ein bisschen Ordnung reinzubringen und zu sagen, hey, pass mal auf, Ich habe jetzt zehn Projekte auf dem Tisch. Diese drei, darauf würde ich mich fokussieren. Die anderen würde ich pausieren oder was weiß der Geier nicht, damit ich mal ein bisschen Zeit hier habe, meine Arbeit auch ordentlich zu machen. Und da kommen wir zu dem Punkt, der mir auch noch recht wichtig ist, um zu evaluieren, ob ich gut bin und ob ich meinen Job gut mache. Und zwar ist es die Kernfrage, arbeite ich an den richtigen Dingen? Denn Tech Lead, Staff Engineer, Engineering Managerin oder oder oder, das sind ja alles nicht nur Leute mit People-Verantwortung. Und ja, es gibt Firmen, da haben die Teamleiter nur People-Verantwortung und keine Projektverantwortung. In vielen Firmen ist es aber auch so, dass die Projektverantwortung ebenfalls Kern deiner Rolle ist. Oder du zumindest einen Teilbereich verantwortest. Und da ist es natürlich ein bisschen schwierig, wie Wolfgang auch schon sagte. Die meisten Manager sagen, ja ich liebe irgendwie mit Leuten zu enablen etc. etc. Aber am Ende des Tages steht die Frage da, was hast du denn jetzt konkret gemacht? Besonders wenn du dich irgendwo auf einen anderen Job bewirbst, kommt oft die Frage, erklär doch mal bitte deine Rolle und was hast du so in den letzten zwei, drei Jahren gemacht? Ja, ich hab ein Team geleitet und ich hab die enabled, damit die performanter werden. Da kommt die nächste Frage, okay, was war denn jetzt dein essentieller Baustein, dein essentieller Beitrag zu der ganzen Geschichte? Kannst du mal ein Beispiel rausholen? Und da habe ich schon super oft gemerkt, die Leute struggeln mit dieser Frage. Also die Leute wissen gar nicht so wirklich, was habe ich denn jetzt wirklich dabei getragen. Und da ist mir ein Konzept mal hängen geblieben und zwar hört sich das jetzt total böse an, aber ich nenne das mal CV-Driven Development. Um die Frage zu beantworten, arbeite ich an den richtigen Dingen, denk mal darüber nach, woran arbeite ich gerade, was ich später auf meinen Lebenslauf schreiben kann. Das hört sich jetzt sehr selfish an, aber wenn du das auf deinen Lebenslauf schreiben könntest, dann ist das mit hoher Wahrscheinlichkeit auch relevant für die Firma und von dem Business, beziehungsweise für die Abteilung, für die du arbeitest. Also zum Beispiel, wenn du die Cloud-Abteilung leitest, Cloud-Kosten runterdrehen, ist auf jeden Fall eine tolle Geschichte, die du für deinen Lebenslauf verwenden kannst. Sie hilft der Firma, weil weniger Geld ausgegeben wird. und so weiter und so fort.

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

Viel Kaffee trinken zählt das auch dazu? Kann man das auf dem CV draufschreiben?

Andy Grunwald (00:50:48 - 00:50:55)

Das kannst du auf dem CV draufschreiben. Wie dann deine Bewerbungschancen sind, weiß ich glaube ich nicht. Also wenn du Kaffeesommel gibst, dann ja.

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

Aber... Weil es war schon sehr wichtig als Lead, Kaffee trinken.

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

Ja, das sind ja vertrauensbildende Maßnahmen, aber wie viel Vertrauen möchtest du aufbauen, um endlich mal zu arbeiten?

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

Ich habe mir gedacht, man hat das Team zum Arbeiten.

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

Team, toll, ein anderer macht's.

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

Genau, ja. Aber ich glaube, es geht auch da wieder darauf zurück, wenn du es eben messen kannst und irgendwo hinschreiben kannst auf einem CV, dann hilft dir das schlussendlich. Und dann hast du das verstanden, was wichtig ist, was die Firma weiterbringt, was dich in deinem CV weiterbringt. Und da schließt sich dann wieder der Kreis. Wenn du weißt, was dein Job ist und wenn du das messen kannst und dann sagen kannst, du warst gut darin, dann weißt du auch, dass du am richtigen Weg bist und dass du einen guten Job machst. Aber es hört sich jetzt leichter an als getan natürlich, also es ist ein langer Zyklus, den man da durchmacht.

Andy Grunwald (00:51:39 - 00:54:07)

Ja und das was du gerade so leicht formuliert hast, ist eine unglaublich harte, schwere Aufgabe und CV driven development sage ich jetzt nicht, dass du alles auf deinen CV, auf deinen Lebenslauf schreiben sollst und dann dich woanders bewerben sollst, so meine ich das gar nicht, sondern denk das nur nach so als Leitfrage, kann ich das später auf meinen Lebenslauf schreiben? Dafür ist natürlich auch die Grundvoraussetzung, dass du das Business deiner Firma verstehst. Also wie verdient die Firma eigentlich Geld? Wir gehen jetzt ganz weit zurück. Nur wenn die Firma Geld verdient, kann die dir einen Job geben und nur wenn du einen Job hast, verdienst du Geld und kannst die Miete zahlen und deine Familie ernähren und so weiter und so fort. Und oft, das habe ich bei ganz vielen Software-Engineers und Engineering-Managern auch schon festgestellt, wir haben gar nicht so ein wirkliches Verständnis, in welcher Industrie die Firma unterwegs ist, beziehungsweise wie die Firma Geld verdient. Es gibt Business-Modelle, die sind sehr, sehr einfach. Eine klassische Web-Agentur. Die kriegen Kunden, werden für eine Webseite bezahlt und dann gehen die Kunden wieder weg. Bei Full-Service-Media-Agenturen geht es schon ein bisschen schwieriger, weil das Business-Modell irgendwie diversifiziert wird, also mit Werbung, Tracking und so weiter und so fort. Aber auch da kann man das noch kristallisieren. Dann hat man so Software-as-a-Services. Nehmen wir mal Spotify, okay. B2C, das bedeutet Endconsumer, zahlen Geld, monatliche Subscription, um Musik zu hören, alles super. Aber dann kommen wir mal an so Sachen wie zum Beispiel Trivago. Trivago ist eine Zoom-Maschine, um Hotelpreise zu vergleichen. Aber woher kriegt denn Trivago zum Beispiel Geld? Trivago kriegt ja kein Geld von den Leuten, die auf die Webseite gehen und ein Hotel. buchen, sondern Trivago ist ein Marktplatz. Auf diesem Marktplatz sind Firmen wie Expedia und Hotels.com und Booking.com und diese Firmen bieten die Hotelzimmer an. Trivago kümmert sich, dass der Traffic auf die richtige Seite kommt und dann im Endeffekt kriegt Trivago Geld von Booking, Hotels.com und Co. Und wenn du das mal verstanden hast, woher die Firma Geld kriegt, Dann weißt du auch, wohin du das Business optimieren musst, beziehungsweise kannst die richtigen Fragen stellen zu deinem Vorgesetzten. Worauf optimieren wir denn jetzt gerade? Und kannst darauf natürlich deine Projekte setzen, um zu sagen, hey, ich kontribute zu dieser Initiative und ich kontribute zu dieser Metrik. Aber das ist für mich so eine Kernsache, dass du dich mal ein bisschen auseinandersetzt, um zu verstehen, wie die Firma, für die du arbeitest, eigentlich Geld verdient. Wie oft hast du das schon gesehen in deinem Team, dass die Leute das gar nicht so wirklich verinnerlicht hatten oder wussten, sondern dass sie zum Beispiel nicht nur für die Technologie interessiert haben?

Wolfi Gassler (00:54:07 - 00:55:12)

Ich hatte bisher dieses Problem eigentlich kaum, muss ich zugeben, aber das waren bei mir auch immer alle sehr produktnahe Teams, die natürlich viel viel mehr damit zu tun hatten. Aber umso mehr du natürlich rausgehst und mit Teams, mit denen ich gesprochen habe, wenn es um Support-Teams geht und Teams, die sehr, sehr tief im Stack sind, im Technischen, dann sind die natürlich viel, viel weiter weg vom Product an sich und bei denen ist es natürlich dann unter Umständen relevant. Wobei ich auch da dazu sagen muss, man sollte halt immer seinen Customer kennen und wenn die Firma so groß ist, dass du als Support-Team eigentlich nicht mehr die End-Customer hast als Customer, sondern deine Customer sind die Developer zum Beispiel, weil du für Developer Experience sorgst, dann solltest du vor allem diese Customer verstehen, also deine Kunden sind dann die Developer in der Firma. Und dann, finde ich, ist es okay, wenn man weiter weg ist vom Product. Aber man sollte meiner Meinung nach am Ende schon auch verstehen, woher das Geld kommt. Ich glaube, das ist wichtig. Wie weit man das versteht und wie weit man es in die eigene Arbeit einfließen lässt, ist dann eine andere Frage. Aber man sollte auf jeden Fall seine Kunden verstehen. Das ist, glaube ich, das Wichtigste daran.

Andy Grunwald (00:55:12 - 00:55:27)

Wer dann deine Kunden sind, das ist dann abhängig von deinem Job, weil wenn du eine Supporting Function bist, eine Infrastruktur Team, ein Plattform Team, dann ist dein Fokus Developer Experience und eine Plattform zu bauen, die von jedem einfach genutzt werden kann, aber dann sind deine Kunden ja intern.

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

Genau.

Andy Grunwald (00:55:27 - 00:56:31)

Um die Probleme deiner Kunden, auch deiner internen Kunden dann zu verstehen, musst du natürlich auch wissen, wo daran deine internen Kunden denn arbeiten. Also was ist denn deren Problemdomain, um den richtigen Service anzubieten. Und darauf geht's wieder. Womit verdient die Firma Geld, wie sind die Strukturen und wieviel Zwischenlayer liegt eigentlich zwischen dir, deinem Job und dem Endkunden, wo das Geld reinkommt. Und wenn du diese Hierarchie und diese Layer verstehst, verstehst du auch diese Zwischenprobleme. Natürlich solltest du immer deine Assumptions irgendwie verifizieren, sprich einfach mal mit deinen Kunden und so weiter und so fort. Und ich denke auch, auch im Infrastrukturbereich sollte man viel mehr mit den Produkte-Engineering-Teams sprechen und Co., damit man das wirklich versteht. Aber im Endeffekt geht es halt wirklich darum zu fragen, arbeitest du an den richtigen Dingen? Und um das herauszufinden, ist natürlich sehr viel drüber nachdenken gefordert. Eine effektive Methode, um herauszufinden, ob du an den richtigen Sachen arbeitest, ist Schubladendenken. Und jeder hasst Schubladendenken, weil man kann ja nicht alles kategorisieren, ja vielleicht ist das richtig, aber in diesem Fall kann man das und in diesem Fall hilft das. Und zwar gibt es ein Framework, das nennt sich LNO, wo L steht für Leverage, N für Neutral und O für Overhead.

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

Also drei Schubladen.

Andy Grunwald (00:56:33 - 00:56:37)

Drei Schubladen, ganz genau, ein kleiner Schrank. Oder eher eine Kommode, ne?

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

Kraschtl heißt das bei uns.

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

Wie heißt das?

Wolfi Gassler (00:56:39 - 00:56:40)

Kraschtl.

Andy Grunwald (00:56:40 - 00:57:51)

Schau dir einfach mal an, was du machst und kategorisiere einfach mal deine Aufgaben in diese drei Schubladen. Welche von deinen Aufgaben sind zum Beispiel Overhead-Aufgaben? Welche von deinen Aufgaben sind neutrale Aufgaben und welche haben einen High Leverage, also einen großen Hebel? Overhead-Aufgaben sind zum Beispiel, wenn du sieben Stunden lang dein Headcount für die nächsten zwei Jahre planst. In vielen Firmen musst du das gegebenenfalls tun. Meines Erachtens nach sollte man da nicht mehr als eine Stunde für investieren, weil wer kann die nächsten zwei Jahre vorkasten? Niemand. Für die nächsten sechs Monate deinen Headcount vorkasten. Gegebenenfalls solltest du da ein bisschen mehr Zeit drauf verschwenden, weil das liegt eher in deiner Hand. Dann, neutrale Tasks. Neutrale Tasks sind einfach Tasks, die da sein müssen, die aber jetzt irgendwie keinen großen Hebel haben, aber nicht overheat. Wie zum Beispiel, einen detaillierten Bug-Report für irgendein Feature zu erstellen. Das ist halt da, muss halt gefixt werden. Das ist halt keep the lights on, KTLO. Und dann gibt's die High-Leverage-Tasks. Das sind so die Tasks, wo man sagt, 10x Ingenieur. Das sind die Aufgaben, da wo du ein bisschen mehr Zeit drauf verwenden solltest und vielleicht sogar ein bisschen mehr perfektionistisch sein solltest. Da geht's darum, andere Leute zu enablen, Leute produktiver zu machen. oder gründlicher zu sein in Themen, die sehr schwer zu ändern sind.

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

Hast du da ein Beispiel dafür?

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

Ja, zum Beispiel ein ordentliches Design-Dokument zu schreiben für eine fundamentale Architektur deiner neuen iOS-App oder ähnliches. Dass du da ein bisschen mehr Zeit drauf verwendest, ist, glaube ich, time well spent, because bei Architekturen man sehr, sehr schwer ändern kann. Und auch mit einem geschriebenen Design-Dokument kannst du Feedback asynchron von anderen Leuten einholen, die wissen genau, wie es umgesetzt werden soll. Und du hast später sogar noch Argumente dafür, warum die Architektur so ist, wie sie ist, also Dokumentation. Das ist zum Beispiel eine High-Leverage-Aufgabe, wo du einfach super viele Leute enablest und wo du ein bisschen mehr Zeit drauf verwenden solltest.

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

Aber das heißt, alle drei Schubladen müssen gemacht werden. Es geht mehr darum, wie viel Zeit du dann investierst pro Schublade. Aber im Endeffekt geht es nicht um, dass du Tasks irgendwie komplett vermeiden kannst, sondern alle drei sind wichtig, so wie ich das jetzt verstanden habe und müssen gemacht werden. Weil Overhead-Tasks müssen genauso gemacht werden und Neutral-Tasks. Aber du kannst natürlich priorisieren und je nachdem mehr oder weniger Zeit investieren.

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

Genau, manche Tasks sind einfach notwendig, manche sind halt einfach nur um den klassischen Alltag aufrechtzuerhalten und manche bringen dich halt wirklich nach vorne und haben halt den sogenannten Hebel. Da kommt man nicht drum rum, es ist halt nur so, verwende mehr Zeit auf die High Leverage Tasks, weniger Zeit auf die neutralen Tasks und noch weniger Zeit auf die Overhead Tasks. Die müssen gemacht werden, aber dein Headcountplan für die nächsten zwei Jahre, ich schwöre dir, du wirst das mindestens noch viermal machen in den nächsten zwei Jahren. Also von daher lohnt es sich da nicht, ganz genau zu sein. Also vielleicht kann man auch sagen, mach einen schlechten Job bei den Overheads-Tasks, mach einen okayischen Job bei den neutralen Tasks und mach einen perfektionistischen Job bei den Leverage-Tasks. Und wie viel Zeit sollte ich jetzt für die Kategorisierung für das Schubladendenken verwenden? Auch keinen perfektionistischen Task, weil dann verschwendet ihr nämlich mehr Zeit fürs Planen anstatt fürs eigentliche Doing.

Wolfi Gassler (00:59:48 - 01:00:52)

Ist ja auch so ein gewisses Mindset, dass man sich da einfach zurechtlegt. Es geht ja nicht darum, dass man da wirklich eine Schublade dann aufbaut und alles genau einkategorisiert. Aber ein gewisses Mindset-Denken in die Richtung ist natürlich sehr, sehr hilfreich, ganz klar. Auf jeden Fall sieht man, umso weiter man wegkommt von der IC-Rolle, umso schwieriger wird es, umso alleingelassener ist man, würde ich mal sagen, umso schwieriger ist es, Feedback zu bekommen, Aufgaben zu bekommen, Definitionen zu bekommen, was der eigene Job ist und umso mehr muss man sich selbst darum kümmern, dieses Feedback einholen, die Job-Definition einholen, auch die messbaren Punkte am Weg selbst definieren und auch messen am Ende, um sich dann vielleicht zu verkaufen, auch wenn das ein böses Wort ist, aber Wenn es um die Gehaltserhöhung geht, muss man sich vielleicht verkaufen oder einfach nennen können, warum man eine Daseinsberechtigung hat und warum es so wichtig ist, dass man auch dabei ist, wie man das Produkt weiterbringt, dass die Firma am Ende auch mehr Geld verdient, weil das steht schlussendlich irgendwo immer in der Hierarchie fast an oberster Stelle, würde ich mal sagen.

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

Wie sagt man so schön, Geld regiert die Welt und Miete zahlen muss man leider auch.

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

Leider, leider, muss ich da gleich drauf sagen. Aber in Firmen ist es noch so.

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

Das war es wieder von uns. Vielleicht habt ihr was mitgenommen, vielleicht nehmt ihr euch mal ein bisschen mehr Zeit, um im Garten Kaffee zu trinken, anstatt gehetzt durch den Alltag zu rennen.

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

Das ist der Leverage-Task, oder? Leverage-Task, Kaffee trinken im Garten.

Andy Grunwald (01:01:14 - 01:01:31)

Wenn man daraus ein paar sinnvolle Gedanken zieht, dann ist das ein High-Leverage-Task in der Tat. Also wenn ihr gehetzt durch den Alltag rennt und euch von externen Meetings leiten lasst, denkt mal drüber nach, ob ihr nicht was ändern wollt. Denn das ist nicht der Job eines Menetters. Das war's von uns. Vielen Dank fürs dranbleiben.

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

Bis bald.

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

Tschüss. Ciao.