#18 Ziele und Performance-Metriken für Teams und mich selbst

Ziel-Definitionen und Mitarbeiter-Metriken: Sinnvoll oder totaler Blödsinn?

Das Thema ist heiß umstritten. Viele lieben Ziele im Job. Andere sind eher auf dem Trichter von “Wer misst, misst Mist.”. In dieser Episode sprechen Wolfgang und Andy über individuelle Ziele, Team-Ziele und über die Frage, ob sich das Team in die richtige Richtung bewegt. Unter anderem mit Fragen wie, ob es immer mathematisch messbare Ziele sein müssen, wie man mit subjektiven Zielen umgeht, ob man Lines of Code messen sollte, was die Velocity aus dem Scrum Framework mit OKRs zu tun haben und noch vieles mehr.

Bonus: Wieso Österreicher Podcasts anschauen können und was das Fortuna Düsseldorf und das Sams mit der ganzen Sache zu tun hat.

Feedback an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk

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

Sprungmarken

(00:00:00) Intro

(00:01:37) Helft uns mit eurem Netzwerk durch eine Podcast-Empfehlung

(00:02:02) Wie kam das Thema dieser Podcast-Folge zustande? Team Metriken, Einzel-Metriken und Performance-Metriken von Mitarbeitern

(00:06:06) Drei Kategorien: Individuelle Ziele, Team-Ziele und "Bewegt sich das Team in die richtige Richtung?"

(00:06:36) Individuelle Ziele: Warum ist das Thema relevant? Warum sollte man sich über Ziele unterhalten?

(00:13:50) Objective Key Results (OKR) als mögliche Ziele

(00:18:09) Die Kritik von Objective und Key Results als individuelle Ziele

(00:21:19) Transparenz von Zielen im Team und in der Firma

(00:23:44) Planung und Ziele ist unnütz und Overhead

(00:25:05) Antipatterns und Ziele die man vermeiden sollte

(00:26:31) Was ist die Velocity innerhalb vom Kontext Scrum? Und wie sollte diese Metrik bewertet werden?

(00:31:27) Die Nutzung von Code- und Software Repository Mining-Metriken als Basis zur Zielsetzung

(00:37:12) Team-Metrik "Happyness" und wie man es messen kann

(00:42:22) Das Westrum-Modell, OfficeVibe und Google Forms

(00:45:43) 360* Feedback: Was ist es und die Kritik am System

(00:52:26) Vergleichbarkeit von Software Engineers und Levels

(00:57:45) Jobtitel und individuelle Ziele und höhere Erwartungen

(00:59:00) "Bewegt sich das Team in die richtige Richtung?", DORA-Metriken und Well-Rounded Software Engineer

(01:03:30) Zieldefinitionen sind nicht einfach und Kontext ist King

(01:07:46) Outro

Hosts

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

Engineering Kiosk Podcast: Anfragen an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk

Transkript

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

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

Episode 18 vom Engineering Kiosk. Hallo und willkommen. Wir freuen uns, dass ihr wieder mit uns am Start seid. Heute geht es um ein Thema, was für einige Leute lästig ist, nur Arbeit und Overhead erzeugt und für andere super sinnvoll, weil es ihnen eine Richtung und klaren Fokus gibt. Wir sprechen über Ziele und Performancemetrik. Nicht im technischen Sinne, wie zum Beispiel Antwortzeit in eurer App, sondern im Kontext von euch als Mitarbeiter und eurem Team. Solltet ihr Ziele mit eurem Vorgesetzten definieren? Oder ist das purer Blödsinn? Was bringt euch das? Und wie können eure individuellen und Teamziele überhaupt aussehen? Wie sinnvoll ist das Ganze aus Managementsicht? Müssen diese Ziele alle im mathematischen Sinne messbar sein? Oder reicht da vielleicht auch das klassische Bauchgefühl? Schwierige Fragen und noch mehr Meinungen. Es ist eine wilde Episode, wo wir viele verschiedene Dinge wie Objective und Key Results, Gehaltsverhandlungen, Scrum, Velocity, das Devops Vestrum Model sowie Dora Metriken zusammenschmeißen. Viel Spaß beim Kursen.

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

Andi, ich hab heute ein paar Kollegen getroffen und hab das Podcast beworben, bzw. hab das schon mal beworben und dann sagt einer, ich hab mir das jetzt angeschaut, dieses Podcast und hab gelesen, der host mit der Ruhrpott-Schnauze und dann hat er daraufhin das Ganze wieder gecancelt und hat nicht reingehört, weil er sich gedacht hat, das ist zu viel für ihn.

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

Was erstmal cool ist an deinen Kollegen, dass er sich ein Podcast anschauen kann?

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

In Österreich schauen wir das immer, wir schauen etwas an.

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

Aber ich meine, kann ich verstehen, ab und zu würde ich mir auch gerne nicht zuhören, aber lässt sich halt nicht vermeiden.

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

Aber ich habe ihn jetzt natürlich überzeugt, er wird sich das anhören. Und da sind wir auch schon bei einem wichtigen Thema. Wenn ihr noch niemandem erzählt habt, wie toll dieses Podcast ist, dann macht es natürlich jetzt. Also macht vielleicht jetzt mal Signal oder WhatsApp oder sonst irgendeine Message-Plattform, Slack, auf und erzählt einfach eurem besten Freund oder Freundin, einer ITlerin, wie toll dieses Podcast ist, dass man da Andi mit der Ruhrpott-Schnauze hören kann.

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

Der Wolfgang hat aber gerade ein tolles Stichwort genannt, und zwar WhatsApp. Und zwar habe ich vor kurzem, diese Woche, von einem alten Bekannten eine WhatsApp-Nachricht bekommen. Hey Andi, ich höre mit Begeisterung euren Podcast und würde gerne mal ein Bierchen an einem Kiosk in Duisburg mit dir trinken. Ich hab natürlich diese chance lasse ich mir nicht nehmen wenige minuten später hatte ich diesen mann am hörer und wir haben ein bisschen ein bisschen gequatschen termin ausgemacht wann wir ein bierchen am kiosk trinken wir treffen uns auf jeden fall und am ende des telefonats hatte ich ihn, auch gefragt hey hast du denn irgendein themenwunsch was du was du was du gerne mal hören würdest wo darüber wir uns einmal unterhalten, sollen und da sagt er ja habe ich in der tat und zwar würde ich gerne mal was zum thema team metriken einzelmetrik und performance metriken von von mitarbeitern hören und wie ihr darüber denkt also wir sind nicht metriken zur infrastruktur sowas wie response zeiten sondern eher sowas wie zieldefinitionen die beantwortende frage ob du deine ziele erreichst oder ob das team die ziele erreicht oder ob sich das team in die richtige richtung bewegt Und dann bin ich in den in unseren slack gegangen und hab den wolfgang das thema vorgeschlagen ob wir nicht darüber mal ein podcast machen sollten und dann er sagte, ich bin eher so ein bauch mensch hast du deine ahnung von sag ich ahnung ist jetzt ein schwieriges wort aber ich hab auf jeden fall eine meinung.

Wolfi Gassler (00:03:24 - 00:03:26)

Und auf eine meinung kann man definitiv aufbauen.

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

Ganz genau. Und dann haben wir uns die Frage gestellt, okay wir haben beide keine Ahnung davon, wir haben beide irgendeine Meinung. Wo kriegen wir denn mal Input her? Und wo kriegt man mehr Input als in diesem tollen Internet? Und wo kriegt man mehr gesprächige Leute als auf dieser tollen Webseite reddit.com? Ich also ab nach Reddit in den deutschen Subreddit der über Ist übrigens, glaube.

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

Ich, der einzige deutsche IT-Subreddit, den es überhaupt gibt.

Andy Grunwald (00:03:57 - 00:04:17)

De-Edv oder edv-de oder so. Ja, und dann habe ich einfach mal gefragt, inwieweit die Leute das so machen. Das bedeutet, wie werden ihr als Mitarbeiter und euer Team performance-technisch gemessen und was sind eure Teammetriken? Hab ich da mal ein bisschen Mühe gegeben, hab da mal so ein paar Beispiele genannt.

Wolfi Gassler (00:04:17 - 00:05:26)

Andi ist ja ein Storyteller, das wissen wir ja alle schon, hat da wirklich ausführlichst eigentlich geschrieben und dann relativ schnell sind die ersten Antworten eingedrudelt, denn ich möchte da eine ganz stark hervorheben. Er hat irgendwie gefragt, wie misst ihr denn solche Sachen oder was habt ihr für Metrikchen und die erste Antwort war irgendwie gar nicht und die nächste Antwort, same here, wer misst, der misst Mist. Alle sehr positiv eingestellt gegenüber Metrikchen, eindeutig. Andi war komplett down, war komplett fertig, hat mir geschrieben, er will dieses Thema nicht mehr machen, da sind nur Hater unterwegs und es ist kein gutes Thema. Ich habe dann immer erklärt, dass das glaube ich dann erst recht ein wichtiges Thema ist, wenn die Leute so eine starke Meinung darüber haben, dass es unwichtig ist und wir eigentlich beide der Meinung sind, dass es doch irgendwo eine Daseinsberechtigung hat und wir haben ja auch in unseren Teams irgendwo Metriken gehabt und haben auch die Probleme gehabt als Leads, wie bewerten wir denn Leute, wie können wir denn Gehaltserhöhungen überhaupt argumentieren oder nicht argumentieren und das ist schon ein großes Problem und darum hab ich an die fast gezwungen dass wir dieses thema doch machen.

Andy Grunwald (00:05:26 - 00:06:55)

Ich muss ja auch zugeben ich war ein bisschen down aber noch mal mütze schlaf sah die ganze sache wieder wieder besser aus und ich gedacht die jungs da machen wir jetzt was weil da gibt es auch so ein paar kommentare, also ich hab mir auf gut deutsch einfach mal eine gute internet klatsche man man man gepflegten shitstorm abgeholt, Nebenkommentaren wie ist auch alles präzentiöser bullshit den original poster da geschrieben hat irgendwelches geschwurbel den sich herr erler ausdenken um sich selbst zu rechtfertigen ich gebe zu ich kenne das wort präzentiöser bullshit ja noch nichtmals. Aber nur gut lassen wir das und das nehmen wir jetzt mal als herausforderung ja wir bringen uns da nicht runter ja wir machen jetzt hier mal geben unsere meinung zu dem ganzen thema ab und zwar haben wir eigentlich haben wir eigentlich drei kategorien für diesen podcast und zwar einmal reden wir über individuelle ziele also ziele für eine einzelne person für dich als individuell kontributor für dich als mitarbeiter, Dann reden wir einmal über Teamziele und als letztes wollen wir mal den Bereich von der Frage bewegt sich das Team eigentlich in die richtige Richtung beantworten und das unterscheidet sich zu Teamzielen wie und wo genau klären wir dann später. Steigen wir direkt mit dem ersten Punkt ein. Einfach mal individuelle Ziele, Ziele für einzelne Mitarbeiter. Wolfgang warum warum ist das thema relevant warum ist das thema wichtig warum warum sollte ein individueller contributor ein mitarbeiter ziele haben oder warum sollte eigentlich jeder mitarbeiter in irgendeiner Weise ziele haben.

Wolfi Gassler (00:06:55 - 00:07:53)

Da fragst du jetzt natürlich den richtigen ich bin ich bin kein großer fan von von zielen ich bin nicht dieser typ der sich nach silvester überlegt was hat er denn jetzt für gute vorsätze oder so fürs nächste jahr. Ich bin ja da eher auf einer anderen Schiene. Trotzdem glaube ich, dass an sich Ziele ganz wichtig sind. Und zwar primär aus dem Grund, dass Mitarbeiterinnen und deren Leads einfach mal über diese Dinge sprechen. Wo soll denn die Reise hingehen? Wie möchte ich mich denn weiterentwickeln? Was sind meine Ziele im Hinblick? Was möchte ich denn vielleicht mal machen? Bin ich aktuell glücklich? Will ich das weiterhin machen? Oder will ich mich verändern? Will ich irgendwas dazulernen? In welche Richtung will ich gehen? Und ich glaube, man muss über diese Ziele diskutieren. Es geht gar nicht darum unbedingt, dass man sich da so harte Ziele setzt und alles unbedingt zielgetrieben ist. Aber wenn man mit dem Lead gemeinsam darüber diskutiert, in 101 zum Beispiel, haben wir ja eine eigene Episode gemacht, dann muss man halt einfach mit Zielen arbeiten, damit sich zwei Leute darüber verständigen können, wo man einfach hin will und wo die Reise hingehen soll, meiner Meinung nach.

Andy Grunwald (00:07:54 - 00:09:35)

Ich meine, vielleicht fangen wir auch mal ein bisschen an, das Wort Ziele zu definieren. Ziele, Metriken, Messen und allem drum und dran. Ziele heißt für mich jetzt nicht unbedingt, dass das eine knallharte Metrik sein muss, die man in einem Line-Diagramm darstellen kann und die dann entweder hoch oder runter geht. Ziele können auch mit ein bisschen Subjektivität behaftet sein. Das ist vielleicht ganz wichtig mal zu trennen. Dennoch denke ich, das Thema hat eine sehr starke Relevanz, weil es unumgänglich ist, dass man irgendwann über das Gehalt, über eine Gehaltserhöhung spricht oder ähnliches. Oder über eine Beförderung, eine sogenannte Promotion, vielleicht vom Senior-Level zum Staff-Level. Oder vielleicht zum Tech-Lead oder Engineering-Manager. Und wenn man über so was spricht oder wenn man so was anstrebt, dann sollte man schon irgendwas in der Hand haben, was man auch vorlegen kann, beziehungsweise wo man sagen kann, du hast so gute Arbeit geleistet, das wird jetzt auch belohnt. Und warum ist das wichtig? Weil es gibt immer, angenommen, ihr habt ein Team von fünf, und ihr habt einen Chef, und irgendwer hört dieselbe Musik wie euer Chef, oder besucht das Stadion zum selben Fußballverein, oder was weiß ich. Es gibt immer diese Konstellation, dass jemand Best Buddy ist mit dem Chef. Und wenn man gar keine Ziele hat, gar keine Mitarbeiterziele, dann ist es auch eine recht schwierige Geschichte, aus der Engineering-Manager-Sicht, die einzelnen Leute zu bewerten. Und niemand kann sich freisprechen von vom persönlichen bias ja wie soll man da wirklich objektiv entscheiden wer jetzt gute arbeit geleistet hat oder nicht.

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

Wobei man da natürlich dazu sagen muss dass es nicht automatisch immer so eine promotion sein muss oder dass man irgendwie nach nach oben wächst also man kann natürlich auch. glaube ich, glücklich sein mit dem, was man macht, aber man probiert dann halt vielleicht irgendwo eine neue Technologie aus oder probiert Technical Debt aufzuräumen oder irgendwas zu verbessern, also man geht ja danach auf technischer Ebene, wenn man in der gleichen Position bleibt und einfach einen guten Job macht. dann bringt man ja auch Dinge voran, irgendwie eine neue Software, ein neues Produkt, man engagiert sich. Also man kann ja auch auf der Stelle in seiner Position bleiben und sich weiterentwickeln, ohne dass man irgendwie eine Promotion anstrebt, eine Seniorstelle, eine Staffstelle, eine Leadstelle, was es auch immer sei. Trotzdem kann man sich irgendwo Ziele setzen oder einfach vielleicht definieren, was man denn gerne macht und was man das nächste Jahr denn so für einen Fokus setzt zum Beispiel. Und dann hat man halt dementsprechend einfach eine Grundlage, über die man diskutieren kann. Und ich glaube, das ist halt umso größer das Team ist, umso wichtiger wird das Ganze. In einer Zwei-Personen-Firma wird das wahrscheinlich irrelevant sein. Da redet man einfach so eh miteinander den ganzen Tag. Aber umso größer das Team wird, umso wichtiger ist glaube ich das, dass man das auch ausspricht und halt dementsprechend mit dem mit dem Lied im Idealfall in 101 genau über diese Sachen spricht und vielleicht auch dokumentiert, dass man dann eben auch was in der Hand hat, wenn es dann um Gehaltsverhandlungen geht oder wenn es dann plötzlich heißt, Andi ist der bessere Mitarbeiter, weil der geht ja mit mir immer ins Fußballstadion und schaut da keine Ahnung über Fußball. Mir fällt nicht einmal so ein Fußballverein ein. Wie heißt der Düsseldorfer Verein von den Toten Hosen?

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

Fortuna Düsseldorf, das ist jetzt nicht dein Ernst?

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

Fortuna, das wäre mir fast eingefallen. Okay, also wenn der mit dem Chef immer Fortuna-Spiele geht, dann ist der halt plötzlich besser und wenn man dann eben nichts in der Hand hat, wo man sagen kann, ja aber Moment, wir haben ja das vereinbart, wir wollten in die Richtung gehen und ihr habt das alles geleistet, dann kann man halt auch dementsprechend diskutieren und dann ist Fortuna nicht der einzige Grund, warum man eine Gehaltserhöhung bekommt.

Andy Grunwald (00:11:39 - 00:12:23)

Ich sag nicht dass das das jeder unbedingt 20 ziele haben muss und ich sag auch nicht dass das immer der heilige gral ist doch ich sage man sollte sich mit seinen vorgesetzten darüber unterhalten und ich denke, dass man dies auch in unabhängig von der firmengröße tun sollte natürlich sind das anderes andere gespräche zwei mann agentur in einer 20 mann in einer 200 mann oder 2000 mann firma. Ja, das sind andere Arten von Gesprächen und die Ziele werden sehr wahrscheinlich auch anders aussehen. Dennoch sollte man darüber sprechen, weil dann hat man auch konstant etwas, was man in seinen One-on-Ones immer aufbringen kann. Man kann konstant nachfragen, hey, wie siehst du denn meine Entwicklung bezüglich der Ziele, die wir letztes Quartal definiert haben, oder, oder, oder. Und so kann man auch konstant über Feedback sprechen und Feedback anfragen und gucken, ob man auf dem richtigen Track ist.

Wolfi Gassler (00:12:23 - 00:13:24)

Und man darf das nicht automatisch verknüpfen mit irgendwelche Bonuszahlungen oder Gehaltserhöhungen. Da geht es auch um die eigene Motivation, dass man einfach glücklich ist, dass man definiert, okay, was will man denn machen, auch damit man eben vielleicht Arbeit macht, die einem Spaß macht und nicht irgendwelche, keine Ahnung, die ganze Zeit nur irgendwelche Bugfixes macht und der andere Fortuna. Zuseher oder Zuschauer bekommt immer die coolen Tasks, wo es um irgendwelche neuen Technologien geht. Auch sowas macht Sinn, dass man das einfach vereinbart und Ziele vereinbart, ohne dass das jetzt irgendwie verknüpft ist mit Bonuszahlungen, die meiner Meinung nach sowieso nicht sehr sinnvoll sind. Aber es ist ein anderes Thema. Also da geht's, das kann eigentlich wirklich jeder machen und sollte sich vielleicht auch jeder für sich einfach überlegen, wo will man denn hin, auch wenn es, wie Andi, du gerade gesagt hast, das braucht jetzt keine Metrik sein im mathematischen Sinne, wo ich dann wöchentlich irgendeine Zahl hinschreiben kann, sondern einfach so eine grobe Richtung. reicht ja auch schon in ganz vielen Fällen aus und hilft.

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

Dennoch möchte ich das Thema Gehaltsverhandlungen, jährliche Gehaltsverhandlungen nicht an den Tisch kehren, weil diese Art von Zielvereinbarungen und auch messbaren mathematischen Metriken spielen dabei eine große Rolle, um einfach ganz klar auch Enttäuschung vielleicht sogar auf beiden Seiten vorzubeugen.

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

Was für mathematische Metriken kennst du denn oder wie schaut denn sowas aus? Wie kann man denn so eine Metrik definieren überhaupt, damit man die dann objektiv beurteilen kann?

Andy Grunwald (00:13:52 - 00:14:07)

Ja, das ist jetzt gerade die Krux der Sache. Ob jetzt alles 100 Prozent objektiv ist oder objektiv sein muss, ist die Frage. Man sollte es aber jedenfalls objektiv gestützt haben. Wenn du mich so fragst, fallen mir zum Beispiel OKRs, Objective and Key Results, ein.

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

Erklär mal kurz, was das ist. Ich glaub, das ist ja nicht so der große Standard. Ist zwar ein Buzzword, was man jetzt oft hört, aber ich glaub, den wenigsten ist bekannt, was das wirklich ist.

Andy Grunwald (00:14:18 - 00:15:22)

OKR steht für Objective and Key Result und ist eine Art von Planungsmethode, die glaube ich von Google entwickelt wurde. OKRs organisieren sich eigentlich genau wie das Organigramm in einer Art von Baumstruktur. Das bedeutet, das Topmanagement gibt sogenannte Objectives vor. Und eine Objective ist ein großes Thema, wie zum Beispiel, wir wollen das Wachstum der Firma um 30% steigern. Und die Subprojekte eigentlich, nennt man Kiwi-Salz und die Kiwi-Salz, die komplette Erfüllung aller Kiwi-Salz soll dann als Ergebnis haben, dass das Wachstum der Firma um 30% steigert. Und die direkten Mitarbeiter von dem Top-Management würden dann ihre Objectives von einer Key-Result vom Top-Management ableiten. Das bedeutet, dass das Top-Management die Ziele vorgibt und bis ganz runter zum Team und zum Individual-Contributor alles ist miteinander verknüpft und arbeitet auf die Top-Ziele vom Management hin. Eine Objective selbst ist eigentlich das, was wir erreichen wollen. Und eine Key-Result, also das Unterprojekt einer Objective, ist eigentlich das, wie wir das erreichen wollen.

Wolfi Gassler (00:15:23 - 00:15:42)

Jetzt muss ich mal gleich klug scheißen, also das ist natürlich von Intel erfunden worden, nicht von Google, aber Google hat es dann implementiert und hat es glaube ich auch sehr groß gemacht, da hast du natürlich recht. Wie könnte denn das jetzt sowas aussehen, OKRs, für ein Entwicklerteam? Hast du da irgendwie Beispiele, was wäre dann objective und was wären dann Key Results dazu?

Andy Grunwald (00:15:42 - 00:17:03)

Zum Beispiel könnte, und da muss ich jetzt ganz klar sagen, das Beispiel was ich jetzt bringe, OKA-Profis werden mich jetzt glaube ich hassen, weil die Formulierung ist auch immer so eine tricky Thematik, wie formuliert man jetzt richtige Objectives und richtige Key Results, aber nur damit man ein Gefühl dafür kriegt. Zum Beispiel ist die Objective, dass wir die Automation von unseren Software-Deployments erhöhen wollen. Mögliche Key-Results wären jetzt zum Beispiel, dass man ein automatisches CI und CD-System, also Continuous Integration und Continuous Deployment, mit Jenkins aufsetzt. Ein zweiter Key-Result wäre, dass 100% der geloggten Fehler nach Sentry reported werden. Sentry ist eine Error-Logging-Plattform. Die dritte Key Result wäre zum Beispiel, dass man die Continuous Integration Build Zeiten von Travis CI auf unter fünf Minuten für alle Projekte reduziert. Das sind jetzt so, das sind alle drei Ziele. Wenn die alle erfüllt sind, erhöhen die die Automation von den eigenen Software Deployments. Und was ich jetzt gerade sagte, OKA-Profis werden mich jetzt sehr wahrscheinlich schlagen für dieses Beispiel, weil ob die jetzt alle so unbedingt objektiv messbar sind, sei dahingestellt und ob die aspirational sind, Also auch irgendwie motivierend sei auch dahingestellt. Auf jeden Fall sind das ein paar Beispiele. Und wir verlinken in den Show Notes mal eine Webseite, die bietet ein paar solcher Beispiele für Software-Teams.

Wolfi Gassler (00:17:03 - 00:17:58)

Wichtig ist natürlich auch, dass die Key-Results einfach messbar sind und im Idealfall keine binären Ziele sind. Also erreiche das ja oder nein. sondern wie viel Prozent erreiche ich zum Beispiel, wie viel Prozent Verbesserung habe ich von meinen Alerts oder wie viel weniger Alerts habe ich, ich will meine Alerts um 30 Prozent reduzieren oder sowas. Damit ich da also nicht nur binär irgendwas habe, habe ich das erreicht oder nicht, das ist ja auch frustrierend, wenn man es knapp nicht erreicht, sondern einfach prozentuell oder eine Zahl habe, wo ich einfach darauf hinarbeiten kann, Und auch wenn ich das nicht erreiche, was ja eigentlich meistens der Fall ist bei OKRs, weil die recht hoch gesteckt sind, diese Ziele, dann habe ich trotzdem etwas erreicht, auch wenn ich dieses Gesamtziel eben vielleicht nicht konkret erreicht habe, sondern nur 20 Prozent erreicht habe, statt 30 Prozent Reduktion von meinen Alerts, die mich in der Nacht aufwecken zum Beispiel.

Andy Grunwald (00:17:58 - 00:18:35)

Jetzt reden wir natürlich eigentlich über individuelle Ziele. Ziele für einen individuellen Mitarbeiter. Und wir sprechen die ganze Zeit über OKRs. Jetzt ist es aber so, dass die OKRs, die vom Topmanagement und dann für die Abteilung, dann für die jeweiligen Teams gesteckt werden, natürlich auch so weit runtergebrochen werden können auf den einzelnen Mitarbeiter. Das bedeutet natürlich auch, dass die immer granularer und immer granularer werden. Das wären jetzt zum Beispiel Ziele, die ein individueller Mitarbeiter sich ausdenken könnte oder mit seinem Vorgesetzten oder Vorgesetzte erarbeiten könnte. Persönlich bin ich da kein riesen Fan von, von persönlichen OKRs.

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

Warum nicht?

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

Der Grund ist relativ einfach, weil die Abgrenzung von der eigentlichen Arbeit zur Teamarbeit ist dort meines Erachtens nach nicht mehr so wirklich gegeben. Und zwar soll man eigentlich im Team an einer Sache arbeiten. Wenn man jetzt eine Key Result auf einzelne Mitarbeiter runter bricht, dann arbeitet schon wieder jeder irgendwie nur für sich, nur um seine Ziele zu erreichen. Und da kommt mir das Teamgefühl und die Teamkultur zu kurz.

Wolfi Gassler (00:19:02 - 00:20:28)

Da hast du sicher einen Punkt. Es ist klar, wie gerade heute, wenn in moderneren Strukturen, auch mit cross-functional Teams, wird es immer schwieriger, weil ja eben eine Person nicht die eigenen Ziele durchdrücken sollte, sondern das eben immer auf Team-Ebene passieren sollte. Nichtsdestotrotz kann man, glaube ich, schon auf persönlicher Ebene auch Ziele definieren. Das ist jetzt bei Personal OKRs etwas schwieriger, weil man sagt ja immer, sie sollten sich eigentlich von den globalen OKRs ableiten und immer feingranularer werden. Aber wenn ich jetzt natürlich ein persönliches Ziel habe mit, ich möchte mich vote bilden oder ich möchte irgendwas Neues lernen, eine neue Technologie, dann hat es wahrscheinlich wenig zu tun mit dem Zielen von meinem Team. Im Idealfall kann man das natürlich irgendwo verknüpfen oder sollte auch vielleicht irgendwo hineinpassen in die Ziele des Teams, dass das irgendwo Platz hat. Aber es kann natürlich auch sein, dass das komplett unabhängig davon ist, weil wenn ich persönlich jetzt mehr Public Speaking machen will und irgendwo auf einer Konferenz sprechen will, dann hat es wahrscheinlich wenig damit zu tun, dass die globalen Ziele 10% mehr Umsatz oder so vorgeben. Dann wird das eher weniger zusammenhängen. Im Idealfall habe ich aber vielleicht irgendwo weiter oben ein Ziel, dass die Firma mehr Employer-Branding machen will und dann kann man das wieder sehr wohl verknüpfen. Also im Idealfall natürlich hat man da sogar Möglichkeiten, aber ich glaube auf individueller Ebene hat das im Normalfall eher weniger zu tun mit den ganz anderen Zielen von Team- oder Management-Ebene.

Andy Grunwald (00:20:29 - 00:21:10)

Aber du hast einen wichtigen Punkt angesprochen. Meines Erachtens sollten die Ziele eines einzelnen Mitarbeiters schon mit den Firmenzielen verknüpft werden. Public Speaking, Beispiel. Mach einen interessanten Talk, geh auf die Bühne, aber sieh halt zu, dass die Firma auch wirklich offene Stellen für Software Engineers hat. Employer Branding. Wenn jetzt jemand eine neue Technologie lernen möchte, okay, warum verbindet man das nicht zum Beispiel mit einer Zertifizierung? Natürlich sollte man irgendwie schauen, dass die Technologie natürlich für die Zukunftsprojekte irgendwas weiterbringen kann. Beispiel, jemand lernt Kubernetes und Grafana und Monitoring. Was kann die Firma davon gewinnen? Und wie kann das Neuerlernte für die neuen Projekte genutzt werden?

Wolfi Gassler (00:21:10 - 00:22:04)

Ich glaube, dass es auch sehr wichtig ist, dass das im Team dann bekannt ist, dass man so wirklich als Team weiß, okay, der Andi möchte das lernen und der Wolfi möchte das lernen, damit man auch dementsprechend sich das ein bisschen ausmachen kann oder vielleicht auch gemeinsam an irgendwas arbeiten kann. Also auch da ist die Kommunikation dann glaube ich wieder sehr wichtig und da können natürlich OKRs auch helfen, weil OKRs bei Definition eigentlich transparent sind und jeder sollte eigentlich auf alle OKRs companywide zugreifen können. Und auch ich kann die OKRs von meinem CEO einsehen und checken, was der denn machen will. Genauso der CEO kann meine OKRs einsehen. Also das sollte ja möglichst transparent sein. und sollte dann auch in der Firma helfen, um zu wissen, wer arbeitet dann an welchen Dingen und wer will sich in welche Richtung weiterentwickeln. Ich glaube, transparent ist da schon auch sehr wichtig.

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

Bist du nicht Freelancer und dein eigener CEO?

Wolfi Gassler (00:22:06 - 00:22:11)

Montags. Dienstag bin ich dann mein Angestellter und check mal meine eigenen OKRs.

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

Mega. Kann ich mal bei den Gehaltsverhandlungen dabei sein?

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

Die sind mittwochs.

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

Jeden Mittwoch? Ist die Inflation in Amsterdam so hart?

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

Ja, da bin ich ziemlich hart. Das sind immer sehr harte Verhandlungen. Donnerstag will ich fast immer kündigen.

Andy Grunwald (00:22:27 - 00:22:28)

Und Freitag ist frei, ne?

Wolfi Gassler (00:22:28 - 00:22:29)

Freitag ist sowieso frei.

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

Kennst du eigentlich das Sams?

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

Klar, bin ich natürlich groß geworden mit dem kleinen Sams.

Andy Grunwald (00:22:36 - 00:23:34)

Wundervoll. Kommen wir zurück zu den Zielen. Was ich mir gut vorstellen kann, ist, dass man als individuelles Ziel hat, zum Beispiel die Definition und das Leiten eines Key Results oder einer Objective. Oder zum Beispiel die technische Leitung übernehmen von einer Key Result für ein Jahresquartal für das Team. Wenn jemand sagt ja das ist ja keine arbeit das ist schon eine ganze menge arbeit zusehen dass er dass die ganze key result überhaupt läuft durchgeplant ist dass der dass der progress getrackt wird dass es alles dokumentiert wird und so weiter und so fort natürlich ist das zusatzaufwand neben eurem normalen job, Und natürlich solltet ihr dann mit eurem Vorgesetzten darüber sprechen, wieviel prozentualen Wochenzeit ihr darauf, ich nenne es mal, ausübt. Die fällt ja natürlich von eurem normalen Job dann ab. Aber das kann natürlich auch ein individuelles Ziel für euch sein, dass ihr die technische Leitung für eine Key Result oder für ein Objective oder für ein Quartalsziel, je nachdem welches Planungsframework ihr nutzt, Was.

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

Sagst du denn zu den zu den Leuten die jetzt sagen so ein absoluter Bullshit und das ist nur Overhead, absoluter Overhead. Vor allem ich bin in einer kleinen Fünf-Mann-Firma, das ist nur Overhead, was soll das Ganze.

Andy Grunwald (00:23:46 - 00:23:48)

Du meinst OKR selbst?

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

Ja oder Ziele allgemein.

Andy Grunwald (00:23:49 - 00:24:56)

In einer kleinen Fünf-Mann-Firma mag das vielleicht so sein, weil da kriegt man jetzt vielleicht noch alle Leute zeitgleich in einer Kaffeeküche unter und man hat sowieso eine andere Beziehung als in einer 100-Mann-Firma. Der Punkt ist aber, um alle Leute am gleichen Strang zu halten und auch in die gleiche Richtung gehen zu lassen, ist einfach ein gewisses Allein mit notwendig. Und es ist auch einfach notwendig, dass man das, wohin man möchte und was man erreichen möchte, die sogenannten definierten Ziele auch aufschreibt, damit jeder ganz klares Verständnis davon hat. weil nur weil wir uns alle auf dasselbe ziel einigen heißt das nicht dass wir das komplett dasselbe verständnis von den zielen haben und auch wenn die wenn die firma mal wächst oder wenn jemand neues dazu kommt der vielleicht noch nicht in der eingeschworenen fünf mann klicke dabei ist dann muss dieser diese person ja auch irgendwo wissen woran und wofür wir hier eigentlich arbeiten. Weil im Endeffekt, eine Firma, sofern das jetzt keine Non-Profit-Firma ist, hat das Ziel, Geld zu verdienen. Und das darf man leider nicht vergessen. So toll eure Arbeit auch ist, es ist eine profitorientierte Firma und da sind gewisse Strukturen von nöten.

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

Jetzt sind wir schon ein paar Metriken und Frameworks wie OKRs durchgegangen, um solche Ziele zu machen. Was wären denn Anti-Patterns oder Anti-Ziele, die man auf keinen Fall oder Anti-Metriken vielleicht, die man auf keinen Fall verwenden sollte und die aber oft im Gespräch sind?

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

Wie viele Lines of Code ich pro Woche geschrieben habe, wie viele Pull Requests ich gemacht habe, wie viele Tickets ich erstellt oder geschlossen habe. Das sind so, ich glaube, die klassischen Metriken, die jedem BWLer einfallen, der keine Ahnung von Softwareentwicklung hat.

Wolfi Gassler (00:25:27 - 00:25:46)

Aber jetzt fließen ja zum Beispiel die Tickets ganz oft in Metriken ein, wenn es um Scrum geht und Velocity und wie performant ist ein Team, werden mehr Tickets abgearbeitet als letzte Woche oder im letzten Sprint. Weißt du dann, ist das sinnlos oder ist das eine falsche Vorgehensweise?

Andy Grunwald (00:25:46 - 00:26:04)

Ja, ich meine, wenn du jetzt hier Scrum und Velocity ansprichst, nur mal kurz für Leute, die mit den Begriffen noch nicht anfangen können, Scrum ist eine agile Methode, eine agile Arbeitsmethode, in der man fest definierte Zeitintervalle hat, in denen man Zwischenziele erreicht, Beispiele.

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

Also Scrum ist jetzt schon so ein Buzzword, das kennt doch jetzt wirklich schon jeder, oder? hat schon jeder mal gehört das lassen wir mal den den hörerinnen als hausaufgabe wenn sie scrum noch nie gehört haben scrum.

Andy Grunwald (00:26:17 - 00:26:19)

Okay und dann google mal gleich noch velocity mit.

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

Velocity kannst du schon mal erklären.

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

Da setzte mich jetzt aber an den pranger. Die velocity ist die art von komplexitätspunkten die ein team pro sprint erreicht. Und diese wird über mehrere Sprints gemessen, um zu schauen, ob wir zu komplexe Tickets hatten, ob sie steigt, ob sie sinkt oder, oder, oder.

Wolfi Gassler (00:26:44 - 00:28:17)

Die Velocity zeigt eigentlich, ob du dich verbesserst. Das heißt, du vergleichst die Velocity, die Geschwindigkeit, wie viele Komplexitätspunkte hast du im letzten Sprint gemacht, wie viel machst du jetzt in diesem Sprint. Und da ist es meiner Meinung nach extrem wichtig, und das vergessen, ganz, ganz viele Manager und vor allem in der Top-Ebene, dass das eine Metrik ist, die nur für dieses einzige Team gilt, wo es auch gemessen wird. Das heißt, es ist keine Metrik, die man verwenden kann, um irgendein Team zu vergleichen mit einem anderen Team. Da geht es nur darum, ist dieses Team schneller geworden oder nicht und das kann nicht verglichen werden mit einem anderen Team, weil das ist komplett individuell, wie komplex etwas bewertet wird von dem Team und das kann einfach nicht mit anderen Teams in Relation gesetzt werden und das wird leider sehr, sehr oft gemacht und dann vergleicht man irgendwie, wie schnell ist ein anderes Team geworden, wie schnell ist dieses Team geworden und das kann man einfach nicht über diese Metrik vergleichen. Ganz allgemein finde ich das sowieso sehr sehr problematisch, wenn du Teams vergleichst, weil es gibt halt selten Metriken, die so teamübergreifend wirklich gültig sind und die das ermöglichen, dass man zwei Teams miteinander vergleicht. Also das ist extrem gefährlich. Und auch erfahrungsgemäß, egal wann, wenn man versucht hat irgendwie Personen oder Teams so company-wide zu vergleichen, ist man da eigentlich gegen die Wand gefahren und hat extrem viele Probleme bekommen. Also das kann ich eigentlich niemandem empfehlen, das zu machen.

Andy Grunwald (00:28:17 - 00:29:57)

Super Punkt, die Velocity und dass diese an das Team gebunden ist. Und eine Sache, die ich, meine Kritik, nicht meine Kritik, ah doch schon, meine Kritik, wie die Velocity oft wahrgenommen wird bezüglich der Teamgebundenheit. Wenn eine Person das Team verlässt, hat man ein neues Team. Wenn eine Person in ein Team kommt, hat man ein neues Team. Was bedeutet das? Das bedeutet, sofern es in irgendeiner Form personelle Änderungen im Team gibt, ist meines Erachtens nach die vorherige Velocity nicht mehr nutzbar. Weil die muss sich erst über zwei, drei, vier Sprints einspielen. Weil man hat, je nachdem, wer geht, entweder einen sehr starken Contributor verloren oder es kommt irgendwie eine sehr laute Person wieder rein, die Kultur des Teams wird verändert, vielleicht, ... Kommt ein Junior rein, der mehr Mentoring braucht, oder, oder, oder. Oder ein super Senior, der alles in Frage stellt, oder, oder, oder. Man hat einfach ein neues Team. Und das bedeutet, man braucht wieder, weiß ich es gar nicht, drei, vier, fünf, sechs Cycles, Sprints, bis diese Velocity sich wieder einspielt. Und da ist die Frage, wenn wir jetzt mal eine Sprintlänge von zwei Wochen nehmen, sechs Sprints, sind wir bei zwölf Wochen, bei drei Monaten und in drei Monaten kann sich halt auch personell schon wieder eine ganze Menge ändern. Da frage ich mich, wie viele stabile Teams gibt es eigentlich, die ihre Velocity knallhart über ein Jahr oder anderthalb wirklich vergleichen können? Also ich meine, ich finde das beachtlich, wenn man so eine gute Retention hat. Aber speziell in der Startup-Welt, in den Hyper-Growth-Firmen, habe ich das noch nicht gesehen.

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

Ich glaube auch, dass das eher in kleineren Firmen ist, wo die Retention ein bisschen höher ist, wo die Teams auch in gleicher Form bestehen bleiben, weil auch in so großen Hypergrowth Firmen, wie du erwähnt hast, oder Startups, da wechseln ja allein die Teamstrukturen irgendwie einmal im Quartal oder fünfmal im Quartal, eben im schlimmsten Fall. Da hast du sowieso ständig neue Teams, aber in kleineren Firmen könnte ich mir vorstellen, dass das gut ist. Und auch da muss man dazu sagen, das sind nicht irgendwelche Metriken für Manager, sondern das sind Metriken für das Team. Das heißt, das Team kann dann für sich einfach entscheiden, was machen wir mit diesen Metriken? Wollen wir irgendwas ändern? Schauen wir mal unsere Velocity an? Müssen wir irgendwie was adaptieren? Müssen wir in irgendeine Richtung etwas abändern oder an unseren an unserem Arbeitsablauf irgendwas was ändern an den Schätzungen oder sonstigen Dingen und das darf man halt nie vergessen, was sind Metriken die für das Management da sind und was sind Metriken die für das Team da sind und alle Scrummetriken sind meiner Meinung nach die Metriken, und keine Managementmetriken, die das Management in irgendeiner Form verwenden kann. Managementmetriken sind irgendwelche KPIs, die zum Beispiel die Revenue, also den Umsatz zum Beispiel darstellen, das man einfach klar messen kann und mit denen kann ja das Management arbeiten, aber die Velocity von irgendeinem einzelnen Team ist nichts für das Management.

Andy Grunwald (00:31:20 - 00:33:18)

Jetzt hattest du mich gerade nach Antipatterns gefragt und ich hab so Klassiker genannt wie Lines of Code oder Anzahl Tickets oder ähnliches. Und jetzt hatte ich im Intro auch den Kollegen erwähnt, der mich da angerufen hatte, mir dieses Thema vorgeschlagen hat. Jetzt auch mal Grüße an Stefan. Und er hat eine sehr interessante Frage gestellt. Und zwar habe ich zwar Lines of Code und Tickets als Anti-Pattern bezeichnet, aber wenn wir jetzt mal zum Beispiel die Teamarbeit und die Arbeit eines einzelnen Mitarbeiters auf Pull-Requests münzen, dann kann man natürlich auch so knallharte Metriken nehmen, wie zum Beispiel, wie viele Review-Runden braucht eine bestimmte Kombination von Mitarbeitern denn immer und wieso verbessert die sich nicht? Beispiel. Ich mache einen Pull-Request und ich mache meinen ersten Pull-Request und meine Teammitglieder und ich brauchen, sagen wir mal, sechs Review-Runden, bis der Pull-Request gemerged werden kann. Jetzt bin ich drei, vier Monate im Team und wir brauchen immer noch pro Pull-Request sechs bis sieben Review-Runden. Da ist natürlich schon mal die Frage, lass uns da doch mal rein schon in den Pull-Request. Wieso braucht man sechs bis sieben Review-Runden? Und was kann man da verbessern? Liegt das am Pull-Request-Autor also an mir? Liegt das daran, dass da immer nur Nitpicking betrieben wird? Und diese Frage fand ich eigentlich ganz interessant, weil es geht gar nicht darum, wer ist jetzt so genau und wer schreibt irgendwie scheiß Code, sondern kann man solche Metriken nutzen, um einzelne Personen weiterzuentwickeln? weiterzuentwickeln in Bezug auf Kommunikation, weiterentwickeln im Bereich Prozessoptimierung, vielleicht sogar einzelne Ziele setzen wie, hey, setzt ihr doch mal dieses Quartal das Ziel, mit dem Team einen eigenen Coding Style Guide zu definieren und implementiert in die GitHub Actions oder in eurer Jenkins einen automatischen Format Checker. Buff, alle nitpicking Kommentare, wo das Komma und die Klammer stehen soll, verschwinden auf einmal. Reduzieren sich dadurch die Review Cycle.

Wolfi Gassler (00:33:18 - 00:35:49)

Da ist es, glaube ich, auch ganz wichtig, dass das klar kommuniziert ist und in dem Team auch vereinbart ist, weil es gibt nichts Schlimmeres als irgendwelche Metriken, die übergestülpt werden und dann kommen irgendwelche Leads, die dann sagen, ja, aber diese Metrik stimmt nicht und diese Metrik stimmt nicht und was macht ihr eigentlich dort? Also im Idealfall hat das Team gemeinsam entschieden, wir wollen diese Metrik, wir wollen messen, wie viele Cycles wir brauchen beim Pull Request. Und wir selber entscheiden dann auch, was wir verbessern können. Weil sonst hast du ja dieses Problem, dass es auch mit Bonuszahlungen z.B. gibt beim finanziellen Anreiz, dass dann jeder nur mehr auf diesen KPI, auf diese Metrik hin optimiert und einfach sagt, okay, wenn wir weniger Review Cycles wollen bei einem Bull Request, dann schreiben wir halt einfach keine Kommentare mehr rein und uns ist alles scheißegal und dann wird es halt einfach durchgewunken. Also da ist es, glaube ich, ganz wichtig, dass die Fehlerkultur und die ganze Engineering Culture in der Company oder im Team dementsprechend vorhanden ist und dass da auch alle einverstanden damit sind. Wir hatten mal so einen Fall, da wollten wir ein System anschaffen, oder es wurde uns ans Herz gelegt, so ein System, das extrem viele Metriken ausspielt aus Git. Also alles, was irgendwo in Git stattfindet, hat da dieses externe Tool extrem viele Metriken gebaut. Das kann man jetzt natürlich positiv sehen, dass man wirklich sagt, okay, man sieht genau wieviel Pull-Requests, wie schnell ist man, wie schnell werden Code-Reviews gemacht, wie schnell wird ein Pull-Request abgearbeitet. Also diese ganzen Metriken und es könnte natürlich ein Team sagen, super cool, wir bekommen da jetzt Metriken und können einfach besser damit arbeiten, uns optimieren und können mal checken, was denn da so abläuft. Auf der anderen Seite kann natürlich ein Team sagen, Das wollen wir überhaupt nicht, da wollen wir da unser Manager nur irgendwie alles überprüfen und alles verbessern und dann bekommen wir diese Metriken aufgedrückt. Also so ein Tool kann in die eine oder in die andere Richtung wirken und da ist es einfach extrem wichtig, dass man mit dem Team gemeinsam das vereinbart. Und wenn das Team so ein Tool oder die Metriking nicht will, kann man es versuchen zu überzeugen, aber sonst hat es einfach wenig Sinn, wenn man da als Manager irgendwas aufdrücken will. Also es sollte schon im Idealfall aus dem Team kommen und wenn man da einen Scrum Master zum Beispiel hat, der da auch dementsprechend das bespricht mit dem Team, kann man da nun mal schon Aus der eigenen Motivation heraus, sich einfach zu verbessern im Team und besser zu werden und Ziele zu haben als Team, damit man dann vielleicht einfach mal auch feiern kann, dass man irgendein Ziel erreicht hat, dann kann man sowas auch dementsprechend verwenden.

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

Da sprichst du natürlich mal wieder über ein Herzensthema von mir, ja? Meiner Bachelorarbeit Software Repository Mining.

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

Also ich hab gedacht, der Kuchen vom Feiern ist dein Herzensthema.

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

Die Analyse von Metadaten, die während eines Softwareentwicklungsprozesses entstehen, Git Commits, Pull Requests, Mailinglisteneinträge, IRC oder Slackchats inzwischen. Mit all solchen Metriken kann man natürlich auch den Speed des ganzen Teams verbessern und erhöhen. Mit Speed meine ich nicht unbedingt die Performance und den Output des Teams, aber eher die Zeit von deinem Code Change bis zum ersten Produktionsfeedback. Jemand, der diese Daten bewertet und auch aufbereitet und auch analysiert, der muss schon wissen, wie ein Software-Entwicklungsprozess vonstanden geht. Was ist eigentlich ein Git-Commit? Was ist eigentlich ein Pull-Request? Wo kommt es beim Debugging drauf an? Und warum macht Per-Programming überhaupt Sinn? Und so weiter und so fort. Und wenn man das alles weiß, dann kann man auch als Engineering Manager mit der Information, warum braucht die Kombination von diesem Autor, diesem Pull-Request-Autor und diesem Reviewer eigentlich immer sieben Cycles bis zum Merge. Ja, dann kann man mit den jeweiligen Personen halt auch mal daran arbeiten, die ganze Sache zu optimieren.

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

Was haltest du denn von der Teammetrik Happiness? Hört man ja sehr oft im Scrum-Umfeld auch.

Andy Grunwald (00:37:12 - 00:37:21)

Also wenn du das so bland aufs Papier schreibst, würde ich sagen, wir würden das gemessen. Also ich bin happy, wenn ich betrunken bin, dann bin ich auch happy.

Wolfi Gassler (00:37:21 - 00:37:24)

Warum haben wir bei Trivago immer so viel Bier gehabt in den Kühlschränken?

Andy Grunwald (00:37:24 - 00:37:40)

Achso, das nennt man Kultur. nee, ich find's immer schwierig, wenn man das so ohne Kontext sagt, was ist Happiness? Also, ich kenn, glaub ich, kein subjektiveres Thema. Doch, vielleicht, aber ich bin verliebt. Vielleicht ist das noch subjektiver.

Wolfi Gassler (00:37:40 - 00:37:42)

Hat ja auch mit Happiness stark zu tun.

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

Sollte, ja.

Wolfi Gassler (00:37:43 - 00:37:46)

Hast du es mal in irgendeinem Team gemessen?

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

Nicht durch ein klassisches Survey oder Ähnliches, weil ich glaub, ich jetzt grad gar nicht wüsste, wie ich dieses Survey aufbauen sollte, dass ich da wirklich valide Daten rauskriege.

Wolfi Gassler (00:37:54 - 00:40:04)

Wir hatten ja bei Trivago dieses Office-Vibe, das bei Slack ständig Fragen stellt an alle Mitarbeiterinnen, wie sie sich fühlen, gewisse Focus-Areas abfragt. Das kann man auch definieren, zentral in der Firma, um einfach so ein Vibe im Office zu bekommen. Und das geht schon sehr in die Happiness-Richtung. Ich glaube, man kann auch in einem Team sehr einfach die Happiness abfragen. Man kann natürlich jedes Teammitglied einfach einmal die Woche auf einer Smiley-Skala zum Beispiel fragen, wie geht es dir denn im Team aktuell? Das ist natürlich sehr subjektiv, wie du richtig sagst, das ist jetzt nicht die ideale Metrik. Vielleicht ist es auch besser, eher in Richtung Teammoral zu gehen und dann die Leute zu fragen, wie sie sich im Team fühlen und mehr Fragen in Richtung Team zu stellen, bin ich stolz auf mein Team, bin ich gechallenged in meinem Team, wie viel Energie bekomme ich von meinem Team, also mehr so Teamfragen stellen. Aber grundsätzlich, auch wenn es eine sehr subjektive Metrik ist, man erhält schon auch als Lead vor allem einen sehr guten Einblick, weil es geht ja auch gar nicht darum, ist es jetzt extrem gut, ist es extrem schlecht, ich vergleiche das auch nicht mit anderen Teams. Aber man kann zum Beispiel einen Einbruch sehen. Wenn jetzt plötzlich alle Team-Members irgendwie um zwei Punkte schlechter wurden in einer Woche oder in der nächsten Woche, dann weiß ich auch als Lead, okay, da ist irgendwo ein Problem und ich muss damit oder ich muss da in diesem Bereich irgendwie agieren und mal nachfragen, in meinen 101 zum Beispiel. Was ist denn überhaupt das Problem? Ich habe in meinen 101 auch immer wieder mal gefragt, okay, wie ist aktuell deine Happiness auf einer Skala von 1 bis 10? Einfach um so eine Einstiegsfrage zu haben und mal zu vergleichen zur letzten Woche einfach oder zur letzten Monat oder was auch immer. Und so bekommt man schon einen gewissen Trend mit. Natürlich im Idealfall, wenn man auch im Team arbeitet, bekommt man das sowieso irgendwo mit so zwischen den Zeilen und wenn man Kaffee trinkt. Aber wenn man natürlich jetzt weniger zu tun hat mit dem Team, hilft so eine Metrik, die man auch ganz schnell abfragen kann, einfach um so ein bisschen ein Gefühl zu bekommen, gibt es aktuell irgendwo Probleme, läuft was in die falsche Richtung und dann muss ich natürlich agieren und ins Detail gehen und tiefer reingehen.

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

Ich glaube, das Wichtige ist, dass man diese Art von Fragen kontinuierlich stellt und über längeren Zeitraum, um da wirklich einen Trend herauszufinden. Und ich glaube, es ist wichtig auch, dass die Daten da mehr oder weniger statistisch relevant sind. Das bedeutet, wenn du nicht nur zwei Leute hast, weiß ich jetzt nicht, wie relevant oder auswertbar die ganze Thematik ist.

Wolfi Gassler (00:40:23 - 00:40:50)

Ich glaube, es muss ja gar nicht unbedingt klassisch-statistisch aussagekräftig sein. Ist es nämlich selten, auch bei so einer Herangehensweise. Aber es hilft mir einfach als Indikator. Läuft denn irgendwas schief? Und wenn von fünf Teammitgliedern plötzlich alle irgendwie von einem Happy Smiley auf einen Unhappy Smiley wechseln, dann weiß ich, okay, in dem Team läuft irgendwo was schief.

Andy Grunwald (00:40:51 - 00:41:03)

Ja, da kann auch einfach sein, dass der Kollege, der den Smiley grad von happy auf unhappy gemacht hat, in einer Mietwohnung wohnt und der Nachbar die ganze Zeit irgendwie gefügelt hat oder in die Wand rumgebohrt hat und deswegen man nicht schlafen konnte, also das kann natürlich auch sein.

Wolfi Gassler (00:41:03 - 00:42:01)

Darum ist es eben besser, in Richtung Teammoral zu gehen und die Fragen auch dementsprechend zu stellen, dass sie mehr mit dem Team zu tun haben. In dem 101 kann ich vielleicht einfach ganz gerade heraus, wie geht's dir denn gerade, Skala 1 bis 10, wie geht's dir, Ganz allgemein, weil da will ich ja vielleicht auch diese private Ebene mit abfragen, aber sonst kann ich natürlich einfach eben mehr team-related questions stellen und dann höre ich schon raus, okay, gibt es eben irgendwo Team-Probleme, weil wenn der private Probleme hat, wird er wahrscheinlich nicht so klar reagieren bei den Team-Fragen und vor allem, es geht ja auch wieder um die Menge. Wenn eben fünf Mitglieder von diesem Team so reagieren, dann weiß ich, dass es ein Teamproblem gibt. Wenn es nur eine Person ist, hat halt diese eine Person ein Problem, kann ich auch tiefer gehen. Aber ich sehe wenigstens, dass die anderen Teammitglieder noch nicht so weit sind, dass sie schon extrem runtergekommen sind und vielleicht im Team gar nicht mehr gerne arbeiten und gar nicht mehr gern zur Arbeit gehen zum Beispiel.

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

Alternativ wohnen auch die fünf Teammitglieder im selben Mietshaus oder haben eine WG, oder?

Wolfi Gassler (00:42:05 - 00:42:08)

In was für Firmen arbeitest du denn du? Sei es dann Kommune?

Andy Grunwald (00:42:08 - 00:42:14)

Wenn wir über Team Happiness reden, reden wir auch so ein bisschen über Organisationskultur, oder?

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

Inwiefern?

Andy Grunwald (00:42:15 - 00:43:26)

Naja, und zwar hat mich auf diesen Link ein Arbeitskollege gebracht und das wollen wir jetzt mal testen. Und zwar gibt es nämlich zur Team Happiness Bewertung oder zur Bewertung deiner Organisationskultur oder wie gesund ist dein Team, Nämlich auch das westrum survey das westrum survey ist ein teil der sogenannten devops kultur und wurde vom soziologen doktor westrum entwickelt auf basis von research und assessment studie rund um das thema devops da wurden ein paar ein paar fragen entwickelt die. hoch valide und statistisch zuverlässig sind um halt ich sag mal die gesundheit eines eines teams festzustellen ein paar fragen sind zum beispiel in meinem team sind die verantwortlichkeiten geteilt in meinem team führen fehler zu untersuchungen in meinem neuen in meinem team sind neue ideen willkommen und so weiter und so fort. Das ist halt so eine Liste von Fragen. Natürlich bezieht sich das eigentlich so auf die DevOps-Kultur. Den Link kann ich auch mal weiterschicken. Ist auf jeden Fall eine ganz interessante Sache, so was jedes Quartal dann mal zu machen, um auch wirklich so eine Art Team-Happiness zumindest mit dem Fokus auf DevOps zu messen. Finde ich eine ganz interessante Geschichte.

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

So Office Vibe ist ja genau sowas. Das ist halt ein Tool, das das automatisch macht für sehr große Firmen. Aber man kann es auch im kleinen Team machen und das wäre eigentlich so eine einfache Sache. Man erstellt einfach irgendeine Google Forms mit genau diesen Fragen. Ich habe das ja auch mal, glaube ich, schon in einer anderen Episode erwähnt, dass ich das als Manager einfach gemacht habe, um Feedback zu meiner Person zu bekommen. Einfach so ein paar Fragen in dem Google Form. Und das sende ich dann einfach regelmäßig aus an mein Team und frag da auch nochmal bitte nach, dass ihr das auch wirklich ausfüllt, dann muss man teilweise ein bisschen pushen. Aber das ist so einfach, das braucht wirklich super kurze Zeit und man bekommt einfach ein gutes Gefühl, was denn gerade so abgeht und wie sich ein Team entwickelt. Und was auch noch sehr gut ist, wenn man das Ganze noch transparent mit dem Team teilt. Also das ist auch ganz wichtig, auch bei so Office-Vibe-Geschichten, also wenn das irgendwie automatisch erfasst wird. Viele haben da irgendwie ein Problem, dass man da personalisierte Daten dann auslesen kann oder als Manager auch mehr sieht. Wenn man da einfach transparent vorgeht und sagt, okay, auch mal herzeigt, okay, wie schaut diese Administration aus oder was ist der Outcome von dieser Umfrage, wenn es jetzt eine Google Form ist, dass man das einfach teilt mit dem Team und auch offen bespricht und einfach sagt, okay, in den letzten drei Wochen ist das Ganze nach unten gegangen, unsere Happiness in dem Team und einfach mal offen anspricht, wo liegt das Problem, was können wir vielleicht machen. Also im Idealfall bespricht man das zuerst in 101s und weiß als Lead schon ungefähr, wo die Probleme liegen, aber dass man es dann trotzdem sehr transparent und offen anspricht. Ich glaube, das ist ein sehr wichtiger Punkt. Aber ich möchte nur noch einmal darauf hinweisen, es ist super einfach und das kann man auch in einer kleinen Firma machen. Man braucht ja nicht irgendwie ein großes Framework, Google Forms aussenden und die Ergebnisse analysieren und teilen und das war es schon. Ich glaube, auch das zeigt dann, dem Team, dass das wichtig ist und dass man das einfach gemeinsam auch lösen will. Und ich glaube, das gibt dann auch ein gutes Gefühl und zeigt die Wertschätzung, was man dem Team gegenüber hat.

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

Springen wir noch mal ganz kurz weg von der Team-Happiness zum individuellen Mitarbeiter. Bei Trivago hatten wir das in der 360-Grad-Umfrage, das 360-System. Kannst du mal kurz für die Herren erklären, was das ist und was du daran gut und was du daran schlecht fandest?

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

Also das ist jetzt, glaube ich, zumindestens nichts, was Trivago erfunden hat bzw. mittlerweile haben das eigentlich relativ viele Firmen. Es kommt meines Wissens, glaube ich, aus dem Coaching-Bereich, 360-Grad-Analysen. Und es heißt eigentlich nichts anderes, dass man eben um diese Person herum 360 Grad Meinungen und Feedback einholt. Bei Trivago war das sehr strukturiert in dem Tool und halbjährlich hat man so eine 360-Grad-Umfrage quasi gemacht, hat Leute ausgewählt, mit denen man zusammengearbeitet hat, und die das Feedback geben sollen. Das waren meistens so 20, 25 Personen. In manchen Fällen bei uns als Leads teilweise auch 50. Und dann hat man von 20 Personen zum Beispiel ein Feedback bekommen in mehreren Kategorien zum letzten halben Jahr. Einfach wie die Zusammenarbeit war, wie viel man geleistet hat in den Augen von anderen Personen. Und darauf aufbauend hat es dann auch ein Gespräch gegeben mit dem Lead, und man hat diese Ergebnisse besprochen. Die sind natürlich auch in gewisser Weise in die Gehaltsverhandlungen eingeflossen, aber dadurch, dass möglichst verteilt war, über 20 Personen zum Beispiel, hat man da schon sehr wohl, und das kann ich jetzt als Lead sagen, der da extrem viele von diesen Evaluierungen und Feedbackbögen bekommen hat, dass man da schon Trends ablesen hat können, dass bei 20 Personen schon ganz klar die Richtung ersichtlich ist, wo denn vielleicht Optimierungsbedarf ist, wo man vielleicht was verbessern kann, wo die Personen sehr stark sind und das hat man dann halt auch den Personen dementsprechend mitteilen können und hat denen wirklich ein qualitatives Feedback geben können, was meiner Meinung nach sehr sehr wertvoll war.

Andy Grunwald (00:47:30 - 00:47:38)

Ich glaube, die größte Kritik an dem 360-Grad-System war eigentlich so, dass die Best Buddies sich immer sehr, sehr positiv bewertet haben, oder?

Wolfi Gassler (00:47:38 - 00:48:24)

Das stimmt natürlich, aber wenn du einfach auch die Regel hast zum Beispiel, dass dein ganzes Team dich bewertet, dann hast du natürlich nicht nur die Best Buddies und du als Lead siehst ja die Kommentare, die sind zwar anonymisiert dann schlussendlich für die Person, aber du als Lead siehst ja genau, wer welche Kommentare schreibt und hast die dann auch zusammenfassen müssen für die Person. Und da kannst du natürlich diesen Bias auch mit rausnehmen, weil als ein guter Lead kennst du ja eben genau diese Connections, die Bodies, die sich gut kennen. Und über 20 Leute hinweg, du kannst normalerweise nicht Best Friend mit 20 Leuten sein. Also da sieht man schon dann auch so Problemfelder im Normalfall. Das war zumindest immer meine Erfahrung, dass das eigentlich ein kleineres Problem war als diese Kritik, die oft natürlich auch angesprochen wurde.

Andy Grunwald (00:48:25 - 00:49:31)

Ich mag das 360-Grad-System, weil man wirklich Feedback von allen kriegt. Von seinem Vorgesetzten, von seinen Direct Reports und auch von seinen Peers. Also einmal wirklich rundum, das finde ich toll. Und dass man nicht nur von seinem Vorgesetzten bewertet wird oder ähnliches. Was ich ein bisschen gefährlich finde, ist die 360-Grad-Bewertung mit in Gehaltsverhandlungen einfließen zu lassen. Und der Grund ist ganz einfach das, weil bei einem 360-Grad nimmt man nicht nur seine direkten 360-Grad-Connections, sondern auch die etwas entfernten, mit denen man zum Beispiel Projekte durchgeführt hat. Und ab und zu ist es halt im Business so, dass man Leuten mal vor den Kopf stoßen muss, weil sie vielleicht einen Schritt zu weit gegangen sind, oder man öfter mal Nein sagen muss und die dann ihre eigenen Ziele nicht erreichen, oder, oder, oder, weil die eigene Zielvereinbarung der Abteilung sich kurzfristig geändert hat und deswegen man einem anderen Team nicht mehr zuarbeiten kann. Das bedeutet, da könnten natürlich auch Konflikte entstehen und deswegen finde ich das immer so ein bisschen schwierig, weil da kommt es nämlich dann wirklich auf die Professionalität der anderen Personen an, wie das denn entgegengenommen wird.

Wolfi Gassler (00:49:31 - 00:52:10)

Wobei, da muss ich auch sagen, da habe ich auch andere Erfahrungen gemacht. Also ich hatte einmal eine Person in meinem Team und der war eigentlich bekannt dafür, dass er extrem direkt war und immer seine Meinung gesagt hat und zwar ziemlich direkt ins Gesicht den anderen Leuten. Und das ist eigentlich sehr gut angekommen. Mir hat immer gewundert, dass die Leute dann gesagt haben, danke für dieses Feedback oder danke für die ehrliche Diskussion. Bin zwar anderer Meinung, aber es war eine gute Diskussion. Also diese Dinge sind eigentlich eher positiv wertgeschätzt worden. Ich weiß, viele Leute haben sich immer beschwert und haben das so als Problem. dargestellt, aber was ich so bei dieser Person auch gesehen habe, ist, dass das durchaus erwünscht ist in diesem Umfeld und gar nicht unbedingt immer negativ gesehen wurde. Wo ich dann natürlich recht gebe, ist, dass man das sehr direkt mit den Gehaltsdiskussionen verknüpft. Wobei, wenn es nur über den Lead geht, dass der Lead halt das als Input verwendet, glaube ich, ist das total legitim. Das Problem ist, sobald man wieder, wie ich schon zuerst erwähnt habe, ICs oder Personen miteinander vergleicht, company-wide womöglich. Der hat irgendwie 3,6 erreicht, der andere hat 4,6 erreicht in irgendeinem anderen Team. Das ist auch wie bei den Teammetriken nicht vergleichbar. Ich glaube, du kannst den Input nehmen, das war ja auch sehr viel textueller Input, also nicht nur eine klare Integerbewertung, sondern auch wirklich textueller Input, Feedback und das kann man sehr wohl dann verwenden meiner Meinung nach und man sieht auch wieder so einen Trend zum letzten Jahr, wo hat sich jemand verbessert vielleicht zum Beispiel, aber man kann meiner Meinung nach in einer Firma mit 1000 Mitarbeiter kann man nicht einen Ingenieur in Team A mit einem Ingenieur in Team B vergleichen. Das ist einfach unmöglich. Das ist eine andere Abteilung. Das sind andere Leads. Das sind andere Personen, die vielleicht anders miteinander umgehen. Manche gehen extrem streng um. Manche Ingenieure sind super picky, wenn es um bei der Evaluierung geht. Wenn ich das Klischee weiterspinnen darf, Marketingleute sind unter Umständen sehr positiv gestimmt immer. Also man kann das nicht automatisch immer eins zu eins vergleichen und das ist glaube ich der große Fehler. Wenn du aber als Lead das einfach als zusätzlichen Input verwendest, um dann zu rechtfertigen, okay diese Person hat einfach 10% Gehaltserhöhung verdient, Dann ist das glaube ich vollkommen legitim, aber du darfst es natürlich nicht vergleichen mit, hey da drüben in dieser Marketingabteilung hat es einen Ingenieur gegeben, der hat einen viel besseren Wert gehabt, daher bekommst du jetzt keine Gehaltserhöhung. Ich glaube das darf einfach nicht stattfinden und das ist das große Problem.

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

Naja eine gewisse vergleichbarkeit muss halt schon gegeben sein wenn das jetzt nicht auf den bewertungssystemen oder bewertungsskalen der 360 grad bewertung ist okay verstehe ich, weil das sind das ist eine ganz andere personengruppe aber speziell wenn es jetzt nennst du mal auf engineering levels kommt ja, Middle-Level-Engineer, Senior-Engineer, Staff-Engineer, und dann speziell auf die Anforderungen, ja, was muss ein Staff-Engineer, können, man muss Projekte leiten können, Kommunikation muss gut sein, man muss gute Architekturentscheidungen treffen, bla bla bla, was es da nicht noch alles gibt, und für alle Hörer, da können wir auch in den Shownotes mal eine super, Kompetenzmatrix von CircleCI, Verlinken die sehr sehr viele Attribute listet mit den jeweiligen Stati.

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

Es heißt nicht Stati, es heißt Statusse oder Status mit langem U. Stati.

Andy Grunwald (00:52:56 - 00:53:14)

Naja auf jeden Fall, also da gibt es halt schon die Vergleichbarkeit ja und ich denke die Firma, wenn die 1000 Mitarbeiter hat und dann ganz viele Engineers und auch Engineers im Marketingbereich und dann im Produktbereich und und und, dass da bezüglich der Anforderungen, was ein Staff Engineer, was ein Senior Engineer denn leisten sollte, das sollte schon vergleichbar sein.

Wolfi Gassler (00:53:14 - 00:54:21)

Aber da hast du dann ganz klar definierte, fast Metriken würde ich sagen, aber zumindest Kriterien. Was macht denn ein Senior, was macht denn eine Staff aus? Wenn du aber in dem 360-Grad-Feedback einfach fragst, okay, bist du mit der Leistung zufrieden oder wie war denn die Kommunikation von jemandem und du musst die Kommunikation einordnen zwischen 1 und 5. Dann ist es halt immer sehr subjektiv und vor allem in diesem Department zum Beispiel sehr subjektiv und du kannst es nicht mit einer anderen Abteilung in dieser Firma vergleichen, wo das vielleicht ganz anders ist. Wenn du aber klare Kriterien hast, okay, was heißt denn ein Projekt voranzutreiben und als ein Senior oder als ein Staff muss ich dementsprechend diese Aufgaben zum Beispiel übernehmen und ein Projekt vorantreiben. Dann habe ich natürlich klare Kriterien, die ich auch dementsprechend messen kann oder halt beurteilen kann danach und dann kann ich auch dementsprechend darauf was aufbauen. Also ich glaube, das ist viel viel besser, wenn ich solche Jobtitles habe und nicht alles natürlich auf so ein Feedback aufbaue, aber ich glaube, ich kann sehr wohl das Input verwenden, aber eben dann ist es schwer vergleichbar, wenn das nicht solche Kriterien sind, die eben firmenweit klar definiert sind, was denn sowas bedeutet.

Andy Grunwald (00:54:22 - 00:55:24)

Ja das ist zwar korrekt, aber ich hebe dann auch noch eine zweite Kritik am 360 Grad System und zwar folgendermaßen, jeder der mich bewertet im 360 Grad System, der müsste eigentlich ganz klar meine Job Description gelesen haben und auch die Anforderungen an meinen Engineering Level. Weil ich stelle andere Kommunikationserwartungen an einen Staff-Engineer und an einen Junior-Engineer. Und ich behaupte einfach mal, und das ist meine Erfahrung, die ich bisher aufs 360-Grad-System gemacht habe, dass viele Leute, die mich bewertet haben, nicht mein Jobprofil gelesen haben und auch nicht wissen, was von der Firma für meine Rolle und für meine Position erwartet wird, sondern dass sie mich als Mensch bewerten, was in diesem 360-Grad-System, was wohl möglich dann vielleicht sogar als Teil in die Gehaltsverhandlungen mit einfließt, dann falsch ist. Und da sind wir schon wieder bei dem Punkt, in irgendeiner Art und Weise oder zu einem gewissen Grad, kann man das dann doch vergleichen auch cross team weil wenn sofern es denn software engineers sind.

Wolfi Gassler (00:55:24 - 00:57:19)

Aber ich glaube da sprechen wir jetzt von von job titles und und da kann man es natürlich vergleichen wobei das ist ja auch der grund warum ich bei job titles und promotions, üblicherweise dann irgendein Komitee bilde, der sich das im Detail ansieht und sagt, okay, was hast du aktuell für Job Description, hast du dementsprechend die Kriterien erreicht und so weiter. Also die schauen sich das im Detail an. Hingegen bei einem 360-Grad-Feedback ist es wirklich so, dass ich einfach Feedback erhalten will und das primäre Ziel von einem 360-Grad-Feedback ist eben Feedback, dass ich einfach die Information bekomme, okay, ist meine Kommunikation gut, Was erwarten denn Leute von mir? Was könnt ihr denn besser machen? Was mache ich denn gut? Wo liegen meine Stärken? Wo erwarten sich Leute vielleicht irgendeine Verbesserung? Also das ist prima Feedback. Trotzdem kann ich das natürlich als Lead auch mit einbeziehen in meine Bewertung von jemandem. Oder wenn ich für ein Cross-Functional Team verantwortlich bin, Dann habe ich natürlich womöglich sehr wenig Einblick, weil ich gar nicht im täglichen Alltag mit dem Team zusammenarbeite. Und dann bin ich natürlich auf so Feedback und Bewertungen von außen auch mehr angewiesen und kann das natürlich mit einbeziehen. Aber gleichzeitig, wenn ich jetzt eine Promotion haben will und einen Jobtitle, dementsprechend gibt es halt ein Komitee, das das auch beurteilen kann und vielleicht in die Tiefe geht. Also das eine schließt das andere nicht aus und es sind glaube ich auch zwei unterschiedliche Ebenen. Aber wenn jetzt natürlich jemand extremes Problem hat in dem Team voranzukommen und das merkt ihr dann über dieses Feedback, dann kann ich das natürlich auch einfließen lassen in meine persönliche Entscheidung. Okay, wie schaut es zum Beispiel mit der Gehaltserhöhung aus? Vielleicht auch nur muss sich diese Person helfen in irgendeiner Form, dass die vielleicht in einem anderen Team besser aufgehoben ist oder irgendwie unterstützend eingreifen, dass zum Beispiel die Kommunikation besser wird oder halt auch die Personen informieren über die jeweiligen Probleme im Team. Da geht es halt mehr in Richtung Feedback.

Andy Grunwald (00:57:20 - 01:01:51)

Du hast aber auch eine gute Sache angesprochen, und zwar Jobtitles generell. Und Jobtitles, wenn ich das in Relation zu individuellen Zielen setze, dann ist es nun mal so, dass je höher der Jobtitle, Staff Engineer, Principal, Distinguished oder Google Fellow, wie du letztens gelernt hast, dass natürlich auch dann die individuellen Ziele deutlich schwieriger, deutlich härter und auch deutlich höhere Anforderungen an dich gesetzt werden. Also das bedeutet, schreit nicht immer nur nach dem höchsten title ich möchte immer den höchsten title haben weil der höchste title mit mit mit mit neuer mit neuem title kommt auch neue verantwortung neue requirements die ihr dann erfüllen müsst weil die erwartungen werden nicht niedriger und da solltet ihr euch auch mal fragen möchte ich denn überhaupt senior engineer werden möchte ich überhaupt staff oder principle werden oder distinguished Denn es gibt in vielen Firmen auch ein sogenanntes Termination Level, wo erwartet wird, dass eine ganze Menge Engineers einfach auf dem Level Senior Engineer stehen bleiben. Und das ist völlig in Ordnung. Ja, weil umso höher es geht, umso mehr Erwartungen werden an euch gesteckt und die Ziele, die individuellen Ziele werden genauer, werden schwieriger zu erreichen und erfordern deutlich mehr Fähigkeiten weit über euer Team hinaus. Jetzt haben wir natürlich ein bisschen über 360 Grad individuelle Ziele und wir sind ein bisschen zwischen den Team-Zielen und den individuellen Zielen hin und her gesprungen. Wir haben in der Intro gesagt, dass wir unter anderem auch mal klären, wo der Unterschied eigentlich zwischen Team-Zielen ist und der Frage, bewegt sich das Team in die richtige Richtung. Team-Ziele, kann man so erkennen, erreicht das Team wirklich das Ziel also wenn das team jetzt das ziel hat okay bringen den neuen microservice am start haben sie das am ende des sprints geschafft ja oder nein die frage bewegt sich das team in die richtige richtung ist eigentlich eine frage wie ist denn eigentlich der mit zu langzeit trend für dieses team in bezug auf ihre team gesundheit. Im Scrum-Umfeld hatte der Wolfgang bereits schon die Velocity genannt. Wird das Team besser, schneller? Kann das Team besser zusammenarbeiten? Ist die Abstimmung, läuft die smoother? Im DevOps-Umfeld oder eigentlich meines Erachtens nach im kompletten Software-Engineering-Umfeld gibt es noch sowas wie die sogenannten Dora-Metriken. Die finde ich recht interessant, um die Gesundheit oder die Performance oder die Handwerksfähigkeit, nenne ich sie auch gerne, zum Team zu messen. Und die Dora-Metriken kommen auch wieder aus dem DevOps- und SRE-Bereich. Meines Erachtens nach sind die aber gültig für jedes Software-Engineering-Team. Und zwar ist das eine Zusammenstellung aus vier Metriken. Aus der Deployment Frequenz, aus der Lead Time for Change. Die Deployment Frequenz ist, how often an organization successfully releases code to production. Also wie oft shippt ihr wirklich zur Produktion. Die Lead Time for Change sagt eigentlich aus, welche Zeit vergeht von einem Git-Commit zur Produktion. Dann die dritte Metrik ist die Change Failure Rate. Prozentuale Anzahl an Deployments, die einen Fehlerfall in Produktion erzeugen. Siehe auch letzte Episode über die Feuerwehr und Incident Management. Vielleicht ganz interessant in diesem Kontext. Und die vierte und letzte Metric ist die Time-to-Restore-Service. Wie lange eine Organisation braucht, um von diesem Fehler in Produktion sich wieder zu recovern. Und warum denke ich, dass diese vier Metriken eine tolle Sache sind, um den richtigen Trend eines Software-Engineering-Teams darzustellen? Weil das für mich sogenannte well-rounded Software-Engineers abdeckt. Nicht nur, dass man Code schreibt, sondern auch, dass man ein bisschen links und rechts guckt. Links bedeutet, man hat den Code deployed, dass man die ersten SQL-Abfragen abfeuern kann, um zu gucken, Wie verhält sich eigentlich meine Applikation in Produktion? Wie laufen eigentlich die Businessmetriken, die Key-KPIs und so weiter? Gehen noch Zahlungen durch meinen E-Commerce-Shop durch, ja oder nein? Das soll der Software-Engineer ebenfalls können und nicht der Business-Intelligence-Analyst. Auf der rechten Seite aber auch, wie verhalten sich denn die Performancemetriken? Wie deploye ich das denn? Und habe ich einen Bug deployed oder muss ich da jetzt einschreiten? Ja, so ein bisschen zur Infrastrukturkenntnis. Das ist so für mich so ein bisschen well-rounded Software-Engineers, links und rechts gucken. Und da könnten zum Beispiel die Dora-Metriken auch helfen, um die Frage zu beantworten, bewegt sich das Team mit oder langfristig in die richtige Richtung.

Wolfi Gassler (01:01:51 - 01:02:54)

Aber auch da wieder ganz, ganz, ganz wichtig, zusammen mit dem Team definieren, nicht irgendwie überstülpen diese Metriken oder aufdrücken. oder nur womöglich im Hintergrund ablesen, sondern wirklich gemeinsam zusammensitzen, sich überlegen, okay, wo wollen wir hin als Team, was wollen wir denn auch messen und das dann auch immer transparent durchführen. Und eigentlich müsste das Team ja auch immer auf diesen Zug aufspringen wollen, weil man sich ja auch dementsprechend verbessern will und üblicherweise im Team ja genau diese Probleme ansprechen will oder verbessern will. Weil wenn man zu langsam deployt oder zu selten, dann ist das ja auch meistens nicht im Sinne der Entwickler und die wollen das ja auch verbessern. Also solche Dinge einfach zu messen und zu verbessern, sollte auch normalerweise im Interesse des Teams sein und das ist normalerweise auch gar nicht schwer irgendwie mit dem Team das zu vereinbaren. Wenn dann alle im gleichen Boot sitzen, dann kann man dementsprechend auch, als falls wir keine gute Metapher haben, für alle im Boot sitzen und Gas geben. Die Segel hissen. Und losstarten.

Andy Grunwald (01:02:54 - 01:03:02)

Wenn man die Segel hisst, hat man hoffentlich Wind und das Team unten drunter muss eigentlich relativ wenig tun, weil der Wind ja viel tut.

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

Der ist ja noch besser.

Andy Grunwald (01:03:04 - 01:04:17)

Okay, gut. Dann, wenn wir so Speed aufnehmen bei nicht tun, finde ich super. Bitte ladet mich in euer Team ein. Das war jetzt aber jetzt ein wilder Ritt hier. Wir haben über individuelle Ziele gesprochen, wir haben über Teamziele gesprochen, wir haben OKRs mit Scrum Velocity in einem Satz genannt. Viele Leute werden uns, glaube ich, dafür schlagen. Ich glaube, worauf wir hinaus wollen und was wir eigentlich sagen wollen, ist, dass die Zieldefinition gar nicht so einfach ist und dass es nicht immer nur objektive, hart mathematische Metriken sein sollen, sondern dass Subjektivität vielleicht auch gar nicht falsch ist oder beziehungsweise ein gewisser Grad an Subjektivität. wovor wir aber auch ganz klassisch warnen ist sich nur auf das bauchgefühl zu verlassen ja also verschriftlich die ziele die ihr mit euren vorgesetzen besprecht check die kontinuierlich nach also fragt kontinuierlich nach und kontinuierlich kann jedes jeden monat jedes quartal sein, Jedes halbe Jahr ist ein bisschen lang, weil der Feedback-Cycle sollte da eher kurz gehalten werden, damit Kurskorrekturen vorgenommen werden können. Wichtig ist aber, dass ihr beide oder vielleicht sogar alle im Team dasselbe Verständnis von den selben Zielen habt und dann auch wirklich darüber reden könnt. Nicht irgendwie nach einem Jahr das schwarze Wunder erlebt und jeder denkt, höh, aber ich denke, ich war doch auf dem richtigen Track. Nee, warst du doch gar nicht, aber du doch auch nicht. Ja, und dann ist nämlich das Geschrei auf allen Seiten groß.

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

Wenn wir zurückkommen auf dieses Kommentar von Reddit, wer misst, misst, misst, also misst Müll. Das stimmt natürlich, es ist keine Metrik perfekt, aber man kann ja mit irgendwas beginnen und wenn das Team dahinter steht, einfach das mal transparent anzusehen, ohne dass es da dann gleich irgendwelche Auswirkungen gibt, wenn da irgendwas mit dieser Metrik in die eine oder andere Richtung geht, dann ist das normalerweise auch kein Problem und man kann es auch verbessern jederzeit. Aber wenn man halt gar nichts misst, dann weiß man halt auch überhaupt nichts und wenn der Server online ist, dann ist er halt online, aber man will ja trotzdem wissen, wie performant ist der Server, wie schnell wird die Webseite ausgeliefert und man misst es ja auch, auch wenn man jetzt nicht vielleicht alles messen kann und das nicht die perfekte Metrik ist, aber es ist halt eine Metrik, wo man mal weiß, spuckt der Server die Webseite in einer sinnvollen Zeit aus und so ist halt auch eine Metrik, ist mein Team, happy oder sind wie im Team happy oder wie schnell können wir deployen. Wir starten einfach mal mit irgendeiner Metrik, schauen uns das gemeinsam an, verbessern die Metrik. Wenn es nicht funktioniert, nehmen wir eine andere Metrik oder lassen es wieder. Aber man sollte auf jeden Fall etwas messen, um einfach damit zu beginnen und das Ganze zu verbessern und irgendwo ein Framework für sich zu finden, das funktioniert. Und dass einem als Team oder auch als Einzelperson irgendwo Mehrwert bietet, wo man sagt, okay, das funktioniert und das hilft mir einfach, ein bisschen subjektiver das Ganze zu sehen, als nur auf den Bauch zu hören. Und das sage ich, obwohl ich absolut kein Freund bin von Neujahresvorsätzen und das auch noch nie gemacht habe.

Andy Grunwald (01:05:53 - 01:07:27)

Im Internet sagen sie immer alle, Content ist King. Ich glaube, bei Zielen und Metriken gilt da eher, Kontext ist King. Von daher, hinterfragt jede Zahl, beziehungsweise seid euch 100% sicher, auf was ihr da eigentlich guckt, wenn ihr wirklich mathematische Metriken habt. Wenn es an eure eigenen Ziele geht, macht ruhig auch mal Vorschläge mit eurem Vorgesetzten, auch wenn die vielleicht nicht in die richtige Richtung gehen, die sich der Vorgesetzter denkt. Dann wird euer Vorgesetzter aber noch dankbar sein, dass ihr euch ein paar Gedanken gemacht habt. Die Ziele können euch natürlich aber auch bei der jährlichen Gehaltsvorhandlung helfen, dass man die als Grundlage nimmt, warum man jetzt zum Beispiel ein höheres Gehalt haben möchte, weil die Ziele, die ihr erreicht habt, vorher definiert werden und so. Ist halt eine gute Grundlage, heißt aber natürlich nicht, dass ihr alle immer 20% Gehaltserhöhung bekommt, nur weil ihr die definierten Ziele erreicht habt. Da spielen natürlich noch ganz andere Metriken eine Rolle. Eine Sache muss man aber auch sagen, es gibt natürlich auch Firmen, wo eine Zieldefinition zu dem Gehalt weniger eine Rolle spielt und das ist mit hoher Wahrscheinlichkeit in Firmen, die Tarifverträge haben. In der IT würde ich mal aus dem Bauch heraus schätzen, wer jetzt gerade nicht für die Bundesregierung arbeitet, ist das eher selten der Fall, gibt es aber immer mal wieder und ich glaube auch besonders bei sehr großen Konzernen ist das glaube ich auch noch so ein Ding. Da kann es natürlich sein, dass ihr natürlich auch außer tariflich bezahlt werdet und da wird die Zielsetzung natürlich dann schon wieder relevant mit Bonuszahlungen und Wolfgang, was hast du heute noch für ein Ziel?

Wolfi Gassler (01:07:27 - 01:07:28)

Schlafen.

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

Finde ich ein gutes Ziel.

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

Bringt meinen Happiness-Value nach oben, auf der Skala.

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

Mal so einen klassischen Brain-Reset, einfach mal 8 Stunden in der Horizontalen verbringen.

Wolfi Gassler (01:07:37 - 01:07:43)

Genau, Augenlid-Training, damit die nicht von selber wieder aufgehen. Das ist harte Arbeit.

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

Wilde Folge, ziemlich viele Themen gemixt. Wir hoffen, ihr hattet trotzdem ein bisschen Spaß und habt etwas mitgenommen. Ich denke, das Thema ist sehr umstritten. Und ich hoffe, ich krieg nicht noch einen zweiten Shitstorm via Twitter. Auf Reddit hatte ich den ja schon. Die Reddit-Diskussion verlinken wir natürlich auch in den Shownotes.

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

Ja, bist ein ziemliches Weichei, wenn du das schon als Shitstorm betrachtest. Das waren ja nur paar Reddit-Kommentare, die ganz nett waren noch dazu.

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

Es geht mir halt schon sehr nah besonders um dinge da wo ich sehr viel energie rein stecke und für die ich um die ich mich ja da wo ich mich darum kümmere möchte ich jetzt nicht sagen aber wo ich schon wert drauf lege ja auf meine profession das was ich hier tue ich tue das ja hier weil ich liebe und und das ist so ich verletze mich schon so ein bisschen aber, ich glaube ich glaube ich bin ich glaube ich bin eher ich bin eher ein bisschen bedrückt weil das keine objektive diskussion war sondern einfach da kommt halt einer von links und sagt das ist scheiße ohne irgendeinen grund und, dass ich dann immer den leuten aus der nase ziehen muss warum das denn scheiße ist das nervt mich so ein bisschen ja also ich pack da so viel energie rein und da kommt jemand der packt halt überhaupt keine energie rein das ist so, Und da frage ich mich schon wieder, warum habe ich diesen Reddit Post eigentlich erstellt? Wolfgang.

Wolfi Gassler (01:08:56 - 01:10:30)

Darum haben wir unser eigenes Podcast, da können wir einfach unseren Senf dazugeben, ohne dass irgendwer zuhören muss. Und wir haben aber auch die Chance, dass wir immer klären können, warum wir persönlich das auch teilweise für wichtig halten und wo die Vor- und Nachteile sind. Und dazu würden wir natürlich auch gerne eure Meinung hören. Habt ihr Ziele in eurer Firma? Habt ihr OKRs? Macht ihr irgendwie in eurem Team etwas dazu? Findet ihr das gut? Findet ihr das schlecht? Ist es irgendwie hilfreich? Ist es nicht hilfreich? Lasst uns das bitte wissen. Auf Twitter engkiosk oder auch bei E-Mail stetig at engineeringkiosk.dev. Würde uns natürlich freuen. Gerade über die kleineren Firmen in Deutschland, da hat man ja weniger Einsicht und da wissen wir auch weniger. Also gerade in dem Bereich wäre es super interessant, wenn wir da mal hören würden, was denn so üblich ist. Von den großen Firmen kann man das meistens am Tech-Blog oder sonst irgendwo lesen. Aber in den kleineren Firmen ist das ja etwas intransparenter, das Ganze leider. Und was uns natürlich am meisten freuen würde, wenn ihr unser Podcast teilen könntet. Auch über diese eigenartigen Sterne oder Bewertungen würden wir uns natürlich extrem freuen, wenn ihr das machen könntet. Gerade heute gesehen bei Apple haben wir erst ein Review. Sehr eigenartig. Auf Spotify haben wir ziemlich viele schon. Also an alle iPhone-User, wenn ihr da iTunes verwendet, bitte bewertet uns. Würde uns natürlich wirklich freuen, dass wir auch über diesen Weg ein bisschen Feedback bekommen. Und danke fürs Zuhören natürlich, dass ihr so lange durchgehalten habt und ich hoffe, wir hören uns dann nächste Woche wieder.

Andy Grunwald (01:10:30 - 01:10:47)

Ciao! Das war in der Tat eine echt lange Folge. Tschüss zusammen! Bei der Absage, da hakelt's aber, ne? Oder sind das die drei Bier?

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

Das sind die drei Bier wahrscheinlich, ja.